not-kennethreitz/convore.json
1
0
Fork 0
mirror of https://github.com/not-kennethreitz/convore.json.git synced 2026-06-18 06:01:00 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
master
convore.json/groups/comppythondevel/gmane/messages.json
T
Kenneth Reitz add958b068 shuffle things around a bit
2012-02-21 01:15:00 -05:00

1 line
903 KiB
JSON
Raw Permalink Blame History

[{"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302896185.5276661, "message": "19697 channel enabled", "group_id": 8954, "id": 704573}, {"user_id": 29156, "stars": [], "topic_id": 19697, "date_created": 1302896184.005995, "message": "!chan-enable", "group_id": 8954, "id": 704572}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302896212.9909351, "message": "rss-register <name> <url>", "group_id": 8954, "id": 704576}, {"user_id": 29156, "stars": [], "topic_id": 19697, "date_created": 1302896115.155452, "message": "!chan-enable", "group_id": 8954, "id": 704562}, {"user_id": 29156, "stars": [], "topic_id": 19697, "date_created": 1302896149.985975, "message": "!test", "group_id": 8954, "id": 704566}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302896247.835093, "message": "rss - http://rss.gmane.org/messages/excerpts/gmane.comp.python.devel bozo_exception: documented declared as us-ascii, but parsed as utf-8", "group_id": 8954, "id": 704579}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302896249.9408569, "message": "rss item added and started in channel 19697", "group_id": 8954, "id": 704580}, {"user_id": 29156, "stars": [], "topic_id": 19697, "date_created": 1302896211.293088, "message": "!rss-register http://rss.gmane.org/messages/excerpts/gmane.comp.python.devel", "group_id": 8954, "id": 704575}, {"user_id": 29156, "stars": [], "topic_id": 19697, "date_created": 1302896238.2956829, "message": "!rss-register devel http://rss.gmane.org/messages/excerpts/gmane.comp.python.devel", "group_id": 8954, "id": 704577}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302900801.254889, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3pvedk8", "group_id": 8954, "id": 705239}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302903506.0817039, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3jcwf4t || Re: Adding test case methods to TestCase subclasses - http://tinyurl.com/66wmabr || Re: Status of json (simplejson) in cpython - http://tinyurl.com/6893sj9", "group_id": 8954, "id": 705663}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302902602.6385379, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3dzn3tp", "group_id": 8954, "id": 705490}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302908004.3114469, "message": "[devel] - Re: Adding test case methods to TestCase subclasses - http://tinyurl.com/3vxbktk", "group_id": 8954, "id": 706510}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302909802.823581, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/44gdnj3 - Antoine Pitrou", "group_id": 8954, "id": 706880}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302908229.585043, "message": "author added to (devel,19697) itemslist", "group_id": 8954, "id": 706596}, {"user_id": 29156, "stars": [], "topic_id": 19697, "date_created": 1302909375.7870209, "message": "!rss-addmarkup devel all-lines 1", "group_id": 8954, "id": 706828}, {"user_id": 29156, "stars": [], "topic_id": 19697, "date_created": 1302908227.993582, "message": "!rss-additem devel author", "group_id": 8954, "id": 706595}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302908902.9870579, "message": "[devel] - Re: Adding test case methods to TestCase subclasses - http://tinyurl.com/3gaqhph - Ethan Furman", "group_id": 8954, "id": 706772}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302909377.5691819, "message": "all-lines added to (devel,19697) markuplist", "group_id": 8954, "id": 706829}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302911603.389118, "message": "[devel] - Re: python and super - http://tinyurl.com/3tsfl99 - Greg Ewing", "group_id": 8954, "id": 707071}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302911606.4280491, "message": "[devel] - Re: python and super - http://tinyurl.com/3wn6hhg - Greg Ewing", "group_id": 8954, "id": 707072}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302912503.5656481, "message": "[devel] - Re: python and super - http://tinyurl.com/3nb38ao - Greg Ewing", "group_id": 8954, "id": 707117}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302912506.847368, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3cwqfpy - Bob Ippolito", "group_id": 8954, "id": 707118}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302917908.3525989, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/4ymy5zv - Matt Billenstein", "group_id": 8954, "id": 707844}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302917903.2423999, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3zyrn55 - Matt Billenstein", "group_id": 8954, "id": 707842}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302926003.5751021, "message": "[devel] - Re: Adding test case methods to TestCase subclasses - http://tinyurl.com/3dgo5f6 - Ethan Furman", "group_id": 8954, "id": 708647}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302938603.0060041, "message": "[devel] - Re: http://docs.python.org/py3k/ pointing to 2.7 - http://tinyurl.com/6enbokg - Georg Brandl", "group_id": 8954, "id": 709738}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302947608.1397519, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/6e8brb5 - Vinay Sajip", "group_id": 8954, "id": 710031}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302954802.809865, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/6c78svm - Gustavo Narea", "group_id": 8954, "id": 710322}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302953903.770992, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3un6947 - Antoine Pitrou", "group_id": 8954, "id": 710294}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302963856.2244649, "message": "summary added to (devel,19697) itemslist", "group_id": 8954, "id": 710838}, {"user_id": 29156, "stars": [], "topic_id": 19697, "date_created": 1302963837.011055, "message": "!rss-scan devel", "group_id": 8954, "id": 710834}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302963838.792819, "message": "tokens of devel: summary_detail=21, links=21, author=21, title=21, updated=21, summary=21, title_detail=21, link=21, id=21", "group_id": 8954, "id": 710835}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302963804.7984979, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/4xxzny4 - Vinay Sajip", "group_id": 8954, "id": 710827}, {"user_id": 29156, "stars": [], "topic_id": 19697, "date_created": 1302963854.4362969, "message": "!rss-additem devel summary", "group_id": 8954, "id": 710837}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302964707.2532859, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/68o9vme - Nick Coghlan - <pre> Nope, we would have a situation where the security team were still attempting to coordinate with the release managers to cut new source releases and new binary releases, and not even releasing the source level patches that *will* allow many, many people to fix the problem on their own. I don't agree that such a situation would be better than the status quo (i.e. where both the problem and *how to fix it yourself* are public knowledge). The *exact* patches for all affected versions of Python are readily available by checking the changesets linked from http://bugs.python.org/issue11662#msg132517 When the list of people potentially using the software is \"anyone running Linux or Mac OS X and an awful lot of people running Windows or an embedded device\", private pre-announcements simply aren't a practical reality. Neither is \"stopping all other development\" when most of the core development team aren't on the security&lt; at &gt;python.org list and don't even know a security issue exists until it is announced publicly.</pre>", "group_id": 8954, "id": 710920}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302965607.4798801, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3ren5rf - Dirkjan Ochtman - <pre> maintains a simplejson for both 2.x and 3.x and that the current stdlib json is replaced by a (trivially changed) version of simplejson. Cheers, Dirkjan </pre>", "group_id": 8954, "id": 711030}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302964704.2559431, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/5wpwesa - Antoine Pitrou - <pre> Hello Vinay, On Sat, 16 Apr 2011 09:50:25 +0000 (UTC) Vinay Sajip &lt;vinay_sajip&lt; at &gt;yahoo.co.uk&gt; wrote: What you're proposing doesn't address the question of who is going to do the ongoing maintenance. Bob apparently isn't interested in maintaining stdlib code, and python-dev members aren't interested in maintaining simplejson (assuming it would be at all possible). Since both groups of people want to work on separate codebases, I don't see how sharing a single codebase would be possible. Regards Antoine. </pre>", "group_id": 8954, "id": 710919}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302966511.694891, "message": "[devel] - Python Language Summit at EuroPython: 19th June - http://tinyurl.com/6brnara - Michael Foord - <pre>Hello all, This is an invite to all core-python developers, and developers of alternative implementations, to attend the Python Language Summit at EuroPython. The summit will be on June 19th and EuroPython this year will be held at the beautiful city of Florence in Italy. http://ep2011.europython.eu/ If you are not a core-Python developer but would like to attend then please email me privately and I will let you know if spaces are available. If you are a core developer, or you have received a direct invitation, then please respond by private email to let me know if you are able to attend. A maybe is fine, you can always change your mind later. Attending for only part of the day is fine. We expect the summit to run from 10am - 4pm with appropriate breaks. Like previous language summits it is an opportunity to discuss topics like, Python 3 adoption, PEPs and changes for Python 3.3, the future of Python 2.7, documentation, package index, web site, etc. If you have topics you'd like to discu</pre>", "group_id": 8954, "id": 711222}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302966507.786272, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/6fe66nc - Antoine Pitrou - <pre>Le samedi 16 avril 2011 \u00e0 16:42 +0200, Dirkjan Ochtman a \u00e9crit : The thing is, we want to bring our own changes to the json module and its tests (and have already done so, although some have been backported to simplejson). Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 711220}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302967404.8388989, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/6kcyu58 - Xavier Morel - <pre> Depending on what those changes are, would it not be possible to apply the vast majority of them to simplejson itself? Furthermore, now that python uses Mercurial, it should be possible (or even easy) to use a versioned queue (via MQ) for the trivial adaptation, and the temporary alterations (things which will likely be merged back into simplejson but are not yet, stuff like that) should it not? </pre>", "group_id": 8954, "id": 711437}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302968306.2152779, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/44nczc9 - Antoine Pitrou - <pre>Le samedi 16 avril 2011 \u00e0 17:07 +0200, Xavier Morel a \u00e9crit : Sure, but the thing is, I don't *think* we are interested in backporting stuff to simplejson much more than Bob is interested in porting stuff to the json module. I've contributed a couple of patches myself after they were integrated to CPython (they are part of the performance improvements Bob is talking about), but that was exceptional. Backporting a patch to another project with a different directory structure, a slightly different code, etc. is tedious and not very rewarding for us Python core developers, while we could do other work on our limited free time. Also, some types of work would be tedious to backport, for example if we refactor the tests to test both the C and Python implementations. Perhaps, perhaps not. That would require someone motivated to put it in place, ensure that it doesn't get in the way, document it, etc. Honestly, I don't think maintaining a single stdlib module should require such an amount of logistics. Regar</pre>", "group_id": 8954, "id": 711612}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302971005.7457521, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3gy94ju - Stefan Behnel - <pre>Antoine Pitrou, 16.04.2011 16:19: Well, if that is not possible, then the CPython devs will have a hard time maintaining the json accelerator module in the long run. I quickly skipped through the github version in simplejson, and it truly is some complicated piece of code. Not in the sense that the code is ununderstandable, it's actually fairly straight forward string processing code, but it's so extremely optimised and tailored and has so much code duplicated for the bytes and unicode types (apparently following the copy+paste+adapt pattern) that it will be pretty hard to adapt to future changes of CPython, especially the upcoming PEP 393 implementation. Maintaining this is clearly no fun. Stefan </pre>", "group_id": 8954, "id": 711928}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302971010.637325, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3qn6ynw - Bob Ippolito - <pre> I've backported every useful patch (for 2.x) I noticed from json to simplejson. Would be happy to apply any that I missed if anyone can point these out. That's exactly why I am not interested in stdlib maintenance myself, I only use 2.x and that's frozen... so I can't maintain the version we would actually use. simplejson's test suite has tested both for quite some time. It certainly shouldn't, especially because neither of them changes very fast. -bob _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 711929}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302973768.331197, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/42wlb57 - Vinay Sajip - <pre>Hi Antoine, Antoine Pitrou &lt;solipsis &lt;at&gt; pitrou.net&gt; writes: I agree, my suggestion is orthogonal to the question of who maintains stdlib json. But if the json module is languishing in comparison to simplejson, then bringing the code bases closer together may be worthwhile. I've just been experimenting with the feasibility of getting simplejson running on Python 3.x, and at present I have it working in the sense of all tests passing on 3.2. Bob has said he isn't interested in Python 3, but he has said that \"if someone contributes the code to make simplejson work in Python 3 I'm willing to apply the patches run the tests against any future changes.\" I take this to mean that Bob is undertaking to keep the codebase working in both 2.x and 3.x in the future (though I'm sure he'll correct me if I've got it wrong). I'm also assuming Bob will be receptive to patches which are functional improvements added in stdlib json in 3.x, as his comments seem to indicate that this is the case. ISTM that for some lib</pre>", "group_id": 8954, "id": 712320}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302972865.825943, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3v4jz25 - Antoine Pitrou - <pre>On Sat, 16 Apr 2011 18:04:53 +0200 Stefan Behnel &lt;stefan_ml&lt; at &gt;behnel.de&gt; wrote: Well, first, the Python 3 version doesn't have the duplicated code since it doesn't accept bytes input. Second, it's not that complicated, and we have already brought improvements to it, meaning we know the code (\"we\" is at least Raymond and I). For example, see http://bugs.python.org/issue11856 for a pending patch. No more than any optimized piece of C code, but no less either. It's actually quite straightforward compared to other classes such as TextIOWrapper. PEP 393 will be a challenge for significant chunks of the interpreter and extension modules; it's not a json-specific issue. Regards Antoine. </pre>", "group_id": 8954, "id": 712232}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302973765.6123531, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3gsb4yj - Xavier Morel - <pre>I was mostly thinking it could work the other way around, really: simplejson seems to move slightly faster than the stdlib's json (though it's not a high-churn module either these days), so improvements (from Python and third parties alike) could be applied there first and then forward-ported, rather than the other way around. Sure, I can understand that, but wouldn't it be easier if the two versions were kept in better sync (mostly removing the \"slightly different code\" part)? I don't think mercurial queues really amount to logistic, it takes a bit of learning but fundamentally they're not much work, and make synchronization with upstream packages much easier. Which would (I believe) benefit both projects and \u2014 ultimately \u2014 language users by avoiding too extreme differences (on both API/features and performances). I'm thinking of a relation along the lines of Michael Foord's unittest2 (except maybe inverted, in that unittest2 is a backport of a next version's unittest) </pre>", "group_id": 8954, "id": 712319}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302975568.6806121, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3txzsaq - Antoine Pitrou - <pre>On Sat, 16 Apr 2011 16:47:49 +0000 (UTC) Vinay Sajip &lt;vinay_sajip&lt; at &gt;yahoo.co.uk&gt; wrote: No, that's not what I'm talking about. The json module *is* maintained (take a look at \"hg log\"), even though it may be less active than simplejson (but simplejson doesn't receive many changes either). I am talking about maintenance of the \"shared codebase\" you are talking about. Mandating a single codebase between two different languages (Python 2 and Python 3) and two different libraries (json and simplejson) comes at a high maintenance cost, and it's not obvious in your proposal who will bear that cost in the long run (you?). It is not a one-time cost, but an ongoing one. I can't speak for Bob, but this assumes the patches are not invasive and don't degrade performance. It's not obvious that will be the case. I think Bob tested with an outdated version of the stdlib json module (2.6 or 2.7, perhaps). In my latest measurements, the 3.2 json C module is as fast as the C simplejson module, the only difference being in</pre>", "group_id": 8954, "id": 712543}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302975565.1077011, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3j62ffm - Antoine Pitrou - <pre> You are assuming that we intend to backport all our json patches to simplejson. I can't speak for other people, but I'm personally not interested in doing that work (even if you find an \"easier\" scheme than the current one). Also, as Raymond said, it's not much of an issue if json and simplejson diverge. Bob said he had no interest in porting simplejson to 3.x, while we don't have any interest in making non-bugfix changes to 2.x json. As long as basic functionality is identical and compliance to the spec is ensured, I think most common uses are covered by both libraries. So, unless you manage to find a scheme where porting patches is almost zero-cost (for either us or Bob), I don't think it will happen. Well, the big difference here is that Michael maintains both the stdlib version and the standalone project, meaning he's committed to avoid any divergence between the two codebases. Regards Antoine. </pre>", "group_id": 8954, "id": 712542}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302980064.2327321, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/42aja5w - Martin v. L\u00f6wis - <pre> Right: *if* the module is languishing. But it's not. It just diverges. Does it actually need improvement? Regards, Martin </pre>", "group_id": 8954, "id": 712987}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302981865.061625, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3z48h6q - Vinay Sajip - <pre> I can't actually say, but I assume it keeps changing for the better - albeit slowly. I wasn't thinking of specific improvements, just the idea of continuous improvement in general... Regards, Vinay Sajip _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 713139}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302988166.8641469, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3mmrbuv - Brett Cannon - <pre>In the grand python-dev tradition of \"silence means acceptance\", I consider this PEP finalized and implicitly accepted. On Tue, Apr 12, 2011 at 15:07, Brett Cannon &lt;brett&lt; at &gt;python.org&gt; wrote: </pre>", "group_id": 8954, "id": 713489}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302989966.920018, "message": "[devel] - Re: PEP 399: Pure Python/C AcceleratorModuleCompatibiilty Requirements - http://tinyurl.com/3schzpb - Stefan Krah - <pre> I did not really see an answer to these concerns: http://mail.python.org/pipermail/python-dev/2011-April/110672.html http://mail.python.org/pipermail/python-dev/2011-April/110675.html Stefan Krah </pre>", "group_id": 8954, "id": 713575}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302989970.896311, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3nwhbgc - Martin v. L\u00f6wis - <pre>Am 16.04.2011 21:13, schrieb Vinay Sajip: Hmm. I cannot believe in the notion of \"continuous improvement\"; I'd guess that it is rather \"continuous change\". I can see three possible areas of improvment: 1. Bugs: if there are any, they should clearly be fixed. However, JSON is a simple format, so the implementation should be able to converge to something fairly correct quickly. 2. Performance: there is always room for performance improvements. However, I strongly recommend to not bother unless a severe bottleneck can be demonstrated. 3. API changes: people apparently want JSON to be more flexible wrt. Python types that are not directly supported in JSON. I'd rather take a conservative approach here, involving a lot of people before adding an API feature or even an incompatibility. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/opti</pre>", "group_id": 8954, "id": 713576}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302991768.741056, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3gyjnz2 - Vinay Sajip - <pre> I agree with all these points, though I was only thinking of Nos. 1 and 2. Over a longer timeframe, improvements may also come with changes in the spec (unlikely in the short and medium term, but you never know in the long term). Regards, Vinay Sajip _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 713670}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302990866.082675, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/4xo7qto - Brett Cannon - <pre> Antoine does seem sold on the 100% branch coverage requirement and views it as pointless. I disagree. =) As for the exception Stefan is saying may be granted, that is not in the PEP so I consider it unimportant. If we really feel the desire to grant an exception we can (since we can break any of our own rules that we collectively choose to), but I'm assuming we won't. Raymond thinks that have a testing requirement conflates having implementations match vs. APIs. Well, as we all know, the stdlib ends up having its implementation details relied upon constantly by people whether they mean to or not, so making sure that this is properly tested helps deal with this known reality. This is a damned-if-you-do-damned-if-you-don't situation. The first draft of this PEP said to be \"semantically equivalent w/ divergence where technically required\", but I got pushback from being too wishy-washy w/ lack of concrete details. So I introduce a concrete metric that some are accusing of being inaccurate for the goals o</pre>", "group_id": 8954, "id": 713623}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302991764.115032, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3aq9q44 - Antoine Pitrou - <pre>On Sat, 16 Apr 2011 14:45:52 -0700 Brett Cannon &lt;brett&lt; at &gt;python.org&gt; wrote: Not really. I think this is an unreasonable requirement because of the reasons I've stated in my previous messages :) If you rephrase it to remove the \"100% coverage\" requirement and replace it by something like \"comprehensive coverage\", then I'm ok. Hmm, what's the difference between \"the Python stdlib\" and \"CPython's stdlib\"? I'm also not sure how you would enforce that anyway. If it means using ctypes to interface with system C libraries, I'm -10 on it :) Regards Antoine. </pre>", "group_id": 8954, "id": 713669}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302993565.4068129, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3shhtf5 - Eric Snow - <pre> Sounds like Brett is talking about the distinction apparently discussed at the language summit (\"Standalone Standard Library\"): http://blog.python.org/2011/03/2011-language-summit-report.html -eric &lt;http://blog.python.org/2011/03/2011-language-summit-report.html&gt; </pre>", "group_id": 8954, "id": 713740}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302994465.208231, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3srb4bu - Michael Foord - <pre>Well, there was a 5x speedup demonstrated comparing simplejson to the standard library json module. That sound like *very* worth pursuing (and crazy not to pursue). I've had json serialisation be the bottleneck in web applications generating several megabytes of json for some requests. All the best, Michael Foord </pre>", "group_id": 8954, "id": 713776}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302995364.355381, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3oyeajb - Steven D'Aprano - <pre> How long does that silence have to last? I didn't notice a definition of what counts as \"100% branch coverage\". Apologies if I merely failed to notice it, but I think it should be explicitly defined. Presumably it means that any time you have an explicit branch (if...elif...else, try...except...else, for...else, etc.) you need a test that goes down each branch. But it isn't clear to me whether it's sufficient to test each branch in isolation, or whether you need to test all combinations. That is, if you have five branches, A or B, C or D, E or F, G or H, I or J, within a single code unit (function? something else?), is it sufficient to have at least one test that goes down each of A...J, or do you need to explicitly test each of: A-C-E-G-I A-C-E-G-J A-C-E-H-I A-C-E-H-J A-C-F-G-I ... B-D-F-H-J (10 tests versus 32 tests). If the latter, this could become impractical *very* fast. But if not, I don't see how we can claim 100% coverage when there are code paths which are never tested. At the ve</pre>", "group_id": 8954, "id": 713840}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302997165.8664351, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3h6bfyt - Matt Billenstein - <pre> Yes, that was 2.6.5 -- 3.2 native json is comparable to simplejson here taking about 330ms... m </pre>", "group_id": 8954, "id": 714009}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1302996265.490679, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3nckwdb - Antoine Pitrou - <pre>On Sat, 16 Apr 2011 23:48:45 +0100 Michael Foord &lt;fuzzyman&lt; at &gt;voidspace.org.uk&gt; wrote: No. </pre>", "group_id": 8954, "id": 713934}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303005267.1125131, "message": "[devel] - Re: python and super - http://tinyurl.com/3lylgyj - Steven D'Aprano - <pre>[...] [...] So you say. I don't have an an opinion on whether or not you are technically correct, but adding DWIM black-magic to super scares me. It scares me even if it were guaranteed to *only* apply to __init__, but if it applied to arbitrary methods, it frankly terrifies me. If it were limited to only apply to __init__, there would be a constant stream of requests that we loosen the restriction and \"make super just work\" for all methods, despite the dangers of DWIM code. </pre>", "group_id": 8954, "id": 714714}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303007067.704129, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3es7ohl - Raymond Hettinger - <pre> On Apr 16, 2011, at 2:45 PM, Brett Cannon wrote: I haven't seen any responses that said, yes this is a well thought-out proposal that will actually benefit any of the various implementations. Almost none of the concerns that have been raised has been addressed. Does the PEP only apply to purely algorithmic modules such as heapq or does it apply to anything written in C (like an xz compressor or for example)? Does testing every branch in a given implementation now guarantee every implementation detail or do we only promise the published API (historically, we've *always* done the latter)? Is there going to be any guidance on the commonly encountered semantic differences between C modules and their Python counterparts (thread-safety, argument handling, tracebacks, all possible exceptions, monkey-patchable pure python classes versus hard-wired C types etc)? The PEP seems to be predicated on a notion that anything written in C is bad and that all testing is good. AFAICT, it doesn't provide any practical </pre>", "group_id": 8954, "id": 714937}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303007965.381655, "message": "[devel] - Re: PEP 399: Pure Python/C AcceleratorModuleCompatibiilty Requirements - http://tinyurl.com/3lgrl8z - exarkun< at >twistedmatrix.com - <pre> The mostly commonly used definition of branch coverage is that each outcome of each individual branch is executed, not that all possible combinations of all branches in a unit are executed. I haven't heard anyone in this thread propose the latter, only the former. \"100% coverage\" by itself is certainly ambiguous. I suspect that everyone who has said \"branch coverage\" in this thread has intended the definition given above (and encourage anyone who meant something else to clarify their position). Jean-Paul </pre>", "group_id": 8954, "id": 715025}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303007968.5287941, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/3orfoba - Brian Curtin - <pre> Yep, and that's enough for me. If you have a vulnerable system, you can now patch it with an accepted fix. Hence why this blog exists and why this post was made... And I doubt they are all capable of patching their system or Maybe that's where the post fell short. Should I have added a section with an example of how to apply the patch to an example system like 2.6? I don't really think there's a \"situation\" here, and I fail to see how the development blog isn't one of the relevant channels. </pre>", "group_id": 8954, "id": 715026}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303008864.842871, "message": "[devel] - Re: python and super - http://tinyurl.com/3lknqab - Mark Janssen - <pre>On Thu, Apr 14, 2011 at 7:09 AM, Ricardo Kirkner &lt;ricardokirkner&lt; at &gt;gmail.com&gt; wrote: I get annoyed by this issue as well, in various forms. It seems like such a discussion would have been resolved by now in the multitude of OOP languages, but I have to say it is quite strange to me that there is no distinction made between IS-A relationship and HAS-A relationships with regard to the issue of Inheritence. Python, confusingly makes no syntactic distinction, and its semantic distinction (through MRO and programmer conventions) seems quite suboptimal and \"special-cased\". --No fault of anyone's, perhaps it is indeed an unresolved issue within Computer Science. It should be clear that IS-A inheritance is really trying to say (or should be) that the following set/class (of methods and attributes) is a *super-set* of its \"parent\" (--See how the OO lexicon is already confused and mixing metaphors?). In this case, manually calling super() is not only completely redundant but adds various confusions. With regard t</pre>", "group_id": 8954, "id": 715142}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303008868.2044489, "message": "[devel] - Re: python and super - http://tinyurl.com/3b6pg3z - Mark Janssen - <pre>Argh! Sorry list. I meant to discard the post that was just sent. Please accept my humblest apologies... Mark </pre>", "group_id": 8954, "id": 715143}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303018766.6785891, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/42dzd9n - R. David Murray - <pre> In that case it may well be that the silence is because the other implementations think the PEP is OK. They certainly voted in favor of the broad outline of it at the language summit. Perhaps representatives will speak up, or perhaps Brett will need to poll them proactively. Anything (new) written in C that can be also written in Python (and usually is first, to at least prototype it). If an XZ compressor is a wrapper around an external library, that would be a different story. As Brett said, people do come to depend on the details of the implementation. But IMO the PEP should be clarified to say that the tests we are talking about should be tests *of the published API*. That is, blackbox tests, not whitebox tests. Presumably we will need to develop such guidance. Decimal already has a Python implementation with a very comprehensive test suite (no, I don't know if it has 100% coverage). My understanding is that Stefan's code passes the Python test suite. So I'm not sure what the issue is, ther</pre>", "group_id": 8954, "id": 715637}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303022370.1738911, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3jzwgl5 - Martin v. L\u00f6wis - <pre> Can you kindly point to that demonstration? Hmm. I'd claim that the web application that needs to generate several megabytes of json for something should be redesigned. I also wonder whether the bottleneck was the *generation*, the transmission, or the processing of the data on the receiving end. Regards, Martin </pre>", "group_id": 8954, "id": 715789}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303022373.288429, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3cr5jvh - Terry Reedy - <pre> I think 100% *branch* coverage is barking up the wrong tree. Better to say comprehensive *api* coverage. Bugs on the tracker generally come from not having that. (I am not saying 'all' to allow for bugs that happen from weird interactions or corner cases in spite of what could reasonably be called comprehensive._ Right. </pre>", "group_id": 8954, "id": 715790}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303022367.011687, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/4yukjnh - Stefan Behnel - <pre>Matt Billenstein, 17.04.2011 00:47: From the POV of CPython 3.2, is \"native\" Python or C? Stefan </pre>", "group_id": 8954, "id": 715788}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303025969.4266779, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3kw3ejn - Stefan Behnel - <pre>Antoine Pitrou, 16.04.2011 19:27: Ok, but then, what's the purpose of having the old Python implementation in the stdlib? The other Python implementations certainly won't be happy with something that is way slower (algorithmically!) than the current version of the non-stdlib implementation. The fact that the CPython json maintainers are happy with the performance of the C implementation does not mean that the performance of the pure Python implementation can be ignored now. Note: I don't personally care about this question since Cython does not suffer from this issue anyway. This is just the general question about the relation of the C module and the Python module in the stdlib. Functional compatibility is not necessarily enough. Stefan </pre>", "group_id": 8954, "id": 715899}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303025972.7762661, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3rm4wh9 - Raymond Hettinger - <pre> Sounds like it was implicitly accepted even before it was written or any of the details were discussed. The big picture of \"let's do something to make life easier for other implementations\" is a worthy goal. What that something should be is still a bit ambiguous. +1 That's an excellent suggestion. Without that change, it seems like the PEP is overreaching. +1 That would be very helpful. Right now, the PEP doesn't address any of the commonly encountered differences. +1 better test coverage is always a good thing (IMO). Raymond </pre>", "group_id": 8954, "id": 715900}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303028666.2713521, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3syyue5 - Matt Billenstein - <pre> \"Native\" as in the version that ships with 3.2. And actually I think my test with 2.6.5 wasn't using the C extension for some reason so that 5.5s number isn't right -- a fresh build of 2.7.1 gives me a runtime of around 350ms. m </pre>", "group_id": 8954, "id": 716021}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303035868.901428, "message": "[devel] - Re: PEP 399: Pure Python/C AcceleratorModuleCompatibility Requirements - http://tinyurl.com/3j7f7vx - Stefan Krah - <pre> I'm not sure that I understand the duplication of effort: If there is a C module without a Python implementation in the stdlib, then the PyPy, Jython, and IronPython developers are free to cooperate and implement a single Python version. I would not consider this a duplication of effort. If, on the other hand, they choose to provide three individual implementations in C#, Java and (?), then that is their own choice and surely not the fault of the C module developer. By contrast, this PEP puts a great burden on the developers of new C modules. If this PEP is accepted, it is the C module developers who will have to do duplicate work. In my view, the PEP should have a clause that *active* participation of PyPy, Jython, and IronPython developers is expected if they want pure compatible Python versions to exist. Raymond has pointed out that the PEP seems to discourage C modules. This is one of the examples. Since implementing C modules takes a lot of time, I'd appreciate to know if they are just tolerate</pre>", "group_id": 8954, "id": 716233}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303038569.5465529, "message": "[devel] - Re: PEP 399: Pure Python/C AcceleratorModuleCompatibility Requirements - http://tinyurl.com/3rh9fgr - Stefan Krah - <pre> Could you explain why C code marginalizes the value of the code? Most people use CPython and they definitely want fast C modules. Also, many people actually use CPython specifically for its C-API. It has been suggested recently that wrapping the ICU library would be desirable for Python. Should all such projects be discouraged because it does not benefit PyPy, Jython and IronPython? I find these projects very interesting and wish them well, but IMO the reality is that CPython will continue to be the dominant player for at least another 10 years. Stefan Krah </pre>", "group_id": 8954, "id": 716343}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303036767.2422659, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3k63ggz - Vinay Sajip - <pre> I've now got my fork working on Python 3.2 with speedups. According to a non-scientific simple test: Python 2.7 ========== Python version: 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) [GCC 4.5.2] 11.21484375 KiB read Timing simplejson: 0.271898984909 Timing stdlib json: 0.338716030121 Python 3.2 ========== Python version: 3.2 (r32:88445, Mar 25 2011, 19:28:28) [GCC 4.5.2] 11.21484375 KiB read Timing simplejson: 0.3150200843811035 Timing stdlib json: 0.32146596908569336 Based on this test script: https://gist.github.com/923927 and the simplejson version here: https://github.com/vsajip/simplejson/ Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 716265}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303037666.539824, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/43aac38 - Vinay Sajip - <pre> Do we even need this complexity in Python 3.x? The speedup code for 2.x is taking different, parallel paths for str and unicode types, either of which might be legitimately passed into JSON APIs in 2.x code. However, in Python 3.x, ISTM we should not be passing in bytes to JSON APIs. So there'd be no equivalent parallel paths for bytes for 3.x speedup code to worry about. Anyway, some simple numbers posted by me elsewhere on this thread show simplejson to be only around 2% faster. Talk of a 5x speedup appears to be comparing non-speeded up vs. speeded up code, in which case the comparison isn't valid. Of course, people might find other workloads which show bigger disparity in performance, or might find something in my 3.x port of simplejson which invalidates my finding of a 2% difference. Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 716278}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303039469.105325, "message": "[devel] - Re: PEP 399: Pure Python/C AcceleratorModuleCompatibility Requirements - http://tinyurl.com/3qh27rx - Stefan Krah - <pre> test_decimal.py does not have 100% coverage yet. cdecimal passes the tests, but several decimal.py functions would have to perform type checking to get identical exception behavior. The current version of the joint unit tests is here: http://hg.python.org/features/cdecimal/file/b00f8fa70126/Lib/test/decimal_tests.py cdecimal specific behavior is guarded by HAVE_CDECIMAL, so it is possible to grep for the differences. As an aside, test_decimal.py constitutes at most 1% of the total tests. The important tests (mathematical correctness and conformance to the specification) are in two separate test suites, one of which runs tests against decimal.py and the other against decNumber. These tests can easily take a week to run, so they can't be part of the regression tests. Stefan Krah </pre>", "group_id": 8954, "id": 716362}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303041270.141835, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/3su7p9c - Antoine Pitrou - <pre>On Sat, 16 Apr 2011 21:32:48 -0500 Brian Curtin &lt;brian.curtin&lt; at &gt;gmail.com&gt; wrote: If we want to make official announcements (like releases or security warnings), I don't think the blog is appropriate. A separate announcement channel (mailing-list or newsgroup) would be better, where people can subscribe knowing they will only get a couple of e-mails a year. Regards Antoine. </pre>", "group_id": 8954, "id": 716474}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303041266.747586, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3blrxos - Antoine Pitrou - <pre>On Sun, 17 Apr 2011 09:21:32 +0200 Stefan Behnel &lt;stefan_ml&lt; at &gt;behnel.de&gt; wrote: Again, I don't think it's \"way slower\" since the code should be almost identical (simplejson hasn't changed much in the last year). That's assuming you measure performance on 3.2 or 3.3, not something older. Besides, the primary selling point of the stdlib implementation is that... it's the stdlib implementation. You have a json serializer/deserializer by default without having to install any third-party package. For most people that's probably sufficient; people with specific needs *may* benefit from installing simplejson. Also, the pure Python paths are still used if you customize some parameters (I don't remember which ones exactly, you could take a look at e.g. Lib/json/encoder.py if you are interested). Regards Antoine. </pre>", "group_id": 8954, "id": 716472}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303043968.0096941, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/3lwbczh - Fred Drake - <pre> Sounds like python-announce to me, with a matching entry on the front of www.python.org. -Fred </pre>", "group_id": 8954, "id": 716652}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303045767.2536709, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/4xolcnu - Antoine Pitrou - <pre>On Sun, 17 Apr 2011 01:32:15 -0400 \"R. David Murray\" &lt;rdmurray&lt; at &gt;bitdance.com&gt; wrote: If that's a recommendation then it's ok, although I would still prefer we don't advocate such metrics. It's too easy for some people to get obsessed about numeric measurements of \"quality\", leading them to dubious workarounds and tricks (e.g. when using style-checking tools \u00e0 la pylint). Regards Antoine. </pre>", "group_id": 8954, "id": 716699}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303048475.0057709, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3vy5pkt - Stefan Behnel - <pre>Vinay Sajip, 17.04.2011 12:33: Is this using the C accelerated version in both cases? What about the pure Python versions? Could you provide numbers for both? Stefan </pre>", "group_id": 8954, "id": 716792}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303047567.2102921, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/442yjb9 - Jesse Noller - <pre> And whose responsibility is it to email yet another mythical list? The person posting the fix? The person who found and filed the CVE? The release manager? Brian *helped* us by raising awareness of the issue: At least now there's a chance that one or more of the OS vendors *saw* that this was an issue that was fixed. </pre>", "group_id": 8954, "id": 716760}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303048471.672014, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/42l8dv3 - Antoine Pitrou - <pre>Le dimanche 17 avril 2011 \u00e0 09:30 -0400, Jesse Noller a \u00e9crit : Well, whose responsibility is it to make blog posts about security issues? If you can answer this question then the other question shouldn't be any more difficult to answer ;) I don't think the people who may be interested in security announcements want to monitor a generic development blog, since Python is far from the only piece of software they rely on. /I/ certainly wouldn't want to. Also, I think Gustavo's whole point is that if we don't have a well-defined, deterministic procedure for security announcements and releases, then it's just as though we didn't care about security at all. Saying \"look, we mentioned this one on our development blog\" isn't really reassuring for the target group of people. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-pytho</pre>", "group_id": 8954, "id": 716790}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303049366.540416, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/5syamfy - Antoine Pitrou - <pre>On Sun, 17 Apr 2011 08:30:33 -0400 Fred Drake &lt;fdrake&lt; at &gt;acm.org&gt; wrote: Looking at python-announce, it can receive an arbitrary amount of announcements from third-party projects, or even call for papers for random conferences. It's probably easy to (dis)miss an important message in all the churn. Regards Antoine. </pre>", "group_id": 8954, "id": 716836}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303049368.80019, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/68hvfra - Paul Moore - <pre> One thing I'm definitely uncomfortable about is expressing the requirement in a way that depends on a non-stdlib module (coverage.py). Should coverage.py be added to the stdlib if we're going to take test coverage as a measure? Hmm, maybe it goes without saying, but does coverage.py work on Jython, IronPython, etc? (A quick google search actually indicates that there might be some issues still to be resolved...) Paul. </pre>", "group_id": 8954, "id": 716837}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303049370.8469889, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/6893nyx - Jesse Noller - <pre> I'm not arguing against us having a well defined, deterministic procedure! We need one, for sure - I'm just defending Brian's actions as perfectly rational and reasonable. Without his post, that CVE would have been published, publicly available on other sites (CVE tracking sites, and hence on the radar for people looking to exploit it), and no one would be the wiser. At least it got *some* attention this way. Is it the right thing to do moving forward? Probably not - but do we have the people/person willing to head up defining the policy and procedure, and do we have the needed contacts in the OS vendors/3rd party distributors to notify them rapidly in the case of fixing something like this? A lag of several weeks from fixing a security issue to a source level release from us that OS vendors can run with is too slow honestly. jesse </pre>", "group_id": 8954, "id": 716838}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303049372.77846, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/67ktdu9 - Jacob Kaplan-Moss - <pre> Just to fill in a bit of missing detail about our process since the doc doesn't perfectly describe what happens: * Our pre-announce list is *really* short. It consists of release managers for various distributions that distribute packaged versions of Django -- Ubuntu, RedHat, and the like. Yes it's a bit of bookkeeping, but we feel it's really important to our users: not everyone installs the Django package *we* put out, so we think it's important to coordinate security releases with downstream distributors so that users get a fixed version of Django regardless of how they're installing Django in the first place. * We don't really halt all development. I don't know why that's in there, except maybe that it pre-dates there being more than a couple-three committers. The point is just that we treat the security issue as our most important issue at the moment and fix it as quickly as possible. I don't really have a point here as it pertains to python-dev, but I thought it's important to clarify what Django *</pre>", "group_id": 8954, "id": 716839}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303055667.812324, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibility Requirements - http://tinyurl.com/3tjo47s - R. David Murray - <pre> Yes, that's exactly what we are trying to encourage. If the Python standard library is seen as common property of all Python implementations, then this is *much* more likely to happen. Right. This is true only because of the current \"blessed\" position of CPython in the Python ecosystem. If a separate Python stdlib is the common property of all Python implementations, then the same double burden would apply to, say, an IronPython developer writing a module in C# and wanting it included in the stdlib. I believe they are welcome, but that they are a CPython implementation detail, and the PEP is trying to make that distinction clear. One can also imagine a C module getting accepted to the stdblib because everybody agrees that (a) it can't be implemented in Python and (b) every Python implementation should support it. In that case only the test suite will be part of the implementation-independent part of the stdlib. I do think that such modules (and we already have several) should have a higher bar t</pre>", "group_id": 8954, "id": 717275}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303052969.040715, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/6a9pd8b - R. David Murray - <pre> That fact that Brian helped publicize it is not really relevant to Antoine's point. The *obvious* answer to your question about whose responsibility it is is: *the security team*. Brian's blog post would then have been much more like he envisioned it when he wrote it, a peek inside the process, rather than appearing to be the primary announcement as many seem to be perceiving it. That's how distributions, at least, handle this. There's a mailing list for security related announcements on which only the \"security officer\" or \"security team\" posts announcements, and security related announcements *only*. Then then the people responsible for security in any context (a distribution, a security manager for a company, J Random User) can subscribe to it and get *only* security announcements. That allows them to easily prioritize those announcements on receipt. Python should have such a mailing list. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 716987}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303052971.699573, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/5v57mok - Nick Coghlan - <pre> I'd rather have Red Hat and Canonical reps *on* the security&lt; at &gt;python.org list rather than a separate pre-announce list. That makes a lot more sense. I'd personally like to see a couple of adjustments to http://www.python.org/news/security/: 1. Identify a specific point-of-contact for the security list, for security-related questions that aren't actually security issues (e.g. how would a core developer go about asking to join the PSRT?) 2. Specifically state on the security page where vulnerabilities and fixes will be announced and the information those announcements will contain (as a reference for the PSRT when responding to an issue, and also to inform others of the expected procedure) The current page does a decent job of describing how to report a security issue, but doesn't describe anything beyond that. Cheers, Nick. </pre>", "group_id": 8954, "id": 716988}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303054766.8584051, "message": "[devel] - Re: python and super - http://tinyurl.com/5wtyvzu - Michael Foord - <pre> Well, super is already pretty \"magic\" and what I'm suggesting is no more magic than currently exists. I'm suggesting (but it won't happen - no-one else is in favour :-) *extending* the existing algorithm in a predictable and understandable way. The main advantage is that it allows methods to express \"don't call my parent class methods but don't halt the chain of calling\", which is currently not possible (so in that context I don't really know what you mean by \"DWIM black-magic\"). I'm *not* suggesting full auto calling. All the best, Michael </pre>", "group_id": 8954, "id": 717179}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303055671.081898, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3rmo6yv - R. David Murray - <pre> No, just the principle that something along these lines would be good. Any final decision of course requires the actual PEP to look at, which was also acknowledged at the summit. My point was that lack of comment from the other implementations *might* indicate they liked how the PEP turned out. But it might also mean they aren't paying attention, which would be bad... As I said in another email, I think the something that should be done is to put CPython on equal footing implementation-pain-wise and lets-make-this-work-wise with the other implementations. The end result will be better test coverage and clearer APIs in the stdlib. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 717278}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303057468.6514089, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/4yg63jy - Michael Foord - <pre>Yes. </pre>", "group_id": 8954, "id": 717415}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303057472.836344, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3d4g3et - Michael Foord - <pre>Hmm... according to a later email in this thread it is 350ms vs 250ms for an 11kb sample. That's a nice speedup but not a 5x one. Bob Ippolito did claim that simplejson was faster than json for real world workloads and I see no reason not to believe him. :-) It was displaying (including sorting) large amounts of information in tables through a web ui. The customer wanted all the information available in the ables, so all the data needed to be sent. We did filtering on the server side where possible to minimize the data sent, but it was ~10mb for many of the queries. We also cached the data on the client and only updated as needed. We could have \"redesigned\" the customer requirements I suppose... The bottleneck was generation. I benchmarked and optimised. (We were using simplejson but I trimmed down the data sent to the absolute minimum needed by the client app rather than merely serialising all the source data from the django model objects - I didn't optimise within simplejson itself...) Pro</pre>", "group_id": 8954, "id": 717417}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303058370.2947879, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3behnkq - Michael Foord - <pre> Well, maybe not. :-) </pre>", "group_id": 8954, "id": 717528}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303061068.0497701, "message": "[devel] - Re: PEP 399: Pure Python/C AcceleratorModuleCompatibility Requirements - http://tinyurl.com/3fgjyuu - Stefan Krah - <pre>[snip a lot] Thank you, this cleared up many things. The technical reason is that the context is a speed critical data structure, so I'm doing some tricks to emulate the context flags and traps dictionaries. But I actually prefer that the context is locked down. The context settings are absolutely crucial for the correctness of the result. Here is a mistake that I've made multiple times while trying something out with decimal.py: # Meaning c.Emax and c.Emin: # The operation silently uses the unchanged context: Decimal('4.995010465071922539720163822E+30102') cdecimal raises an AttributeError: Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt; AttributeError: 'cdecimal.Context' object has no attribute 'emax' So, if one of the goals of the PEP is to clean up various APIs, I'm all for it. My concern is though that the process will be very slow due to lack of time and general reluctance to change APIs. And this is where I see a potentially negative effect: Is it worth to stall d</pre>", "group_id": 8954, "id": 717668}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303063768.01015, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibility Requirements - http://tinyurl.com/3ff3gl9 - R. David Murray - <pre> Heh. Keep in mind that this is my viewpoint. I *think* Brett agrees with me. I'm sure he'll speak up if he doesn't. [snip] Thanks, your explanation seems to me to make a good case for making the decimal.py implementation less permissive. Well, the general reluctance to change APIs is certainly an issue. But since you are advocating cdecimal changing the API *anyway*, if it is going to go in to CPython this would have to be addressed regardless. So I don't see that the PEP affects the speed of that part of the process from CPython's point of view. In my vision it wouldn't stall development in any place it shouldn't be stalled by our normal backward compatibility rules. It would be a bug in the bug tracker saying \"the API of module X has some undesirable characteristics that get in the way of implementing accelerators, can we change it?\" Again, I don't see this as changing what the current procedure should be anyway, just clarifying it and making it more likely that we will *notice* the changes an</pre>", "group_id": 8954, "id": 717889}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303065569.803849, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/6bdvmuy - Stephen J. Turnbull - <pre> &gt; Well, that's a long shot. I doubt the people/organizations affected are &gt; all aware. That's really not Python's responsibility. That's theirs. Caveats: Python should have a single place where security patches are announced *first*, before developer blogs and the like. Python's documentation should make it clear at the most important entry points that the appropriate place to report possible security issues is security&lt; at &gt;python.org, not the tracker. In particular, the tracker's top page (the one you get from http://bugs.python.org/) should make that clear. Ironically, Brian's blog entry outlines a plausible security policy, but a quick Google didn't find it elsewhere on site:python.org. Oops, a different search did find it -- under News/Security Advisories. The tracker suggestion submitted as http://psf.upfronthosting.co.za/roundup/meta/issue393. &gt; And I doubt they are all capable of patching their system or &gt; getting a patched Python from a trusted party. Then they shouldn't be running Python </pre>", "group_id": 8954, "id": 718012}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303067374.9031279, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/68cb2ml - Antoine Pitrou - <pre>On Sun, 17 Apr 2011 17:09:17 +0100 Michael Foord &lt;fuzzyman&lt; at &gt;voidspace.org.uk&gt; wrote: That speedup is actually because of a slowdown in py3k, which should be solved with http://bugs.python.org/issue11856 Regards Antoine. </pre>", "group_id": 8954, "id": 718085}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303067368.1220231, "message": "[devel] - Re: Releases for recent security vulnerability - http://tinyurl.com/5wexzsh - Stephen J. Turnbull - <pre> &gt; I'd personally like to see a couple of adjustments to &gt; http://www.python.org/news/security/: For another thing, it needs to be more discoverable. For yet another thing, it has two ancient entries on it. Surely there are more than that? </pre>", "group_id": 8954, "id": 718083}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303067371.9152329, "message": "[devel] - Re: python and super - http://tinyurl.com/6a87z8p - Nikolay Zakharov - <pre>16.04.2011 03:38, Greg Ewing \u043f\u0438\u0448\u0435\u0442: Michael's words are not about *auto-calling* but about *stopping prevention* of parent's method call by a class that unrelated to such parent. In the example above A is such a stopper that prevents calling of B.__init__ and B is a stopper for calling A.__init__ but A and B are completely unrelated to each other. object.__init__ would not be called anyway (in this example) but the point is that nobody (at least among Michael and myself) going to *auto-call* object.__init__ with some automagically picked arguments. -- Nikolay Zakharov _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 718084}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303071868.8519509, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/43cn5hz - Martin v. L\u00f6wis - <pre> Thanks a lot for doing this research, by the way. Regards, Martin </pre>", "group_id": 8954, "id": 718415}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303078174.8831329, "message": "[devel] - [ANN] Python 2.5.6 Release Candidate 1 - http://tinyurl.com/3suyt3k - Martin v. L\u00f6wis - <pre>On behalf of the Python development team and the Python community, I'm happy to announce the release candidate 1 of Python 2.5.6. This is a source-only release that only includes security fixes. The last full bug-fix release of Python 2.5 was Python 2.5.4. Users are encouraged to upgrade to the latest release of Python 2.7 (which is 2.7.1 at this point). This releases fixes issues with the urllib, urllib2, SimpleHTTPServer, and audiop modules. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of bugs fixed. For more information on Python 2.5.6, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.5.6 Highlights of the previous major Python releases are available from the Python 2.5 page, at http://www.python.org/2.5/highlights.html Enjoy this release, Martin Martin v. Loewis martin&lt; at &gt;v.loewis.de Python Release Manager (on behalf of the entire python-dev team) </pre>", "group_id": 8954, "id": 718918}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303080876.027312, "message": "[devel] - Re: python and super - http://tinyurl.com/3rcsq5d - Greg Ewing - <pre> I'm not sure what you mean by that. Inheritance is (or should be) used only for is-a relationships. Misusing it for has-a relationships leads to problems. Yes, it does, as long as you use composition instead of inheritance for has-a relationships. </pre>", "group_id": 8954, "id": 719411}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303086270.5253761, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3tdd3un - Vinay Sajip - <pre> What I posted earlier were C-accelerated timings. I'm not sure exactly how to turn off the speedups for stdlib json. With some assumptions, as listed in this script: https://gist.github.com/924626 I get timings like this: Python version: 3.2 (r32:88445, Mar 25 2011, 19:28:28) [GCC 4.5.2] 11.21484375 KiB read Timing simplejson (with speedups): 0.31562185287475586 Timing stdlib json (with speedups): 0.31923389434814453 Timing simplejson (without speedups): 4.586531162261963 Timing stdlib json (without speedups): 2.5293829441070557 It's quite likely that I've failed to turn off the stdlib json speedups (though I attempted to turn them off for both encoding and decoding), which would explain the big disparity in the non-speedup case. Perhaps someone with more familiarity with stdlib json speedup internals could take a look to see what I've missed? I perhaps can't see the forest for the trees. Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 719883}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303096171.71016, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibility Requirements - http://tinyurl.com/448wjgv - Nick Coghlan - <pre> Indeed. Since the current handling of Context in decimal.py violates \"Errors should never pass silently, unless explicitly silenced\", I would personally support a proposal to lock down its __setattr__ to a predefined set of attributes, have its __delattr__ always raise an exception, and introduce a parent ABC that is used for an isinstance() check in setcontext(). (The ABC could include an attribute check, so only objects that failed to provide all the appropriate methods and attributes would raise the TypeError). Cheers, Nick. </pre>", "group_id": 8954, "id": 721130}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303097070.7436271, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3jpobfh - Nick Coghlan - <pre> Consider trying: import sys sys.modules[\"_json\"] = 0 # Block the C extension import json in a fresh interpreter. (This is the same dance test.support.import_fresh_module() uses internally to get unaccelerated modules for testing purposes) Cheers, Nick. </pre>", "group_id": 8954, "id": 721399}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303097075.0975909, "message": "[devel] - Re: [ANN] Python 2.5.6 Release Candidate 1 - http://tinyurl.com/42vpvqr - Leo Jay - <pre>Hi, I think the release date of 2.5.6c1 should be 17-Apr-2011, instead of 17-Apr-2010 http://www.python.org/download/releases/2.5.6/NEWS.txt On Mon, Apr 18, 2011 at 5:57 AM, \"Martin v. L\u00f6wis\" &lt;martin&lt; at &gt;v.loewis.de&gt; wrote: -- Best Regards, Leo Jay _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 721400}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303105171.479167, "message": "[devel] - Re: [ANN] Python 2.5.6 Release Candidate 1 - http://tinyurl.com/43nxacu - Martin v. L\u00f6wis - <pre> Thanks, fixed. Martin </pre>", "group_id": 8954, "id": 722750}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303110571.4326479, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3n56mrs - Maciej Fijalkowski - <pre>On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger &lt;raymond.hettinger&lt; at &gt;gmail.com&gt; wrote: My understanding is it does apply only to stuff that does not wrap an external library. Sounds about right We try very hard to optimize for usual python idioms. They're very often much better than specific cpython hacks. Unless you mean things like rebiding a global into default a \"pythonic idiom\". We had to rewrite places in standard library which are precisely not very pythonic. You're wrong. We didn't even write _heapq and _bisect. That's actually a lot of work and PyPy's team is quite small *and* it has to do all the other stuff as well. heapq and bisect were never a problem (except one case in twisted), but other stuff where C version diverged from Python version were a problem. Hell, we even wrote cPickle which wraps pickle and provides correct interface! This is kind of things we would rather not spend time on (and yes, it is time consuming). _______________________________________________ Python-Dev mailin</pre>", "group_id": 8954, "id": 723785}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303116871.2578831, "message": "[devel] - Re: Status of json (simplejson) in cpython - http://tinyurl.com/3zm3ktj - Vinay Sajip - <pre> Thanks for the tip. The revised script at https://gist.github.com/924626 shows more believable numbers vis-\u00e0-vis the no-speedups case. Interestingly this morning, stdlib json wins in both cases, though undoubtedly YMMV. --------------------------------------------------------------------------- (jst3)vinay&lt; at &gt;eta-natty:~/projects/scratch$ python time_json.py --no-speedups Python version: 3.2 (r32:88445, Mar 25 2011, 19:28:28) [GCC 4.5.2] 11.21484375 KiB read Timing simplejson (without speedups): 4.585145950317383 Timing stdlib json (without speedups): 3.9949100017547607 (jst3)vinay&lt; at &gt;eta-natty:~/projects/scratch$ python time_json.py Python version: 3.2 (r32:88445, Mar 25 2011, 19:28:28) [GCC 4.5.2] 11.21484375 KiB read Timing simplejson (with speedups): 0.3202629089355469 Timing stdlib json (with speedups): 0.3200039863586426 --------------------------------------------------------------------------- Regards, Vinay Sajip _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;p</pre>", "group_id": 8954, "id": 724233}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303116875.4073629, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3qkg8er - Paul Moore - <pre> My understanding is that this is most people's understanding, so it should be explicitly documented in the PEP. It would also be worth asking: are there any other reasons for using C code beyond wrapping external libraries and accelerating code that could equally be written in Python? I can't think of any, myself, but OTOH I wonder if the *degree* of acceleration is also relevant - some things (compression algorithms, for example) just can't realistically be coded in Python (CPython, at least). I disagree. To me, a Python without libraries such as os, zlib, zipfile, threading, etc wouldn't be much use (except in specialised circumstances). OK, that means that alternative implementations need to do extra work to implement equivalents in their own low-level language, but so be it (sorry!) This PEP has a flavour to me of the old \"100% pure Java\" ideal, where Java coders expected everything to be reimplemented in Java, avoiding any native code. I didn't like the idea then, and I don't have much more love f</pre>", "group_id": 8954, "id": 724234}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303117770.9918649, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3nhx6u3 - Antoine Pitrou - <pre>On Mon, 18 Apr 2011 09:36:20 +0100 Paul Moore &lt;p.f.moore&lt; at &gt;gmail.com&gt; wrote: faulthandler is an example. Very low-level tinkering with threads, signal handlers and possibly corrupt memory simply can't be done in Python. Regards Antoine. </pre>", "group_id": 8954, "id": 724340}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303130372.904953, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3hnny96 - R. David Murray - <pre> I think Maciej left out an \"only\" in that sentence. If you say \"only C\", then the sentence makes sense, even when applied to modules that *can* only be written in C (for CPython). That is, not having a Python version is bad. Necessary in many cases (or not worth the cost, for external library wrappers), but wouldn't it be nicer if it wasn't necessary? The Pythonic ideal contains quite a bit of pragmatism, so yes, that is an exaggeration of the goals of the PEP, certainly. (Although pypy may do it anyway, for pragmatic reasons :) That might indeed be a useful exercise, especially since other implementations (or even perhaps CPython developers) may want to contribute Python-only versions and/or tests for things that would have been affected by the PEP. I don't have time to do it right now, but if I can pry any time loose I'll have it near the top of my list. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 725687}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303132177.2845891, "message": "[devel] - Python 2.6.7 - http://tinyurl.com/3lqehr6 - Barry Warsaw - <pre>With Martin getting ready to release 2.5.6, I think it's time to prepare a 2.6.7 source-only security release. I'll work my way through the NEWS file and recent commits, but if there is anything that you know is missing from the 2.6 branch, please let me know. It would be especially helpful if there were bugs for any such issues. Cheers, -Barry </pre>", "group_id": 8954, "id": 726012}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303141172.816777, "message": "[devel] - Post from Mark Summerfield - http://tinyurl.com/43ho88z - skip< at >pobox.com - <pre>Mark Summerfield responded to Martin's python-announce post. Rather than approving it I rejected it and forwarded it here. (I suppose I could have forwarded it directly to Martin, but that would have required that I recall or look up his email address...) Skip </pre>", "group_id": 8954, "id": 727425}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303144774.825253, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3n5aje8 - \u00c9ric Araujo - <pre> Hi, If I understand correctly, you\u2019ve made internal changes preserving the official API of the modules. Have you reported those cases to bugs.python.org? I\u2019m sure we\u2019d be glad to incorporate those changes into the stdlib, possibly even in the stable branches if their rationale is strong enough. Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 727889}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303144779.1687291, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/697foyk - \u00c9ric Araujo - <pre> Hi, That\u2019s called test.support.cpython_only (see also test.support.check_impl_detail). You\u2019re welcome. Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 727890}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303148371.2977321, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/68zsbcv - Raymond Hettinger - <pre> On Apr 18, 2011, at 10:11 AM, Maciej Fijalkowski wrote: Do you have any thoughts on the problem with the concrete C API not working well with subclasses of builtin types? I'm thinking that the PEP should specifically ban the practice of using the concrete api unless it is known for sure that an object is an exact type match. It is okay to write PyList_New() followed by PyList_SetItem() but not okay to use PyList_SetItem() on a user supplied argument that is known to be a subclass of list. A fast path can be provided for an exact path, but there would also need to a be a slower path that either converts the object to an exact list or that uses PyObject_SetItem(). In the discussions about this topic, there doesn't seem to be any technical solutions; instead, it will take a social solution such as a PEP and clear warnings in the docs. Raymond</pre>", "group_id": 8954, "id": 728610}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303147474.3157091, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3dvehfl - Maciej Fijalkowski - <pre> I think what's relevant was merged by benjamin. Usually: * we do revert things that were specifically made to make cpython faster, like def f(_getattr=getattr): ... * we usually target CPython version that's already frozen, which is pretty inconvinient to post this changes back. Example would be a socket module where it has changed enough in 3.x that 2.7 changes make no sense. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 728474}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303148373.6651139, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/64lpavh - R. David Murray - <pre> Nope. That's not what I was talking about. I was talking about marking a test as something that we require only the *python* implementation of a module to pass (presumably because it tests an internal implementation detail). Thus a C accelerator would not be expected to pass that test, nor would a C# accelerator, but pypy or any platform without an accelerator (that is, anything *using* the python code) would be expected to pass it. I would hope that such tests would be vanishingly rare (that is, that all needed tests can be expressed as black box tests). -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 728611}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303151973.840373, "message": "[devel] - Re: cpython: #11731: simplify/enhance parser/generator API by introducing policy objects. - http://tinyurl.com/4xrzcot - Georg Brandl - <pre> Hmm, so *strict* wasn't actually removed in 3.2? The 3.3 version is missing here. Also, please always end version directive text with a period. See above. See above. See above. This file should have a \".. versionadded:: 3.3\" (without further content) here. Looks like something is missing from this sentence :) [...] Should be Unix, not ``unix``. That keyword arg doesn't look right. Also, if you put interactive prompts, please use them correctly (\"...\" prompt and one blank line for the with block). \"uses\" ^^^^^^ Something is missing around here. Interesting API :) These string constants are probably better off in code markup, i.e. ``'\\n'``. Please use either :const:`True` or ``True``. A short sentence that the following are methods would be nice. What kind of object is *obj*? We're usually using \"^^^^\" for underlining this level of headings, but it's not really important. Indentation switches to 4 spaces below here... </pre>", "group_id": 8954, "id": 729189}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303155573.8093641, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3hogh23 - Stefan Behnel - <pre>Maciej Fijalkowski, 18.04.2011 19:11: Thanks. Speaking for the Cython project, we are certainly happy to see these micro optimisations reverted. Makes our life easier and the generated code faster. Stefan _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 729806}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303156474.885746, "message": "[devel] - Re: cpython: #11731: simplify/enhance parser/generatorAPI by introducing policy objects. - http://tinyurl.com/44fmzd6 - R. David Murray - <pre> Correct. I had previously checked in a versionchanged with the wrong release number. Should have corrected that separately. [...] \u00c3\u0089ric thought so too, but it reads fine to me. Maybe it is colloquial grammar and I'm just blind to it. I can't now remember what his suggested modification was, either. I've rewritten it as: Policy objects give the email package the flexibility to handle all these disparate use cases. [...] Yep, I got that backward when I edited it. \u00c3\u0089ric had me fix one example of that already. What do you mean by \"one blank line\" though? Doctest doesn't require blank lines after the ... lines, does it? [...] Whatever object is being used to represent the data being parsed when the defect is found. Right now that's always a Message, but that won't continue to be true. The rest of the documentation mentions or will mention which objects have defect lists, and it felt like duplicating that information here was a bad case of repetition (ie: one that doesn't add mu</pre>", "group_id": 8954, "id": 730014}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303156478.5123999, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/443a22p - Stefan Behnel - <pre>Raymond Hettinger, 18.04.2011 19:26: Absolutely. For what it's worth, Cython generates code that contains optimistic optimisations for common cases, such as iteration, x.append() calls, etc. When it finds such a pattern, it generates separate code paths for the most likely (builtin type) case and a slower fallback for the more unlikely case of a user provided type. So you get both speed and compatibility for free, just by writing idiomatic code like \"for item in some_iterable\". Stefan </pre>", "group_id": 8954, "id": 730016}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303161874.3781509, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3sazb93 - Stefan Behnel - <pre>R. David Murray, 18.04.2011 14:30: FWIW, there is a proposed GSoC project that aims to implement a Cython backend for PyPy, either using ctypes or PyPy's own FFI. That would basically remove the need to write library wrappers in C for both CPython and PyPy, and eventually for IronPython, which also has a Cython port in the making. Not sure how Jython fits into this, but I wouldn't object to someone writing a JNI backend either. Stefan </pre>", "group_id": 8954, "id": 731549}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303162773.4338131, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3jt74os - Brett Cannon - <pre>I just want to say upfront that my personal life has just gotten very hectic as of late (green card stuff for my wife who is Canadian) and probably will not let up until June. So if I go a while without replying to points being made for quite a while, I apologize. Luckily there seem to be others here who understand the direction I am coming from so there is no need to stop talking while I am pre-occupied with the real world. On Sun, Apr 17, 2011 at 00:30, Raymond Hettinger &lt; raymond.hettinger&lt; at &gt;gmail.com&gt; wrote: Actually I directly emailed the relevant people from the other VMs to make sure they were happy with what I was aiming for before I approached python-dev with the PEP. So IronPython, Jython, and PyPy lead developers have all told me that they want something along the lines of this PEP to happen. I'm okay with going with this line of through, including R. David's \"100% branch coverage is but one way to achieve extensive testing of the published API\". If people are willing to help me (i.e., go a</pre>", "group_id": 8954, "id": 731757}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303191626.4291611, "message": "[devel] - Re: cpython: #11731: simplify/enhance parser/generator API by introducing policy objects. - http://tinyurl.com/3hafaha - Georg Brandl - <pre> Sure, I was only asking because the original ended in a trailing comma. Not sure what doctest requires, but in the actual interactive shell you'd have ... do something ... It's not really important though. Georg </pre>", "group_id": 8954, "id": 738469}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303190723.6465709, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/43qoqla - Stefan Behnel - <pre>Brett Cannon, 05.04.2011 01:46: This PEP has received a lengthy discussion by now, so here's why I think it's being fought so heavily by several CPython core developers, specifically those who have traditionally carried a large part of the optimisation load in the project. I think the whole point of this PEP is that, having agreed that a shared standard library for all Python implementations is a good thing, the amount of shareable code should be maximised. I doubt that anyone will argue against this goal. But that obviously includes all sides. If other implementations are free to cherry pick the targets of their own effort geared by the optimisation of their own implementation, and leave the whole burden of compatibility and code reusability on CPython, in addition to the CPython efforts of improving and optimising its own core code base and its own stdlib version, it's not an equal matter. That's what makes the PEP feel so unfair to CPython developers, because they are the ones who carry mo</pre>", "group_id": 8954, "id": 738381}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303204224.010098, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3hm979f - Nick Coghlan - <pre> We've made a start on that aspect by granting CPython access to several of the core developers on the other VMs. The idea being that they can update the pure Python versions of modules directly rather than having to wait for one of us to do it on their behalf. Of course, as Maciej pointed out, that is currently hindered by the fact that the other VMs aren't targeting 3.3 yet, and that's where the main CPython development is happening. Cheers, Nick. </pre>", "group_id": 8954, "id": 739354}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303207825.369596, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3gp883j - Stefan Behnel - <pre>Nick Coghlan, 19.04.2011 10:57: A related question is: when other Python VM projects try to port a given C module, would they actually invest the time to write a pure Python version that may or may not run within acceptable performance bounds for them, or would they prefer saving time by writing only a native implementation directly for their VM for performance reasons? Maybe both, maybe not. If they end up writing a native version after prototyping in Python, is the prototype worth including in the shared stdlib, even if its performance is completely unacceptable for everyone? Or, if they write a partial module and implement another part of it natively, would the incomplete implementation qualify as a valid addition to the shared stdlib? Implementing a 100% compatible and \"fast enough\" Python version of a module is actually a rather time consuming task. I think we are expecting some altruism here that is easily sacrificed for time constraints, in any of the Python VM projects. CPython is just </pre>", "group_id": 8954, "id": 739551}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303213224.7628729, "message": "[devel] - Re: cpython: os.sendfile(): on Linux if offset parameter is passed asNULL we were - http://tinyurl.com/3z44uda - Antoine Pitrou - <pre>On Tue, 19 Apr 2011 09:47:21 +0200 giampaolo.rodola &lt;python-checkins&lt; at &gt;python.org&gt; wrote: Do we have tests for this? Regards Antoine. </pre>", "group_id": 8954, "id": 739853}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303215025.3443961, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3ghegwg - Jesse Noller - <pre>[snip] I am going to go out on a limb here and state that once the stdlib is shared, it is all of the VM's responsibility to help maintaining it, meaning the PEP 399 is binding to all of the VMs. If Jython wants to write an accelerator module in Java for something in the stdlib, they have to follow the same guidelines, same applies to PyPy, etc. I think this is an equal matter, and if needed, we should make note of it in the PEP. The goal here is to make it easier to share the code base of the stdlib and not pull the rug out from other implementations by having a stdlib module written only in highly optimized C with no Python fallback, leaving them with the unsavory duty of reimplementing it in Python|Java|C#, etc. Pure Python is the coin of the realm. Sure, at first glance this seems to place an unfair burden on CPython - because we're just as guilty as being \"closed\" to other implementation as the other implementations are to us. We're trying to change that, and someone (us, as the reference implement</pre>", "group_id": 8954, "id": 740042}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303215929.9820001, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3wyj9g2 - Jesse Noller - <pre> Yeah, I emailed him this morning, I dropped the ball on his commit bit post pycon due to email overload. I'm resolving it today. </pre>", "group_id": 8954, "id": 740200}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303215926.9304841, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/42dwoat - Maciej Fijalkowski - <pre> We're also slightly hindered by the fact that not all of us got privilages so far (Antonio Cuni in particular). _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 740199}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303216836.4664891, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://permalink.gmane.org/gmane.comp.python.devel/124015 - Maciej Fijalkowski - <pre> I would also like to point out that some valuable contributions were made already by other implementations. When talking about stdlib, it's mostly in the area of test suite, but not only in terms of \"skip those tests\", but also improving test coverage and even fixing bugs. Unicode fixes were prototyped on PyPy first and some PyPy optimizations were ported to CPython (the original method cache patch came from Armin Rigo as far as I remember). So it's not completely \"Cpython's burden\" only. Cheers, fijal </pre>", "group_id": 8954, "id": 740436}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303216832.7204821, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3lwbp2k - Maciej Fijalkowski - <pre> At least from our (PyPy's side), we do use pure python versions a lot. Their performance vary, but sometimes you don't care, you just want the module to work. Contrary to popular belief, not all code is performance critical in standard library. We got quite far without even looking. Later on we usually look there, but for us rewriting it in RPython most of the time makes no sense, since pure python code might even behave better than RPython code, especially if there are loops which get jitted more efficiently if they're in pure python. I think 100% compatible with whatever performance is already a lot for us. We can improve the performance later on. For example we never touched heapq module and it works just fine as it is. </pre>", "group_id": 8954, "id": 740433}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303216828.6921029, "message": "[devel] - Re: Python 2.6.7 - http://tinyurl.com/44252bm - anatoly techtonik - <pre> Does 'anything' only relate to security fixes? -- anatoly t. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 740432}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303221327.7231481, "message": "[devel] - Drop OS/2 and VMS support? - http://tinyurl.com/626ovsh - Victor Stinner - <pre>Hi, I asked one year ago if we should drop OS/2 support: Andrew MacIntyre, our OS/2 maintainer, answered: http://mail.python.org/pipermail/python-dev/2010-April/099477.html Extract: &lt;&lt; The 3.x branch needs quite a bit of work on OS/2 to deal with Unicode, as OS/2 was one of the earlier OSes with full multiple language support and IBM developed a unique API. I'm still struggling to come to terms with this, partly because I myself don't \"need\" it. &gt;&gt; So one year later, Python 3 does still not support OS/2. -- About VMS: I don't know if anyone is using Python (2 or 3) on VMS, or if Python 3 does work on VMS. I bet that it does just not compile :-) I don't know anyone using VMS or OS/2. -- There are 39 #ifdef VMS and 52 #ifdef OS2. We can keep them and wait until someone work on these OSes to ensure that the test suite pass. But if nobody cares of these OSes and nobody wants to maintain them, it would be easier for the maintenance of the Python source code base to remove specific code. Well, not \"r</pre>", "group_id": 8954, "id": 741752}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303222225.6953521, "message": "[devel] - Re: Python 2.6.7 - http://tinyurl.com/3mc9s62 - Barry Warsaw - <pre> Yes. -Barry </pre>", "group_id": 8954, "id": 741931}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303223124.759764, "message": "[devel] - Providing a mechanism for PEP 3115 compliant dynamicclass creation - http://tinyurl.com/4xa858f - Nick Coghlan - <pre>In reviewing a fix for the metaclass calculation in __build_class__ [1], I realised that PEP 3115 poses a potential problem for the common practice of using \"type(name, bases, ns)\" for dynamic class creation. Specifically, if one of the base classes has a metaclass with a significant __prepare__() method, then the current idiom will do the wrong thing (and most likely fail as a result), since \"ns\" will probably be an ordinary dictionary instead of whatever __prepare__() would have returned. Initially I was going to suggest making __build_class__ part of the language definition rather than a CPython implementation detail, but then I realised that various CPython specific elements in its signature made that a bad idea. Instead, I'm thinking along the lines of an \"operator.prepare(metaclass, bases)\" function that does the metaclass calculation dance, invoking __prepare__() and returning the result if it exists, otherwise returning an ordinary dict. Under the hood we would refactor this so that operator.prepa</pre>", "group_id": 8954, "id": 742145}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303224926.030055, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/4xpjqx8 - R. David Murray - <pre> So, the PEP makes the burden worse in that it requires that someone who works on a module with a C accelerator must make sure that any existing Python version and the C version stay in sync, and that *anyone* who wants to introduce a new module into the stdlib must make sure it has a Python version if that is practical. IMO both of these are policies that make sense for CPython even aside from the existence of other implementations: Python is easier to read and understand, so where practical we should provide a Python version of any module in the stdlib, for the benefit of CPython users. It doesn't sound like a great burden to me, but I'm not really qualified to judge, since I don't generally work on C code. Also, could you expand on \"It often even runs counter to the interest of CPython itself\"? I'm not seeing that, unless you are talking about the parameter-binding micro-optimization, which I think we discourage these days anyway. Personally, I consider myself an stdlib maintainer: I only occasiona</pre>", "group_id": 8954, "id": 742554}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303224030.062068, "message": "[devel] - Re: Drop OS/2 and VMS support? - http://tinyurl.com/3qzwrlj - M.-A. Lemburg - <pre> The Python core team is not really representative of the Python community users, so I think this needs a different approach: Instead of simply deprecating OSes without notice to the general Python community, how about doing a \"call for support\" for these OSes ? If that doesn't turn up maintainers, then we can take the PEP 11 route. FWIW: There's still a fan-base out there for OS/2 and its successor eComStation: http://en.wikipedia.org/wiki/EComStation http://www.ecomstation.com/ecomstation20.phtml http://www.warpstock.eu/ Same for VMS in form of OpenVMS: http://en.wikipedia.org/wiki/OpenVMS http://h71000.www7.hp.com/index.html?jumpid=/go/openvms http://www.vmspython.org/ </pre>", "group_id": 8954, "id": 742353}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303224929.711096, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator Module Compatibiilty Requirements - http://tinyurl.com/3fmz7gy - Antoine Pitrou - <pre>On Tue, 19 Apr 2011 10:37:41 -0400 \"R. David Murray\" &lt;rdmurray&lt; at &gt;bitdance.com&gt; wrote: I think it's ok. Our experience on the io module proves, I think, that's it's indeed useful to have a pure Python (pseudocode-like) implementation. Regards Antoine. </pre>", "group_id": 8954, "id": 742557}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303224934.014322, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3blughg - R. David Murray - <pre> I would say yes, it is worth including. And even more worth including is any additional tests they develop to validate their implementation. Well, I don't think we are really expecting altruism. We're trying to leverage the work the community is doing, by drawing as much of the Python code and validation tests that get created into a common stdlib. If a module in the wild is being considered for inclusion in the stdlib, it will need to have a Python version if practical. Since we accept so few modules anyway (for good reason), I really don't see this as a big deal. And, there's always the practicality beats purity argument: if the PEP turns out to really get in the way of something everyone wants, then we can agree to an exception. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 742559}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303226726.591543, "message": "[devel] - Re: PEP 399: Pure Python/C Accelerator ModuleCompatibiilty Requirements - http://tinyurl.com/3lcb3n9 - R. David Murray - <pre> Yes, and you also need to keep in mind that several developers wear multiple hats, and contribute to CPython on a regular or semi-regular basis. It is also enlightening to look at the output of hg churn. The number of active CPython developers over the past year is not huge, and very few of them have spoken up in this thread. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 742922}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303228528.016474, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Fix a few hyphens in argparse.rst. - http://tinyurl.com/3vka468 - \u00c9ric Araujo - <pre> Hi, I believe that change should be reverted. \u201cargument parsing library\u201d is a noun determined (qualified) by another noun itself determined by a noun, not by an adjective. You changed \u201carg\u201d to \u201cargument\u201d in one place but not throughout. I think it\u2019s best to use only full words in the docs (and for names in code, as recommended by PEP 8 :). Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 743183}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303241126.4057789, "message": "[devel] - Re: Drop OS/2 and VMS support? - http://tinyurl.com/4xlkoyc - Doug Hellmann - <pre> On Apr 19, 2011, at 10:36 AM, M.-A. Lemburg wrote: Victor, if you want to post the \"call for support\" to Python Insider, let me know off list and I will set you up with access. Doug </pre>", "group_id": 8954, "id": 745603}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303242926.633091, "message": "[devel] - Re: Drop OS/2 and VMS support? - http://tinyurl.com/3jl2rnj - M.-A. Lemburg - <pre> I can help with that if you like. </pre>", "group_id": 8954, "id": 745999}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303246554.851099, "message": "[devel] - Re: Drop OS/2 and VMS support? - http://tinyurl.com/3jbphep - Antoine Pitrou - <pre>On Tue, 19 Apr 2011 15:20:13 -0400 Doug Hellmann &lt;doug.hellmann&lt; at &gt;gmail.com&gt; wrote: Doesn't it have more chances of succeeding if posted to comp.lang.python, simply? Regards Antoine. </pre>", "group_id": 8954, "id": 747030}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303244728.020154, "message": "[devel] - Re: Drop OS/2 and VMS support? - http://tinyurl.com/3gv22hb - Victor Stinner - <pre>Le mardi 19 avril 2011 \u00e0 15:20 -0400, Doug Hellmann a \u00e9crit : If we ask users if they want to keep OS/2 and VMS, I expect that at least someone would like to keep them. But it doesn't solve the maintenance problem: we need maintainers (developers), not users. If a \"call for support\" can help us to maintain these OSes, nice. But I don't want to touch these OSes (I want to do less work, not more work :-)), and so I don't want to write such call. If you feel concerned by this issue, contact Doug to write the call ;-) Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 746545}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303248352.9472871, "message": "[devel] - Re: Drop OS/2 and VMS support? - http://tinyurl.com/3dquu75 - Martin v. L\u00f6wis - <pre> I think the PEP 11 procedure is just right for this. It *is* a call for maintainers, so if any user is interested in ongoing support, they should step forward. Having then also blog posts about these pending deprecations sounds fine to me - also adding them to the 3.2.x release pages would be appropriate (IMO). It's important that we give users due notice, but lacking any actual contribution, we should also be able to remove the code eventually. So please go ahead and add them to PEP 11. Regards, Martin </pre>", "group_id": 8954, "id": 747482}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303288017.572531, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Add threading._info() function providinginformations about the - http://tinyurl.com/3wnexse - Victor Stinner - <pre>Hi, Le mardi 19 avril 2011 \u00e0 22:42 -0400, Terry Reedy a \u00e9crit : Well, I suppose that this function might be specific to CPython. Do you think that this function can/should be implemented in PyPy, Jython and IronPython? Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 753054}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303289817.9725161, "message": "[devel] - Re: Drop OS/2 and VMS support? - http://tinyurl.com/4xogdj6 - Lennart Regebro - <pre> I say \"all of the above\". It could be good to find a OS/2 and OpenVMS developer mailing list as well, and post it there. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Telephone: +48 691 268 328 </pre>", "group_id": 8954, "id": 753216}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303292518.668045, "message": "[devel] - Buildbots and faulthandler - http://tinyurl.com/3mol7x5 - Victor Stinner - <pre>Hi, The new faulthandler module is now fully functional and it has no more known issue. Its timeout feature is used on regrtest to dump the Python backtrace and exit if a test takes more than 1 hour. Using the regrtest timeout and faulthandler signal handlers (enable in regrtest), I started to collect tracebacks of all timeouts. Open issues: * test_threading.test_notify() on Windows http://bugs.python.org/issue11769 Not analyzed yet. I am unable to reproduce it in my VM. * test_mmap.test_large_offset() on Mac OS X http://bugs.python.org/issue11779 May be related (and fixed) by issue #11277 which has a patch. * test_threading.test_3_join_in_forked_from_thread() on Ubuntu http://bugs.python.org/issue11870 Only seen once. * test_mmap.test_big_buffer() on Mac OS X (it's a crash, bus error) http://bugs.python.org/issue11277 The origin of the problem was already identified, but the trace proves that faulthandler is able to catch correctly SIGBUS ;-) * test_ttk_guionly on Mac</pre>", "group_id": 8954, "id": 753433}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303297014.4960461, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the - http://tinyurl.com/6y6ppf4 - Nick Coghlan - <pre>On Wed, Apr 20, 2011 at 6:20 PM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: I agree with your reasoning (and the leading underscore), but I suggest marking the docs with the implementation detail flag. Cheers, Nick. </pre>", "group_id": 8954, "id": 753651}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303297017.2904601, "message": "[devel] - Re: Buildbots and faulthandler - http://tinyurl.com/62cmk5f - Nick Coghlan - <pre>On Wed, Apr 20, 2011 at 7:37 PM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: Excellent work :) Minor nit: the faulthandler docs could use an \"impl-detail\" block similar to the one in the dis module docs. Cheers, Nick. </pre>", "group_id": 8954, "id": 753652}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303301515.316807, "message": "[devel] - Re: Buildbots and faulthandler - http://tinyurl.com/3n9jmu8 - Ethan Furman - <pre> Congratulations! Nice work. ~Ethan~ </pre>", "group_id": 8954, "id": 753946}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303304215.4138341, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223:Addthreading._info() function providing informations about the - http://tinyurl.com/3qnon69 - exarkun< at >twistedmatrix.com - <pre> Can I propose something wildly radical? Maybe the guarantees made about whether an API will be available in future versions of Python (ostensibly what \"public\" vs \"private\" is for) should not be tightly coupled to the decision about whether to bother to explain what an API does? Jean-Paul </pre>", "group_id": 8954, "id": 754442}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303306014.7923269, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the - http://tinyurl.com/6jfzcvd - Benjamin Peterson - <pre>2011/4/20 &lt;exarkun&lt; at &gt;twistedmatrix.com&gt;: With what criteria would you propose to replace it with? </pre>", "group_id": 8954, "id": 754672}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303308716.2083199, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the - http://tinyurl.com/3m8jwjb - Victor Stinner - <pre>Le mercredi 20 avril 2011 \u00e0 20:24 +1000, Nick Coghlan a \u00e9crit : I chose to return a dict to be flexible: any thread implementation may add new specific keys. There is just one mandatory key: 'name', name of the thread implementation (nt, os2, pthread or solaris for CPython 3.3). http://docs.python.org/dev/py3k/library/threading.html#threading._info After thinking twice, PyPy, Jython and IronPython should be able to fill the only required key (name). PyPy reuses the code from CPython, so it can just reuse the same names (pthread or nt). I suppose that IronPython uses Windows threads and semaphores, so it can use the name 'nt'. For Jython, I don't know if Jython is able to get the name of the thread implementation used by the JVM. If it is not, something like 'jvm' can be used. threading._info() is a function: it can call other functions to retrieve informations (it is not hardcoded or initialized at startup). What do you think? Can I remove the leading underscore? :-) Victor ________________________</pre>", "group_id": 8954, "id": 755102}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303309626.945682, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Addthreading._info() function providing informations about the - http://tinyurl.com/3v6zhfo - R. David Murray - <pre> I believe Jean-Paul was suggesting that just because an interface is marked as \"private\" and might go away or change in the future does not automatically mean it must also be undocumented. To which I say +1. (Note that we already have a whole module like that: test.support.) -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 755242}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303309623.8233919, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223:Addthreading._info() function providing informations about the - http://tinyurl.com/3jptknr - exarkun< at >twistedmatrix.com - <pre> I'm not sure what kind of criteria you're thinking of. I'm only suggesting that: 1) Document whatever you want (preferably as much as possible) 2) Make \"privateness\" defined by whether there is a leading underscore It is a big mistake to think that documentation isn't necessary for things just because you don't want application developers to use them. Maintainers benefit from it just as much. Jean-Paul </pre>", "group_id": 8954, "id": 755241}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303319540.256938, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the - http://tinyurl.com/3h3cjvt - Benjamin Peterson - <pre>2011/4/20 Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt;: How about using a structseq ala sys.float_info or sys.long_info? (In fact, we might want to put this in sys.) </pre>", "group_id": 8954, "id": 757474}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303319536.6470399, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the - http://tinyurl.com/6blvptn - Benjamin Peterson - <pre>2011/4/20 R. David Murray &lt;rdmurray&lt; at &gt;bitdance.com&gt;: I think that test.* as a special case is private stuff. </pre>", "group_id": 8954, "id": 757472}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303324081.5567911, "message": "[devel] - Re: cpython: os.sendfile(): on Linux if offset parameter is passed as NULL we were - http://tinyurl.com/4xco8t5 - Giampaolo Rodol\u00e0 - <pre>No we haven't. I plan to make a unique commit for offset=None on Linux and a serie of other tests I have implemented for py-sendfile module [1]. In details test for small file, empty file and (most important) large file: http://code.google.com/p/py-sendfile/source/browse/trunk/test/test_sendfile.py?spec=svn68&amp;r=68#296 [1] http://code.google.com/p/py-sendfile --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil 2011/4/19 Antoine Pitrou &lt;solipsis&lt; at &gt;pitrou.net&gt;: </pre>", "group_id": 8954, "id": 759063}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303335777.2061491, "message": "[devel] - Re: cpython: os.sendfile(): on Linux if offset parameter is passed as NULL we were - http://tinyurl.com/3cdodpg - Terry Reedy - <pre> \"No we haven't\" what? Such out-of-context responses exemplify why top-posting is greatly inferior for readers, who vastly outnumber the one writer. If that line had been put where it belongs, right after what it refers to, it would have been clear. </pre>", "group_id": 8954, "id": 761904}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303337584.73125, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the - http://tinyurl.com/3v4q66u - Benjamin Peterson - <pre>2011/4/20 Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt;: The only things that would improve that beautiful sight would be s/threadinfo/thread_info/. :) </pre>", "group_id": 8954, "id": 762147}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303337581.962997, "message": "[devel] - Re: Buildbots and faulthandler - http://tinyurl.com/3bzev4p - Terry Reedy - <pre> Ditto. Multiple pats on the back. </pre>", "group_id": 8954, "id": 762145}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303336679.945781, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the - http://tinyurl.com/3zlon7a - Terry Reedy - <pre> Maintainers can and will read the doc string. </pre>", "group_id": 8954, "id": 762017}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303336676.7283759, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the - http://tinyurl.com/3owdorf - Terry Reedy - <pre> sys.thread_info strikes me as a good idea too. The only thing required should be 'name' with '' at the default indicating no threading. </pre>", "group_id": 8954, "id": 762016}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303337579.1543951, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the - http://tinyurl.com/3hxr9jv - Victor Stinner - <pre>Le mercredi 20 avril 2011 \u00e0 11:57 -0500, Benjamin Peterson a \u00e9crit : Would you prefer something like the following example? sys.threadinfo(name='pthread', 'lock_implementation': 'semaphore', version: 'NPTL 2.11.2') sys.threadinfo(name='nt', 'lock_implementation': 'semaphore', version: '') sys.threadinfo(name='os2', 'lock_implementation': '', version: '') Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 762144}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303338476.572248, "message": "[devel] - Re: [Python-checkins] cpython: Issue #11223: Add threading._info() function providing informations about the - http://tinyurl.com/3elzev5 - Antoine Pitrou - <pre>On Wed, 20 Apr 2011 17:03:19 -0500 Benjamin Peterson &lt;benjamin&lt; at &gt;python.org&gt; wrote: And None instead of the empty string when a value is unknown/irrelevant. Regards Antoine. </pre>", "group_id": 8954, "id": 762287}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303424881.492471, "message": "[devel] - Re: Test cases not garbage collected after run - http://tinyurl.com/44o6ccc - Michael Foord - <pre> I can't remember if I replied to this or not. Sorry. Anyway, so long as *unittest* doesn't keep your test cases alive (which currently it does) then if any individual test framework keeps the tests alive that is a bug in the framework (and it can be tested for). If we stomp on the test instance dictionaries then legitimate use cases may be prevented (like test cases copying themselves and executing a copy when run - a use case described by Robert Collins in a previous email). Although other test frameworks may implement additional measures required specifically by them, the duty of unittest is just to ensure that it doesn't make disposing of test cases *impossible* during normal use. All the best, Michael Foord </pre>", "group_id": 8954, "id": 776314}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303496969.1042869, "message": "[devel] - Summary of Python tracker Issues - http://tinyurl.com/3fy9wth - Python tracker - <pre> ACTIVITY SUMMARY (2011-04-15 - 2011-04-22) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2752 (+18) closed 20937 (+38) total 23689 (+56) Open issues with patches: 1194 Issues opened (38) ================== #4608: urllib.request.urlopen does not return an iterable object http://bugs.python.org/issue4608 reopened by orsenthil #11584: email.decode_header fails if msg.__getitem__ returns Header ob http://bugs.python.org/issue11584 reopened by r.david.murray #11619: On Windows, don't encode filenames in the import machinery http://bugs.python.org/issue11619 reopened by haypo #11779: test_mmap.test_large_offset() timeout (1 hour) on \"AMD64 Snow http://bugs.python.org/issue11779 reopened by haypo #11854: __or__ et al instantiate subclass of set without calling __ini http://bugs.python.org/issue11854 opened by Robert.Burke #11856: Optimize parsing of JSON n</pre>", "group_id": 8954, "id": 783775}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303583295.9404409, "message": "[devel] - Hello guys! - http://tinyurl.com/3c6p8mu - Jayme Proni Filho - <pre>Hello guys! Well, I'll do like welcome message of the python-dev-request ask. I'm a brazilian C programmer and I'm learning how to programm in Python fast because it is cool. I installed python a few days ago in my notebook. So, I will be here learning with you guys just watching you and your discussions about what it is better for python's future for while and when I fell 100% sure about what I have to post it here. I will. I'm sorry about my English. That's my first time typing in English in a important place. See you guys! --------------------------------------------------------------------------------------- Jayme Proni Filho Skype: jaymeproni Twitter: &lt; at &gt;jaymeproni Phone: +55 - 17 - 3631 - 6576 Mobile: +55 - 17 - 9605 - 3560 e-Mail: jaymeproni at yahoo dot com dot br --------------------------------------------------------------------------------------- </pre>", "group_id": 8954, "id": 790493}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303700845.208034, "message": "[devel] - Re: Drop OS/2 and VMS support? - http://tinyurl.com/3l7jfgp - Jesus Cea - <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/04/11 22:48, Antoine Pitrou wrote: I think \"Python Insider\" point was to translate to general public relevant python-dev discussions. This is a perfect example. +1 to include deprecation warnings/errors in 3.3 and remove in 3.4, according to PEP11. A heads-up warning and request for help in \"Python Insider\" is the way to go, too. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea&lt; at &gt;jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea&lt; at &gt;jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ \"Things are not so easy\" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ \"My name is Dump, Core Dump\" _/_/_/ _/_/_/ _/_/ _/_/ \"El amor es poner tu felicidad en la felicidad de otro\" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTbTk</pre>", "group_id": 8954, "id": 798429}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303699942.9287, "message": "[devel] - Re: [Python-checkins] cpython (merge 3.2 -> default): Correctly merging #9319 into 3.3? - http://tinyurl.com/3ms9jdc - Jesus Cea - <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If a patch in 3.2 is not applicable in 3.3, a \"null merge\" should be done. If not, next developer tring to merge will find some other unrelated code to merge, and she doesn't have the context knowledge to know what to do :-). In this case, I merged code that doesn't actually compile, breaking the build for 20 minutes :-). And yes, I fully realized that I should try to compile locally first. Dealing with this unexpected merge when merging my own patch was... unexpected, and the code seemed sensible enough. Do we have some hat-of-shame I should wear because breaking the build? :). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea&lt; at &gt;jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea&lt; at &gt;jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ \"Things are not so easy\" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ \"My name is Dump, Core Dump</pre>", "group_id": 8954, "id": 798316}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303702648.65288, "message": "[devel] - Re: Issue 11715: building Python from source on multiarch Debian/Ubuntu - http://tinyurl.com/3bhbcos - Jesus Cea - <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/04/11 00:37, Nick Coghlan wrote: Well, I, for one, have Python 2.3, 2.4, 2.5, 2.6, 2.7, 3.1 and 3.2 installed in my machine (Ubuntu 10.04) because I need to support code spanning such a range of python versions. I remember that compiling 2.3 or 2.4 was a bit painful. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea&lt; at &gt;jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea&lt; at &gt;jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ \"Things are not so easy\" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ \"My name is Dump, Core Dump\" _/_/_/ _/_/_/ _/_/ _/_/ \"El amor es poner tu felicidad en la felicidad de otro\" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTbTqSJlgi5GaxT1NAQJdBwP/fVcqmac2gF/rPLYJvrwRKC7JqlmogRuQ h9Wp97Ihl430</pre>", "group_id": 8954, "id": 798628}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303702644.625701, "message": "[devel] - Re: Test \"Force Build\" on custom buildbots - http://tinyurl.com/679nj9y - Jesus Cea - <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/03/11 18:27, Antoine Pitrou wrote: I guess you are talking about &lt;http://mercurial.selenic.com/wiki/PurgeExtension&gt;. Do you want me to activate this extension in my buildbots? (OpenIndiana machine). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea&lt; at &gt;jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea&lt; at &gt;jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ \"Things are not so easy\" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ \"My name is Dump, Core Dump\" _/_/_/ _/_/_/ _/_/ _/_/ \"El amor es poner tu felicidad en la felicidad de otro\" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTbTpjZlgi5GaxT1NAQKVfwP9FwD50nnoIErTpigrG8W/7ds1kWQz3C02 4qwt7P5jQ9mbXImIbmh0TKNjJJg0zsp+QR/3cZZRkg67R0Walu9glbXlcp9mDeWZ qU3SuiRQ4vNq+lcX</pre>", "group_id": 8954, "id": 798624}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303731623.9695051, "message": "[devel] - Re: [Python-checkins] cpython (merge 3.2 -> default): Correctly merging #9319 into 3.3? - http://tinyurl.com/3bwkqkq - Antoine Pitrou - <pre>On Mon, 25 Apr 2011 04:47:03 +0200 Jesus Cea &lt;jcea&lt; at &gt;jcea.es&gt; wrote: You should *always* recompile and run the affected tests before checking in a change. Even if the changes look \"trivial\". By trying to save a little time on your side your may lose a lot of other people's time. The tests are still broken it seems: ====================================================================== ERROR: test_issue9319 (test.test_imp.ImportTests) ---------------------------------------------------------------------- Traceback (most recent call last): File \"/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_imp.py\", line 181, in test_issue9319 imp.find_module, \"test/badsyntax_pep3120\") File \"/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/unittest/case.py\", line 574, in assertRaises callableObj(*args, **kwargs) ImportError: No module named 'test/badsyntax_pep3120' Regards Antoine. </pre>", "group_id": 8954, "id": 802650}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303736127.974519, "message": "[devel] - Why are there no 'set' and 'frozenset' types in the'types' module? - http://tinyurl.com/439vkmh - haael - <pre> Sorry if I am asking the obvious, but why are the aliases of set types not included in the 'types' module? I thought for a moment that they are just classes, but no, they introduce themselves as built-in types, just like any other standard Python type. &gt; print type(set([1, 2, 4])) &lt;type 'set'&gt; &gt; print type(frozenset([3, 5])) &lt;type 'frozenset'&gt; Is it intentional, or is there some meaning behind this? If not, shouldn't they be added to the module? Regards, Bartosz Tarnowski --------------------------------------------------------------- Darmowy program do wype\u0142niania PIT: http://linkint.pl/f2931 _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 802951}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303737029.5713511, "message": "[devel] - Re: Why are there no 'set' and 'frozenset' types in the 'types' module? - http://permalink.gmane.org/gmane.comp.python.devel/124061 - Fred Drake - <pre> The types module pre-dates the time when classes were actually types in their own right, and many of the built-in constructors, like \"float\", \"int\", and \"list\", were simply functions. When that was the case: &gt;&gt;&gt; import types &gt;&gt;&gt; types.IntType == int False For types that have always been types, there's no corresponding entry in the types module, nor is there any need for any, since the type itself is already accessible. -Fred </pre>", "group_id": 8954, "id": 803057}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303737026.5550351, "message": "[devel] - Re: Why are there no 'set' and 'frozenset' types in the 'types' module? - http://tinyurl.com/3oja3d2 - Antoine Pitrou - <pre>On Mon, 25 Apr 2011 14:04:35 +0200 haael &lt;haael&lt; at &gt;interia.pl&gt; wrote: Because there's no reason to include them, since they are already in the root (builtins) namespace. You'll notice that in Python 3, the \"types\" module only contains types which are not obviously accessed through easier means: ['BuiltinFunctionType', 'BuiltinMethodType', 'CodeType', 'FrameType', 'FunctionType', 'GeneratorType', 'GetSetDescriptorType', 'LambdaType', 'MemberDescriptorType', 'MethodType', 'ModuleType', 'TracebackType', '__builtins__', '__cached__', '__doc__', '__file__', '__name__', '__package__'] Regards Antoine. </pre>", "group_id": 8954, "id": 803055}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303740748.1852231, "message": "[devel] - Re: Why are there no 'set' and 'frozenset' types in the 'types' module? - http://tinyurl.com/3btemj8 - haael - <pre> OK, makes sense, but in this case it would be handy to have some list of all possible built-in types. I was just creating one and I nearly missed sets. If an entry in 'types' module is too much, there should be some comprehensive list in the documentation at least. Regards, Bartosz Tarnowski --------------------------------------------- Ksiegowa radzi: Jak za\u00c5\u0082ozyc firme w 15 minut? http://linkint.pl/f2968 </pre>", "group_id": 8954, "id": 803666}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303740751.7960019, "message": "[devel] - Re: Why are there no 'set' and 'frozenset' types in the 'types' module? - http://tinyurl.com/3u9t2v2 - Benjamin Peterson - <pre>2011/4/25 haael &lt;haael&lt; at &gt;interia.pl&gt;: http://docs.python.org/dev/library/stdtypes </pre>", "group_id": 8954, "id": 803667}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303740755.9895599, "message": "[devel] - Re: [Python-checkins] cpython (merge 3.2 -> default): Correctly merging #9319 into 3.3? - http://tinyurl.com/3ss4fee - Victor Stinner - <pre>Le lundi 25 avril 2011 \u00e0 04:47 +0200, Jesus Cea a \u00e9crit : Correct. Sorry, I forgot that. And yes, the 3.2 fix was not applicable to 3.3, that's why I forgot to merge. Hum, you may read the history of the issue to decide what to do, or ask the commiter to do the merge. He he, it was a trap! When you touch one of my commit, all buildbots turn red! :-) Don't worry, it doesn't matter if you quickly fix your mistake. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 803670}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303742546.4391191, "message": "[devel] - Re: Drop OS/2 and VMS support? - http://tinyurl.com/3t5tcvt - Victor Stinner - <pre>Le mardi 19 avril 2011 \u00e0 23:21 +0200, \"Martin v. L\u00f6wis\" a \u00e9crit : Ok, I added OS/2 and VMS to the PEP 11. I also opened any issue to remember that I should do something to raise an error on build. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 803843}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303745244.780396, "message": "[devel] - Re: Why are there no 'set' and 'frozenset' types inthe'types' module? - http://tinyurl.com/3mvp5kw - exarkun< at >twistedmatrix.com - <pre> Maybe this is what you're after? [&lt;type 'type'&gt;, &lt;type 'weakref'&gt;, &lt;type 'weakcallableproxy'&gt;, &lt;type 'weakproxy'&gt;, &lt;type 'int'&gt;, &lt;type 'basestring'&gt;, &lt;type 'bytearray'&gt;, &lt;type 'list'&gt;, &lt;type 'NoneType'&gt;, &lt;type 'NotImplementedType'&gt;, &lt;type 'traceback'&gt;, &lt;type 'super'&gt;, &lt;type 'xrange'&gt;, &lt;type 'dict'&gt;, &lt;type 'set'&gt;, &lt;type 'slice'&gt;, &lt;type 'staticmethod'&gt;, &lt;type 'complex'&gt;, &lt;type 'float'&gt;, &lt;type 'buffer'&gt;, &lt;type 'long'&gt;, &lt;type 'frozenset'&gt;, &lt;type 'property'&gt;, &lt;type 'tuple'&gt;, &lt;type 'enumerate'&gt;, &lt;type 'reversed'&gt;, &lt;type 'code'&gt;, &lt;type 'frame'&gt;, &lt;type 'builtin_function_or_method'&gt;, &lt;type 'instancemethod'&gt;, &lt;type 'function'&gt;, &lt;type 'classobj'&gt;, &lt;type 'dictproxy'&gt;, &lt;type 'generator'&gt;, &lt;type 'getset_descriptor'&gt;, &lt;type 'wrapper_descriptor'&gt;, &lt;type 'instance'&gt;, &lt;type 'ellipsis'&gt;, &lt;type 'member_descriptor'&gt;, &lt;type 'EncodingMap'&gt;, &lt;type 'module'&gt;, &lt;type 'classmethod'&gt;, &lt;type 'file'&gt;] Jean-Paul </pre>", "group_id": 8954, "id": 804319}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303752544.2040541, "message": "[devel] - Syntax quirk - http://tinyurl.com/3o8sw83 - Rob Cliffe - <pre> &gt;&gt;&gt; type (3.) &lt;type 'float'&gt; &gt;&gt;&gt; 3..__class__ &lt;type 'float'&gt; &gt;&gt;&gt; type(3) &lt;type 'int'&gt; &gt;&gt;&gt; 3.__class__ File \"&lt;stdin&gt;\", line 1 3.__class__ ^ SyntaxError: invalid syntax Superficially the last example ought to be legal syntax (and return &lt;type 'int'&gt;). Is it an oversight which could be fixed in a straightforward way, or are there reasons why it can't? I have tested this with Python 2.5 and Python 3.2. Best wishes Rob Cliffe </pre>", "group_id": 8954, "id": 805316}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303753443.88869, "message": "[devel] - Re: Syntax quirk - http://tinyurl.com/3l3oq3q - Alexander Belopolsky - <pre>.. If it was valid, then would have to raise an attribute error instead of 30000000.0 </pre>", "group_id": 8954, "id": 805419}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303755305.029238, "message": "[devel] - Re: Why are there no 'set' and 'frozenset' types in the'types' module? - http://tinyurl.com/3ns5rc8 - haael - <pre> Yes, something like that, but without abstract types like 'basestring'. If abstract types were OK, it would suffice to use 'object'. The use case is designing protocols that export Python objects to outer world, 'pickle' is an example. One needs to typecase through all built-in Python types and handle them in some way. Nevertheless, my problem is solved. Thank you. Regards, Bartosz Tarnowski --------------------------------------------------------------- Darmowy program do wype\u00c5\u0082niania PIT: http://linkint.pl/f2931 </pre>", "group_id": 8954, "id": 805696}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303753449.584408, "message": "[devel] - Re: Syntax quirk - http://permalink.gmane.org/gmane.comp.python.devel/124070 - Terry Reedy - <pre> You are a more sophisticated parser than Python, which is limited to LL(1) parsing. (No that is not in the manual, but it is a known design consraint.) This sort of question as to why Python is the way it is really belongs on python-list. 3.x is parsed as (3.)x (float 3. followed by x) which is invalid syntax unless 'x' is a digit(s). You automatically back up and reparse as 3(.x) 3 .0 is a syntax error. 3 .__class__ is int. </pre>", "group_id": 8954, "id": 805422}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303753447.100075, "message": "[devel] - Re: Syntax quirk - http://tinyurl.com/44gsrgb - Nick Coghlan - <pre> The parser (or is it the lexer? I never remember which it is that has the problem in this case) can't handle it - it sees the first \".\" and expects a floating point value. It's hard to disambiguate due to 3.e10 and the like being valid floating point numbers, while 3..e10 has to be an attribute access. You have to use whitespace or parentheses to eliminate the ambiguity: 3. __class__ (3).__class__ Cheers, Nick. </pre>", "group_id": 8954, "id": 805420}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303758904.127809, "message": "[devel] - Re: Drop OS/2 and VMS support? - http://tinyurl.com/4ykde7f - Martin v. L\u00f6wis - <pre> For OS/2, I propose to syntactically break the makefile; anybody trying to build it should then run into that, and a) can easily overcome the limitation (probably to then run into more severe problems), and b) consider taking over maintenance if they are interested For VMS, I *think* the build process is configure-based (but I may misremember); if so, adding an exit into configure.in would be appropriate. Else an #error in a central header file may do as well. Or perhaps we could always use the #error if we can trust that compilers will honor it. Regards, Martin </pre>", "group_id": 8954, "id": 806246}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303758004.1919999, "message": "[devel] - Why doesn't `functools.total_ordering` use theexisting ordering methods? - http://tinyurl.com/3lzocj9 - cool-RR - <pre>Hello, Today I was trying to use `total_ordering` for the first time. I was expecting that in order to implement e.g. `x &gt; y` it would do `not x &lt; y and not x == y`, assuming that `__lt__` and `__eq__` are defined. But I see it just does `y &lt; x`, which is problematic. For example if you have a class that is decorated by `total_ordering`, and implements only `__lt__` and `__eq__`, then trying to do `x &lt; y` will result in infinite recursion. Why not have `total_ordering` work in the way I suggested? Ram. </pre>", "group_id": 8954, "id": 806137}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303759804.784795, "message": "[devel] - Re: Why doesn't `functools.total_ordering` use theexisting ordering methods? - http://tinyurl.com/3s4wtdt - Raymond Hettinger - <pre> On Apr 25, 2011, at 11:43 AM, cool-RR wrote: This was fixed. The current code has: convert = { '__lt__': [('__gt__', lambda self, other: not (self &lt; other or self == other)), ('__le__', lambda self, other: self &lt; other or self == other), ('__ge__', lambda self, other: not self &lt; other)], '__le__': [('__ge__', lambda self, other: not self &lt;= other or self == other), ('__lt__', lambda self, other: self &lt;= other and not self == other), ('__gt__', lambda self, other: not self &lt;= other)], '__gt__': [('__lt__', lambda self, other: not (self &gt; other or self == other)), ('__ge__', lambda self, other: self &gt; other or self == other), ('__le__', lambda self, other: not self &gt; other)], '__ge__': [('__le__', lambda self, other: (not self &gt;= other) or self == other), ('__gt__', lambda self, other: self &gt;= other and not self == other), </pre>", "group_id": 8954, "id": 806385}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303802231.6737671, "message": "[devel] - Re: Why doesn't `functools.total_ordering` use the existing ordering methods? - http://tinyurl.com/6lcpoa8 - Lennart Regebro - <pre> This has been partly fixed for Python 3.2, although it can still happen if you compare two types that both use the total_ordering decorator. See http://bugs.python.org/issue10042 . </pre>", "group_id": 8954, "id": 811363}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303804928.439661, "message": "[devel] - Re: cpython (2.7): #11901: add description of how bitfields are laid out to hexversion docs - http://tinyurl.com/4y2xkmp - Georg Brandl - <pre> Should have a colon at the end. We usually have table headings capitalized. Even though PY_RELEASE_LEVEL_GAMMA is defined, I think this should say \"release candidate\" instead of \"gamma\". ... and zero in final releases. Please capitalize and add a period. Georg </pre>", "group_id": 8954, "id": 811589}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303827631.905432, "message": "[devel] - Re: [Python-checkins] cpython (3.2): Issue #11919: try to fix test_imp failure on some buildbots. - http://tinyurl.com/3tln6ae - Jim Jewett - <pre>This seems to be changing what is tested -- are you saying that filenames with an included directory name are not intended to be supported? On 4/25/11, antoine.pitrou &lt;python-checkins&lt; at &gt;python.org&gt; wrote: </pre>", "group_id": 8954, "id": 814858}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303827635.532625, "message": "[devel] - Re: [Python-checkins] cpython (3.2): Issue #11919: try to fix test_imp failure on some buildbots. - http://tinyurl.com/68zuagz - Antoine Pitrou - <pre>Le mardi 26 avril 2011 \u00e0 10:03 -0400, Jim Jewett a \u00e9crit : I don't know, but that's not the point of this very test. (I also find it a bit surprising that find_module() would accept a module name - and not a filename - containing a slash and treat it as some kind of directory path) Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 814859}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303832131.1058021, "message": "[devel] - Tip for hg merge - http://tinyurl.com/3w4s4kf - \u00c9ric Araujo - <pre>Hi, Here\u2019s a useful tip: instead of merging pulled changesets with your branch, do the reverse. That is: $ hg pull $ hg heads . # get only heads for the checked-out branch $ hg up other-head $ hg merge Now instead of merging unknown code into your checkout, you will merge the code added by your unpushed changesets to the other code. If you\u2019re using a three-way file merge tool, it is your code that will be in the \u201cother\u201d pane, not the unknown code. Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 815706}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303840289.6676619, "message": "[devel] - Allowing import star with namespaces - http://tinyurl.com/3out2ku - Brendan Moloney - <pre>We all know that doing: is bad because it obliterates the 'pkg' namespace. So why not allow something like: This would still be helpful for interactive sessions while keeping namespaces around. Sorry if this has been brought up before, my searching didn't find anything relevant in the archives. Thanks, Brendan </pre>", "group_id": 8954, "id": 817113}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303841189.646733, "message": "[devel] - Re: Allowing import star with namespaces - http://tinyurl.com/3vvw4y4 - Steven D'Aprano - <pre> I don't quite know what you mean by obliterating the pkg namespace, but if my guess is correct, you're wrong. One of the problems with import * is that it (potentially) obliterates the caller's namespace, not pkg. That is, if you have a function spam(), and you do \"from module import *\", and module also has spam(), it blows away your function. The pkg namespace isn't touched -- it's just unavailable to the caller. &gt;&gt; import pkg.* I don't understand what the difference between that and just \"import pkg\" would be. By the way, this sort of question should probably go to the python-ideas mailing list for any extended discussion. </pre>", "group_id": 8954, "id": 817204}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303841192.9912889, "message": "[devel] - Re: Allowing import star with namespaces - http://tinyurl.com/3b2a4sg - Ethan Furman - <pre> The strongest reason for not doing this is that it pollutes the current namespace, not that it obliterates the 'pkg' namespace. How would that be different from --&gt; import pkg ? If you want convenience for interactive work, you can always: --&gt; import pkg --&gt; from pkg import * and then have the best (and worst!) of both techniques. ~Ethan~ </pre>", "group_id": 8954, "id": 817205}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303841197.452847, "message": "[devel] - Re: cpython: test_logging coverage improvements. - http://tinyurl.com/3jjfqk4 - Antoine Pitrou - <pre>On Tue, 26 Apr 2011 19:43:12 +0200 vinay.sajip &lt;python-checkins&lt; at &gt;python.org&gt; wrote: Apparently produces some failures: ====================================================================== FAIL: test_time (test.test_logging.FormatterTest) ---------------------------------------------------------------------- Traceback (most recent call last): File \"/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_logging.py\", line 2238, in test_time self.assertEqual(f.formatTime(r), '1993-04-21 08:03:00,123') AssertionError: '1993-04-21 09:03:00,123' != '1993-04-21 08:03:00,123' - 1993-04-21 09:03:00,123 ? ^ + 1993-04-21 08:03:00,123 ? ^ (http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%203.x/builds/121/steps/test/logs/stdio) Regards Antoine. </pre>", "group_id": 8954, "id": 817206}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303844010.503737, "message": "[devel] - Simple XML-RPC server over SSL/TLS - http://tinyurl.com/3sfadw5 - Marc Garcia - <pre>Hi there, I'm working on a project where I'm using Python's simple XML-RPC server [1] on Python 3.x. I need to use it over TLS, which is not possible directly, but it's pretty simple to implement extending few classes of the standard library. But what I would like to know, is if is there any reason why XML-RPC can't optionally work over TLS/SSL using Python's ssl module. I'll create a ticket, and send a patch, but I was wondering if it was a reason why this was not implemented. Cheers, Marc 1. http://docs.python.org/dev/library/xmlrpc.server.html </pre>", "group_id": 8954, "id": 817634}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303845809.9767389, "message": "[devel] - Re: Issue Tracker - http://tinyurl.com/6xpwj4k - Ethan Furman - <pre>Okay, I finally found a little time and got roundup installed and operating. Only major complaint at this point is that the issue messages are presented in top-post format (argh). Does anyone know off the top of one's head what to change to put roundup in bottom-post (chronological) format? TIA! ~Ethan~ </pre>", "group_id": 8954, "id": 817927}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303844910.906301, "message": "[devel] - Re: Allowing import star with namespaces - http://tinyurl.com/6abeqzl - Brendan Moloney - <pre> Sorry, I phrased that badly. When I said \"obliterates the 'pkg' namespace\" I was referring to dumping the 'pkg' namespace into the current namespace (polluting it, as you would say). Because that does not import all of the (public) modules and packages under 'pkg'. For example scipy has has a subpackage 'linalg'. If I just do 'import scipy' then I can not refer to 'scipy.linalg' until I do 'import scipy.linalg'. Steven D'Aprano wrote: Sorry, didn't realize that would be the more appropriate list. Thanks, Brendan </pre>", "group_id": 8954, "id": 817782}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303852171.427495, "message": "[devel] - Re: [Python-checkins] cpython (3.2): Issue #11919: try to fix test_imp failure on some buildbots. - http://tinyurl.com/62h2hhd - Victor Stinner - <pre>Le mardi 26 avril 2011 \u00e0 10:03 -0400, Jim Jewett a \u00e9crit : The test checks the Python parser, not the imp module :-) I don't understand why: sometimes, find_module() accepts a (relative) path, sometimes it doesn't. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 818890}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303867592.1313241, "message": "[devel] - Re: Issue Tracker - http://tinyurl.com/6zgkqrp - Ezio Melotti - <pre>See line 309 of http://svn.python.org/view/tracker/instances/python-dev/html/issue.item.html?view=markup If you have other questions about Roundup see https://lists.sourceforge.net/lists/listinfo/roundup-users Best Regards, Ezio Melotti </pre>", "group_id": 8954, "id": 820500}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303897413.0788989, "message": "[devel] - PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6kuopxy - Hrvoje Niksic - <pre>The other day I was surprised to learn this: &gt;&gt;&gt; nan = float('nan') &gt;&gt;&gt; nan == nan False &gt;&gt;&gt; [nan] == [nan] True # also True in tuples, dicts, etc. # also: &gt;&gt;&gt; l = [nan] &gt;&gt;&gt; nan in l True &gt;&gt;&gt; l.index(nan) 0 &gt;&gt;&gt; l[0] == nan False The identity test is not in container comparators, but in PyObject_RichCompareBool: /* Quick result when objects are the same. Guarantees that identity implies equality. */ if (v == w) { if (op == Py_EQ) return 1; else if (op == Py_NE) return 0; } The guarantee referred to in the comment is not only (AFAICT) undocumented, but contradicts the documentation, which states that the result should be the \"equivalent of o1 op o2\". Calling PyObject_RichCompareBool is inconsistent with calling PyObject_RichCompare and converting its result to bool manually, something that wrappers (C++) and generators (cython) might reasonably want to do themselves, for various reasons. If this is considere</pre>", "group_id": 8954, "id": 823919}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303904734.087929, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3lvnljk - \u0141ukasz Langa - <pre>Wiadomo\u015b\u0107 napisana przez Hrvoje Niksic w dniu 2011-04-27, o godz. 11:37: This surprises me as well. I guess this is all related to the fact that: True Have a look at this as well: True True True 0 True # Or even: True For the infinity part, I believe this is related to the funky IEEE 754 standard. I found some discussion about this here: http://compilers.iecc.com/comparch/article/98-07-134 </pre>", "group_id": 8954, "id": 824576}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303907495.2722771, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3k6qqaf - Nick Coghlan - <pre>2011/4/27 \u0141ukasz Langa &lt;lukasz&lt; at &gt;langa.pl&gt;: The inf behaviour is fine (inf != inf only when you start talking about aleph levels, and IEEE 754 doesn't handle those). It's specifically `nan` that is problematic, as it is one of the very few cases that breaks the reflexivity of equality. That said, the current behaviour was chosen deliberately so that containers could cope with `nan` at least somewhat gracefully: http://bugs.python.org/issue4296 Issue 10912 added an explicit note about this behaviour to the 3.x series documentation, but that has not as yet been backported to 2.7 (I reopened the issue to request such a backport). Cheers, Nick. </pre>", "group_id": 8954, "id": 825122}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303916497.740104, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3h2zrv8 - Guido van Rossum - <pre>On Wed, Apr 27, 2011 at 7:39 AM, Raymond Hettinger &lt;raymond.hettinger&lt; at &gt;gmail.com&gt; wrote: Maybe we should just call off the odd NaN comparison behavior? </pre>", "group_id": 8954, "id": 826918}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303916493.987108, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6gpu7pt - Raymond Hettinger - <pre> On Apr 27, 2011, at 2:37 AM, Hrvoje Niksic wrote: Would also be surprised if you put an object in a dictionary but couldn't get it out? Or added it to a list but its count was zero? Identity-implies-equality is necessary so that classes can maintain their invariants and so that programmers can reason about their code. It is not just in PyObject_RichCompareBool, it is deeply embedded in the language (the logic inside dicts for example). It is not a short-cut, it is a way of making sure that internally we can count on equality relations reflexive, symmetric, and transitive. A programmer needs to be able to make basic deductions such as the relationship between the two forms of the in-operator: for elem in somelist: assert elem in somelist # this should never fail. What surprises me is that anyone gets surprised by anything when experimenting with an object that isn't equal to itself. It is roughly in the same category as creating a __hash__ that has no relationship to __eq__ or making self-refere</pre>", "group_id": 8954, "id": 826916}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303919199.078378, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5wcwh9v - Alexander Belopolsky - <pre>.. +1 There was a long thread on this topic last year: http://mail.python.org/pipermail/python-dev/2010-March/098832.html I was trying to find a rationale for non-reflexivity of equality in IEEE and although it is often mentioned that this property simplifies some numerical algorithms, I am yet to find an important algorithm that would benefit from it. I also believe that long history of suboptimal hardware implementations of nan arithmetics has stifled the development of practical applications. High performance applications that rely on non-reflexivity will still have an option of using ctypes.c_float type or NumPy. </pre>", "group_id": 8954, "id": 827452}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303920996.453135, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6fxzjlr - Alexander Belopolsky - <pre>.. Why? float('nan') has always been in the use-at-your-own-risk territory despite recent efforts to support it across Python platforms. I cannot speak about decimal.Decimal (and decimal is a different story because it is tied to a particular standard), but the only use of non-reflexifity for float nans I've seen was use of x != x instead of math.isnan(x). These are orthogonal issues. A third party type that plays with __eq__ and other basic operations can easily break stdlib algorithms no matter what we do. Therefore it is important to document the properties of the types that each algorithm relies on. It is more important, however that stdlib types do not break 3rd party's algorithms. I don't think I've ever seen a third party type that deliberately defines a non-reflexive __eq__ except as a side effect of using float attributes or C float members in the underlying structure. (Yes, decimal is a counter-example, but this is a very special case.) </pre>", "group_id": 8954, "id": 827789}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303919196.1226599, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3hmqskm - Nick Coghlan - <pre> Rereading Meyer's article (I read it last time this came up, but it's a nice piece, so I ended up going over it again this time) the quote that leapt out at me was this one: \"\"\"A few of us who had to examine the issue recently think that \u2014 whatever the standard says at the machine level \u2014 a programming language should support the venerable properties that equality is reflexive and that assignment yields equality. Every programming language should decide this on its own; for Eiffel we think this should be the specification. Do you agree?\"\"\" Currently, Python tries to split the difference: \"==\" and \"!=\" follow IEEE754 for NaN, but most other operations involving builtin types rely on the assumption that equality is always reflexive (and IEEE754 be damned). What that means is that \"correct\" implementations of methods like __contains__, __eq__, __ne__, index() and count() on containers should be using \"x is y or x == y\" to enforce reflexivity, but most such code does not (e.g. our own collections.abc.Se</pre>", "group_id": 8954, "id": 827450}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303920999.900542, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/69ha2ak - Alexander Belopolsky - <pre>.. math.isnan() is implemented in C and does not rely on float.__eq__ in any way. </pre>", "group_id": 8954, "id": 827790}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303920993.9913709, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6hyp4h4 - Nick Coghlan - <pre>On Thu, Apr 28, 2011 at 1:43 AM, Alexander Belopolsky &lt;alexander.belopolsky&lt; at &gt;gmail.com&gt; wrote: However, that's exactly the reason I don't see any reason to reverse course on having float() and Decimal() follow IEEE754 semantics, regardless of how irritating we may find those semantics to be. Since we allow types to customise __eq__ and __ne__ with non-standard behaviour, if we want to permit *any* type to have a non-reflexive notion of equality, then we need to write our container types to enforce reflexivity when appropriate. Many of the builtin types already do this, by virtue of it being built in to RichCompareBool. It's now a matter of documenting that properly and updating the non-conformant types accordingly. Cheers, Nick. </pre>", "group_id": 8954, "id": 827788}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303922796.9536359, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3l3e72o - Isaac Morland - <pre> Alexander Belopolsky pointed out to me (thanks!) that isnan is implemented in C so my caveat about the implementation of isnan is not an issue. But then that made me realize the ieee_equal (or just \"eq\" if that's preferable) probably ought to be implemented in C using a floating point comparison - i.e., use the processor implementation of the comparison operation.. Isaac MorlandCSCF Web Guru DC 2554C, x36650WWW Software Specialist </pre>", "group_id": 8954, "id": 828150}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303921895.593025, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6euyb66 - Isaac Morland - <pre> Python could also provide IEEE-754 equality as a function (perhaps in \"math\"), something like: def ieee_equal (a, b): return a == b and not isnan (a) and not isnan (b) Of course, the definition of math.isnan cannot then be by checking its argument by comparison with itself - it would have to check the appropriate bits of the float representation. Isaac MorlandCSCF Web Guru DC 2554C, x36650WWW Software Specialist </pre>", "group_id": 8954, "id": 828006}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303921897.9458289, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6ygv8by - Antoine Pitrou - <pre>On Wed, 27 Apr 2011 12:05:12 -0400 (EDT) Isaac Morland &lt;ijmorlan&lt; at &gt;uwaterloo.ca&gt; wrote: +1 (perhaps call it math.eq()). Regards Antoine. </pre>", "group_id": 8954, "id": 828007}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303922794.0391331, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3ssrt6h - Raymond Hettinger - <pre> On Apr 27, 2011, at 7:53 AM, Guido van Rossum wrote: I'm reluctant to suggest changing such enshrined behavior. ISTM, the current state of affairs is reasonable. Exotic objects are allowed to generate exotic behaviors but consumers of those objects are free to ignore some of those behaviors by making reasonable assumptions about how an object should behave. It's possible to make objects where the __hash__ doesn't correspond to __eq__.; they just won't behave well with hash tables. Likewise, it's possible for a sequence to define a __len__ that is different from it true length; it just won't behave well with the various pieces of code that assume collections are equal if the lengths are unequal. All of this seems reasonable to me. Raymond </pre>", "group_id": 8954, "id": 828149}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303923694.4067509, "message": "[devel] - Re: Issue Tracker - http://tinyurl.com/6bm99wh - Ethan Furman - <pre> Thanks so much! That was just what I needed. ~Ethan~ </pre>", "group_id": 8954, "id": 828295}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303925496.0977311, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3mlb449 - Alexander Belopolsky - <pre>On Wed, Apr 27, 2011 at 12:28 PM, Raymond Hettinger &lt;raymond.hettinger&lt; at &gt;gmail.com&gt; wrote: Unfortunately NaNs are not that exotic. They can be silently produced in calculations and lead to hard to find errors. For example: nan This means that every program dealing with float data has to detect nans at every step and handle them correctly. This in turn makes it impossible to write efficient code that works equally well with floats and integers. Note that historically, Python was trying hard to prevent production of non-finite floats. AFAICT, none of the math functions would produce inf or nan. I am not sure why arithmetic operations are different. For example: inf but Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt; OverflowError: (34, 'Result too large') and Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt; OverflowError: math range error </pre>", "group_id": 8954, "id": 828701}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303926456.8299429, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/65szpbd - Terry Reedy - <pre> &gt;&gt; Identity-implies-equality is necessary so that classes can maintain &gt;&gt; their invariants and so that programmers can reason about their code. [snip] I carefully reread this, with the comments, and again came to the conclusion that the committee left us no *good* answer, only a choice between various more-or-less unsatifactory answers. The current Python compromise may be as good as anything. In any case, I think it should be explicitly documented with an indexed paragraph, perhaps as follows: \"The IEEE-754 committee defined the float Not_a_Number (NaN) value as being incomparable with all others floats, including itself. This violates the math and logic rule that equality is reflexive, that 'a == a' is always True. And Python collection classes depend on that rule for their proper operation. So Python makes the follow compromise. Direct equality comparisons involving Nan, such as \"NaN=float('NaN'); NaN == ob\", follow the IEEE-754 rule and return False. Indirect comparisons conducted intern</pre>", "group_id": 8954, "id": 829070}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303926454.484262, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5vbwtxu - Raymond Hettinger - <pre> On Apr 27, 2011, at 10:16 AM, Alexander Belopolsky wrote: They're exotic in the sense that they have the unusual property of not being equal to themselves. Exotic (adj) strikingly strange or unusual Raymond </pre>", "group_id": 8954, "id": 829068}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303930115.5169089, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3mujhd2 - Glenn Linderman - <pre> +1 to everything Nick said. One issue that I don't fully understand: I know there is only one instance of None in Python, but I'm not sure where to discover whether there is only a single, or whether there can be multiple, instances of NaN or Inf. The IEEE 754 spec is clear that there are multiple bit sequences that can be used to represent these, so I would hope that there can be, in fact, more than one value containing NaN (and Inf). This would properly imply that a collection should correctly handle the case of storing multiple, different items using different NaN (and Inf) instances. A dict, for example, should be able to hold hundreds of items with the index value of NaN. The distinction between \"is\" and \"==\" would permit proper operation, and I believe that Python's \"rebinding\" of names to values rather than the copying of values to variables makes such a distinction possible to use in a correct manner. Can someone confirm or explain this issue? </pre>", "group_id": 8954, "id": 830096}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303931014.476546, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/63tgchn - Robert Kern - <pre> I suspect most of us would oppose changing it on general backwards-compatibility grounds rather than actually *liking* the current behavior. If the behavior changed with Python floats, we'd have to mull over whether we try to match that behavior with our scalar types (one of which subclasses from float) and our arrays. We would be either incompatible with Python or C, and we'd probably end up choosing Python to diverge from. It would make a mess, honestly. We already have to explain why equality is funky for arrays (arr1 == arr2 is a rich comparison that gives an array, not a bool, so we can't do containment tests for lists of arrays), so NaN is pretty easy to explain afterward. </pre>", "group_id": 8954, "id": 830556}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303934618.4950161, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3foe98y - Terry Reedy - <pre> Which is why I proposed a Glossary entry in another post. +1 to making my proposed text consistenly true if not now ;-). Robert Kern confirmed my suspicion about this relative to numpy. &gt; It also wouldn't achieve much, since we Good point. </pre>", "group_id": 8954, "id": 831670}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303934615.1624329, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5w8oyoc - Terry Reedy - <pre> I am sure there are multiple instances with just one bit pattern, the same as other floats. Otherwise, float('nan') would have to either randomly or systematically choose from among the possibilities. Ugh. There are functions in the math module that pull apart (and put together) floats. &gt; The IEEE 754 spec is clear that there are multiple bit Anyone actually interested in those should use C or possibly the math module float assembly function. &gt; so I would hope that If you do not know which pattern is which, what use could such passibly be? </pre>", "group_id": 8954, "id": 831668}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303939115.6665699, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6emngpx - Mark Dickinson - <pre> That one surprises me a bit too: I knew we were using identity-then-equality checks for containment (nan in [nan]), but I hadn't realised identity-then-equality was also used for the item-by-item comparisons when comparing two lists. It's defensible, though: [nan] == [nan] should presumably produce the same result as {nan} == {nan}, and the latter is a test that's arguably based on containment (for sets s and t, s == t if each element of s is in t, and vice versa). I don't think any of this should change. It seems to me that we've currently got something approaching the best approximation to consistency and sanity achievable, given the fundamental incompatibility of (1) nan breaking reflexivity of equality and (2) containment being based on equality. That incompatibility is bound to create inconsistencies somewhere along the line. Declaring that 'nan == nan' should be True seems attractive in theory, but I agree that it doesn't really seem like a realistic option in terms of backwards compatibility an</pre>", "group_id": 8954, "id": 832831}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303939119.2553079, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6catrbb - Mark Dickinson - <pre> For infinities, there's no issue: there are exactly two distinct infinities (+inf and -inf), and they don't have any special properties that affect membership tests. Your float-keyed dict can contain both +inf and -inf keys, or just one, or neither, in exactly the same way that it can contain both +5.0 and -5.0 as keys, or just one, or neither. For nans, you *can* put multiple nans into a dictionary as separate keys, but under the current rules the test for 'sameness' of two nan keys becomes a test of object identity, not of bitwise equality. Python takes no notice of the sign bits and 'payload' bits of a float nan, except in operations like struct.pack and struct.unpack. For example: True True 1 2 But using struct.pack, you can see that x and y are bitwise identical: True Mark _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-d</pre>", "group_id": 8954, "id": 832834}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303940016.0513511, "message": "[devel] - Socket servers in the test suite - http://tinyurl.com/6km4tpw - Vinay Sajip - <pre>I've been recently trying to improve the test coverage for the logging package, and have got to a not unreasonable point: logging/__init__.py 99% (96%) logging/config.py 89% (85%) logging/handlers.py 60% (54%) where the figures in parentheses include branch coverage measurements. I'm at the point where to appreciably increase coverage, I'd need to write some test servers to exercise client code in SocketHandler, DatagramHandler and HTTPHandler. I notice there are no utility classes in test.support to help with this kind of thing - would there be any mileage in adding such things? Of course I could add test server code just to test_logging (which already contains some socket server code to exercise the configuration functionality), but rolling a test server involves boilerplate such as using a custom RequestHandler-derived class for each application. I had in mind a more streamlined approach where you can just pass a single callable to a server to handle requests, e.g. as outlined in https://gist.github.</pre>", "group_id": 8954, "id": 833067}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303944515.4921811, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6kxuoec - Greg Ewing - <pre> That's probably as good an idea as anything. The weirdness of NaNs is supposed to ensure that they propagate through a computation as a kind of exception signal. But to make that work properly, comparing two NaNs should really give you a NaB (Not a Boolean). As long as we're not doing that, we might as well treat NaNs sanely as Python objects. </pre>", "group_id": 8954, "id": 833695}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303943616.8377581, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/444jj6z - Glenn Linderman - <pre>Thanks, Mark, for the succinct description and demonstration. Yes, only two Inf values, many possible NaNs. And this is what I would expect. I would not, however expect the original case that was described: &gt;&gt;&gt; nan = float('nan') &gt;&gt;&gt; nan == nan False &gt;&gt;&gt; [nan] == [nan] True # also True in tuples, dicts, etc. </pre>", "group_id": 8954, "id": 833588}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303950041.3588381, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6ksjoub - Steven D'Aprano - <pre> I think Glenn is asking whether NANs are singletons. They're not: &gt;&gt;&gt; x = float('nan') &gt;&gt;&gt; y = float('nan') &gt;&gt;&gt; x is y False &gt;&gt;&gt; [x] == [y] False I'd like to point out that way back in the 1980s, Apple's Hypercard allowed users to construct, and compare, distinct NANs without needing to use C or check bit patterns. I think it is painful and ironic that a development system aimed at non-programmers released by a company notorious for \"dumbing down\" interfaces over 20 years ago had better and simpler support for NANs than we have now. </pre>", "group_id": 8954, "id": 834490}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303950935.705384, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3sx26hz - Steven D'Aprano - <pre> That doesn't follow. You can compare NANs, and the result of the comparisons are perfectly well defined by either True or False. There's no need for a NAB comparison flag. </pre>", "group_id": 8954, "id": 834569}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303950035.3520391, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6g3lkpf - Glenn Linderman - <pre> I think it should change. Inserting a NaN, even the same instance of NaN into a list shouldn't suddenly make it compare equal to itself, especially since the docs (section 5.9. Comparisons) say: * Tuples and lists are compared lexicographically using comparison of corresponding elements. This means that to compare equal, each element must compare equal and the two sequences must be of the same type and have the same length. If not equal, the sequences are ordered the same as their first differing elements. For example, [1,2,x] &lt;= [1,2,y] has the same value as x &lt;= y. If the corresponding element does not exist, the shorter sequence is ordered first (for example, [1,2] &lt; [1,2,3]). The principle of least surprise, says that if two unequal items are inserted into otherwise equal lists, the lists should be unequal. NaN is unequal to itself. </pre>", "group_id": 8954, "id": 834488}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303950038.788027, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/62lbjno - Steven D'Aprano - <pre> This doesn't solve the broader problem that *any* type might deliberately define non-reflexive equality, and therefore people will still be surprised by &gt;&gt;&gt; x = SomeObject() &gt;&gt;&gt; x == x False &gt;&gt;&gt; [x] == [x] True The \"problem\" (if it is a problem) here is list, not NANs. Please don't break NANs to not-fix a problem with list. Since we can't (can we?) prohibit non-reflexivity, and even if we can, we shouldn't, reasonable solutions are: (1) live with the fact that lists and other built-in containers will short-cut equality with identity for speed, ignoring __eq__; (2) slow containers down by guaranteeing that they will use __eq__; (but how much will it actually hurt performance for real-world cases? and this will have the side-effect that non-reflexivity will propagate to containers) (3) allow types to register that they are non-reflexive, allowing containers to skip the identity shortcut when necessary. (but it is not clear to me that the extra complexity will be worth the cost) My vote</pre>", "group_id": 8954, "id": 834489}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303950937.9868169, "message": "[devel] - Re: [Python-checkins] cpython: PyGILState_Ensure(), PyGILState_Release(), PyGILState_GetThisThreadState() are - http://tinyurl.com/6bhbwxt - Jim Jewett - <pre>Would it be a problem to make them available a no-ops? On 4/26/11, victor.stinner &lt;python-checkins&lt; at &gt;python.org&gt; wrote: </pre>", "group_id": 8954, "id": 834570}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303952755.6023879, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3h4lpoc - Ethan Furman - <pre> Totally out of my depth, but what if the a NaN object was allowed to compare equal to itself, but different NaN objects still compared unequal? If NaN was a singleton then the current behavior makes more sense, but since we get a new NaN with each instance creation is there really a good reason why the same NaN can't be equal to itself? ~Ethan~ </pre>", "group_id": 8954, "id": 834753}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303953698.1016049, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6bjcp3u - Glenn Linderman - <pre> I think it is perfectly reasonable that containers containing items with non-reflexive equality should sometimes have non-reflexive equality also (depends on the placement of the item in the container, and the values of other items, whether the non-reflexive equality of an internal item will actually affect the equality of the container in practice). I quoted the docs for tuple and list comparisons in a different part of this thread, and for those types, the docs are very clear that the items must compare equal for the lists or tuples to compare equal. For other built-in types, the docs are less clear: * Mappings (dictionaries) compare equal if and only if they have the same (key, value) pairs. Order comparisons ('&lt;', '&lt;=', '&gt;=', '&gt;') raise TypeError &lt;http://docs.python.org/py3k/library/exceptions.html#TypeError&gt;. So we can immediately conclude that mappings do not provide an ordering for sorts. But, the language \"same (key, value)\" pairs implies identity compariso</pre>", "group_id": 8954, "id": 834935}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303954596.542619, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3pv4a5s - Glenn Linderman - <pre> &gt;&gt;&gt; n1 = float('NaN') &gt;&gt;&gt; n2 = float('NaN') &gt;&gt;&gt; n3 = n1 &gt;&gt;&gt; n1 nan &gt;&gt;&gt; n2 nan &gt;&gt;&gt; n3 nan &gt;&gt;&gt; [n1] == [n2] False &gt;&gt;&gt; [n1] == [n3] True This is the current situation: some NaNs compare equal sometimes, and some don't. And unless you are particularly aware of the identity of the object containing the NaN (not the list, but the particular NaN value) it is surprising and confusing, because the mathematical definition of NaN is that it should not be equal to itself. </pre>", "group_id": 8954, "id": 835045}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303954598.983151, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6c2kvel - Glenn Linderman - <pre> Pardon me, please ignore the parenthetical statement... it was really inspired by inequality comparisons, not equality comparisons. </pre>", "group_id": 8954, "id": 835047}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303959157.5844879, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/62vams7 - Stephen J. Turnbull - <pre> &gt; Declaring that 'nan == nan' should be True seems attractive in &gt; theory, No, it's intuitively attractive, but that's because humans like nice continuous behavior. In *theory*, it's true that some singularities are removable, and the NaN that occurs when evaluating at that point is actually definable in a broader context, but the point of NaN is that some singularities are *not* removable. This is somewhat Pythonic: \"In the presence of ambiguity, refuse to guess.\" </pre>", "group_id": 8954, "id": 835708}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303958257.040283, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/3kx3l8j - Nick Coghlan - <pre> If you poke around in the test directory a bit, you may find there is already some code along these lines in other tests (e.g. I'm pretty sure the urllib tests already fire up a local server). Starting down the path of standardisation of that test functionality would be good. For larger components like this, it's also reasonable to add a dedicated helper module rather than using test.support directly. I started (and Antoine improved) something along those lines with the test.script_helper module for running Python subprocesses and checking their output, although it lacks documentation and there are lots of older tests that still use subprocess directly. Cheers, Nick. </pre>", "group_id": 8954, "id": 835624}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303958259.534682, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3baku7p - Stephen J. Turnbull - <pre> &gt; I would not, however expect the original case that was described: &gt; &gt;&gt;&gt; nan = float('nan') &gt; &gt;&gt;&gt; nan == nan &gt; False &gt; &gt;&gt;&gt; [nan] == [nan] &gt; True # also True in tuples, dicts, etc. Are you saying you would expect that False ?? I wouldn't even expect False but I guess I have to live with that.&lt;wink&gt; While I wouldn't apply it to other people, I have to admit Raymond's aphorism applies to me (the surprising thing is not the behavior of NaNs, but that I'm surprised by anything that happens in the presence of NaNs!) </pre>", "group_id": 8954, "id": 835625}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303960960.7433519, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3lnwo8r - Guido van Rossum - <pre>On Wed, Apr 27, 2011 at 9:28 AM, Raymond Hettinger &lt;raymond.hettinger&lt; at &gt;gmail.com&gt; wrote: No doubt there would be some problems; probably more for decimals than for floats. Hardly; when I picked the NaN behavior I knew the IEEE std prescribed it but had never seen any code that used this. I'd say that the various issues and inconsistencies brought up (e.g. x in A even though no a in A equals x) make it clear that one ignores NaN's exoticnesss at one's peril. That's not the same thing at all. Such an object would violate a rule of the language (although one that Python cannot strictly enforce) and it would always be considered a bug. Currently NaN is not violating any language rules -- it is just violating users' intuition, in a much worse way than Inf does. (All in all, Inf behaves pretty intuitively, at least for someone who was awake during at least a few high school math classes. NaN is not discussed there. :-) (you probably meant \"are never equal\") Again, typically a bug. Given the IEEE std and</pre>", "group_id": 8954, "id": 835925}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303960957.525681, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3r2rc6t - Stephen J. Turnbull - <pre> &gt; On 4/27/2011 6:11 PM, Ethan Furman wrote: &gt; &gt; Totally out of my depth, but what if the a NaN object was allowed to &gt; &gt; compare equal to itself, but different NaN objects still compared &gt; &gt; unequal? If NaN was a singleton then the current behavior makes more &gt; &gt; sense, but since we get a new NaN with each instance creation is there &gt; &gt; really a good reason why the same NaN can't be equal to itself? Yes. A NaN is a special object that means \"the computation that produced this object is undefined.\" For example, consider the computation 1/x at x = 0. If you approach from the left, 1/0 \"obviously\" means minus infinity, while if you approach from the right just as obviously it means plus infinity. So what does the 1/0 that occurs in [1/x for x in range(-5, 6)] mean? In what sense is it \"equal to itself\"? How can something which is not a number be compared for numerical equality? &gt; &gt;&gt;&gt; n1 = float('NaN') &gt; &gt;&gt;&gt; n2 = float('NaN') &gt; &gt;&gt;&gt; n3 = n1 &gt; &gt; &gt;&gt;&gt; n1 &gt; nan &gt; &gt;&gt;&gt; n2 &gt; nan &gt; &gt;&gt;&gt;</pre>", "group_id": 8954, "id": 835924}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303960962.8135581, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6974svl - Guido van Rossum - <pre> So does NumPy also follow Python's behavior about ignoring the NaN special-casing when doing array ops? </pre>", "group_id": 8954, "id": 835926}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303962756.148247, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/69q339z - Robert Kern - <pre> By \"ignoring the NaN special-casing\", do you mean that identity is checked first? When we use dtype=object arrays (arrays that contain Python objects as their data), yes: [~] |1&gt; nan = float('nan') [~] |2&gt; import numpy as np [~] |3&gt; a = np.array([1, 2, nan], dtype=object) [~] |4&gt; nan in a True [~] |5&gt; float('nan') in a False Just like lists: [~] |6&gt; nan in [1, 2, nan] True [~] |7&gt; float('nan') in [1, 2, nan] False Actually, we go a little further by using PyObject_RichCompareBool() rather than PyObject_RichCompare() to implement the array-wise comparisons in addition to containment: [~] |8&gt; a == nan array([False, False, True], dtype=bool) [~] |9&gt; [x == nan for x in [1, 2, nan]] [False, False, False] But for dtype=float arrays (which contain C doubles, not Python objects) we use C semantics. Literally, we use whatever C's == operator gives us for the two double values. Since there is no concept of identity for this case, there is no cognate behavior of Python to match. [~] |10&gt; b = np</pre>", "group_id": 8954, "id": 836200}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303962758.9043181, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6j3q3e3 - Nick Coghlan - <pre>On Thu, Apr 28, 2011 at 12:42 PM, Stephen J. Turnbull &lt;stephen&lt; at &gt;xemacs.org&gt; wrote: Refusing to guess in this case would be to treat all NaNs as signalling NaNs, and that wouldn't be good, either :) I like Terry's suggestion for a glossary entry, and have created an updated proposal at http://bugs.python.org/issue11945 (I also noted that array.array is like collections.Sequence in failing to enforce the container invariants in the presence of NaN values) Cheers, Nick. </pre>", "group_id": 8954, "id": 836202}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303963656.6929801, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5scjkly - Guido van Rossum - <pre> Hm, this sounds like NumPy always considers a NaN equal to *itself* as long as objects are concerned. And I wouldn't want to change that. It sounds like NumPy wouldn't be much affected if we were to change this (which I'm not saying we would). Thanks! </pre>", "group_id": 8954, "id": 836305}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303964561.879847, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3kajvqt - Alexander Belopolsky - <pre>.. Most NumPy applications are actually not exposed to NaN problems because it is recommended that NaNs be avoided in computations and when missing or undefined values are necessary, the recommended solution is to use ma.array or masked array which is a drop-in replacement for numpy array type and carries a boolean \"mask\" value with every element. This allows to have undefined elements is arrays of any type: float, integer or even boolean. Masked values propagate through all computations including comparisons. </pre>", "group_id": 8954, "id": 836367}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303965457.7139521, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3hopfxm - Guido van Rossum - <pre>On Wed, Apr 27, 2011 at 9:15 PM, Alexander Belopolsky &lt;alexander.belopolsky&lt; at &gt;gmail.com&gt; wrote: So do new masks get created when the outcome of an elementwise operation is a NaN? Because that's the only reason why one should have NaNs in one's data in the first place -- not to indicate missing values! </pre>", "group_id": 8954, "id": 836505}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303965460.5028081, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/68nsp2e - Robert Kern - <pre> Well, I didn't say that. If Python changed its behavior for (float('nan') == float('nan')), we'd have to seriously consider some changes. We do like to keep *some* amount of correspondence with Python semantics. In particular, we like our scalar types that match Python types to work as close to the Python type as possible. We have the np.float64 type, which represents a C double scalar and corresponds to a Python float. It is used when a single item is indexed out of a float64 array. We even subclass from the Python float type to help working with libraries that may not know about numpy: [~] |5&gt; import numpy as np [~] |6&gt; nan = np.array([1.0, 2.0, float('nan')])[2] [~] |7&gt; nan == nan False [~] |8&gt; type(nan) numpy.float64 [~] |9&gt; type(nan).mro() [numpy.float64, numpy.floating, numpy.inexact, numpy.number, numpy.generic, float, object] If the Python float type changes behavior, we'd have to consider whether to keep that for np.float64 or change it to match the usual C semantics use</pre>", "group_id": 8954, "id": 836506}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303964558.672384, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3gptemt - Guido van Rossum - <pre> Regardless of whether we go any further it would indeed be good to be explicit about the rules in the language reference and fix the behavior of collections.Sequence. I'm not sure about array.array -- it doesn't hold objects so I don't think there's anything to enforce. It seems to behave the same way as NumPy arrays when they don't contain objects. </pre>", "group_id": 8954, "id": 836365}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303965462.6881061, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5v78u7z - Robert Kern - <pre> No. Yes. I'm not sure that Alexander was being entirely clear. Masked arrays are intended to solve just the missing data problem and not the occurrence of NaNs from computations. There is still a persistent part of the community that really does like to use NaNs for missing data, though. I don't think that's entirely relevant to this discussion[1]. I wouldn't say that numpy applications aren't exposed to NaN problems. They are just as exposed to computational NaNs as you would expect any application that does that many flops to be. [1] Okay, that's a lie. I'm sure that persistent minority would *love* to have NaN == NaN, because that would make their (ab)use of NaNs easier to work with. </pre>", "group_id": 8954, "id": 836508}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303967260.1254251, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/63lpt4z - Guido van Rossum - <pre> Ah, but I'm not proposing anything of the sort! float('nan') returns a new object each time and two NaNs that are not the same *object* will still follow the IEEE std. It's just when comparing a NaN-valued *object* to *itself* (i.e. the *same* object) that I would consider following the lead of Python's collections. Yeah, this is where things might change, because it is the same *object* left and right. Given what I just said, would it still be a dilemma? Maybe a smaller one? </pre>", "group_id": 8954, "id": 836716}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303967262.180099, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6e5cnwe - Guido van Rossum - <pre> Too bad, because that won't change. :-) I agree that this is abuse of NaNs and shouldn't be encouraged. </pre>", "group_id": 8954, "id": 836717}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303966356.9671221, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6ctnbwp - Nick Coghlan - <pre> Yep, after reading Robert's post I realised the point about native arrays in NumPy (and the lack of \"object identity\" in those cases) applied equally well to the array module. Cheers, Nick. </pre>", "group_id": 8954, "id": 836593}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303968159.547725, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3mgsftp - Glenn Linderman - <pre> It _can_ be interpreted as a containment question, but doing so is contrary to the documentation of Python list comparison, which presently doesn't match the implementation. The intuitive definition of equality of lists is that each member is equal. The presence of NaN destroys intuition of people that don't expect them to be as different from numbers as they actually are, but for people that understand NaNs and expect them to behave according to their definition, then the presence of a NaN in a list would be expected to cause the list to not be equal to itself, because a NaN is not equal to itself. Some people will be unhappy just because they exist in the language, so I agree :) </pre>", "group_id": 8954, "id": 836853}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303967258.052506, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5u4ydg5 - Glenn Linderman - <pre> Yes, absolutely. Once you understand the definition of NaN, it certainly cannot be True. a is a, but a is not equal to a. The only thing that should happen in the presence of NaNs is more NaNs :) </pre>", "group_id": 8954, "id": 836714}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303968163.4798231, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3jp7no5 - Nick Coghlan - <pre> The reason this possibility bothers me is that it doesn't mesh well with the \"implementations are free to cache and reuse immutable objects\" rule. Although, if the updated NaN semantics were explicit that identity was now considered part of the value of NaN objects (thus ruling out caching them at the implementation layer), I guess that objection would go away. Regards, Nick. </pre>", "group_id": 8954, "id": 836854}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303969962.538599, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3cgop8z - Greg Ewing - <pre> But it's *arbitrarily* defined, and it's far from clear that the definition chosen is useful in any way. If you perform a computation and get a NaN as the result, you know that something went wrong at some point. But if you subject that NaN to a comparison, your code takes some arbitrarily-chosen branch and produces a result that may look plausible but is almost certainly wrong. The Pythonic thing to do (in the Python 3 world at least) would be to regard NaNs as non-comparable and raise an exception. </pre>", "group_id": 8954, "id": 837094}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303969057.648062, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6jqbg4o - Alexander Belopolsky - <pre>.. Same here. The only code I've seen that depended on this NaN behavior was either buggy (programmer did not consider NaN case) or was using x == x as a way to detect nans. The later idiom is universally frowned upon regardless of the language. In Python one should use math.isnan() for this purpose. I would like to present a challenge to the proponents of the status quo. Look through your codebase and find code that will behave differently if nan == nan were True. Then come back and report how many bugs you have found. :-) Seriously, though, I bet that if you find anything, it will fall into one of the two cases I mentioned above. .. Note that ctypes' floats already behave this way: True .. Before we go down this path, I would like to discuss another peculiarity of NaNs: False False This property in my experience causes much more trouble than nan == nan being false. The problem is that common sorting or binary search algorithms may degenerate into infinite loops in the presence of nans. Th</pre>", "group_id": 8954, "id": 836992}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303969958.2850561, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5svdx3q - Alexander Belopolsky - <pre>.. Yes. [-- ] (I don't have numpy on this laptop, so the example is using Numeric, but I hope you guys did not change that while I was not looking:-) </pre>", "group_id": 8954, "id": 837091}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303970859.6422789, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3vb2brl - Alexander Belopolsky - <pre> If this is the case, why Python almost never produces NaNs as IEEE standard prescribes? Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt; ZeroDivisionError: float division Sometimes you don't have a choice. For example when you data comes from a database that uses NaNs for missing values. </pre>", "group_id": 8954, "id": 837313}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303971756.9710431, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3kulf5c - Greg Ewing - <pre> I would say it *can't* be compared for *numerical* equality. It might make sense to compare it using some other notion of equality. One of the problems here, I think, is that Python only lets you define one notion of equality for each type, and that notion is the one that gets used when you compare collections of that type. (Or at least it's supposed to, but the identity- implies-equality shortcut that gets taken in some places interferes with that.) So if you're going to decide that it doesn't make sense to compare undefined numeric quantities, then it doesn't make sense to compare lists containing them either. </pre>", "group_id": 8954, "id": 837447}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303971760.054595, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5u3mdkd - Greg Ewing - <pre> If it's to be an official language non-rule (by which I mean that types are officially allowed to compare non-reflexively) then any code assuming that identity implies equality for arbitrary objects is broken and should be fixed. </pre>", "group_id": 8954, "id": 837448}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303971762.226645, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6a2kld2 - Alexander Belopolsky - <pre>.. As I mentioned in a previous post, I agree in case of &lt;, &lt;=, &gt;, or &gt;= comparisons, but == and != are a harder case because you don't want, for example: 3 to raise an exception. </pre>", "group_id": 8954, "id": 837449}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303972657.376719, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/69lkqqu - Glenn Linderman - <pre> In that bug, Nick, you mention that reflexive equality is something that container classes rely on in their implementation. Such reliance seems to me to be a bug, or an inappropriate optimization, rather than a necessity. I realize that classes that do not define equality use identity as their default equality operator, and that is acceptable for items that do not or cannot have any better equality operator. It does lead to the situation where two objects that are bit-for-bit clones get separate entries in a set... exactly the same as how NaNs of different identity work... the situation with a NaN of the same identity not being added to the set multiple times seems to simply be a bug because of conflating identity and equality, and should not be relied on in container implementations. </pre>", "group_id": 8954, "id": 837552}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303974458.029444, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3kgnm9d - Alexander Belopolsky - <pre>.. An alternative interpretation would be that it is a bug to use NaN values in lists. It is certainly nonsensical to use NaNs as keys in dictionaries and that reportedly led Java designers to forgo the nonreflexivity of nans: \"\"\" A \"NaN\" value is not equal to itself. However, a \"NaN\" Java \"Float\" object is equal to itself. The semantic is defined this way, because otherwise \"NaN\" Java \"Float\" objects cannot be retrieved from a hash table. \"\"\" - http://www.concentric.net/~ttwang/tech/javafloat.htm With the status quo in Python, it may only make sense to store NaNs in array.array, but not in a list. </pre>", "group_id": 8954, "id": 837827}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303974460.5240619, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5vrft3s - Nick Coghlan - <pre> No, as Raymond has articulated a number of times over the years, it's a property of the equivalence relation that is needed in order to present sane invariants to users of the container. I included in the bug report the critical invariants I am currently aware of that should hold, even when the container may hold types with a non-reflexive definition of equality: assert [x] == [x] # Generalised to all container types assert not [x] != [x] # Generalised to all container types for x in c: assert x in c assert c.count(x) &gt; 0 # If applicable assert 0 &lt;= c.index(x) &lt; len(c) # If applicable The builtin types all already work this way, and that's a deliberate choice - my proposal is simply to document the behaviour as intentional, and fix the one case I know of in the standard library where we don't implement these semantics correctly (i.e. collections.Sequence). The question of whether or not float and decimal.Decimal should be modifie</pre>", "group_id": 8954, "id": 837829}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303976262.383822, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/3hs2o3t - Vinay Sajip - <pre> I have poked around, and each test module pretty much does its own thing. Perhaps that's unavoidable; I'll try and see if there are usable common patterns in the specific instances. Yes, I thought perhaps it was too specialised for adding to test.support itself. Thanks for the feedback, Vinay </pre>", "group_id": 8954, "id": 838003}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303978158.4579439, "message": "[devel] - the role of assert in the standard library ? - http://tinyurl.com/3bxagao - Tarek Ziad\u00e9 - <pre>Hello I removed some assert calls in distutils some time ago because the package was not behaving correctly when people were using Python with the --optimize flag. In other words, assert became a full part of the code logic and removing them via -O was changing the behavior. In my opinion assert should be avoided completely anywhere else than in the tests. If this is a wrong statement, please let me know why :) So, I grepped the stdlib for assert calls, and I have found 177 of them and many of them are making Python acts differently depending on the -O flag, Here's an example on a randomly picked assert in the threading module: import threading class test(threading.Thread): def __init__(self): self.bla = 1 def run(self): print('running') t = test() print(t) &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; The __repr__ method is not behaving the same way depending on the O flag: $ python3 -O test.py Traceback (most recent call last): File \"test.py\", line 12, in &lt;module&gt; print(t) File \"/usr/loc</pre>", "group_id": 8954, "id": 838163}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303977260.3209989, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5u7m9cl - Glenn Linderman - <pre> I probably wasn't around when Raymond did his articulation :) Sorry for whatever amount of rehashing I'm doing here -- pointers to some of the articulation would be welcome, but perhaps the summary below is intended to recap the results of such discussions. If my comments below seem to be grasping the essence of those discussions, then no need for the pointers... if I'm way off, I'd like to read a thread or two. Yes, I agree they are orthogonal questions... separate answers and choices can be made for specific classes, just like some classes implement equality using identity, it would also be possible to implement identity using equality, and it is possible to conflate the two as has apparently been deliberately done for Python containers, without reflecting that in the documentation. If the containers have been deliberately implemented in that way, and it is not appropriate to change them, then more work is needed in the documentation than just your proposed Glossary definition, as the ver</pre>", "group_id": 8954, "id": 838082}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303977262.4601021, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/66hg3l5 - Alexander Belopolsky - <pre>.. It is an interesting question of what \"sane invariants\" are. Why you consider the invariants that you listed essential while say if c1 == c2: assert all(x == y for x,y in zip(c1, c2)) optional? Can you give examples of algorithms that would break if one of your invariants is violated, but would still work if the data contains NaNs? </pre>", "group_id": 8954, "id": 838083}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303977266.413259, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6zombpw - Nick Coghlan - <pre> In my first post to this thread, I pointed out the bug tracker item (http://bugs.python.org/issue4296) that included the discussion of restoring this behaviour to the 3.x branch, after it was inadvertently removed. Cheers, Nick. </pre>", "group_id": 8954, "id": 838084}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303978160.863379, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6by9xno - Nick Coghlan - <pre>On Thu, Apr 28, 2011 at 5:30 PM, Alexander Belopolsky &lt;alexander.belopolsky&lt; at &gt;gmail.com&gt; wrote: Because this assertion is an assertion about the behaviour of comparisons that violates IEEE754, while the assertions I list are all assertions about the behaviour of containers that can be made true *regardless* of IEEE754 by checking identity explicitly. The correct assertion under Python's current container semantics is: if list(c1) == list(c2): # Make ordering assumption explicit assert all(x is y or x == y for x,y in zip(c1, c2)) # Enforce reflexivity Meyer is a purist - sticking with the mathematical definition of equality is the sort of thing that fits his view of the world and what Eiffel should be, even if it hinders interoperability with other languages and tools. Python tends to be a bit more pragmatic about things, in particular when it comes to interoperability, so it makes sense to follow IEEE754 and the decimal specification at the individual comparison level. However, we can contain the </pre>", "group_id": 8954, "id": 838164}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303979961.1383359, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/433vf3f - Alexander Belopolsky - <pre>.. AFAIK, IEEE754 says nothing about comparison of containers, so my invariant cannot violate it. What you probably wanted to say is that my invariant cannot be achieved in the presence of IEEE754 conforming floats, but this observation by itself does not make my invariant less important than yours. It just makes yours easier to maintain. Being correct is different from being important. What practical applications of lists containing NaNs do this and your other invariants enable? I think even with these invariants in place one should either filter out NaNs from their lists or replace them with None before doing applying container operations. </pre>", "group_id": 8954, "id": 838349}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303979958.3057449, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/65z5gss - Hrvoje Niksic AVL HR - <pre> I would expect l1 == l2, where l1 and l2 are both lists, to be semantically equivalent to len(l1) == len(l2) and all(imap(operator.eq, l1, l2)). Currently it isn't, and that was the motivation for this thread. If objects that break reflexivity of == are not allowed, this should be documented, and such objects banished from the standard library. Hrvoje </pre>", "group_id": 8954, "id": 838348}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303979963.324898, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/69bnqq5 - Terry Reedy - <pre> My understanding is that assert can be used in production code but only to catch logic errors by testing supposed invariants or postconditions. It should not be used to test usage errors, including preconditions. In other words, assert presence or absence should not affect behavior unless the code has a bug. This, to me is wrong: def __init__(self, group=None, target=None, name=None, args=(), kwargs=None, verbose=None): assert group is None, \"group argument must be None for now\" That catches a usage error and should raise a ValueError. This def _wait(self, timeout): if not self._cond.wait_for(lambda : self._state != 0, timeout): #timed out. Break the barrier self._break() raise BrokenBarrierError if self._state &lt; 0: raise BrokenBarrierError assert self._state == 1 appears to be, or should be, a test of a postcondition that should *always* be true regardless of usage. </pre>", "group_id": 8954, "id": 838350}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303981757.4324901, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/68xm2v5 - Glenn Linderman - <pre> Sure. I had read that. It was mostly discussing it from a backward compatibility perspective, although it mentioned some invariants as well, etc. But mentioning the invariants is different than reading discussion about the pros and cons of such, or what reasoning lead to wanting them to be invariants. Raymond does make a comment about necessary for correctly reasoning about programs, but that is just a tautological statement based on previous agreement, rather than being the discussion itself, which must have happened significantly earlier. One of your replies to Alexander seems to say the same thing I was saying, though.... On 4/28/2011 12:57 AM, Nick Coghlan wrote: That reinforces the idea that the discussion about containers was to try to make them like containers in pre-NaN languages such as Eiffel, rather than in post-NaN languages such as SQL. It is not that one cannot reason about containers in either case, but rather that one cannot borrow all the reasoning from pre-NaN concepts </pre>", "group_id": 8954, "id": 838477}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303981760.764291, "message": "[devel] - Not-a-Number (was PyObject_RichCompareBool identityshortcut) - http://tinyurl.com/3qhzsa4 - Mark Shannon - <pre>Related to the discussion on \"Not a Number\" can I point out a few things that have not be explicitly addressed so far. The IEEE standard is about hardware and bit patterns, rather than types and values so may not be entirely appropriate for high-level language like Python. NaN is *not* a number (the clue is in the name). Python treats it as if it were a number: &gt;&gt;&gt; import numbers &gt;&gt;&gt; isinstance(nan, numbers.Number) True Can be read as \"'Not a Number' is a Number\" ;) NaN does not have to be a float or a Decimal. Perhaps it should have its own class. The default comparisons will then work as expected for collections. (No doubt, making NaN a new class will cause a whole new set of problems) As pointed out by Meyer: NaN == NaN is False is no more logical than NaN != NaN is False Although both NaN == NaN and NaN != NaN could arguably be a \"maybe\" value, the all important reflexivity (x == x is True) is effectively part of the language. All collections rely on it and Python wouldn't be much use witho</pre>", "group_id": 8954, "id": 838478}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303982659.5436759, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3pufobu - Greg Ewing - <pre> Aren't you making something of a circular argument here? You're saying that non-reflexive comparisons are okay because they don't interfere with certain critical invariants. But you're defining those invariants as the ones that don't happen to conflict with non-reflexive comparisons! </pre>", "group_id": 8954, "id": 838584}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303982661.7956059, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBool identity shortcut) - http://tinyurl.com/6gqugpj - Greg Ewing - <pre> Perhaps, but that wouldn't solve anything on its own. If this new class compares reflexively, then it still violates IEE754. Conversely, existing NaNs could be made to compare reflexively without making them a new class. </pre>", "group_id": 8954, "id": 838585}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303986319.4322989, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/44x7qs5 - Nick Coghlan - <pre>On Thu, Apr 28, 2011 at 6:30 PM, Alexander Belopolsky &lt;alexander.belopolsky&lt; at &gt;gmail.com&gt; wrote: No, I meant what I said. Your assertion includes a direct comparison between values (the \"x == y\" part) which means that IEEE754 has a bearing on whether or not it is a valid assertion. Every single one of my stated invariants consists solely of relationships between containers, or between a container and its contents. This keeps them all out of the domain of IEEE754 since the *container implementers* get to decide whether or not to factor object identity into the management of the container contents. The core containment invariant is really only this one: for x in c: assert x in c That is, if we iterate over a container, all entries returned should be in the container. Hopefully it is non-controversial that this is a sane and reasonable invariant for a container *user* to expect. The comparison invariants follow from the definition of set equivalence as: set1 == set2 iff all(x in set2 for x in s</pre>", "group_id": 8954, "id": 839043}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303987218.4068871, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/67p54fc - Nick Coghlan - <pre> No, I'm taking the existence of non-reflexive comparisons as a given (despite agreeing with Meyer from a theoretical standpoint) because: 1. IEEE754 works that way 2. Even if float() is changed to not work that way, 3rd party types may still do so 3. Supporting rich comparisons makes it impossible for Python to enforce reflexivity at the language level (even if we wanted to) However, as I detailed in my reply to Antoine, the critical container invariants I cite *don't include* direct object-object comparisons. Instead, they merely describe how objects relate to containers, and how containers relate to each other, using only the two basic rules that objects retrieved from a container should be in that container and that two sets are equivalent if they are each a subset of the other. The question then becomes, how do we reconcile the container invariants with the existence of non-reflexive definitions of equality at the type level, and the answer is to officially adopt the approach already used in the stand</pre>", "group_id": 8954, "id": 839067}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303987220.8203101, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/64znl2x - Michael Foord - <pre> Agreed. We should ideally have buildbots doing test runs with -O and -OO. R. David Murray did a lot of work a year ago (or so) to ensure the test run passes with -OO but it easily degrades.. There are a couple of asserts in unittest (for test discovery) but I only use them to provide failure messages early. The functionality is unchanged (and tests still pass) with -OO. All the best, Michael Foord </pre>", "group_id": 8954, "id": 839068}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303987223.5613201, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBoolidentity shortcut) - http://tinyurl.com/6yt9r2w - Nick Coghlan - <pre> And 3rd party NaNs can still do whatever the heck they want :) Cheers, Nick. </pre>", "group_id": 8954, "id": 839069}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303987228.4335871, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/6fwchqu - Antoine Pitrou - <pre>On Thu, 28 Apr 2011 07:23:43 +0000 (UTC) Vinay Sajip &lt;vinay_sajip&lt; at &gt;yahoo.co.uk&gt; wrote: You can take a look at Lib/test/ssl_servers.py. Regards Antoine. </pre>", "group_id": 8954, "id": 839071}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303987225.964927, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/5thf64u - Antoine Pitrou - <pre>On Thu, 28 Apr 2011 07:23:43 +0000 (UTC) Vinay Sajip &lt;vinay_sajip&lt; at &gt;yahoo.co.uk&gt; wrote: You can also take a look at Lib/test/ssl_servers.py. Regards Antoine. </pre>", "group_id": 8954, "id": 839070}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303993519.856544, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/5smhxjf - Tarek Ziad\u00e9 - <pre>On Thu, Apr 28, 2011 at 12:27 PM, Michael Foord &lt;fuzzyman&lt; at &gt;voidspace.org.uk&gt; wrote: I'll try to add a useful report on \"bad asserts\" in the bug tracker. I am replying again to this on Python-ideas because I want to debate on assert :) Cheers Tarek </pre>", "group_id": 8954, "id": 839613}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303993530.1841371, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/3vgjt8x - Giampaolo Rodol\u00e0 - <pre>2011/4/27 Vinay Sajip &lt;vinay_sajip&lt; at &gt;yahoo.co.uk&gt;: I agree having a standard server framework for tests woul be useful, because it's something which appears quite often, (e.g. when writing functional tests). See for example: http://hg.python.org/cpython/file/b452559eee71/Lib/test/test_os.py#l1316 http://hg.python.org/cpython/file/b452559eee71/Lib/test/test_ftplib.py#l211 http://hg.python.org/cpython/file/b452559eee71/Lib/test/test_ssl.py#l844 http://hg.python.org/cpython/file/b452559eee71/Lib/test/test_smtpd.py http://hg.python.org/cpython/file/b452559eee71/Lib/test/test_poplib.py#l115 Regards --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ </pre>", "group_id": 8954, "id": 839618}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303995319.1067619, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/5shjv33 - Antoine Pitrou - <pre>On Thu, 28 Apr 2011 09:54:23 +0200 Tarek Ziad\u00e9 &lt;ziade.tarek&lt; at &gt;gmail.com&gt; wrote: Agreed. Argument checking should not depend on the -O flag. Regards Antoine. </pre>", "group_id": 8954, "id": 840187}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1303999820.8638179, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3p42u82 - Rob Cliffe - <pre>I am not a specialist in this area (although I call myself a mathematician). But they say that sometimes the outsider sees most of the game, or more likely that sometimes the idiot's point of view is useful. To me the idea of non-reflexive equality (an object not being equal to itself) is abhorrent. Nothing is more likely to put off new Python users if they happen to run into it. And I bet even very experienced programmers will be tripped up by it a good proportion of the time they hit it. Basically it's deferring to a wart, of dubious value, in floating point calculations and/or the IEEE754 standard, and allowing it to become a monstrous carbuncle disfiguring the whole language. I think implementations of equal/not-equal which are make equality non-reflexive (and thus break \"identity implies equality\") should be considered broken. On 27/04/2011 15:53, Guido van Rossum wrote: Right on, Guido. (A pity that a lot of people don't seem to be listening.) On 27/04/2011 17:05, Isaac Morland wrote</pre>", "group_id": 8954, "id": 841520}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304000721.5021789, "message": "[devel] - Re: Simple XML-RPC server over SSL/TLS - http://tinyurl.com/3v4ed8y - \u00c9ric Araujo - <pre>Hi, I think there\u2019s no deeper reason than nobody thought about it. The ssl module is new in 2.6 and 3.x, xmlrpc is an older module for an old technology *cough*, so feel free to open a bug report. Patch guidelines are found at http://docs.python.org/devguide Thanks in advance! Cheers _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 841718}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304000725.2896681, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/3rhvhbw - \u00c9ric Araujo - <pre>Hi, A generic test helper to run a server for tests would be a great addition. In distutils/packaging (due to be merged into 3.3 Really Soon Now\u2122), we also have a server, to test PyPI-related functionality. It\u2019s a tested module providing a server class that runs in a thread, a SimpleHTTPRequest handler able to serve static files and reply to XML-RPC requests, and decorators to start and stop the server for one test method instead of a whole TestCase instance. I\u2019m sure some common ground can be found and all these testing helpers factored out in one module. +1, script_helper is great. Cheers _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 841720}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304001623.227375, "message": "[devel] - Re: [Python-checkins] cpython: Refined time test intest_logging. - http://tinyurl.com/6d6a38s - \u00c9ric Araujo - <pre>Hi, Any reason not to use datetime.datetime.utc here? Regards </pre>", "group_id": 8954, "id": 841804}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304001626.0917971, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/5w7l8v2 - Barry Warsaw - <pre> I would agree. Use asserts for \"this can't possibly happen &lt;wink&gt;\" conditions. -Barry </pre>", "group_id": 8954, "id": 841805}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304003423.0951209, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/3tz9f4s - Fred Drake - <pre> Maybe we should rename \"assert\" to \"wink\", just to be clear on the usage. :-) -Fred </pre>", "group_id": 8954, "id": 842182}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304002519.0668781, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Fix closes issue10761: tarfile.extractall failure when symlinked files are - http://tinyurl.com/6cokfef - Senthil Kumaran - <pre> The lock to avoid race conditions (if you were thinking along those lines) would usually be implemented at the higher level code which is using extractall in threads. Checking that no one else is accessing the file before unlinking may not be suitable for the library method and of course, we cannot check if someone is waiting to act on that file. </pre>", "group_id": 8954, "id": 841961}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304005220.4654109, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/3vudndp - Barry Warsaw - <pre> BTW, I think it always helps to have a really good assert message, and/or a leading comment to explain *why* that condition can't possibly happen. -Barry </pre>", "group_id": 8954, "id": 842535}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304003419.693928, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBool identity shortcut) - http://tinyurl.com/5vgja2n - Steven D'Aprano - <pre> I would argue that the implementation of NANs is irrelevant. If NANs are useful in hardware floats -- and I think they are -- then they're just as equally useful as objects, or as strings in languages like REXX or Hypertalk where all data is stored as strings, or as quantum wave functions in some future quantum computer. I see your wink, but what do you make of these? class NotAnObject(object): pass nao = NotAnObject() assert isinstance(nao, object) class NotAType(object): pass assert type(NotAType) is type Others have already pointed out this won't make any difference. Fundamentally, the problem is that some containers bypass equality tests for identity tests. There may be good reasons for that shortcut, but it leads to problems with *any* object that does not define equality to be reflexive, not just NANs. &gt;&gt;&gt; class Null: ... def __eq__(self, other): ... return False ... &gt;&gt;&gt; null = Null() &gt;&gt;&gt; null == null False &gt;&gt;&gt; [null] == [null] True I don't agree </pre>", "group_id": 8954, "id": 842180}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304004320.920362, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/64vfddo - skip< at >pobox.com - <pre> Barry&gt; I would agree. Use asserts for \"this can't possibly happen Barry&gt; &lt;wink&gt;\" conditions. Without looking, I suspect that's probably what the author thought he was doing. Skip </pre>", "group_id": 8954, "id": 842357}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304005223.9889281, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/3lgfd6w - Barry Warsaw - <pre> Off to python-ideas for you! &lt;wink&gt; -Barry </pre>", "group_id": 8954, "id": 842536}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304006120.505408, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Fix closes issue10761: tarfile.extractall failure when symlinked files are - http://tinyurl.com/3jkc2vj - Antoine Pitrou - <pre>On Thu, 28 Apr 2011 22:44:50 +0800 Senthil Kumaran &lt;orsenthil&lt; at &gt;gmail.com&gt; wrote: A lock would only protect only against multi-threaded use of the tarfile module, which is probably quite rare and therefore not a real concern. The kind of race condition which can happen here is if an attacker creates \"targetpath\" between os.path.exists and os.unlink. Whether it is an exploitable flaw would need a detailed analysis, of course. Regards Antoine. </pre>", "group_id": 8954, "id": 842716}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304006123.6689889, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/3mgsavs - Tarek Ziad\u00e9 - <pre> why bother, it can't happen ;) </pre>", "group_id": 8954, "id": 842717}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304006126.6448081, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3sb5j9v - Robert Kern - <pre> Ah, I see! Smaller, certainly. But now it's a trilemma. :-) 1. Have just np.float64 and np.complex128 scalars follow the Python float semantics since they subclass Python float and complex, respectively. 2. Have all np.float* and np.complex* scalars follow the Python float semantics. 3. Keep the current IEEE-754 semantics for all float scalar types. </pre>", "group_id": 8954, "id": 842719}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304007919.4636641, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBool identity shortcut) - http://tinyurl.com/62vovnl - Rob Cliffe - <pre> On 28/04/2011 15:58, Steven D'Aprano wrote: I say you have that backwards. It is a legitimate shortcut, and any object that (perversely) doesn't define equality to be reflexive leads (unsurprisingly) to problems with it (and with *anything else* that - very reasonably - assumes that identity implies equality). And you can write True = False (at least in older versions of Python you could). No language stops you from writing stupid programs. In fact I would propose that the language should DEFINE the meaning of \"==\" to be True if its operands are identical, and only if they are not would it use the comparison operators, thus enforcing reflexivity. (Nothing stops you from writing your own non-reflexive __eq__ and calling it explicitly, and I think it is right that you should have to work harder and be more explicit if you want that behaviour.) Please, please, can we have a bit of common sense and perspective here. No-one (not even a mathematician) except someone from Wonderland would se</pre>", "group_id": 8954, "id": 843077}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304007022.52126, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/42we8dy - Robert Kern - <pre> This behavior is not what you think it is. Rather, some binary operations have been augmented with a domain of validity, and the results will be masked out when the domain is violated. Division is one of them, and division by zero will cause the result to be masked. You can produce NaNs in other ways that will not be masked in both numpy and old Numeric: [~] |4&gt; minf = np.ma.array([1e300]) * np.ma.array([1e300]) Warning: overflow encountered in multiply [~] |5&gt; minf masked_array(data = [ inf], mask = False, fill_value = 1e+20) [~] |6&gt; minf - minf masked_array(data = [ nan], mask = False, fill_value = 1e+20) [~] |14&gt; import MA [~] |15&gt; minf = MA.array([1e300]) * MA.array([1e300]) [~] |16&gt; minf array([ inf,]) [~] |17&gt; (minf - minf)[0] nan [~] |25&gt; (minf - minf)._mask is None True Numeric has a bug where it cannot print arrays with NaNs, so I just grabbed the element out instead of showing it. But I guarantee you that it is not masked. M</pre>", "group_id": 8954, "id": 842887}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304007025.3239379, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBool identity shortcut) - http://tinyurl.com/43bqonf - Mark Shannon - <pre> So, Indeed, so its OK if type(NaN) != type(0.0) ? Trying to make something not an object in a language where everything is an object is bound to be problematic. Just because you can do that, doesn't mean you should. Equality should be reflexive, without that fundamental assumption many non-numeric algorithms fall apart. Not breaking a whole bunch of collections and algorithms has a certain practical appeal as well ;) The problem with this argument is the present King of France does not exist, whereas NaN (as a Python object) does exist. The present King of France argument only applies to non-existent things. Python objects do exist (as much as any computer language entity exists). So the expression \"The present King of France\" either raises an exception (non-existence) or evaluates to an object (existence). In this case \"the present King of France\" doesn't exist and should raise a FifthRepublicException :) inf / inf does not raise an exception, but evaluates to NaN, so NaN exists. For objec</pre>", "group_id": 8954, "id": 842888}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304011520.7407801, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/3sozn64 - Guido van Rossum - <pre> I would turn that around. The assert statement should not be used in unit tests; unit tests should use self.assertXyzzy() always. In regular code, assert should be about detecting buggy code. It should not be used to test for error conditions in input data. (Both these can be summarized as \"if you still want the test to happen with -O, don't use assert.) </pre>", "group_id": 8954, "id": 843992}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304008819.5484221, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBool identity shortcut) - http://tinyurl.com/67rz5lm - Steven D'Aprano - <pre> Sure. But that just adds complexity without actually resolving anything. [...] So what? If I have a need for non-reflexivity in my application, why should I care that some other algorithm, which I'm not using, will fail? Python supports non-reflexivity. If I take advantage of that feature, I can't guarantee that *other objects* will be smart enough to understand this. This is no different from any other property of my objects. [...] NANs (as Python objects) exist in the same way as the present King of France exists as words. It's an implementation detail: we can't talk about the non-existent present King of France without using words, and we can't do calculations on non-existent/indeterminate values in Python without objects. Words can represent things that don't exist, and so can bit-patterns or objects or any other symbol. We must be careful to avoid mistaking the symbol (the NAN bit-pattern or object) for the thing (the result of whatever calculation generated that NAN). The idea of e</pre>", "group_id": 8954, "id": 843385}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304010621.000335, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3qq8tpl - Guido van Rossum - <pre>[This is a mega-reply, combining responses to several messages in this thread. I may be repeating myself a bit, but I think I am being consistent. :-)] On Wed, Apr 27, 2011 at 10:12 PM, Nick Coghlan &lt;ncoghlan&lt; at &gt;gmail.com&gt; wrote: The rules for float could be expanded to disallow NaN caching. But even if we didn't change any rules, reusing immutable objects could currently make computations undefined, because container comparisons use the \"identity wins\" rule. E.g. if we didn't change the rule for nan==nan, but we did change float(\"nan\") to always return a specific singleton, comparisons like [float(\"nan\")] == [float(\"nan\")] would change in outcome. (Note that not all NaNs could be the same object, since there are multiple bit patterns meaning NaN; IIUC this is different from Inf.) All this makes me realize that there would be another issue, one that I wouldn't know how to deal with: a JITting interpreter could translate code involving floats into machine code, at which point object identity would be lost (</pre>", "group_id": 8954, "id": 843828}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304015126.6616931, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/64julxq - Alexander Belopolsky - <pre>.. This use case reminded me Kahan's \"\"\" Were there no way to get rid of NaNs, they would be as useless as Indefinites on CRAYs; as soon as one were encountered, computation would be best stopped rather than continued for an indefinite time to an Indefinite conclusion. \"\"\" http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps More often than not, you would want to sum non-NaN values instead. .. I like NaNs for high-performance calculations, but once you wrap floats individually in Python objects, performance is killed and you are better off using None instead of NaN. Python lists don't support element-wise operations and therefore there is little gain from being able to write x + y in loops over list elements instead of ieee_add(x, y) or add_or_none(x, y) with proper definitions of these functions. On the other hand, __eq__ gets invoked implicitly in cases where you don't access to the loop. Your only choice is to filter your data before invoking such operations. </pre>", "group_id": 8954, "id": 844904}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304013321.0244069, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3lldm6k - Steven D'Aprano - <pre> That's a bit extreme. It only gets you into trouble if you reason like this: &gt;&gt;&gt; a = b = [1, 2, 3, float('nan')] &gt;&gt;&gt; if a == b: ... for x,y in zip(a,b): ... assert x==y ... Traceback (most recent call last): File \"&lt;stdin&gt;\", line 3, in &lt;module&gt; AssertionError But it's perfectly fine to do this: &gt;&gt;&gt; sum(a) nan exactly as expected. Prohibiting NANs from lists is massive overkill for a small (alleged) problem. I know thousands of words have been spilled on this, including many by myself, but I really believe this discussion is mostly bike-shedding. Given the vehemence of some replies, and the volume of talk, anyone would think that you could hardly write a line of Python code without badly tripping over problems caused by NANs. The truth is, I think, that most people will never see one in real world code, and those who are least likely to come across them are the most likely to be categorically against them. (I grant that Alexander is an exception -- I understand that he </pre>", "group_id": 8954, "id": 844522}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304013325.410244, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3z2qw6j - Steven D'Aprano - <pre> I believe that's a gross exaggeration. In any case, that's just your opinion, and Python is hardly the only language that supports (at least partially) NANs. Besides, floats have all sorts of unintuitive properties that go against properties of real numbers, and new users manage to cope. With floats, even ignoring NANs, you can't assume: a*(b+c) == a*b + a*c a+b+c = c+b+a 1.0/x*x = 1 x+y-x = y x+1 &gt; x or many other properties of real numbers. In real code, the lack of reflexivity for NANs is just not that important. You can program for *years* without once accidentally stumbling over one, whereas you can't do the simplest floating point calculation without stubbing your toes on things like this: &gt;&gt;&gt; 1.0/10 0.10000000000000001 Search the archives of the python-list&lt; at &gt;python.org mailing list. You will find regular questions from newbies similar to \"Why doesn't Python calculate 1/10 correctly, is it broken?\" (Except that most of the time they don't *ask* if it's broken, they just declare that </pre>", "group_id": 8954, "id": 844523}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304014221.494849, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3zqn7wt - Steven D'Aprano - <pre> I think that so long as \"badly defined\" objects are explicitly still permitted (with the understanding that they may behave badly in containers), and so long as NANs continue to be \"badly behaved\" in this sense, then I could live with that. It's really just formalizing the status quo as deliberate policy rather than an accident: nan == nan will still return False [nan] == [nan] will still return True. Purists on both sides will hate it :) </pre>", "group_id": 8954, "id": 844723}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304015124.1865809, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/3nzseb9 - Glyph Lefkowitz - <pre> On Apr 28, 2011, at 12:59 PM, Guido van Rossum wrote: You're both right! :) My take on \"assert\" is \"don't use it, ever\". assert is supposed to be about conditions that never happen. So there are a few cases where I might use it: If I use it to enforce a precondition, it's wrong because under -OO my preconditions won't be checked and my input might be invalid. If I use it to enforce a postcondition, then my API's consumers have to occasionally handle this weird error, except it won't be checked under -OO so they won't be able to handle it consistently. If I use it to try to make assertions about internal state during a computation, then I introduce an additional, untested (at the very least untested under -OO), probably undocumented (did I remember to say \"and raises AssertionError when...\" in its docstring?) code path where when this \"bad\" thing happens, I get an exception instead of a result. If that's an important failure mode, then there ought to be a documented exception, which the computation'</pre>", "group_id": 8954, "id": 844903}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304015120.8959141, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6eqqh6b - Steven D'Aprano - <pre> Hmmm... on reflection, I think I may have been a bit unfair. In particular, I don't mean any slight on any of the people who have made intelligent, insightful posts, even if I disagree with them. </pre>", "group_id": 8954, "id": 844902}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304016020.644556, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6kxtpn3 - Rob Cliffe - <pre>Of course, these are inevitable consequences of floating-point representation. Inevitable in just about *any* language. I am not arguing against the use of NANs. Or even against different NANs not being equal to each other. What I was arguing about was the behaviour of Python objects that represent NANs, specifically in allowing x == x to be False, something which is *not* inevitable but a choice of language design or usage. Rob Cliffe </pre>", "group_id": 8954, "id": 845066}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304017821.1910729, "message": "[devel] - Re: Simple XML-RPC server over SSL/TLS - http://tinyurl.com/43t3v6u - Bill Janssen - <pre> What he said. I'm not a big fan of XMLRPC in the first place, so I probably didn't even notice that there wasn't SSL support for it. Go for it! Bill _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 845680}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304019620.8136001, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6ed8cqr - Terry Reedy - <pre> I agree that the container (author) gets to define container equality. The definition should also be correctly documented. 5.9. Comparisons says \"Tuples and lists are compared lexicographically using comparison of corresponding elements. This means that to compare equal, each element must compare equal and the two sequences must be of the same type and have the same length.\". This, I believe is the same as what Hrvoje said \"I would expect l1 == l2, where l1 and l2 are both lists, to be semantically equivalent to len(l1) == len(l2) and all(imap(operator.eq, l1, l2)).\" But \"Currently it isn't, and that was the motivation for this thread.\" In this case, I think the discrepancy should be fixed by changing the doc. Add 'be identical or ' before 'compare equal'. </pre>", "group_id": 8954, "id": 846246}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304020520.644449, "message": "[devel] - Re: Proposal for a common benchmark suite - http://tinyurl.com/69g6ke3 - Stefan Behnel - <pre>DasIch, 28.04.2011 20:55: Try not to care too much about pybench. There is some value in it, but some of its microbenchmarks are also tied to CPython's interpreter behaviour. For example, the benchmarks for literals can easily be considered dead code by other Python implementations so that they may end up optimising the benchmarked code away completely, or at least partially. That makes a comparison of the results somewhat pointless. Stefan </pre>", "group_id": 8954, "id": 846454}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304021421.1231451, "message": "[devel] - Identity implies equality - http://tinyurl.com/44whhn9 - Raymond Hettinger - <pre>ISTM there is no right or wrong answer. There is just a question of what is most useful. AFAICT, the code for dictionaries (and therefore the code for sets) has always had identity-implies-equality logic. It makes dicts blindingly fast for common cases. It also confers some nice properties like making it possible to retrieve a NaN that has been stored as a key; otherwise, you could store it but not look it up, pop it, or delete it (because the equality test would always fail). The logic also confers other nice-to-have properties such as: * d[k] = v; assert k in d # assignment-implies-contains * assert all(k in d for k in d) # all-members-are-members These aren't essential invariants but they do provide a pleasant programming environment and make it easier to reason about programs. Another place where identity-implies-equality logic is explicit is in Py_RichCompareBool(). That lets methods in many other functions and methods work like dicts and sets. It speeds them up and confers some nice-to-</pre>", "group_id": 8954, "id": 846593}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304022325.753336, "message": "[devel] - Re: Identity implies equality - http://tinyurl.com/689qjkz - Laurens Van Houtven - <pre>On Thu, Apr 28, 2011 at 9:51 PM, Raymond Hettinger &lt; raymond.hettinger&lt; at &gt;gmail.com&gt; wrote: +1 cheers lvh </pre>", "group_id": 8954, "id": 846806}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304022323.2135069, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBoolidentity shortcut) - http://tinyurl.com/3qhsj67 - Terry Reedy - <pre> The problem is that the committee itself did not believe or stay consistent with that. In the text of the draft, they apparently refer to Nan as an indefinite, unspecified *number*. Sort of like a random variable with a uniform pseudo* distribution over the reals (* 0 everywhere with integral 1). Or a quantum particle present but smeared out over all space. And that apparently is their rationale for Nan != NaN: an unspecified number will equal another unspecified number with probability 0. The rationale for bool(NaN)==True is that an unspecified *number* will be 0 with probability 0. If Nan truly indicated an *absence* (like 0 and '') then bool(NaN) should be False, I think the committee goofed -- badly. Statisticians used missing value indicators long before the committee existed. They has no problem thinking that the indicator, as an object, equaled itself. So one could write (and I often did through the 1980s) the equivalent of for i,x in enumerate(datavec): if x == XMIS: # singleton mi</pre>", "group_id": 8954, "id": 846801}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304023220.9880149, "message": "[devel] - Re: Proposal for a common benchmark suite - http://tinyurl.com/3lmrqx7 - M.-A. Lemburg - <pre> The point of the micro benchmarks in pybench is to be able to compare them one-by-one, not by looking at the sum of the tests. If one implementation optimizes away some parts, then the comparison will show this fact very clearly - and that's the whole point. Taking the sum of the micro benchmarks only has some meaning as very rough indicator of improvement. That's why I wrote pybench: to get a better, more details picture of what's happening, rather than trying to find some way of measuring \"average\" use. This \"average\" is very different depending on where you look: for some applications method calls may be very important, for others, arithmetic operations, and yet others may have more need for fast attribute lookup. </pre>", "group_id": 8954, "id": 846994}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304025922.0083859, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/3uypwwf - Robert Kern - <pre> Regardless of whether those frameworks encourage it, it's still the wrong thing to do for the reason that Guido states. Some bugs only show up under -O, so you ought to be running your test suite under -O, too. </pre>", "group_id": 8954, "id": 847547}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304024122.9510989, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/5tncucr - Holger Krekel - <pre> FWIW this is only true for the unittest module/pkg policy for writing and organising tests. There are other popular test frameworks like nose and pytest which promote using plain asserts within writing unit tests and also allow to write tests in functions. And judging from my tutorials and others places many people appreciate the ease of using asserts as compared to learning tons of new methods. YMMV. Holger </pre>", "group_id": 8954, "id": 847189}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304025023.294966, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/3l2mgjn - Terry Reedy - <pre> You wish: to repeat the example from threading: def __init__(self, group=None, target=None, name=None, args=(), kwargs=None, verbose=None): assert group is None, \"group argument must be None for now\" is something that can easily happen. </pre>", "group_id": 8954, "id": 847351}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304025020.1936979, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3z72eff - Terry Reedy - <pre> This, to me, is a statement of the obvious ;-), but it should be stated in the docs. Do you also propose to make NaNs at least this well-behaved or leave them ill-behaved? &gt; and Python This almost states the status quo of the implementation, and the doc needs to be updated correspondingly. I do not think we should let object ill-behavior infect containers, so that they also become ill-behaved (not equal to themselves). </pre>", "group_id": 8954, "id": 847348}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304025924.485795, "message": "[devel] - Re: Proposal for a common benchmark suite - http://tinyurl.com/6jj4mhj - Stefan Behnel - <pre>M.-A. Lemburg, 28.04.2011 22:23: I wasn't talking about \"averages\" or \"sums\", and I also wasn't trying to put down pybench in general. As it stands, it makes sense as a benchmark for CPython. However, I'm arguing that a substantial part of it does not make sense as a benchmark for PyPy and others. With Cython, I couldn't get some of the literal arithmetic benchmarks to run at all. The runner script simply bails out with an error when the benchmarks accidentally run faster than the initial empty loop. I imagine that PyPy would eventually even drop the loop itself, thus leaving nothing to compare. Does that tell us that PyPy is faster than Cython for arithmetic? I don't think it does. When I see that a benchmark shows that one implementation runs in 100% less time than another, I simply go *shrug* and look for a better benchmark to compare the two. Stefan </pre>", "group_id": 8954, "id": 847548}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304028680.367451, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5wawghq - Guido van Rossum - <pre> As I said, my proposal is to consider this a bug of the same severity as __hash__ and __eq__ disagreeing, and would require float and Decimal to be changed. The more conservative folks are in favor of not changing anything (except the abstract Sequence class), and solving things by documentation only. In that case the exotic current behavior of should not be considered a bug but merely unusual, and the behavior of collections (assuming an object is always equal to itself, never mind what its __eq__ says) documented as just that. There would not be any mention of well-behaved nor a judgment that NaN is not well-behaved. If my proposal is accepted, the definition of sequence comparison etc. would actually become simpler, since it should not have to mention the special-casing of object identity; instead it could mention the assumption of items being well-behaved. Again, the relationship between __eq__ and __hash__ would be the model here; and in fact a \"well-behaved\" type would have both properties (__eq__ r</pre>", "group_id": 8954, "id": 847868}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304028683.55177, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/43w6gxd - Raymond Hettinger - <pre> On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote: I've also observed that people appreciate using asserts with nose.py and py.test. Raymond </pre>", "group_id": 8954, "id": 847869}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304029581.3454161, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/424w5sv - Guido van Rossum - <pre>On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger &lt;raymond.hettinger&lt; at &gt;gmail.com&gt; wrote: They must not appreciate -O. :-) </pre>", "group_id": 8954, "id": 847939}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304029584.611362, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3lnwu4p - Robert Kern - <pre> *If* so, then we would then just have to decide between #2 and #3. With respect to this proposal, how does that interact with types that do not return bools for rich comparisons? For example, numpy arrays return bool arrays for comparisons. SQLAlchemy expressions return other SQLAlchemy expressions, etc. I realize that by being \"not well-behaved\" in this respect, we give up our rights to be proper elements in sortable, containment-checking containers. But in this and your followup message, you seem to be making a stronger statement that self.__eq__(self) not returning anything but True would be a bug in all contexts. </pre>", "group_id": 8954, "id": 847940}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304030481.7921391, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/3lzmkbb - Raymond Hettinger - <pre> On Apr 28, 2011, at 3:07 PM, Guido van Rossum wrote: It might be nice if there were a pragma or module variable to selectively enable asserts for a given test module so that -O would turn-off asserts in the production code but leave them on in a test_suite. Raymond </pre>", "group_id": 8954, "id": 848042}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304031381.1583509, "message": "[devel] - Re: Identity implies equality - http://tinyurl.com/63mkqtx - Nick Coghlan - <pre>On Fri, Apr 29, 2011 at 5:51 AM, Raymond Hettinger &lt;raymond.hettinger&lt; at &gt;gmail.com&gt; wrote: While I agree with your point of view regarding the status quo as a useful, practical compromise, I need to call out that particular example: False True Due to rich comparison and the freedom to implement non-reflexive definitions of \"equality\", the assignment \"x = obj\" implies only that: - x is obj - x in locals().values() Cheers, Nick. </pre>", "group_id": 8954, "id": 848162}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304032285.4339869, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3rwk4qq - Nick Coghlan - <pre> That's a point in favour of the status quo, though - with the burden of enforcing reflexivity placed on the containers, types are free to make use of rich comparisons to return more than just simple True/False results. I hadn't really thought about it that way before this discussion - it is the identity checking behaviour of the builtin containers that lets us sensibly handle cases like sets of NumPy arrays. Cheers, Nick. </pre>", "group_id": 8954, "id": 848265}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304033186.8815949, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/5wpcm64 - Guido van Rossum - <pre> Possibly. Though for types that *do* return True/False, NaN's behavior can still be infuriating. But do they? For non-empty arrays, __eq__ will always return something that is considered true, so any hash collisions will cause false positives. And look at this simple example: ... def __eq__(self, other): ... if isinstance(other, C): ... return [x == y for x, y in zip(self, other)] ... [False, False, True] True </pre>", "group_id": 8954, "id": 848384}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304032281.964371, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6bt9dkz - Guido van Rossum - <pre> Sorry, we'll have to make an exception for those of course. This will somewhat complicate the interpretation of well-behaved, because those are *not* well-behaved as far as containers go (both dict key lookup and list membership are affected) but it is not a bug -- however it is a bug to put these in containers and then use container comparisons on the container. </pre>", "group_id": 8954, "id": 848263}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304033181.8788879, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/3d8v4ye - Benjamin Peterson - <pre>2011/4/28 Raymond Hettinger &lt;raymond.hettinger&lt; at &gt;gmail.com&gt;: from __future__ import perfect_code_so_no_asserts :) </pre>", "group_id": 8954, "id": 848381}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304033184.4047849, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6a5eqgt - Nick Coghlan - <pre> I'm a fan of the status quo, but not just for performance reasons - there is quite a bit of set theory that breaks once you allow non-reflexive equality*, so it makes sense to me to make it official that containers should ignore any non-reflexivity they come across. *To all the mathematicians in the audience yelling at their screens that the very idea of \"non-reflexive equality\" is an oxymoron... yes, I know :P Cheers, Nick. P.S. It's hard to explain the slightly odd point of view that seeing standard arithmetic constructed from Peano's Axioms and set theory can give you on discussions like this. It's a seriously different (and strange) way of thinking about the basic arithmetic constructs we normally take for granted, though :) </pre>", "group_id": 8954, "id": 848382}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304034985.505317, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/429cyex - Guido van Rossum - <pre> Now we're talking. :-) Probably wouldn't kill us if fixed pickle to take object identity into account for floats whose value is nan. (Fortunately for 3rd party types pickle always preserves identity.) But it seems pickle is *already* broken, so that can't really be an argument against the proposed change, right? </pre>", "group_id": 8954, "id": 848664}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304034982.2936709, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/68brarh - Nick Coghlan - <pre> Hmm, true. And things like count() and index() would still be thoroughly broken for sequences. OK, so scratch that idea - there's simply no sane way to handle such objects without using an identity-based container that ignores equality definitions altogether. Pondering the NaN problem further, I think we can relatively easily argue that reflexive behaviour at the object level fits within the scope of IEEE754. 1. IEEE754 is a value-based system, with a finite number of distinct NaN payloads 2. Python is an object-based system. In addition to their payload, NaN objects are further distinguished by their identity (infinite in theory, in practice limited by available memory). 3. We can still technically be conformant with IEEE754 even if we say that a given NaN object is equivalent to itself, but not to other NaN objects with the same payload. Unfortunately, this still doesn't play well with serialisation, which assumes that the identity of float objects doesn't matter: True [nan, nan] False Contrast that </pre>", "group_id": 8954, "id": 848663}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304035880.91276, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/44r2dyn - Alexander Belopolsky - <pre> Note that Kahan is very critical of Java's approach, but NaN objects' comparison is not on his list of Java warts: http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf </pre>", "group_id": 8954, "id": 848807}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304037688.198849, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBoolidentity shortcut) - http://tinyurl.com/5vgosu4 - Steven D'Aprano - <pre> But NANs aren't missing values (although some people use them as such, that can be considered abuse of the concept). R distinguishes NANs from missing values: they have a built-in value NaN, and a separate built-in value NA which is the canonical missing value. R also treats comparisons of both special values as a missing value: &gt; NA == NA [1] NA &gt; NaN == NaN [1] NA including reflexivity: &gt; x = NA &gt; x == x [1] NA which strikes me as the worst of both worlds, guaranteed to annoy those who want the IEEE behaviour where NANs compare unequal, those like Terry who expect missing values to compare equal to other missing values, and those who want reflexivity to be treated as an invariant no matter what. I don't see that making NANs a separate class would make any practical difference what-so-ever, but the point is moot since we're not starting fresh :) To be pedantic, the IEEE standard doesn't have anything to say about comparisons of lists of floats that might contain NANs. Given the c</pre>", "group_id": 8954, "id": 849160}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304039483.082109, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3h6jf3b - Robert Kern - <pre> Actually, numpy.ndarray.__nonzero__() raises an exception. We've decided that there are no good conventions for deciding whether an array should be considered True or False that won't mislead people. It's quite astonishing how many people will just test \"if x == y:\" or \"if x != y:\" for a single set of inputs and \"confirm\" their guess as to the general rule from that. But your point stands, numpy arrays cannot be members of sets or keys of dicts or orderable/\"in-able\" elements of lists. </pre>", "group_id": 8954, "id": 849496}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304037682.395354, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3k2evzz - Glenn Linderman - <pre> And the problem with that is that not all values are interned, to share a single identity per value, correct? On the other hand, proliferation of float objects containing NaN \"works\", thus so would proliferation of non-float objects of the same value... but \"works\" would have a different meaning when there could be multiple identities of 6,981,433 in the same set. But this does bring up an interesting enough point to cause me to rejoin the conversation: Would it be reasonable to implement 3 types of containers: 1) using __eq__ (would not use identity comparison optimization) 2) using is (the case you describe above) 3) the status quo: is or __eq__ The first two would require an explicit constructor call because the syntax would be retained for case 3 for backward compatibility. Heavy users of NaN and other similar values might find case 1 useful, although they would need to be careful with mappings and sets. Heavy users of NumPy and other similar structures might find case 2 useful. Offerin</pre>", "group_id": 8954, "id": 849158}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304037685.32005, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/43odpod - Guido van Rossum - <pre> That's something for python-ideas. Occasionally containers that use custom comparisons come in handy (e.g. case-insensitive dicts). </pre>", "group_id": 8954, "id": 849159}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304039485.739789, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6x66mx2 - Greg Ewing - <pre> Except that it doesn't: &gt;&gt;&gt; from numpy import array &gt;&gt;&gt; a1 = array([1,2]) &gt;&gt;&gt; a2 = array([3,4]) &gt;&gt;&gt; s = set([a1, a2]) Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt; TypeError: unhashable type: 'numpy.ndarray' Lists aren't trouble-free either: &gt;&gt;&gt; lst = [a1, a2] &gt;&gt;&gt; a2 in lst Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt; ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() </pre>", "group_id": 8954, "id": 849497}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304040383.6487539, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/3eu2x3m - Ben Finney - <pre> Would it make sense for \u2018NaN\u2019 to be another instance of \u2018NoneType\u2019? </pre>", "group_id": 8954, "id": 849665}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304040387.8927469, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/4ya7xxk - Greg Ewing - <pre>Taking a step back from all this, why does Python allow NaNs to arise from computations *at all*? +Inf and -Inf are arguably useful elements of the algebra, yet Python insists on raising an exception for 1.0./0.0 instead of returning an infinity. Why do this but not raise an exception for any operation that produces a NaN? </pre>", "group_id": 8954, "id": 849666}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304040390.7722239, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/3u94mkz - James Mills - <pre> This is fine IHMO as I (personally) find myself doing things like: if x is None: ... cheers James </pre>", "group_id": 8954, "id": 849667}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304042182.8411801, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/3rk8wmq - Steven D'Aprano - <pre> I argue that's an implementation detail that makes no difference. NANs should compare unequal, including to itself. That's the clear intention of IEEE-754. There's no exception made for \"unless y is another name for x\". If there was, NANs would be reflexive, and we wouldn't be having this discussion, but the non-reflexivity of NANs is intended behaviour. The clear equivalent to object identity in value-languages is memory location. If you compare variable x to the same x, IEEE754 says you should get False. Consider: # Two distinct NANs are calculated somewhere... x = float('nan') y = float('nan') # They find themselves in some data in some arbitrary place seq = [1, 2, x, y] random.shuffle(seq) # And later x is compared to some arbitrary element in the data if math.isnan(x): if x == seq[0]: print(\"Definitely not a NAN\") nan != x is an important invariant, breaking it just makes NANs more complicated and less useful. Tests will need to be written \"if x == y and not math.isnan(x)\"</pre>", "group_id": 8954, "id": 849982}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304042185.687294, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/67snxse - Steven D'Aprano - <pre> The real question should be, why does Python treat all NANs as signalling NANs instead of quiet NANs? I don't believe this helps anyone. I would argue that Python is wrong to do so. As I've mentioned a couple of times now, 20 years ago Apple felt that NANs and INFs weren't too complicated for non-programmers using Hypercard. There's no sign that Apple were wrong to expose NANs and INFs to users, no flood of Hypercard users confused by NAN inequality. </pre>", "group_id": 8954, "id": 849983}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304046742.1657569, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/442zwew - Robert Kern - <pre> Actually, Python treats all NaNs as quiet NaNs and never signalling NaNs. </pre>", "group_id": 8954, "id": 850658}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304052142.127835, "message": "[devel] - Re: PyObject_RichCompareBool identity shortcut - http://tinyurl.com/6bhxc2q - Stephen J. Turnbull - <pre> &gt; (I grant that Alexander is an exception -- I understand that he does do &gt; a lot of numeric work, and does come across NANs, and still doesn't like &gt; them one bit.) I don't think I'd want anybody who *likes* NaNs to have a commit bit at python.org.&lt;shiver/&gt; </pre>", "group_id": 8954, "id": 851901}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304055744.212115, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/3buemdd - Steven D'Aprano - <pre> Sorry, did I get that backwards? I thought it was signalling NANs that cause a signal (in Python terms, an exception)? If I do x = 0.0/0 I get an exception instead of a NAN. Hence a signalling NAN. </pre>", "group_id": 8954, "id": 852200}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304059404.0458021, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Fix closes issue10761: tarfile.extractall failure when symlinked files are - http://tinyurl.com/64bu7oo - Eli Bendersky - <pre> Just out of curiosity, could you please elaborate on the potential threat of this? If the \"exists\" condition is true, targetpath already exists, so what use there is in overwriting it? If the condition is false, unlink isn't executed, so no harm either. What am I missing? Eli </pre>", "group_id": 8954, "id": 852691}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304059407.2628419, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/3bnwt53 - Ben Finney - <pre> Robert has interpreted your \u201ctreats all NaNs as signalling NaNs\u201d to mean \u201ctreats all objects that Python calls a NaN as signalling NaNs\u201d, and is pointing out that no, the objects that Python calls \u201cNaN\u201d are all quiet NaNs. You might be clearer if you distinguish between what Python calls a NaN and what you call a NaN. It seems you're saying that some Python exception objects (e.g. ZeroDivisionError objects) are what you call NaNs, despite the fact that they're not what Python calls a NaN. </pre>", "group_id": 8954, "id": 852692}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304061206.5625031, "message": "[devel] - Re: Not-a-Number (wasPyObject_RichCompareBoolidentity shortcut) - http://tinyurl.com/3s3hg7w - Stephen J. Turnbull - <pre> &gt; &gt; Python treats it as if it were a number: &gt; &gt; As I said, so did the committee, and that was its mistake that we are &gt; more or less stuck with. The committee didn't really have a choice. You could ask that they call NaNs something else, but some bit pattern is going to appear in the result register after each computation, and further operations may (try to) use that bit pattern. Seems reasonable to me to apply duck- typing and call those patterns \"numbers\" for the purpose of IEEE 754, and to define them in such a way that operating on them produces a non-NaN only when *all* numbers (including infinity) produce the same non-NaN. The alternative is to raise an exception whenever a NaN would be generated (but something is still going to appear in the register; I don't know any number that should be put there, do you?) That is excessively punishing to Python users and programmers, though, since Python handles exceptions by terminating the computation. (Kahan points out that signaling NaNs are esse</pre>", "group_id": 8954, "id": 852981}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304059410.589958, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/3zhj4jq - Nick Coghlan - <pre> Aside from the divide-by-zero case, we treat NaNs as quiet NaNs. This is largely due to the fact float operations are delegated to the underlying CPU, and SIGFPE is ignored by default. You can fiddle with it either by building and using the fpectl module, or else by switching to decimal.Decimal() instead (which offers much finer control over signalling through its thread local context information). The latter is by far the preferable course, unless you're targeting specific hardware with well-defined FPE behaviour. Cheers, Nick. </pre>", "group_id": 8954, "id": 852693}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304060303.34519, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/5scb7rg - Steven D'Aprano - <pre> I'm sorry for my lack of clarity. I'm referring to functions which potentially produce NANs, not the exceptions themselves. A calculation which might have produced a (quiet) NAN as the result instead raises an exception (which I'm treating as equivalent to a signal). </pre>", "group_id": 8954, "id": 852816}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304059413.7163651, "message": "[devel] - Re: Proposal for a common benchmark suite - http://tinyurl.com/3qbp5fl - Maciej Fijalkowski - <pre> I second here what Stefan says. This sort of benchmarks might be useful for CPython, but they're not particularly useful for PyPy or for comparisons (or any other implementation which tries harder to optimize stuff away). For example a method call in PyPy would be inlined and completely removed if method is empty, which does not measure method call overhead at all. That's why we settled on medium-to-large examples where it's more of an average of possible scenarios than just one. </pre>", "group_id": 8954, "id": 852694}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304061203.311661, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Fix closes issue10761: tarfile.extractall failure when symlinked files are - http://tinyurl.com/3czn5xd - Nick Coghlan - <pre> That's the \"detailed analysis\" part. What happens if other code deletes the path, and the unlink() call subsequently fails despite the successful exists() check? Hence why exception checking (as Nadeem posted) is typically the only right way to do things that access an external environment that supports multiple concurrent processes. For this kind of case, denial-of-service (i.e. an externally induced program crash) is likely to be the limit of the damage, so the threat isn't severe. Still worth avoiding the risk, though. Really tricky cases can lead to all sorts of fun and games, like manipulating programs that were granted elevated privileges into executing malicious code that was put in place using only user privileges (combining \"sudo\" and its ilk with \"python\" without passing -E and -s is an unfortunately-less-than-tricky way sysadmins can shoot themselves in the foot on that front). Cheers, Nick. </pre>", "group_id": 8954, "id": 852979}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304064804.1485319, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/5uq6bxs - Holger Krekel - <pre>On Fri, Apr 29, 2011 at 12:31 AM, Raymond Hettinger &lt;raymond.hettinger&lt; at &gt;gmail.com&gt; wrote: A way to tell Python \"if you are going to compile this module/path, don't turn off asserts, no matter what\" would be great. Then nose/py.test and whichever tools/apps could fine-tune the handling of asserts. (This would probably be better than marking things inline for those use cases). Then testing with \"-O\" would work nicely as well which would be appreciated :) best, holger </pre>", "group_id": 8954, "id": 853556}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304064806.883311, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Fix closes issue10761: tarfile.extractall failure when symlinked files are - http://tinyurl.com/5utoyhw - Eli Bendersky - <pre> I completely understand this \"other code/thread deletes the path between exists() and unlink()\" case - it indeed is a race condition waiting to happen. What I didn't understand was Antoine's example of \"attacker creates targetpath between os.path.exists and os.unlink\", and was asking for a more detailed example, since I'm not really experienced with security-oriented thinking. Eli </pre>", "group_id": 8954, "id": 853557}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304065705.218425, "message": "[devel] - Re: the role of assert in the standard library ? - http://tinyurl.com/6x9o93n - Maciej Fijalkowski - <pre> Any reason why -O behavior regarding removing asserts should not be changed? Or should I go to python-ideas? _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 853655}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304068404.667222, "message": "[devel] - Re: Proposal for a common benchmark suite - http://tinyurl.com/65ayfx5 - Mark Shannon - <pre> If CPython were to start incorporating any specialising optimisations, pybench wouldn't be much use for CPython. The Unladen Swallow folks didn't like pybench as a benchmark. </pre>", "group_id": 8954, "id": 853886}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304070229.267488, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Fix closes issue10761: tarfile.extractall failure when symlinked files are - http://tinyurl.com/4344g38 - Nadeem Vawda - <pre> If targetpath is created after the os.path.exists() check, then os.unlink() will not be called, so os.symlink() will raise an exception when it sees that targetpath already exists. On Thu, Apr 28, 2011 at 5:44 PM, Antoine Pitrou &lt;solipsis&lt; at &gt;pitrou.net&gt; wrote: Like I said, that code only handles the case of targetpath being deleted. I can't think of a similarly easy fix for the creation case. You could solve that particular form of the problem with something like: if tarinfo.issym(): while True: try: os.symlink(tarinfo.linkname, targetpath) except OSError as e: if e.errno != errno.EEXIST: raise else: break try: os.unlink(targetpath) except OSError as e: if e.errno != errno.ENOENT: raise ... but that would open up another DOS vulnerability - if an attacker manages to keep re-creating targetpath in the window between un</pre>", "group_id": 8954, "id": 854142}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304077464.759095, "message": "[devel] - Re: Proposal for a common benchmark suite - http://tinyurl.com/6dcck47 - M.-A. Lemburg - <pre> This is all true, but I think there's a general misunderstanding of what pybench is. I wrote pybench in 1997 when I was working on optimizing the Python 1.5 implementation for use in an web application server. At the time, we had pystone and that was a really poor benchmark for determining of whether certain optimizations in the Python VM and compiler made sense or not. pybench was then improved and extended over the course of several years and then added to Python 2.5 in 2006. The benchmark is written as framework for micro benchmarks based on the assumption of a non-optimizing (byte code) compiler. As such it may or may not work with an optimizing compiler. The calibration part would likely have to be disabled for an optimizing compiler (run with -C 0) and a new set of benchmark tests would have to be added; one which tests the Python implementation at a higher level than the existing tests. That last part is something people tend to forget: pybench is not a monolithic application with a predefined </pre>", "group_id": 8954, "id": 854667}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304077468.0078931, "message": "[devel] - Re: Proposal for a common benchmark suite - http://tinyurl.com/3gewopo - Michael Foord - <pre> pybench proved useful for IronPython. It certainly highlighted some performance problems with some of the basic operations it measures. All the best, Michael Foord </pre>", "group_id": 8954, "id": 854669}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304077472.6463411, "message": "[devel] - Re: the role of assert in the standard library ? - http://permalink.gmane.org/gmane.comp.python.devel/124263 - Floris Bruynooghe - <pre> Personaly I'd love to get rid of all of -O's meanings apart from setting __debug__ to False. Then you can write a strip tool which could strip all docstrings, just unused docstrings (an improvement over -O), and any \"dead\" code resulting from setting __debug__ to either True or False. The last thing to do is place assert statements inside a if __debug__ block. That way you could use the strip tool on the modules under test but not on the test modules. Regards Floris PS: I actually wrote some prototype code for such a strip tool last year but never finished it off, so I'm pretty sure most of this is possible. </pre>", "group_id": 8954, "id": 854671}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304078433.7289519, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/3uabkbl - Georg Brandl - <pre> BTW, didn't we agree not to put \"pragma\" comments into the stdlib code? Georg </pre>", "group_id": 8954, "id": 854822}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304079331.603406, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/3r34btt - Nick Coghlan - <pre> I think some folks objected, but since they're essential to keeping track of progress in code coverage improvement efforts, there wasn't a consensus to leave them out. The pragmas themselves are easy enough to grep for, so it isn't like they don't leave a record of which lines may not be getting tested. Cheers, Nick. </pre>", "group_id": 8954, "id": 855063}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304081130.9010179, "message": "[devel] - Re: Proposal for a common benchmark suite - http://tinyurl.com/6gjg3ew - DasIch - <pre>Given those facts I think including pybench is a mistake. It does not allow for a fair or meaningful comparison between implementations which is one of the things the suite is supposed to be used for in the future. This easily leads to misinterpretation of the results from this particular benchmark and it negatively affects the performance data as a whole. The same applies to several Unladen Swallow microbenchmarks such as bm_call_method_*, bm_call_simple and bm_unpack_sequence. </pre>", "group_id": 8954, "id": 855541}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304081134.8337779, "message": "[devel] - Re: Proposal for a common benchmark suite - http://tinyurl.com/63dfel2 - M.-A. Lemburg - <pre> I don't think we should exclude any implementation specific benchmarks from a common suite. They will not necessarily allow for comparisons between implementations, but will provide important information about the progress made in optimizing a particular implementation. </pre>", "group_id": 8954, "id": 855543}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304082029.9466341, "message": "[devel] - Re: Proposal for a common benchmark suite - http://tinyurl.com/5vck8ff - Antoine Pitrou - <pre>On Fri, 29 Apr 2011 14:29:46 +0200 DasIch &lt;dasdasich&lt; at &gt;googlemail.com&gt; wrote: \"Including\" is quite vague. pybench is \"included\" in the suite of benchmarks at hg.python.org, but that doesn't mean it is given any particular importance: you can select whichever benchmarks you want to run when \"perf.py\" is executed (there are even several predefined benchmark groups, none of which pybench is a member IIRC). Regards Antoine. </pre>", "group_id": 8954, "id": 855719}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304082932.0316861, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/3c9soeg - Ben Finney - <pre> Yes, it produces a Python exception, which is not a Python NaN. If you want to talk about \u201csignalling NaNs\u201d, you'll have to distinguish that (every time!) so you're not misunderstood as referring to a Python NaN object. </pre>", "group_id": 8954, "id": 855912}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304088332.3441081, "message": "[devel] - Re: What if replacing items in a dictionary returns thenew dictionary? - http://tinyurl.com/3jxob6b - Mark Shannon - <pre> Roy Hyunjin Han wrote: Could you please post this to python-ideas, rather than python-dev Python-dev is about aspects of the implementation, not significant language changes. Mark. </pre>", "group_id": 8954, "id": 857342}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304088335.6388581, "message": "[devel] - Re: What if replacing items in a dictionary returnsthe new dictionary? - http://tinyurl.com/3lhs2t6 - R. David Murray - <pre> This belongs on python-ideas, but the short answer is no. The general language design principle (as I understand it) is that mutable object do not return themselves upon mutation, while immutable objects do return the new object. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 857344}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304087431.4209261, "message": "[devel] - What if replacing items in a dictionary returns thenew dictionary? - http://tinyurl.com/3mrfmf2 - Roy Hyunjin Han - <pre>It would be convenient if replacing items in a dictionary returns the new dictionary, in a manner analogous to str.replace(). What do you think? :: # Current behavior x = {'key1': 1} x.update(key1=3) == None x == {'key1': 3} # Original variable has changed # Possible behavior x = {'key1': 1} x.replace(key1=3) == {'key1': 3} x == {'key1': 1} # Original variable is unchanged </pre>", "group_id": 8954, "id": 856986}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304089230.7617791, "message": "[devel] - Re: What if replacing items in a dictionary returns the new dictionary? - http://tinyurl.com/6golww7 - Oleg Broytman - <pre>Hi! Seems like a question for python-ideas mailing list, not for python-dev. On Fri, Apr 29, 2011 at 10:27:46AM -0400, Roy Hyunjin Han wrote: You can implement this in your own subclass of dict, no? Oleg. </pre>", "group_id": 8954, "id": 857650}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304090131.2065351, "message": "[devel] - Re: What if replacing items in a dictionary returns the new dictionary? - http://tinyurl.com/6k88qw6 - Roy Hyunjin Han - <pre>2011/4/29 R. David Murray &lt;rdmurray&lt; at &gt;bitdance.com&gt;: Thanks for the responses. Sorry for the mispost, I'll post things like this on python-ideas from now on. RHH </pre>", "group_id": 8954, "id": 857957}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304090133.395036, "message": "[devel] - Re: What if replacing items in a dictionary returns the new dictionary? - http://tinyurl.com/63l2bzd - Roy Hyunjin Han - <pre> Yes, I just thought it would be convenient to have in the language itself, but the responses to my post seem to indicate that [not returning the updated object] is an intended language feature for mutable types like dict or list. class ReplaceableDict(dict): def replace(self, **kw): 'Works for replacing string-based keys' return dict(self.items() + kw.items()) </pre>", "group_id": 8954, "id": 857959}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304091932.5789881, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/3eng2d3 - Robert Kern - <pre> And in fact, 0.0/0.0 is covered by the more general rule that x/0.0 raises ZeroDivisionError, not a rule that converts IEEE-754 INVALID exceptions into Python exceptions. Other operations that produce a NaN and issue an IEEE-754 INVALID signal do not raise a Python exception. But that's not the difference between signalling NaNs and quiet NaNs. A signalling NaN is one that when it is used as an *input* to an operation, it issues an INVALID signal, not whether a signal is issued when it is the *output* of an operation. </pre>", "group_id": 8954, "id": 858587}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304093736.3573959, "message": "[devel] - Summary of Python tracker Issues - http://tinyurl.com/3exnerp - Python tracker - <pre> ACTIVITY SUMMARY (2011-04-22 - 2011-04-29) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2760 ( +8) closed 20976 (+39) total 23736 (+47) Open issues with patches: 1201 Issues opened (33) ================== #3561: Windows installer should add Python and Scripts directories to http://bugs.python.org/issue3561 reopened by ncoghlan #10912: PyObject_RichCompare differs in behaviour from PyObject_RichCo http://bugs.python.org/issue10912 reopened by ncoghlan #10914: Python sub-interpreter test http://bugs.python.org/issue10914 reopened by pitrou #11895: pybench prep_times calculation error http://bugs.python.org/issue11895 reopened by jcea #11908: Weird `slice.stop or sys.maxint` http://bugs.python.org/issue11908 opened by cool-RR #11909: Doctest sees directives in strings when it should only see the http://bugs.python.org/issue11909 opened by Devin Jeanpi</pre>", "group_id": 8954, "id": 859116}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304093738.963413, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/3eoj8jj - Vinay Sajip - <pre>[Georg] I'd be grateful for a link to the prior discussion - it must have passed me by originally, and I searched python-dev on gmane but couldn't find any threads about this. [Nick] Yes - in theory the pragmas can give a false idea about coverage, but in practice they help increase the signal-to-noise ratio. As maintainer of a module, one'd only be kidding oneself by adding pragmas willy-nilly. The coverage reports are up-front about telling you how many lines were excluded, both in the summary HTML pages and the drill-downs HTML pages for individual modules. BTW, is there a public place somewhere showing stdlib coverage statistics? I looked on the buildbot pages as the likeliest home for them, but perhaps I missed them. Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 859120}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304095532.0798969, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/5u6ttmh - Alexander Belopolsky - <pre>.. It is unfortunate that official text of IEEE-754 is not freely available and as a result a lot of discussion in this thread is based on imperfect information. I find Kahan's \"Lecture Notes on the Status of IEEE Standard 754 for Binary Floating-Point Arithmetic\" [1] a reasonable reference in the absence of the official text. According to Kahan's notes, INVALID operation is defined as follows: \"\"\" Exception: INVALID operation. Signaled by the raising of the INVALID flag whenever an operation's operands lie outside its domain, this exception's default, delivered only because any other real or infinite value would most likely cause worse confusion, is NaN , which means \u201c Not a Number.\u201d IEEE 754 specifies that seven invalid arithmetic operations shall deliver a NaN unless they are trapped: real \u221a(Negative) , 0*\u221e , 0.0/0.0 , \u221e/\u221e, REMAINDER(Anything, 0.0) , REMAINDER( \u221e, Anything) , \u221e - \u221e when signs agree (but \u221e + \u221e = \u221e when signs agree). Conversion from floating-point</pre>", "group_id": 8954, "id": 859614}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304098230.661592, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBoolidentity shortcut) - http://tinyurl.com/5rvp4vf - Guido van Rossum - <pre>On Fri, Apr 29, 2011 at 12:10 AM, Stephen J. Turnbull &lt;stephen&lt; at &gt;xemacs.org&gt; wrote: ISTM that the current behavior of NaN (never mind the identity issue) helps numeric experts write better code. For naive users, however, it causes puzzlement if they ever run into it. Decimal, for that reason, has a context that lets one specify different behaviors when a NaN is produced. Would it make sense to add a float context that also lets one specify what should happen? That could include returning Inf for 1.0/0.0 (for experts), or raising exceptions when NaNs are produced (for the numerically naive like myself). I could see a downside too, e.g. the correctness of code that passingly uses floats might be affected by the context settings. There's also the question of whether the float context should affect int operations; floats vs. ints is another can of worms since (in Python 3) we attempt to tie them together through 1/2 == 0.5, but ints have a much larger range than floats. </pre>", "group_id": 8954, "id": 860125}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304099191.379843, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBoolidentity shortcut) - http://tinyurl.com/6fpzoqo - Alexander Belopolsky - <pre> ISTM, this is approaching py4k territory. Adding contexts will not solve backward compatibility problem unless you introduce a \"quirks\" contexts that would preserve current warts and make it default. For what it's worth, I think the next major version of Python should use decimal as its main floating point type an leave binary floats to numerical experts. </pre>", "group_id": 8954, "id": 860305}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304104592.755549, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/6equx8m - Terry Reedy - <pre> http://docs.python.org/devguide/coverage.html has a link to http://coverage.livinglogic.de/ </pre>", "group_id": 8954, "id": 861586}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304105492.099349, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/6czbfdv - Terry Reedy - <pre> which, however, currently has nothing for *.py. Perhaps a glitch/bug, as there used to be such. Anyone who knows the page owner might ask about this. </pre>", "group_id": 8954, "id": 861862}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304112733.9447939, "message": "[devel] - Fwd: viewVC shows traceback on non utf-8 module markup - http://tinyurl.com/63meqbo - Michael Foord - <pre>I know that the svn repo is now for legacy purposes only, but I doubt it is intended that the online source browser should raise exceptions. (See report below.) All the best, Michael -------- Original Message -------- Subject: viewVC shows traceback on non utf-8 module markup Date: Thu, 28 Apr 2011 17:47:12 +0900 From: Ikkei Shimomura &lt;ikkei.shimomura&lt; at &gt;gmail.com&gt; To: webmaster&lt; at &gt;python.org Hi, here is a report, I found some module markup shows traceback. like this: http://svn.python.org/view/python/trunk/Lib/heapq.py?view=markup I do not know about latin-1 coding, this is just note what I found at that position It's \"\\xe7\" and as I read the traceback, viewvc and pygment assumes utf-8 encoding, its hard-coded. Other modules which use non- utf8 encoding (searched by grep -r coding\\: *.py) inspect, pydoc were ok. tarfile, shlex were not. Excute me for my writting broken English. ---- Ikkei Shimomura </pre>", "group_id": 8954, "id": 864287}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304113637.7515991, "message": "[devel] - Re: python and super - http://tinyurl.com/62hwrca - Ethan Furman - <pre> I have to disagree -- anytime you are using somebody else's code you need to be aware of what it's supposed to do -- especially when playing with multiple inheritance. This response to the decorator I wrote for this situation may be helpful: Carl Banks wrote (on Python-List): &gt; The problem is that he was doing mixins wrong. Way wrong. &gt; &gt; Here is my advice on mixins: &gt; &gt; Mixins should almost always be listed first in the bases. (The only &gt; exception is to work around a technicality. Otherwise mixins go &gt; first.) &gt; &gt; If a mixin defines __init__, it should always accept self, *args and &gt; **kwargs (and no other arguments), and pass those on to &gt; super().__init__. Same deal with any other function that different &gt; sister classes might define in varied ways (such as __call__). &gt; &gt; A mixin should not accept arguments in __init__. Instead, it should &gt; burden the derived class to accept arguments on its behalf, and set &gt; attributes before calling super().__init__, which the mixin can &gt; acc</pre>", "group_id": 8954, "id": 864410}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304113635.0428021, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/3rn5ptq - Vinay Sajip - <pre> Thanks for the pointer, nevertheless, Terry. Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 864409}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304116332.4596801, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/62lxfdh - Robert Kern - <pre>On Fri, Apr 29, 2011 at 11:35, Alexander Belopolsky &lt;alexander.belopolsky&lt; at &gt;gmail.com&gt; wrote: Nonetheless, the reason that *Python* raises a ZeroDivisionError is because it checks that the divisor is 0.0, not because 0.0/0.0 would issue an INVALID signal. I didn't mean that 0.0/0.0 is a \"Division by Zero\" error as defined in IEEE-754. This is another area where Python ignores the INVALID signal and does its own thing. Right. Elsewhere I gave a more exhaustive list including this one. The other is int(nan), though that becomes a Python exception for a more fundamental reason (there is no integer value that can represent it) than that the IEEE-754 standard specifies that the operation should signal INVALID. Arithmetic operations on signalling NaNs don't raise an exception either. These are the minority *exceptions* to the majority of cases where operations on Python floats that would issue an INVALID signal do not raise Python exceptions. If you want to lump all of the inf-related cases together, that's fine</pre>", "group_id": 8954, "id": 864732}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304126293.0365169, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/66sgrk3 - Greg Ewing - <pre> But the exception you get is ZeroDivisionError, so I think Python is catching this before you get to the stage of producing a NaN. </pre>", "group_id": 8954, "id": 865516}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304147173.7846861, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/3kqldl2 - Mark Dickinson - <pre> History, I think. There's a c.l.p. message from Tim Peters somewhere saying something along the lines that he'd love to make (e.g.,) 1e300 * 1e300 raise an exception instead of producing an infinity, but dare not for fear of the resulting outcry from people who use the current behaviour. Apologies if I've misrepresented what he actually said---I'm failing to find the exact message at the moment. If it weren't for backwards compatibility, I'd love to see Python raise exceptions instead of producing IEEE special values: IOW, to act as though the divide-by-zero, overflow and invalid_operation FP signals all produce an exception. As a bonus, perhaps there could be a mode that allowed 'nonstop' arithmetic, under which infinities and nans were produced as per IEEE 754: with math.non_stop_arithmetic(): ... But this is python-ideas territory. Mark </pre>", "group_id": 8954, "id": 866777}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304160676.4738491, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/3r5sdyt - Antoine Pitrou - <pre>On Sat, 30 Apr 2011 08:02:33 +0100 Mark Dickinson &lt;dickinsm&lt; at &gt;gmail.com&gt; wrote: I would much prefer this idea than the idea of making NaNs non-orderable. It would break code, but at least it would break in less unexpected and annoying ways. Regards Antoine. </pre>", "group_id": 8954, "id": 867397}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304166207.7439799, "message": "[devel] - Re: [Python-checkins] cpython: PyGILState_Ensure(), PyGILState_Release(), PyGILState_GetThisThreadState() are - http://tinyurl.com/3eoer4k - Victor Stinner - <pre>Le mercredi 27 avril 2011 \u00e0 20:18 -0400, Jim Jewett a \u00e9crit : Oh, I realized that PyGILState_STATE may also be included only if Python is compiled with threads. -- PyGILState_Ensure() and PyGILState_Release() could be no-op yes, it would simplify the usage of these functions. For example: #ifdef WITH_THREAD PyGILState_STATE gil; #endif fprintf(stderr, \"object : \"); #ifdef WITH_THREAD gil = PyGILState_Ensure(); #endif (void)PyObject_Print(op, stderr, 0); #ifdef WITH_THREAD PyGILState_Release(gil); #endif -- Even without threads, a Python process has a PyThreadState structure, so PyGILState_GetThisThreadState() can be patched to work even if Python is compiled without threads. -- Would you like to work on such patch? Or at least open an issue? Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/pyt</pre>", "group_id": 8954, "id": 867657}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304173406.685216, "message": "[devel] - Re: Not-a-Number - http://tinyurl.com/5tkvnhd - Tim Peters - <pre>[Greg Ewing] [Mark Dickinson] Exactly. It's impossible to create a NaN from \"normal\" inputs without triggering div-by-0 or invalid_operation, and if overflow were also enabled it would likewise be impossible to create an infinity from normal inputs. So, 20 years ago, that's how I arranged Kendall Square Research's default numeric environment: enabled those three exception traps by default, and left the underflow and inexact exception traps disabled by default. It's not just \"naive\" users initially baffled by NaNs and infinities; most of KSR's customers were heavy duty number crunchers, and they didn't know what to make of them at first either. But experts do find them very useful (after climbing the 754 learning curve), so there was also a simple function call (from all the languages we supported - C, C++, FORTRAN and Pascal), to establish the 754 default all-traps-disabled mode: All of which is just moving toward the numeric environment 754 was aiming for from the start: complete user control over</pre>", "group_id": 8954, "id": 868305}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304176107.5019641, "message": "[devel] - Re: Issue Tracker - http://tinyurl.com/3ktrxyq - anatoly techtonik - <pre> How much in % is it worse than Django templating language? -- anatoly t. </pre>", "group_id": 8954, "id": 868545}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304179709.05229, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/6k52fsu - \u00c9ric Araujo - <pre> Hi, Le 29/04/2011 18:09, Vinay Sajip a \u00e9crit : I remember only this: http://bugs.python.org/issue11572#msg131139 Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 868936}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304204131.2089801, "message": "[devel] - sys.settrace: behavior doesn't match docs - http://tinyurl.com/3srcj9o - Ned Batchelder - <pre>This week I learned something new about trace functions (how to write a C trace function that survives a sys.settrace(sys.gettrace()) round-trip), and while writing up what I learned, I was surprised to discover that trace functions don't behave the way I thought, or the way the docs say they behave. The docs say: The trace function is invoked (with /event/ set to 'call') whenever a new local scope is entered; it should return a reference to a local trace function to be used that scope, or None if the scope shouldn't be traced. The local trace function should return a reference to itself (or to another function for further tracing in that scope), or None to turn off tracing in that scope. It's that last part that's wrong: returning None from the trace function only has an effect on the first call in a new frame. Once the trace function returns a function for a frame, returning None from subsequent calls is ignored. A \"local trace function\" can't turn off tracing in i</pre>", "group_id": 8954, "id": 872876}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304211333.156806, "message": "[devel] - Re: sys.settrace: behavior doesn't match docs - http://tinyurl.com/3chl29q - Guido van Rossum - <pre>I think you need to go back farther in time. :-) In Python 2.0 the call_trace function in ceval.c has a completely different signature (but the docs are the same). I haven't checked all history but somewhere between 2.0 and 2.3, SET_LINENO-less tracing was added, and that's where the implementation must have gone wrong. So I think we should fix the code. --Guido On Sat, Apr 30, 2011 at 3:49 PM, Ned Batchelder &lt;ned&lt; at &gt;nedbatchelder.com&gt; wrote: </pre>", "group_id": 8954, "id": 873300}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304247453.8111329, "message": "[devel] - Re: 2to3 status, repositories and HACKING guide - http://tinyurl.com/3dzwn4t - anatoly techtonik - <pre>Is there any high-level overview of 2to3 tool that people can use as a quick start for writing their own fixers? Source doesn't explain much (to me at least), and some kind of \"learn by example\" would really help a lot. In particular, I find the syntax of tree matchers the most unclear part. -- anatoly t. On Fri, Mar 25, 2011 at 9:12 PM, Benjamin Peterson &lt;benjamin&lt; at &gt;python.org&gt; wrote: </pre>", "group_id": 8954, "id": 874445}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304250154.0612381, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBoolidentity shortcut) - http://tinyurl.com/664v6jz - Nick Coghlan - <pre> Given that we delegate most float() behaviour to the underlying CPU and C libraries (and then the math module tries to cope with any cross-platform discrepancies), introducing context handling isn't easy, and would likely harm the current speed advantage that floats hold over the decimal module. We decided that losing the speed advantage of native integers was worthwhile in order to better unify the semantics of int and long for Py3k, but both the speed differential and the semantic gap between float() and decimal.Decimal() are significantly larger. However, I did find Terry's suggestion of using the warnings module to report some of the floating point corner cases that currently silently produce unexpected results to be an interesting one. If those operations issued a FloatWarning, then users could either silence them or turn them into errors as desired. Cheers, Nick. </pre>", "group_id": 8954, "id": 874665}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304265634.7451921, "message": "[devel] - Re: 2to3 status, repositories and HACKING guide - http://tinyurl.com/6augqjf - Benjamin Peterson - <pre>2011/5/1 anatoly techtonik &lt;techtonik&lt; at &gt;gmail.com&gt;: No. I think you can learn a lot by reading through the current fixers in lib2to3/fixers/. </pre>", "group_id": 8954, "id": 876347}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304268394.801224, "message": "[devel] - Re: Issue Tracker - http://tinyurl.com/67qeybp - Georg Brandl - <pre> I'm just guessing here, but I'd say 47.256 %. Georg </pre>", "group_id": 8954, "id": 876537}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304272896.5489061, "message": "[devel] - Python 3.2.1 - http://tinyurl.com/3uzbayh - Georg Brandl - <pre>Hi, I'd like to release Python 3.2.1 on May 21, with a release candidate on May 14. Please bring any issues you think need to be fixed in it to my attention by assigning \"release blocker\" status in the tracker. Georg </pre>", "group_id": 8954, "id": 876983}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304276495.0929339, "message": "[devel] - Re: Not-a-Number (was PyObject_RichCompareBoolidentity shortcut) - http://tinyurl.com/4ybhdgs - Terry Reedy - <pre> I would like to take credit for that, but I was actually seconding Alexander's insight and idea. I may have added the specific name after looking at the currently list and seeing UnicodeWarning and BytesWarning, so why not a FloatWarning. I did read the warnings doc more carefully to verify that it would really put the user in control, which was apparently the intent of the committee. I am not sure whether FloatWarnings should ignored or printed by default. Ignored would, I guess, match current behavior, unless something else is changed as part of a more extensive overhaul. -f and -ff are available to turn ignored FloatWarning into print or raise exception, as with BytesWarning. I suspect that these would get at lease as much usage as -b and -bb. So I see 4 questions: 1. Add FloatWarning? 2. If yes, default disposition? 3. Add command line options? 4. Use the addition of FloatWarning as an opportunity to change other defaults, given that user will have more options? </pre>", "group_id": 8954, "id": 877280}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304283756.7367721, "message": "[devel] - Windows 2000 Support - http://tinyurl.com/6g28jcr - Brian Curtin - <pre>I'm currently writing a post about the process of removing OS/2 and VMS support and thought about a discussion of Windows 2000 some time back. http://mail.python.org/pipermail/python-dev/2010-March/098074.html makes a proposal for beginning to walk away from 2000, but doesn't appear to come to any conclusion. Was anything decided off the list? I don't see anything in PEP-11 and don't see any changes in the installer made around Windows 2000. If nothing was decided, should anything be done for 3.3? </pre>", "group_id": 8954, "id": 877928}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304333508.55563, "message": "[devel] - Raise OSError or RuntimeError in the OS module? - http://tinyurl.com/6f9nmtz - Victor Stinner - <pre>Hi, I introduced recently the signal.pthread_sigmask() function (issue #8407). pthread_sigmask() (the C function) returns an error code using errno codes. I choosed to raise a RuntimeError using this error code, but I am not sure that RuntimeError is the best choice. It is more an OS error than a runtime error: should signal.pthread_sigmask() raise an OSError instead? signal.signal() raises a RuntimeError if setting the signal handler failed. signal.siginterrupt() raises also a RuntimeError on error. signal.setitimer() and signal.getitimer() have their own exception class: signal.ItimerError, raised on setimer() and getitimer() error. Victor </pre>", "group_id": 8954, "id": 881965}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304336208.6494081, "message": "[devel] - Re: sys.settrace: behavior doesn't match docs - http://tinyurl.com/6ksenhe - Ned Batchelder - <pre>Indeed, the 2.0 code is very different, and got this case right. I'm a little surprised no one is arguing that changing this code now could break some applications. Maybe the fact no one noticed the docs were wrong proves that no one ever tried returning None from a local trace function. --Ned. On 4/30/2011 8:43 PM, Guido van Rossum wrote: </pre>", "group_id": 8954, "id": 882132}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304340711.8219609, "message": "[devel] - Re: sys.settrace: behavior doesn't match docs - http://tinyurl.com/69vf5tr - Mark Hammond - <pre>... Or if they did, they should have complained by now. IMO, if the behaviour regresses from how it is documented and how it previously worked and no reports of the regression exist, we should just fix it without regard to people relying on the \"new\" functionality... Mark </pre>", "group_id": 8954, "id": 882650}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304342568.067898, "message": "[devel] - Re: sys.settrace: behavior doesn't match docs - http://tinyurl.com/6fzyx99 - Nick Coghlan - <pre> +1 Cheers, Nick. </pre>", "group_id": 8954, "id": 882890}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304347071.2505679, "message": "[devel] - Re: Socket servers in the test suite - http://tinyurl.com/3uvsuck - Vinay Sajip - <pre> I've made a start with test_logging.py by implementing some potential server classes for use in tests: in the latest test_logging.py, the servers are between comments containing the text \"server_helper\". The basic approach for implementing socket servers is traditionally to use a request handler class which implements the custom logic, but for some testing applications this is overkill - you just want to be able to pass a handling callable which is, say, a test case method. So the signatures of the servers are all like this: __init__(self, listen_addr, handler, poll_interval ...) Initialise using the specified listen address and handler callable. Internally, a RequestHandler subclass will be used whose handle() delegates to the handler callable passed in. A zero port number can be passed in, and a port attribute will (after binding) have the actual port number used, so that clients can connect on that port. start() Start the server on a separate thread, using the poll_interval specified in the underly</pre>", "group_id": 8954, "id": 883716}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304353369.9659469, "message": "[devel] - Re: Issue Tracker - http://tinyurl.com/3kgyy89 - anatoly techtonik - <pre> That means switching to Django templates will make Roundup design plumbing work 47.256% more attractive for potential contributors. -- anatoly t. </pre>", "group_id": 8954, "id": 885343}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304353373.336345, "message": "[devel] - Re: Issue Tracker - http://tinyurl.com/3t5gp93 - Benjamin Peterson - <pre>2011/5/2 anatoly techtonik &lt;techtonik&lt; at &gt;gmail.com&gt;: Perhaps some of those eager contributors would like to volunteer for the task. </pre>", "group_id": 8954, "id": 885344}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304353377.0931499, "message": "[devel] - Re: Issue Tracker - http://tinyurl.com/3mbfuct - Brian Curtin - <pre> What if these \"potential contributors\" never surface? Then we've made a 47.256% change in attractiveness, which is a 1423.843% waste of time. </pre>", "group_id": 8954, "id": 885345}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304356974.629003, "message": "[devel] - Re: PEP 386 and dev repository versions workflow - http://tinyurl.com/6et4rhp - Tarek Ziad\u00e9 - <pre> This is a typo I'll fix, thanks for noticing </pre>", "group_id": 8954, "id": 886229}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304356969.7320781, "message": "[devel] - PEP 386 and dev repository versions workflow - http://tinyurl.com/6bjcuby - anatoly techtonik - <pre>http://guide.python-distribute.org/quickstart.html proposes suffixing version of a module in repository with 'dev' in a way that after release of '1.0' version, the repository version is changed to '2.0dev'. This makes sense, but it is not compatible with PEP 386, which suggests using 2.0.devN, where N is a repository revision number. I'd expand PEP 386 to include 2.0dev use case. -- anatoly t. </pre>", "group_id": 8954, "id": 886227}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304361473.7456231, "message": "[devel] - Re: Issue Tracker - http://tinyurl.com/635cg88 - Giampaolo Rodol\u00e0 - <pre>2011/4/30 anatoly techtonik &lt;techtonik&lt; at &gt;gmail.com&gt;: Knowing both of them I can say ZPT is one of the few things I like about Zope and I find it a lot more powerful than Django templating system. Other than that, I don't see how changing the templating language can make any difference. If one does not contribute something because of the language used in templates... well, I think it wouldn't have been a particular good contribution anyway. =) --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ </pre>", "group_id": 8954, "id": 887264}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304362369.695051, "message": "[devel] - Re: Issue Tracker - http://tinyurl.com/5tgzhar - Georg Brandl - <pre> That's not true actually. It'll be 89.595 % more attractive. Georg </pre>", "group_id": 8954, "id": 887577}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304363272.349833, "message": "[devel] - Convert Py_Buffer to Py_UNICODE - http://tinyurl.com/6hoyxmk - Sijin Joseph - <pre>Hi - I am working on a patch where I have an argument that can either be a unicode string or binary data, I parse the argument using the PyArg_ParseTuple method using the s* format specification and get a Py_Buffer. I now need to convert this Py_Buffer object to a Py_Unicode and pass it into a function. What is the best way to do this? If I determine that the passed argument was binary using another flag parameter then I am passing Py_Buffer-&gt;buf as a pointer to the start of the data. This is in winsound module, here's the relevant code snippet sound_playsound(PyObject *s, PyObject *args) { Py_buffer *buffer; int flags; int ok; LPCWSTR pszSound; if (PyArg_ParseTuple(args, \"s*i:PlaySound\", &amp;buffer, &amp;flags)) { if (flags &amp; SND_ASYNC &amp;&amp; flags &amp; SND_MEMORY) { /* Sidestep reference counting headache; unfortunately this also prevent SND_LOOP from memory. */ PyBuffer_Release(buffer); PyErr_SetString(PyExc_RuntimeError, \"Cannot play as</pre>", "group_id": 8954, "id": 887749}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304363269.401778, "message": "[devel] - running/stepping python backwards - http://tinyurl.com/6j9abnc - Adrian Johnston - <pre>This may seem like an odd question, but I\u2019m intrigued by the idea of using Python as a data definition language with \u201cundo\u201d support. If I were to try and instrument the Python interpreter to be able to step backwards, would that be an unduly difficult or inefficient thing to do? (Please reply to me directly.) </pre>", "group_id": 8954, "id": 887747}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304364168.8500559, "message": "[devel] - Re: Convert Py_Buffer to Py_UNICODE - http://tinyurl.com/3l7oo38 - M.-A. Lemburg - <pre> I don't understand why you'd want to convert PyUnicode to PyBytes (encoded as UTF-8), only to decode it again afterwards in order to pass it to some other PyUnicode API. It'd be more efficient to use the \"O\" parser marker and then use PyObject_GetBuffer() to convert non-PyUnicode objects to a Py_buffer. </pre>", "group_id": 8954, "id": 887966}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304365071.743412, "message": "[devel] - Re: Issue Tracker - http://tinyurl.com/4xu9now - Benjamin Peterson - <pre>2011/5/2 Georg Brandl &lt;g.brandl&lt; at &gt;gmx.net&gt;: I don't understand why you're truncating to 3 digits. Let's be honest in that it will be sqrt(2)^(13e/2) % more attractive. </pre>", "group_id": 8954, "id": 888214}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304371436.881671, "message": "[devel] - Re: running/stepping python backwards - http://tinyurl.com/66rhass - Dan Stromberg - <pre> Actually, this is not only appropriate on some lists, on some lists one is actually strongly discouraged from doing anything else. EG: sun-managers, where replies are expected to be private, and the originator of the thread is expected to collect all (private) replies and summarize them, to keep the list traffic low and the S/N ratio high. </pre>", "group_id": 8954, "id": 889812}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304371434.5691569, "message": "[devel] - Re: Windows 2000 Support - http://tinyurl.com/6xvx4b6 - Martin v. L\u00f6wis - <pre>Am 01.05.2011 22:51, schrieb Brian Curtin: That's what you get for not following your own processes. It seems the discussion just stopped, with no action. I vaguely recall having made changes to the installer to produce a warning, but apparently never got to commit these changes. Most certainly. It seems we missed the chance of dropping support for W2k, so we still can't actively remove any code. However, I'd a) add it to PEP 11, and b) add a warning to the installer I stand by http://mail.python.org/pipermail/python-dev/2010-March/098101.html i.e. if there are patches that happen not to work on W2k, I'd accept them anyway - anybody interested in W2k would then have to provide fixes before 3.3rc1. So please go ahead and change PEP 11. While you are at it, also threaten to remove support for systems where the COMSPEC points to command.com (#2405). Regards, Martin </pre>", "group_id": 8954, "id": 889811}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304370529.6618321, "message": "[devel] - Re: running/stepping python backwards - http://tinyurl.com/6hq6zqn - Terry Reedy - <pre> The pydev list is for development of the next version of Python. Please direct your question to a more appropriate forum such as python-list. &gt; (Please reply to me directly.) I did this time, but you should not expect that when posting to a public list. </pre>", "group_id": 8954, "id": 889625}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304378633.7201619, "message": "[devel] - Re: Fwd: viewVC shows traceback on non utf-8 module markup - http://tinyurl.com/69xpq2m - Martin v. L\u00f6wis - <pre>Am 29.04.2011 22:03, schrieb Michael Foord: It's certainly not. However, I don't plan to do anything about it, either (nor would I know that anybody else would). To view the source code of the file, use http://svn.python.org/view/python/trunk/Lib/heapq.py?view=co&amp;content-type=text/plain Regards, Martin </pre>", "group_id": 8954, "id": 890722}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304384090.8782189, "message": "[devel] - Re: Windows 2000 Support - http://tinyurl.com/6jqubeg - Brian Curtin - <pre> Done and done - http://hg.python.org/peps/rev/b9390aa12855 I'll have a look at the installer and add some type of message. </pre>", "group_id": 8954, "id": 891457}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304433166.214308, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by - http://tinyurl.com/3k4hnj4 - Nadeem Vawda - <pre>On Tue, May 3, 2011 at 3:19 PM, victor.stinner &lt;python-checkins&lt; at &gt;python.org&gt; wrote: 0x7FFFFFFF is (2G-1) bytes. For a 2GB buffer, int_max should be 0x80000000. However, if you make this change, crc32() and adler32() raise OverflowErrors (see changeset a0681e7a6ded). This makes the test to erroneously report that the filesystem doesn't support large files. The assertEqual() tests should probably be changed to assertRaises(..., OverflowError). Also, the assignment to m needs to be moved outside of the inner try...finally block. If mmap() fails, the call to m.close() raises a new exception because m has not yet been bound. This seems to be causing failures on some of the 32-bit buildbots. As an aside, in this sort of situation is it better to just go and commit a fix myself, or is raising it on the mailing list first the right way to do things? Cheers, Nadeem _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubs</pre>", "group_id": 8954, "id": 898535}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304448648.5387731, "message": "[devel] - Re: Windows 2000 Support - http://tinyurl.com/3hblvfo - Brian Curtin - <pre> It turns out that you did make the change at some point for 2.7 being the last, but there was no corresponding 3.x version chosen. http://hg.python.org/cpython/rev/de53c52fbcbf changed the installer to list 3.3.0 as the last Windows 2000 release on the default branch. </pre>", "group_id": 8954, "id": 901699}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304450505.2815421, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by - http://tinyurl.com/5vem6wc - Antoine Pitrou - <pre> Hello, On Tue, 3 May 2011 16:22:27 +0200 Nadeem Vawda &lt;nadeem.vawda&lt; at &gt;gmail.com&gt; wrote: Raising it on the mailing-list makes it serve as a kind of post-commit review. Also, it ensures that the committer of the original patch understands the issues with it. cheers Antoine. </pre>", "group_id": 8954, "id": 902097}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304448644.7788739, "message": "[devel] - Re: Raise OSError or RuntimeError in the OS module? - http://tinyurl.com/66zdgfg - Georg Brandl - <pre> If it has an errno, it should be a subclass of EnvironmentError. Georg </pre>", "group_id": 8954, "id": 901697}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304455967.60269, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by - http://tinyurl.com/5t2wx9d - Victor Stinner - <pre>Le mardi 03 mai 2011 \u00e0 16:22 +0200, Nadeem Vawda a \u00e9crit : I don't want to check OverflowError: the test is supposed to compute the checksum of a buffer of 0x7FFFFFFF bytes, to check crc32() and adler32(). 0x7FFFFFFF is the biggest size supported by these functions (zlib doesn't use Py_ssize_t in Python 2.7). If you use a buffer of 0x80000000 bytes, you test PyArg_Parse*() functions, which have already a dedicated test (in test_xml_etree_c, it's not the best file to store such test...). Yeah, I noticed this with buildbots: already fixed by dd58f8072216. I'm not sure that you understood the test, so I think that it's better to ask first on IRC and/or the mailing list. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 903347}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304457826.5452549, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by - http://tinyurl.com/3f43wan - Nadeem Vawda - <pre>On Tue, May 3, 2011 at 10:38 PM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: I see. Since you mentioned issue 10276 in the commit message, I assumed you were testing for the underlying C functions truncating their arguments. It seems that I was mistaken. Sorry for the confusion. Cheers, Nadeem </pre>", "group_id": 8954, "id": 903690}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304500310.3991871, "message": "[devel] - The zombi thread of the Tcl library - http://tinyurl.com/3s26hmc - Victor Stinner - <pre>Hi, I have a question: would it be possible to mask all signals in the Tcl thread? To understand the question, let's see the context... I'm working on signals, especially on pthread_sigmask(), and I'm trying to understand test_signal failures. test_signal fails if the _tkinter module is loaded, because _tkinter loads the Tcl library which create a thread waiting events in select(). For example, \"python -m test test_pydoc test_signal\" fails, because test_pydoc loads ALL Python modules. I opened an issue for test_pydoc: http://bugs.python.org/issue11995 _tkinter.c contains the following code: #if 0 /* This was not a good idea; through &lt;Destroy&gt; bindings, Tcl_Finalize() may invoke Python code but at that point the interpreter and thread state have already been destroyed! */ Py_AtExit(Tcl_Finalize); #endif Tcl_Finalize() exits the thread, but this function is never called in Python. Anyway, it is not possible to unload a module implemented in C. I would like to know if it would be pos</pre>", "group_id": 8954, "id": 911058}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304500313.419764, "message": "[devel] - Borrowed and Stolen References in API - http://tinyurl.com/3cuksl8 - Mark Shannon - <pre>Hi, The online documentation specifies which API function borrow and/or steal references (as opposed to the default behaviour). Yet, I cannot find this information anywhere in the source. Any clues as to where I should look? Cheers, Mark </pre>", "group_id": 8954, "id": 911059}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304502169.0544081, "message": "[devel] - Borrowed and Stolen References in API - http://tinyurl.com/6jcf3ap - Amaury Forgeot d'Arc - <pre>Hi, Le mercredi 4 mai 2011, Mark Shannon &lt;marks&lt; at &gt;dcs.gla.ac.uk&gt; a \u00e9crit\u00a0: It's in the file Doc/data/refcounts.dat in some custom format. </pre>", "group_id": 8954, "id": 911364}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304504032.3459239, "message": "[devel] - Re: The zombi thread of the Tcl library - http://tinyurl.com/3e7ecqe - Antoine Pitrou - <pre>On Wed, 04 May 2011 10:58:42 +0200 Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: You could expose Tcl_Finalize() for debug purposes and call it in test_signal. Regards Antoine. </pre>", "group_id": 8954, "id": 911476}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304510332.2264991, "message": "[devel] - Re: The zombi thread of the Tcl library - http://tinyurl.com/3fqtk3q - Victor Stinner - <pre>Le mercredi 04 mai 2011 \u00e0 12:05 +0200, Antoine Pitrou a \u00e9crit : Good idea. I opened an issue with a patch implementing Tcl_Finalize(): http://bugs.python.org/issue11998 I also added a workaround _tkinter border effect in test_signal. Buildbots look to be happy. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 912023}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304529351.9607649, "message": "[devel] - New interest areas in Experts Index - http://tinyurl.com/68nnhol - Nick Coghlan - <pre>I just added two new interest areas in the Expert's Index [1] context managers: for any issues relating to proposals to add context management capabilities to objects in the stdlib, triagers should feel free to add me to the nosy list test coverage: this is specifically for anyone willing to help review and commit test coverage improvement patches (rather than the more general \"testing\" interest area that was already present) Cheers, Nick. [1] http://docs.python.org/devguide/experts </pre>", "group_id": 8954, "id": 915965}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304538418.2240951, "message": "[devel] - Re: cpython (2.7): Issue #11277: test_zlib tests a buffer of 1 GB on 32bits - http://tinyurl.com/3qmosb8 - Antoine Pitrou - <pre>On Wed, 04 May 2011 21:27:50 +0200 victor.stinner &lt;python-checkins&lt; at &gt;python.org&gt; wrote: What's the point? The issue with 2GB or 4GB buffers is that they cross the potential limit of a machine type (a signed or unsigned integer). I don't see any benefit in testing a 1GB buffer; the test could probably be removed instead. Regards Antoine. </pre>", "group_id": 8954, "id": 918801}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304548495.313992, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/3hotswl - Greg Ewing - <pre> However, it doesn't seem to quite convey the same information. It lists the \"refcount effect\" on each parameter, but translating that into the notion of borrowed or stolen references seems to require knowledge of what the function does. For example, PyDict_SetItem has: PyDict_SetItem:PyObject*:p:0: PyDict_SetItem:PyObject*:key:+1: PyDict_SetItem:PyObject*:val:+1: All of these parameters take borrowed references, but the key and val get incremented because they're being stored in the dict. So this file appears to be of limited usefulness. </pre>", "group_id": 8954, "id": 920906}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304548491.8640721, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/3puj79t - Greg Ewing - <pre> There are comments in some places, e.g. in listobject.h: *** WARNING *** PyList_SetItem does not increment the new item's reference count, but does decrement the reference count of the item it replaces, if not nil. It does *decrement* the reference count if it is *not* inserted in the list. Similarly, PyList_GetItem does not increment the returned item's reference count. If you're looking for evidence in the actual code, there's nothing particular to look for -- it's implicit in the way the function works overall. </pre>", "group_id": 8954, "id": 920905}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304549393.6808081, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by - http://tinyurl.com/3wpucf5 - Ethan Furman - <pre> The comment says 'check that inputs of 2 GB are handled correctly' but the file created is 1 byte short of 2Gb. Is the test wrong, or just wrongly commented? Or am I not understanding? ~Ethan~ _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 921018}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304589057.2268579, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by - http://tinyurl.com/4ykudj3 - Victor Stinner - <pre>Le mercredi 04 mai 2011 \u00e0 15:40 -0700, Ethan Furman a \u00e9crit : If you write a byte after 2 GB of zeros, the file size is 2 GB+the few bytes. This trick is to create quickly a large file: some OSes support sparse files, zeros are not written on disk. But on Mac OS X and Windows, you really write 2 GB+some bytes. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 927172}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304589955.0042109, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by - http://tinyurl.com/5uhkofb - Paul Moore - <pre> FWIW, on Windows you can create sparse files, using DeviceIoControl(FILE_SET_SPARSE). It's probably too messy to be worth it for this case, though... Paul </pre>", "group_id": 8954, "id": 927265}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304589062.3848081, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by - http://tinyurl.com/3cyau8q - Nadeem Vawda - <pre>On Thu, May 5, 2011 at 11:33 AM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: Ethan's point is that 0x7FFFFFFF is not 2GB - it is (2G-1) bytes. So the test and the preceding comment are inconsistent. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 927174}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304590856.106796, "message": "[devel] - Re: What if replacing items in a dictionary returns the new dictionary? - http://tinyurl.com/3cme8kb - Giuseppe Ottaviano - <pre>On Fri, Apr 29, 2011 at 4:05 PM, Roy Hyunjin Han &lt;starsareblueandfaraway&lt; at &gt;gmail.com&gt; wrote: In general nothing stops you to use a proxy object that returns itself after each method call, something like class using(object): def __init__(self, obj): self._wrappee = obj def unwrap(self): return self._wrappee def __getattr__(self, attr): def wrapper(*args, **kwargs): getattr(self._wrappee, attr)(*args, **kwargs) return self return wrapper d = dict() print using(d).update(dict(a=1)).update(dict(b=2)).unwrap() # prints {'a': 1, 'b': 2} l = list() print using(l).append(1).append(2).unwrap() # prints [1, 2] </pre>", "group_id": 8954, "id": 927334}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304592654.891995, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/44rmq6y - Amaury Forgeot d'Arc - <pre>Hi, Le jeudi 5 mai 2011, Greg Ewing &lt;greg.ewing&lt; at &gt;canterbury.ac.nz&gt; a \u00e9crit\u00a0: This is not always true, for example when the item is already present in the dict. It's not important to know what the function does to the object, Only the action on the reference is relevant. </pre>", "group_id": 8954, "id": 927469}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304598116.1734769, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by - http://tinyurl.com/3w7yy2c - Ethan Furman - <pre> &gt;&gt;&gt; &gt;&gt; True, but that's not what's happening -- four bytes are being written at int_max - 4, and int_max is one less that 2GB; hence the resulting file is one less than 2GB. ~Ethan~ </pre>", "group_id": 8954, "id": 928011}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304599016.409658, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by - http://tinyurl.com/3v4bdsx - Victor Stinner - <pre>Le jeudi 05 mai 2011 \u00e0 05:07 -0700, Ethan Furman a \u00e9crit : Yep, it's 0x7FFFFFFF because it's INT_MAX, the biggest value storable in an int. The zlib module stores the buffer size into an int in Python 2.7 (and Py_ssize_t in Python 3.3). Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 928137}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304610836.5086169, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by - http://tinyurl.com/69kj3kd - Ethan Furman - <pre> &gt;&gt; So we are agreed that the file is not, in fact, 2GB in size... &gt; On Tue, May 3, 2011 at 3:19 PM, victor.stinner &gt; &lt;python-checkins&lt; at &gt;python.org&gt; wrote: &gt;&gt; +# Issue #10276 - check that inputs of 2 GB are handled correctly. &gt;&gt; +# Be aware of issues #1202, #8650, #8651 and #10276 So why do the comments say we are testing a 2GB input? ~Ethan~ </pre>", "group_id": 8954, "id": 930925}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304618996.1733921, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/67svsuo - Amaury Forgeot d'Arc - <pre>2011/5/5 Guido van Rossum &lt;guido&lt; at &gt;python.org&gt;: Should we change this file then? And only list functions that don't follow the usual conventions. But I'm sure that there are external tools which already use refcounts.dat in its present format. </pre>", "group_id": 8954, "id": 932444}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304618998.924021, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/62h47wm - Guido van Rossum - <pre>On Thu, May 5, 2011 at 10:17 AM, Amaury Forgeot d'Arc &lt;amauryfa&lt; at &gt;gmail.com&gt; wrote: Maybe we can *add* a column with the desired information? </pre>", "group_id": 8954, "id": 932446}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304619898.339386, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/4ysv9gy - Georg Brandl - <pre> We're not using the information about arguments anyway in the doc build. So we're free to change the file to list only return types, and parameters in the event of stolen references. Georg </pre>", "group_id": 8954, "id": 932610}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304620799.5805941, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/5sea52q - Raymond Hettinger - <pre> On May 5, 2011, at 10:18 AM, Guido van Rossum wrote: +1 Raymond </pre>", "group_id": 8954, "id": 932796}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304620797.274622, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/5syulpc - Antoine Pitrou - <pre>On Thu, 5 May 2011 19:17:30 +0200 \"Amaury Forgeot d'Arc\" &lt;amauryfa&lt; at &gt;gmail.com&gt; wrote: +1 Regards Antoine. </pre>", "group_id": 8954, "id": 932795}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304621697.7130401, "message": "[devel] - Re: cpython (merge 3.2 -> default): Avoid codec spelling issues by justusing the utf-8 default. - http://tinyurl.com/3eznv8p - Antoine Pitrou - <pre>On Thu, 05 May 2011 20:38:27 +0200 raymond.hettinger &lt;python-checkins&lt; at &gt;python.org&gt; wrote: Isn't explicit better than implicit? By reading the new code it is not obvious that any thought was given to the choice of a codec, while stating \"utf-8\" explicitly hints that a decision was made. (also, I don't understand the spelling issue: \"utf-8\" just works) Regards Antoine. </pre>", "group_id": 8954, "id": 932940}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304622602.44766, "message": "[devel] - Re: cpython (merge 3.2 -> default): Avoid codec spelling issues by just using the utf-8 default. - http://tinyurl.com/42yfjju - Antoine Pitrou - <pre>Le jeudi 05 mai 2011 \u00e0 15:01 -0400, Alexander Belopolsky a \u00e9crit : This sounds like a bug to fix (isn't it fixed it already, btw?) rather than add hackish workarounds for in stdlib code. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 933081}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304622597.0071051, "message": "[devel] - Re: cpython (merge 3.2 -> default): Avoid codec spelling issues by just using the utf-8 default. - http://tinyurl.com/62zxry4 - Alexander Belopolsky - <pre>.. This is probably referring to the fact that while encode() accepts many spelling variants, some are short-circuited in C code while others require codec lookup implemented in python. </pre>", "group_id": 8954, "id": 933078}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304623497.7185071, "message": "[devel] - Re: cpython (merge 3.2 -> default): Avoid codec spelling issues by just using the utf-8 default. - http://tinyurl.com/3fdol95 - Benjamin Peterson - <pre>2011/5/5 Alexander Belopolsky &lt;alexander.belopolsky&lt; at &gt;gmail.com&gt;: Isn't it cached after the first run? If this is the reasoning, I find it hard to believe that seed() is a large bottleneck in random. </pre>", "group_id": 8954, "id": 933288}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304628992.5309529, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/3prtdur - Georg Brandl - <pre> I doubt it. And even if there are, the information in there is in parts highly outdated (because the docs don't use parameter info), and large numbers of functions are missing. Let's remove the cruft, and only keep interesting info. This will also make the file much more manageable. Georg </pre>", "group_id": 8954, "id": 934411}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304636254.0799091, "message": "[devel] - Re: cpython (3.2): Avoid codec spelling issues by just using the utf-8 default. - http://tinyurl.com/6xaf4cb - Terry Reedy - <pre> I thought about this and decided that the purpose of having defaults is so one does not have to always spell it out. So use it. Readers can always look it up and learn. </pre>", "group_id": 8954, "id": 935343}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304638054.054693, "message": "[devel] - Re: [Python-checkins] cpython (3.2): Avoid codec spelling issues by just using the utf-8 default. - http://tinyurl.com/5shh27e - Victor Stinner - <pre>Le jeudi 05 mai 2011 \u00e0 18:54 -0400, Alexander Belopolsky a \u00e9crit : You don't get the same random number sequence if you use a different encoding. 639 992 So it is useful to know how the seed was computed. The real question is which encoding gives the most random numbers? :-) Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 935620}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304646274.7226329, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/6cunfw4 - Greg Ewing - <pre>Amaury Forgeot d'Arc wrote [concerning the Doc/data/refcounts.dat file]: Yes, that's the whole point. When using a functon, what you need to know is whether it borrows or steals a reference. But this file *doesn't tell* you that -- rather it assigns either 0 or +1 to a borrowed reference, apparently based on some notion of what the function \"usually\" does with that parameter. There does not seem to be enough information in that file to work out the borrowed/stolen statuses, which makes it seem rather useless. </pre>", "group_id": 8954, "id": 936558}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304647173.9343359, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/6gq7wap - skip< at >pobox.com - <pre> Georg&gt; Let's remove the cruft, and only keep interesting info. This Georg&gt; will also make the file much more manageable. If I was to do this from scratch I'd think hard about annotating the source code. No matter how hard you try, if you keep this information separate from the code and maintain it manually, it's going to get out-of-date. Skip </pre>", "group_id": 8954, "id": 936639}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304668895.2007511, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/6aq7w9x - Mark Shannon - <pre>What about #defining PY_STOLEN in some header? Then any stolen parameter can be prefixed with PY_STOLEN in signature. For return values, similarly #define PY_BORROWED. Cheers, Mark. </pre>", "group_id": 8954, "id": 939455}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304670695.240984, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/5rul8fg - Amaury Forgeot d'Arc - <pre>Le vendredi 6 mai 2011, Mark Shannon &lt;marks&lt; at &gt;dcs.gla.ac.uk&gt; a \u00e9crit\u00a0: Header files are harder to parse, and I don't see how it would apply to macros. What about additional tags in the .rst files? </pre>", "group_id": 8954, "id": 939526}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304678805.6811609, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/3kvnddj - Antoine Pitrou - <pre>On Fri, 06 May 2011 13:28:11 +1200 Greg Ewing &lt;greg.ewing&lt; at &gt;canterbury.ac.nz&gt; wrote: Doesn't \"borrow\" mean the same as \"steal\" in that context? If an API borrows a reference, I expect it to take it from me. Regards Antoine. </pre>", "group_id": 8954, "id": 940411}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304679696.861165, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/6xn2dxe - Mark Shannon - <pre> \"Stealing\" takes the ownership. Borrowing does not. This explains it better: http://docs.python.org/py3k/c-api/intro.html#reference-count-details Cheers, Mark. </pre>", "group_id": 8954, "id": 940484}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304690737.057507, "message": "[devel] - Re: [Python-checkins] cpython: Userlist.copy() wasn'treturning a UserList. - http://tinyurl.com/6grywrd - Jim Jewett - <pre>Do you also want to assert that u is not v, or would that sort of \"copy\" be acceptable by some subclasses? On 5/5/11, raymond.hettinger &lt;python-checkins&lt; at &gt;python.org&gt; wrote: </pre>", "group_id": 8954, "id": 942276}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304691637.0415289, "message": "[devel] - Linus on garbage collection - http://tinyurl.com/66y67q6 - Neal Becker - <pre>http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html </pre>", "group_id": 8954, "id": 942391}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304691639.5599301, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/6gj3rvk - Antoine Pitrou - <pre>On Fri, 06 May 2011 10:04:09 -0400 Neal Becker &lt;ndbecker2&lt; at &gt;gmail.com&gt; wrote: Since we're sharing links, here's Matt Mackall's take: http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html cheers Antoine. </pre>", "group_id": 8954, "id": 942392}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304693439.7100201, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/44ydy7s - Mark Shannon - <pre> Neal Becker wrote: Being famous does not necessarily make you right. OS kernels are pretty atypical software, even if Linus is right about Linux, it doesn't apply to Python. I have empirical evidence, not opinion, that PyPy and my own HotPy are a *lot* faster (x5 or better) on Unladen Swallow's gcbench benchmark (which stresses the memory management subsystem). (Note that gcbench does not introduce any cycles, so its being easy on CPython) In fact, for gcbench CPython spends over twice as long in the cycle-collector as HotPy takes in total! I don't have such detailed results for PyPy. For other benchmarks, the HotPy GC times are often smaller than the inter-run variations in runtime, for example: HotPy GC stats for pystones (on a slow machine with a small cache): Total memory allocated: 20 Mbytes. 20 minor collections, 0 major collections Max heap size 2.4 Mbytes. Total time spent in GC: 3.5 milliseconds. ( &lt;1% of execution time) My GC is quick, but its not the fastest. Evidence trumps opinion</pre>", "group_id": 8954, "id": 942574}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304699020.637584, "message": "[devel] - Summary of Python tracker Issues - http://tinyurl.com/67r53nj - Python tracker - <pre> ACTIVITY SUMMARY (2011-04-29 - 2011-05-06) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2783 (+23) closed 21017 (+41) total 23800 (+64) Open issues with patches: 1201 Issues opened (47) ================== #11955: 3.3 : test_argparse.py fails 'make test' http://bugs.python.org/issue11955 opened by Jason.Vas.Dias #11956: 3.3 : test_import.py causes 'make test' to fail http://bugs.python.org/issue11956 opened by Jason.Vas.Dias #11957: re.sub confusion between count and flags args http://bugs.python.org/issue11957 opened by mindauga #11959: smtpd cannot be used without affecting global state http://bugs.python.org/issue11959 opened by vinay.sajip #11962: Buildbot reliability http://bugs.python.org/issue11962 opened by skrah #11963: Use real assert* for test_trigger_memory_error (test_parser) http://bugs.python.org/issue11963 opened by eric.araujo #119</pre>", "group_id": 8954, "id": 943758}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304697217.4870319, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/6jogh9v - Antoine Pitrou - <pre>On Fri, 06 May 2011 15:46:08 +0100 Mark Shannon &lt;marks&lt; at &gt;dcs.gla.ac.uk&gt; wrote: The thing is, it would be easy to change our collection heuristics so that the cycle collector gets called less often (actually, you can already do so using gc.set_threshold, IIRC). Something which is much more delicate for a \"full\" GC, where it would grow memory consumption a lot. Regards Antoine. </pre>", "group_id": 8954, "id": 943385}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304700817.7952311, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/6kxxfpo - Gregory P. Smith - <pre> Python being \"broken\" in this regard is pretty much exactly why __enter__, __exit__ and with as context managers were added to the language. That gives the ability to have the equivalent of well defined nested scopes that destroy something (exit) deterministically much as it is easy to do in C++ with some {}s and a ~destructor(). It is not broken, just different. -gps </pre>", "group_id": 8954, "id": 944044}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304701718.294915, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/3nu5fkq - Stefan Behnel - <pre>Mark Shannon, 06.05.2011 18:33: May I quote you on that one the next time my software crashes? It may not make a difference for the runtime, but the difference for user software may be \"dead\" or \"alive\". Stefan </pre>", "group_id": 8954, "id": 944116}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304699023.1333599, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/5rc9m3c - skip< at >pobox.com - <pre> Antoine&gt; Since we're sharing links, here's Matt Mackall's take: Antoine&gt; http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html 1: You can't have meaningful destructors, because when destruction happens is undefined. And going-out-of-scope destructors are extremely useful. Python is already a rather broken in this regard, so feel free to ignore this point. Given the presence of cyclic data I don't see how reference counting or garbage collection win. Ignoring the fact that in a pure reference counted system you won't even consider cycles for reclmation, would both RC and GC have to punt because they can't tell which object's destructor to call first? Skip </pre>", "group_id": 8954, "id": 943759}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304700821.156498, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/3qnss2c - Mark Shannon - <pre> It doesn't matter which is called first. In fact, the VM could call all the destructors at the same time if the machine has enough cores and there's no GIL. All objects are kept alive by the GC until after the destructors are called. Those that are still dead will have their memory reclaimed. </pre>", "group_id": 8954, "id": 944046}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304699918.0317919, "message": "[devel] - Re: Linus on garbage collection - http://permalink.gmane.org/gmane.comp.python.devel/124382 - Michael Foord - <pre> pypy and .NET choose to arbitrarily break cycles rather than leave objects unfinalised and memory unreclaimed. Not sure what Java does. All the best, Michael Foord </pre>", "group_id": 8954, "id": 943898}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304702624.8497801, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/438zpgg - Glyph Lefkowitz - <pre> I think that's a mischaracterization of their respective collectors; \"arbitrarily break cycles\" implies that user code would see broken or incomplete objects, at least during finalization, which I'm fairly sure is not true on either .NET or PyPy. Java definitely has a collector that can handles cycles too. (None of these are reference counting.) -glyph</pre>", "group_id": 8954, "id": 944219}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304702618.9349301, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/3u85uc2 - Michael Foord - <pre> How does that help with cycles? Sure it makes cleaning up some resources easier, but not at all this case. Explicit destruction is of course always an alternative to the runtime doing it for you, but it doesn't help with (for example) reclaiming memory. For long running processes memory leaks due to unreclaimable cycles can be a problem with CPython. +1 QOTW ;-) Michael </pre>", "group_id": 8954, "id": 944216}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304702621.891331, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/3sowt6x - Michael Foord - <pre> Arbitrarily breaking cycles *could* cause a problem if a destructor attempts to access an already collected object. Not breaking cycles *definitely* leaks memory and definitely doesn't call finalizers. Michael </pre>", "group_id": 8954, "id": 944217}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304703518.781584, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/5uvzdeb - Stephen J. Turnbull - <pre> &gt; &gt; &gt; Neal Becker wrote: &gt; &gt; http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html &gt; &gt; &gt; Being famous does not necessarily make you right. No, but being a genius sure helps you beat the odds. &gt; OS kernels are pretty atypical software, &gt; even if Linus is right about Linux, it doesn't apply to Python. Well, actually he was writing about GCC.... &gt; I have empirical evidence, not opinion, that PyPy and my own HotPy &gt; are a *lot* faster (x5 or better) on Unladen Swallow's gcbench benchmark &gt; (which stresses the memory management subsystem). You're missing Linus's point, I think. Linus did *not* claim that it's impossible to write a fast *GC*. He claimed that it's hard to write a fast *program* that uses GC for memory management. A benchmark that stresses *only* the memory management system is unlikely to impress him. </pre>", "group_id": 8954, "id": 944328}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304703521.2070129, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/6cl3ygv - Michael Foord - <pre> http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-1.html \"Therefore we decided to break such a cycle at an arbitrary place, which doesn't sound too insane.\" All the best, Michael Foord </pre>", "group_id": 8954, "id": 944329}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304706220.1459911, "message": "[devel] - Problems with regrtest and with logging - http://tinyurl.com/6zpw9q6 - \u00c9ric Araujo - <pre> Hi, Sorry for quick email-battery dying. regrtest helpfully reports when a test leaves the environment unclean (sys.path, os.environ, logging._handlerList), but I think the implementation is buggy: it compares object identity and then value. Why is comparing identity useful? I\u2019d just use ==. It makes writing cleanup code easier (just use addCleanup(setattr, obj, 'attr', copy(obj.attr))). Second: in packaging, we have two modules that create a logging handler. I\u2019m not sure how if we should change the code or fix the tests to restore the _handlerList, or how. Thanks for advice. Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 944707}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304705318.354435, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/67pbafg - Mark Shannon - <pre> A finalized object will still be a valid object. Python code cannot make an object unsafe. Obviously C code can make it unsafe, but that's true of C code anywhere. For example, a file object will close itself during finalization, but its still a valid object, just a closed file rather than an open one. </pre>", "group_id": 8954, "id": 944593}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304705321.833909, "message": "[devel] - Re: cpython (3.2): Avoid codec spelling issues by just using the utf-8 default. - http://tinyurl.com/6ywmphj - \u00c9ric Araujo - <pre> Le 06/05/2011 00:52, Terry Reedy a \u00e9crit : Agreed. I thought about something similar after Victor\u2019s commit that changed open(mode='rU') to use just 'r': Why not remove the mode argument entirely when it is the default value? Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 944594}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304706222.4812689, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/5rgf9b7 - skip< at >pobox.com - <pre> Michael&gt; \"Therefore we decided to break such a cycle at an arbitrary Michael&gt; place, which doesn't sound too insane.\" I trust \"arbitrary\" != \"random\"? Skip </pre>", "group_id": 8954, "id": 944708}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304706225.496784, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/3v42gcm - Stefan Behnel - <pre>Michael Foord, 06.05.2011 19:06: This is more real than the \"could\" suggests. Remember that CPython includes a lot of C code, and is commonly used to interface with C libraries. While you will simply get an exception when cycles are broken in Python code, cycles that involve C code can suffer quite badly from this problem. There was a bug in the lxml.etree XML library a while ago that could let it crash hard when its Element objects participated in a reference cycle. It's based on libxml2, so there's an underlying C tree that potentially involves disconnected subtrees, and a Python space representation using Element proxies, with at least one Element for each disconnected subtree. Basically, Elements reference their Document (not the other way round) even if they are disconnected from the main C document tree. The Document needs to do some final cleanup in the end, whereas the Elements require the Document to be alive to do their own subtree cleanup, if only to know what exactly to clean up, as</pre>", "group_id": 8954, "id": 944709}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304707118.876127, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/3vfp6es - Georg Brandl - <pre> Possible, of course, and even easier to implement. Georg </pre>", "group_id": 8954, "id": 944782}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304707121.3428011, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/6anjf6b - Georg Brandl - <pre> Basically, \"borrow\" is applied to return values (or, more generally, \"out\" parameters), and means that *you* borrowed the reference. \"steal\", OTOH, is applied to (and the exception for) \"in\" parameters. Georg </pre>", "group_id": 8954, "id": 944783}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304708018.1974599, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/68pj3vu - Mark Shannon - <pre> With a tracing collector it is *impossible* to access dead memory, ever. If it can be reached the GC will *not* collect it. This should be a fundamental invariant of *all* GCs. If an object is finalizable or reachable from any finalizable objects then it is reachable and its memory should not be reclaimed until it is truly unreachable. Finalization and reclamation are separate phases. With a tracing GC: While the Elements are finalized, the Document is still alive. While the Document is finalized, the Elements are still alive. Then, and only then, is the whole lot reclaimed. Mark. </pre>", "group_id": 8954, "id": 944873}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304708918.6991129, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/67d3nt9 - Vinay Sajip - <pre> If you are saying this happens in your unit tests for packaging, then you can either restore the _handlerList using the approach in test_logging, or else you can just close the handlers when you've done with them. If you point me at the relevant code (is it on bitbucket or on hg.python.org?) I can perhaps take a look and advise. Regards, Vinay Sajip _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 945021}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304709818.1308081, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/6ecg7nc - Stefan Behnel - <pre>Mark Shannon, 06.05.2011 20:45: Sure. However, I'm talking about Python types and C memory here. Even if the Python objects are still alive, they may already have freed the underlying C memory during their *finalisation*. When an Element goes out of scope, it must free its C subtree if it is disconnected, even if the Document stays alive. So that's what Elements do in their destructor, and they need the Document's C memory for that, which the Document frees during its own finalisation. I do agree that CPython's destructor call algorithms could have been smarter in this case. After all, the described crash case indicates that the Document destructor was called before all of the Element destructors had been called, although all Elements reference their Document, but the Document does not refer to any of the Elements, so it's basically a dead end. That would have provided a detectable hint to call the Document destructor last, after the ones of all objects that reference it. Apparently, this hint</pre>", "group_id": 8954, "id": 945170}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304713479.009197, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/68p5572 - Dan Stromberg - <pre> Of course, a generational GC improves locality of reference. </pre>", "group_id": 8954, "id": 945800}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304715278.9219229, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/62d28o3 - R. David Murray - <pre> Well, the implementation is intentional. Nick (I think) added the identity check, and he had a reason at the time. I don't remember what it was, though. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 946252}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304725299.9975719, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/42lla6q - Greg Ewing - <pre> There, Linus says It's interesting to note that, even though you *can* get reference count information in CPython, it's not all that useful for doing things like that, because it's hard to be sure how many incidental references have been created on the way to the code concerned. So tricks like this at the Python level aren't really feasible in any robust way. </pre>", "group_id": 8954, "id": 947688}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304726318.8545671, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/665owhx - Greg Ewing - <pre>Antoine&gt; http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html It's only broken if you regard RAII as the One True Way to implement scoped resource management. Python has other approaches to that, such as the with-statement. Also, you *can* have destructors that work for objects in cycles, as long as you don't insist on the destructor having access to the object that's being destroyed. Weakref callbacks provide a way of implementing this in CPython. </pre>", "group_id": 8954, "id": 947792}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304727220.2279949, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/6z5fjah - Greg Ewing - <pre> It might be valid in the sense that you won't get a segfault. But the point is that the destructors of some objects may be relying on other objects still being in a certain state, e.g. a file still being open. One would have to adopt a highly defensive coding style in destructors, verging on paranoia, to be sure that one's destructor code was completely immune to this kind of problem. All of this worry goes away if the destructor is not a method of the object being destroyed, but something external that runs *after* the object has disappeared. </pre>", "group_id": 8954, "id": 947893}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304728119.1824591, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/69kxouy - Nick Coghlan - <pre>Even if he's right (and he probably is) manual memory management is still a premature optimization for most applications. C and C++ data structures are a PITA because you have to be so careful to avoid leaks and double-frees, so people end up using dumb algorithms. Worrying about losing cycles waiting for main memory is stupid if your high level algorithm is O(N^2). Cheers, Nick. -- Nick Coghlan, Brisbane, Australia On 07/05/2011, at 12:04 AM, Neal Becker &lt;ndbecker2&lt; at &gt;gmail.com&gt; wrote: </pre>", "group_id": 8954, "id": 947952}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304728121.4757309, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/6jmfome - Greg Ewing - <pre> One problem is that, at the C level in CPython, you can't separate finalisation and reclamation. When an object's refcount drops to zero, its tp_dealloc method is called, which both finalises the object and reclaims its memory. Another problem is that just because an object's memory hasn't been reclaimed yet doesn't mean it's safe to do anything with that object. This is doubly true at the C level, where the consequences can include segfaults. Seems to me the basic issue here is that the C code wasn't designed with tracing GC in mind. There is a reference cycle, but it is assumed that the user is in manual control of deallocation and will deallocate the Nodes before the Document. </pre>", "group_id": 8954, "id": 947953}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304729019.785917, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/6zra4ur - Greg Ewing - <pre> In that case, why was the GC system regarding this as a cycle at all? There must be more going on. </pre>", "group_id": 8954, "id": 947995}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304732621.5254581, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/3vpbb72 - Glyph Lefkowitz - <pre>Apologies in advance for contributing to an obviously and increasingly off-topic thread, but this kind of FUD about GC is a pet peeve of mine. On May 6, 2011, at 10:04 AM, Neal Becker wrote: Counterpoint: &lt;http://lwn.net/Articles/268783/&gt;. Sorry Linus, sometimes correctness matters more than performance. But, even the performance argument is kind of bogus. See, for example, this paper on real-time garbage collection: &lt;http://domino.research.ibm.com/comm/research_people.nsf/pages/dgrove.ecoop07.html&gt;. That's just one example of an easy-to-find solution to a problem that Linus holds up as unsolved or unsolvable. There are solutions to pretty much all of the problems that Linus brings up. One of these solutions is even famously implemented by CPython! The CPython \"string +=\" idiom optimization fixes at least one case of the \"you tend to always copy the node\" antipattern Linus describes, and lots of languages (especially Scheme and derivatives, IIRC) have very nice optimizations around this area. One </pre>", "group_id": 8954, "id": 948252}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304751521.735321, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/3sp9tfd - Georg Brandl - <pre> But they are at the C level, see for example the optimization for string += something if \"string\"'s reference count is exactly one. Georg </pre>", "group_id": 8954, "id": 949263}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304753321.9312739, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/6fo9eyl - Stefan Behnel - <pre>Greg Ewing, 07.05.2011 02:26: It's a dead-end that is referenced by a cycle, that's all. Stefan </pre>", "group_id": 8954, "id": 949380}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304757822.275183, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/43at2td - Antoine Pitrou - <pre>On Fri, 6 May 2011 21:39:10 -0400 Glyph Lefkowitz &lt;glyph&lt; at &gt;twistedmatrix.com&gt; wrote: \"Staggeringly massive\"? The average 4MB L3 cache is very small compared to the heap of non-trivial Python (or Java) workloads. And Linus is right: modern hardware is not optimized for random pointer-chasing, simply because optimizing for it is very hard. Regards Antoine. </pre>", "group_id": 8954, "id": 949554}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304756922.8997059, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/6k9sg74 - Greg Ewing - <pre> But shouldn't it be breaking the cycle by clearing one of the objects that's actually part of the cycle, rather than part of the dead-end? I can't see how the Document could get picked for clearing unless it was actually in the cycle. Either that or I'm imagining the cyclic GC algorithm to be smarter than it actually is. </pre>", "group_id": 8954, "id": 949520}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304769522.7755721, "message": "[devel] - Python Insider translations - http://tinyurl.com/3r9v7uf - Doug Hellmann - <pre>I wanted to take a few minutes to let you all know that the recent call for help with translating Python Insider was met with a wave of enthusiastic contributors. We now have teams prepared to translate all posts to Simplified and Traditional Chinese, German, Japanese, Portuguese, Romanian, and Spanish. Setting up each blog takes a bit of effort, so we are launching them in batches as they are ready. When all of the existing teams are launched, I will be looking for translators for additional languages. The next time you have Python related information that you would like to share with the community, I hope you will consider working with us and publishing it through Python Insider, so it can reach the widest possible audience. Either Brian Curtin or I can help you get set up, so contact one of us directly when you are ready. Thanks, Doug </pre>", "group_id": 8954, "id": 950456}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304786139.947314, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/3cdeqmw - \u00c9ric Araujo - <pre> Hi, Le 06/05/2011 22:07, R. David Murray a \u00e9crit : Drat. Nick, if it was indeed you, can you enlighten me? /off to replace all those addCleanup/setattr combos :( Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 951517}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304786134.988302, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/3uo7mdn - \u00c9ric Araujo - <pre> Le 06/05/2011 20:57, Vinay Sajip a \u00e9crit : We create one handler in a command-line script, not in the lib, which is the Right Way AFAIU, but there is also one module that creates one handler (in order to set its level depending on a verbose attribute) deep in the library code, not in the command-line script, which I think is bad. Our tests that instantiate that object (dist.Distribution) end up modifying logging._handlerList, but I feel that the code is wrong, not the tests. The code is on https://bitbucket.org/tarek/cpython, in Lib/packaging. Thanks! _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 951514}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304794234.367806, "message": "[devel] - Re: Linus on garbage collection - http://tinyurl.com/3o6p9nw - Xavier Morel - <pre>Not sure it had all those bells and whistles, and there were other issues, but I believe Lisp Machines implemented garbage collection at the hardware (or at least microcode) level, and the OS itself provided a pretty direct interface to it (it was part of the core services). </pre>", "group_id": 8954, "id": 952197}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304806049.617264, "message": "[devel] - Re: cpython (2.7): Some tests were incorrectly marked as C specific. - http://tinyurl.com/42quab7 - Antoine Pitrou - <pre>On Sat, 07 May 2011 23:16:51 +0200 raymond.hettinger &lt;python-checkins&lt; at &gt;python.org&gt; wrote: This class contains no tests. Regards Antoine. </pre>", "group_id": 8954, "id": 953278}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304864738.370364, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/6fl3kur - Vinay Sajip - <pre> The cases you refer to seem to be _set_logger in packaging/run.py (which appears not to be used at all - there appear to be no other references to it in the code), Dispatcher.__init__ in packaging/run.py and Distribution.parse_command_line in packaging/dist.py. I can't see why the first case is there. In the second and third cases, can you be sure that only one of these code paths will be executed, at most once? If not, multiple StreamHandler instances would be added to the logger, resulting in duplicated messages. If the code paths will be executed at most once, then the code seems to be acceptable. You may wish to add a guard using \"if not logger.hasHandlers():\" so that even if the code is executed multiple times, a handler isn't added multiple times. In the case of the test support code, I'm not really sure that LoggingCatcher is needed. There is already a TestHandler class in test.support which captures records in a buffer, and allows flexible matching for assertions, as described in http://plumber</pre>", "group_id": 8954, "id": 957769}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304937884.023807, "message": "[devel] - Commit changelog: issue number and merges - http://tinyurl.com/6j3hof6 - Victor Stinner - <pre>Hi, Commit changelogs are important to understand why the code was changed. I regulary use hg blame to search which commit introduced a particular line of code, and I am always happy if I can find an issue number because it usually contains the whole story. And since the migration to Mercurial, we have also a great tool adding a comment to an issue if the changelog contains an issue number (e.g. changelog starting with \"Issue #118888: ...\"). So if someone watchs an issue (is in the nosy list), (s)he will be noticed that a related commit was pushed. It is not exactly something new: we already do that with Subversion except that today it is more automatic. I noticed that some recent commits don't contain the issue number: please try to always prefix your changelog with the issue number. It is not \"mandatory\", but it helps me when I dig the Python history. -- For merge commits: many developers just write \"merge\" or \"merge 3.1\". I have to go to the parent commit (and something to the grandparent, 3.1-&gt;3.2-&gt;</pre>", "group_id": 8954, "id": 970394}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304945084.378463, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/3rnomnx - R. David Murray - <pre> +1. What I do is, in the edit window for the commit message, I pull in .hg/last-message.txt, and just type 'Merge' in front of my previous first line. I don't add the merge-from number, because I figure if you know which branch you are looking at you know which branch the merge came from, given that there is a strict progression. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 970974}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304945982.6740229, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #11277: Remove useless test from test_zlib. - http://tinyurl.com/62dgdlj - Jim Jewett - <pre>Can you clarify (preferably in the commit message as well) exactly *why* these largefile tests are useless? For example, is there another test that covers this already? -jJ On 5/7/11, nadeem.vawda &lt;python-checkins&lt; at &gt;python.org&gt; wrote: </pre>", "group_id": 8954, "id": 971110}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304945985.7700989, "message": "[devel] - more timely detection of unbound locals - http://tinyurl.com/6dqyrqn - Eli Bendersky - <pre>Hi all, It's a known Python gotcha (*) that the following code: x = 5 def foo(): print(x) x = 1 print(x) foo() Will throw: UnboundLocalError: local variable 'x' referenced before assignment On the usage of 'x' in the *first* print. Recently, while reading the zillionth question on StackOverflow on some variation of this case, I started thinking whether this behavior is desired or just an implementation artifact. IIUC, the reason it behaves this way is that the symbol table logic goes over the code before the code generation runs, sees the assignment 'x = 1` and marks 'x' as local in foo. Then, the code generator generates LOAD_FAST for all loads of 'x' in 'foo', even though 'x' is actually bound locally after the first print. When the bytecode is run, since it's LOAD_FAST and no store was made into the local 'x', ceval.c then throws the exception. On first sight, it's possible to signal that 'x' truly becomes local only after it's bound in the scope (and before that LOAD_NAME can b</pre>", "group_id": 8954, "id": 971113}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304946884.5804069, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/42rszbx - Jim Jewett - <pre>Are you asserting that all foreign modules (or at least all handled by this) are in C, as opposed to C++ or even Java or Fortran? (And the C won't change?) Is this ASCII restriction (as opposed to even UTF8) really needed? Or are you just saying that we need to create an ASCII name for passing to C? -jJ On 5/7/11, victor.stinner &lt;python-checkins&lt; at &gt;python.org&gt; wrote: </pre>", "group_id": 8954, "id": 971335}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304946887.125922, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/6gtqutz - Senthil Kumaran - <pre> Thanks for this tip. I shall start following this one too. </pre>", "group_id": 8954, "id": 971337}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304948687.2283909, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/3bmzc2m - Eric Snow - <pre>zillionth question on StackOverflow on some variation of this case, I started thinking whether this behavior is desired or just an implementation artifact. over the code before the code generation runs, sees the assignment 'x = 1` and marks 'x' as local in foo. Then, the code generator generates LOAD_FAST for all loads of 'x' in 'foo', even though 'x' is actually bound locally after the first print. When the bytecode is run, since it's LOAD_FAST and no store was made into the local 'x', ceval.c then throws the exception. after it's bound in the scope (and before that LOAD_NAME can be generated for it instead of LOAD_FAST). To do this, some modifications to the symbol table creation and usage are required, because we can no longer say \"x is local in this block\", but rather should attach scope information to each instance of \"x\". This has some overhead, but it's only at the compilation stage so it shouldn't have a real effect on the runtime of Python code. This is also less convenient and \"clean\" than the cur</pre>", "group_id": 8954, "id": 971745}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304947784.5907221, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/3pc8wph - Isaac Morland - <pre> x = 5 def foo (): print (x) if bar (): x = 1 print (x) Isaac MorlandCSCF Web Guru DC 2554C, x36650WWW Software Specialist </pre>", "group_id": 8954, "id": 971521}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304948683.6915319, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/3gxq7jj - Stefan Behnel - <pre>Eli Bendersky, 09.05.2011 14:56: Well, basically any compiler these days can detect that a variable is being used before assignment, or at least that this is possibly the case, depending on prior branching. ISTM that your suggestion is to let x refer to the outer x up to the assignment and to the inner x from that point on. IMHO, that's much worse than the current behaviour and potentially impractical due to conditional assignments. However, it's also a semantic change to reject code with unbound locals at compile time, as the specific code in question may actually be unreachable at runtime. This makes me think that it would be best to discuss this on the python-ideas list first. If nothing else, I'd like to see a discussion on this behaviour being an implementation detail of CPython or a feature of the Python language. Stefan </pre>", "group_id": 8954, "id": 971744}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304950487.029979, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/6a7osuh - Benjamin Peterson - <pre>2011/5/9 Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt;: I thought the whole point of merging was that you brought a changeset from one branch to another. This why I just write \"merge\" because otherwise you're technically duplicating information that is pulled onto the branch by merging. It seems like something that should be solved by tools like a display visual graph indicating what is merged. (like Bazaar) </pre>", "group_id": 8954, "id": 972116}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304950483.740989, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Issue #11277: Remove useless test from test_zlib. - http://tinyurl.com/6lebbl6 - Nadeem Vawda - <pre> Ah, sorry about that. It was discussed on the tracker issue, but I guess I can't expect people to read through 90+ messages to figure it out :P The short version is that it was supposed to test 4GB+ inputs, but in 2.7, the functions being tested don't accept inputs that large. The details: The test was originally intended to catch the case where crc32() or adler32() would get a buffer of &gt;=4GB, and then silently truncate the buffer size and produce an incorrect result (issue10276). It had been written for 3.x, and then backported to 2.7. However, in 2.7, zlibmodule.c doesn't define PY_SSIZE_T_CLEAN, so passing in a buffer of &gt;=2GB raises an OverflowError (see issue8651). This means that it is impossible to trigger the bug in question on 2.7, making the test pointless. Of course, the code that was deleted tests with an input sized 2GB-1 or 1GB, rather than 4GB (the size used in 3.x). When the test was backported, the size of the input was reduced, to avoid triggering an OverflowException. At the time, no</pre>", "group_id": 8954, "id": 972115}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304951385.517101, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/6eyyogs - Victor Stinner - <pre>Le lundi 09 mai 2011 \u00e0 09:00 -0400, Jim Jewett a \u00e9crit : C and C++ identifiers are restricted to ASCII. I don't know for Fortran or Java. Is it possible to write a CPython extension module in Java or Fortran? (My change doesn't concern Jython: it's an implementation detail of dynamic modules in CPython.) I prefer to explicitly limit module names of dynamic modules to ASCII. If we decide to extend the support to something else than ASCII, we will need a working module to test it, and maybe also a test. You pass a Unicode module name to import (import h\u00e9 or __import__('h\u00e9')), and Python encodes the name to ASCII if it is a dynamic module. It is still possible to use non-ASCII module names, but only for modules written in Python. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 972308}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304951388.4221029, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/6c558uo - Victor Stinner - <pre>Le lundi 09 mai 2011 \u00e0 09:08 -0500, Benjamin Peterson a \u00e9crit : Yeah, we could fix buildbot, hg.python.org website, improve hg log, and all other tools using Mercurial. But until that, I would prefer to duplicate the information. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 972309}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304952283.6649179, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/64kcnn2 - Nick Coghlan - <pre> Input parameter, borrowed or new reference: caller retains ownership and must still decref item Input parameter, stolen reference: caller transfers ownership and must NOT decref item (or must incref before call to guarantee lifecycle if planning to continue using the object after the call) Output parameter or return value, borrowed reference: caller does NOT receive ownership and does not need to decref item, but needs to be careful of lifecycle (and promote to a full reference with incref if the borrowed reference may outlive the original) Output parameter or return value, stolen or new reference: caller receives ownership and must decref item One interesting aspect is that from the caller's point of view, a *new* reference to the relevant behaves like a borrowed reference for input parameters, but like a stolen reference for output parameters and return values. It is typically the converse cases (stolen reference to an input parameter, borrowed reference to an output parameter or return value) that requ</pre>", "group_id": 8954, "id": 972447}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304953184.5673881, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/3nmk6c4 - Steven D'Aprano - <pre> I think part of the problem is that UnboundLocalError is a jargon name, while it's predecessor NameError (used up to Python 1.5) is far more intuitively obvious. [...] I think you are making an unwarranted assumption about what is \"more expected\". I presume you are thinking that the expected behaviour is that foo() should: print global x (5) assign 1 to local x print local x (1) If we implemented this change, there would be no more questions about UnboundLocalError, but instead there would be lots of questions like \"why is it that globals revert to their old value after I change them in a function?\". </pre>", "group_id": 8954, "id": 972695}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304954983.1112731, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/6b2bycf - Nick Coghlan - <pre> However, since flow control constructs in Python don't create new scopes (unlike C/C++), you run into a fundamental problem with cases like the one Isaac posted, or even nastier ones like the following: def f(): if bar(): fill = 1 else: fiil = 2 print(fill) # Q: What does this do when bool(bar()) is False? Since we want to make the decision categorically at compile-time, the simplest, least-confusing option is to say \"assignment makes a variable name local, referencing it before the first assignment is now an error\". I don't know of anyone that particularly *likes* UnboundLocalError, but it's better than letting errors like the one above pass silently. (It obviously doesn't trap *all* typo-related errors, but it at least lets you reason sanely about name bindings) On the reasoning-sanely front, closures likely present a more compelling argument: def f(): def g(): print(x) # We want this to refer to the closure in f(), thanks x = 1 return g UnboundLocalError is really about alig</pre>", "group_id": 8954, "id": 973138}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304954085.9552751, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/5ttpv3w - Eli Bendersky - <pre> True, but this is less confusing and follows the rules in a more straightforward way. x = 1 without a 'global x' assigns a local x, this make sense and is similar to what happens in C where an inner declaration temporarily shadows a global one. Eli </pre>", "group_id": 8954, "id": 972944}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304954091.3819611, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/6fh9phy - Eli Bendersky - <pre> I wish you'd annotate this code sample, what do you intend it to demonstrate? It probably shows the original complaint even more strongly. As for being a problem with the suggested solution, I suppose you're right, although it doesn't make it much different. Still, before a *possible* assignment to 'x', it should be loaded as LOAD_NAME since it was surely not bound as local, yet. Eli </pre>", "group_id": 8954, "id": 972946}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304954083.7845809, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/6e3eate - Nick Coghlan - <pre> Because changing the identity of any of those global state attributes that regrtest monitors is itself suggestive of a bug. When it comes to containers, identity matters at least as much as value does (and sometimes more so - e.g. sys.modules). Replacing those global containers with new ones isn't guaranteed to work, as they may be cached in various places rather than always retrieved fresh from the relevant module namespace. Modifying them in place, on the other hand, does the right thing even in the presence of cached references. A comment to that effect may be a useful addition to regrtest, as I expect others may have similar questions about those identity checks in the future. (It may even be a useful addition to the documentation, but I have no idea where it could be sensibly included). Also, don't be surprised if wholesale cleanup like that isn't completely reliable - it's far, far better if the test case understands the changes it is making (even indirectly) and explicitly reverses them. Save-and-r</pre>", "group_id": 8954, "id": 972942}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304954089.1756279, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/6kcbxoh - Nick Coghlan - <pre> The extension module that interfaces them to CPython will be written in C, or something that can export a C-compatible library interface (after reading in the Python C API headers). Cheers, Nick. </pre>", "group_id": 8954, "id": 972945}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304954985.5308969, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/5vaf7ly - Nick Coghlan - <pre> Yeah, I've decided I'm happier with the closure based arguments than the conditional statement related ones. \"Assignments create local variables\" is a relatively simple rule to reason about, and is equally valid for the current scope and for any nested scopes. The symtable analysis for nested scopes is ordering independent (and can't be changed for backwards compatibility reasons if nothing else), and UnboundLocalError is a natural outgrowth of applying those semantics to the current scope as well. Cheers, Nick. </pre>", "group_id": 8954, "id": 973140}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304956851.56371, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/674dzfr - Isaac Morland - <pre> Extrapolating from your suggestion, you're saying before a *possible* assignment it will be treated as global, and after a *possible* assignment it will be treated as local? But surely: print (x) if False: x = 1 print (x) should always print the same thing twice (in the absence of actions taken by other threads)! Replace \"False\" by something that is usually (but not always) True, and \"print (x)\" by something that actually does something, and you had best put on your helmet because it's going to be a fun ride. But I won't be on it. The idea that the same name within the same scope always refers to the same value is an idea from functional programming and not part of Python; but surely the same name within the same scope should at least always refer to the same variable! If something is to be done here, it occurs to me that the same parser that decides that the initial reference to x should use the local x could conceivably issue an error right away - \"local variable can never be assigned</pre>", "group_id": 8954, "id": 973572}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304956783.6550789, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/6cg2nt2 - R. David Murray - <pre> No it isn't. The commit message isn't pulled into the new branch. You'd need some extension to hg log that would show the original commit message for the first changeset in the merge line in order to \"fix\" this. I doubt that is going to happen. Note that saying just 'merge' makes perfect sense when you are pulling in a whole group of changesets in order to synchronize two branches. But if you are applying a single changeset to multiple branches, as we often do in our workflow, then I think duplicating the commit message is (1) easy to do and (2) very helpful when looking at hg log output. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 973556}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304956857.7408919, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/3e6hvg3 - \u00c9ric Araujo - <pre> Hi, Le 09/05/2011 16:08, Benjamin Peterson a \u00e9crit : I follow conventions I\u2019ve seen elsewhere (maybe Mercurial itself): I use \u201cBranch merge\u201d when I merge anonymous branches on the same named branch, and \u201cMerge x.y\u201d for forward-porting across named branches. I also tend to do more than one commit before merging. It would not be very easy with my current toolchain to get the commit message(s) to insert into the new message, and I think it\u2019s not necessary. +1. No interest in manually duplicating available information. Le 09/05/2011 17:44, R. David Murray a \u00e9crit : Sorry, your terminology does not make sense. If you mean that the commit message is not reused in the new commit after the merge, it\u2019s true. However, the commit message with the relevant information is available as part of the changesets that have been pulled and merged. Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/</pre>", "group_id": 8954, "id": 973576}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304960386.971463, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/6l2ces7 - Steven D'Aprano - <pre> I disagree that it is less confusing. Instead of a nice, straightforward error that you can google, the function will silently do the wrong thing, giving no clue that weirdness is happening. def spam(): if x &lt; 0: # refers to global x x = 1 # now local if x &gt; 0: # could be either global or local x = x - 1 # local on the LHS of the equal # sometimes global on the RHS else: x += 1 # local x, but what value does it have? Just thinking about debugging the mess that this could make gives me a headache. </pre>", "group_id": 8954, "id": 974206}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304960391.677597, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/3fq4xy9 - \u00c9ric Araujo - <pre> Hi, That makes sense, thanks for the explanation! Somewhere in unittest doc, say in the section about tearDown. Or maybe it\u2019s time for a Python testing best practices howto? Yep, I was probably bringing out the big guns too early. self.addCleanup(sys.path.remove, path) is better and even shorter than my previous code! Cheers _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 974208}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304959483.141995, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/6gu32o9 - \u00c9ric Araujo - <pre> Hi, Thanks for the help. I didn\u2019t know about handler.close. (By which I mean that I used logging without re-reading its documentation, which is a testimony to its usability :) Yep, probably dead code. I think that an handler should be defined only once, in the \u201cif __name__ == '__main__'\u201d block. Am I right? Just like you don\u2019t call sys.exit from library code (hello optparse!), you don\u2019t set logging handlers in library code, only in the outmost layer of the script. This is the new-fangled command line parser, which can run global (Python-wide) commands (search, uninstall, etc.) as well as traditional project-wide commands (build, check, sdist, etc.) This is the older command line parser, that can handle only project-wide commands. I\u2019m not sure the work is finished to integrate both parsers; my smoke test used to be --help-commands, which can be hard to run these days. The problem is that Dispatcher or Distribution get the quiet or verbose options from the co</pre>", "group_id": 8954, "id": 974037}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304961346.2505231, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/3l6rdjy - Terry Reedy - <pre> </pre>", "group_id": 8954, "id": 974359}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304962247.0043371, "message": "[devel] - Commit messages: please avoid temporal ambiguity - http://tinyurl.com/6y5whzb - Terry Reedy - <pre>A commit (push) partition time and behavior into before and after (with a short change period in between during which behavior is undefined). Some commit messages have the form 'x does y'. Does 'does' mean before or after? Sometimes that is clear. 'x crashes' means before. 'x return correct value' means after. But some messages of this type are unclear to me as written. Consider 'x raises exception'? The temporal reference is obvious to the committer but not necessary to everyone else. It could mean 'x used to segfault and now raises a catchable exception'. There was a fix like this (with a clear message) just today. It could also mean 'x used to raise but now return an answer. There have been many fixes like this. Two minimal fixes are 'x raised exception' or 'make x raise exception'. </pre>", "group_id": 8954, "id": 974503}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304964046.8551929, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/3uwbg7n - Vinay Sajip - <pre> That's right, though it's OK to provide a documented convenience API for adding handlers. You don't necessarily need to set the level on the handler - why can you not just set it on the logger? The effect would often be the same: the logger's level is checked first, and then the handler's level. Generally you set levels on handlers when you want specific behaviour, such as all ERROR and above to a particular file, all CRITICAL to an email handler etc. For command-line scripts outputting to the console and nowhere else, usually you could just add a StreamHandler (with no level set on it), and set the level on the logger. Where the functionality may be used in an API, you should perhaps check logger.hasHandlers() and avoid adding handlers if there are already some added by a using library or application. Regards, Vinay Sajip _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.</pre>", "group_id": 8954, "id": 974986}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304964049.473901, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/643j4d9 - R. David Murray - <pre> The changesets are in the repository and there are pointers to them from the merge changeset, sure, but the data isn't in the checkout (that's how I understood \"pulled in to the new branch\"). If I do 'hg log' and search for a revno (that I got from hg annotate), the commit message describing the change is not attached to that revno, nor as far as I know is there a tool that makes it easy to get from that revno to the explanatory commit message. That's what Victor and I are talking about. Is there a tool that fixes this problem? (svnmerge did a nice job of that from the automate-the-message-generation end of things). -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 974988}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304966749.1226311, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/4xtdc6q - Ned Batchelder - <pre>I've always favored \"X now properly raises an exception.\" --Ned. </pre>", "group_id": 8954, "id": 975591}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304969506.947371, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/3mfnarm - Guido van Rossum - <pre> While my own preference is \"make X properly raise an exception\" I'm happy with any of the alternatives proposed here, and grateful to Terry for calling this out. Checkin comments of the form \"X does Y\" are ambiguous and confusing. (Same for feature requests in the tracker.) I'm curious where the habit to use the present tense comes from; I wonder if it originates in some agile development practice? </pre>", "group_id": 8954, "id": 976224}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304971424.035943, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/5sf9m47 - Eric Smith - <pre> Thanks indeed for bringing this up, Terry. It's been on my to-do list for a while. I think it comes from just copying the title of a bug report. The bug is \"X does Y\", and that's what's used in the fix. Eric. </pre>", "group_id": 8954, "id": 976979}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304972266.178551, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/3b4el5x - Guido van Rossum - <pre> But in bug reports it is also ambiguous, since I've often seen it used meaning \"X should do Y\" which is very confusing when it doesn't do Y yet at the time the bug is created. :-( </pre>", "group_id": 8954, "id": 977186}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304982168.5653, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/3w2j86k - Terry Reedy - <pre> I am willing to admit that I do not know all corners of Python ;-) I read the commit messages to learn more; in particular what sort of errors exist and how are they fixed. &gt;&gt;&gt; Checkin comments of the form \"X does Y\" I have always assumed that an issue entitled 'x does y' is a bug report about doing y now, before a fix. I have also seen this type of message for non-tracker-issue commits. If I notice a title that bad, I will try to change it. </pre>", "group_id": 8954, "id": 979986}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304983187.4971371, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/6hcj5t2 - Terry Reedy - <pre> TortoiseSvn, and I presume TortoiseHg also, has a 'recent messages' box that makes is trivial to reuse a message. I used it with svn and will make sure to use it, if it exists, when I get started with hg. </pre>", "group_id": 8954, "id": 980171}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304984089.579561, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/6x9nfu7 - Benjamin Peterson - <pre>2011/5/9 R. David Murray &lt;rdmurray&lt; at &gt;bitdance.com&gt;: *cough* http://mercurial.selenic.com/wiki/GraphlogExtension What's the difference between pulling multiple changesets in and one then? </pre>", "group_id": 8954, "id": 980371}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304985910.397187, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/6cte7sq - Neil Hodgson - <pre>Victor Stinner: Some C and C++ implementations currently allow non-ASCII identifiers and the forthcoming C1X and C++0x language standards include non-ASCII identifiers. The allowed characters are specified in Annexes of the respective standards. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf - Annex D http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3225.pdf - Annex E Neil </pre>", "group_id": 8954, "id": 980799}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304986787.7194331, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/3nd93fo - Antoine Pitrou - <pre>On Mon, 09 May 2011 16:11:15 +0200 Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: Why is it important, though? What matters is not what C/C++ can produce, but what a shared library can export. So the question is: are shared libraries limited to ASCII symbols? Regards Antoine. </pre>", "group_id": 8954, "id": 981016}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304986791.870048, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/3quwkjo - Greg Ewing - <pre> I think it's less confusing to use the term \"new\" only for output/return values, and \"stolen\" only for input values. Inputs are either \"borrowed\" or \"stolen\" (by the callee). Outputs are either \"new\" (to the caller) or \"borrowed\" (by the caller). (Or maybe the terms for outputs should be \"given\" and \"lent\"?-) </pre>", "group_id": 8954, "id": 981017}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304989525.8096621, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/629upb7 - Victor Stinner - <pre>Le mardi 10 mai 2011 \u00e0 09:52 +1000, Neil Hodgson a \u00e9crit : I read these documents but they don't explain which encoding is used in libraries and programs. Does it mean that Windows and Linux may use different encodings? At least, the surrogate range (U+DC00-U+DFFF) is excluded, which is a good news (UTF-8 decoder of Python 3 rejects surrogate characters). I discovered -fextended-identifiers option of gcc: using this option, you can use \\uHHHH and \\UHHHHHHHH in identifiers, but not \\xHH. On Linux, identifiers are encoded to UTF-8. Example: -------------- #define _ISOC99_SOURCE #include &lt;stdio.h&gt; int f\\u00E9() { wprintf(L\"U+00E9 = \\xE9\\n\"); } int g\\U000000E8() { wprintf(L\"U+00E8 = \\xE8\\n\"); } int main() { f\\u00E9(); g\\U000000E8(); return 0; } -------------- It's not very practical, I would prefer to write directly Unicode characters (as I can do in Python 3!). I'm not sure that chineses will prefer to call \\u4f60\\u597d() instead of hello(). Ok, I now agree, it is possible to use non-ASCII characters </pre>", "group_id": 8954, "id": 981329}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304992225.950799, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/6384h9b - R. David Murray - <pre> I'm sorry, but I've looked at the output of that and the mental overhead has so far proven too high for it to be of any use to me. I apologize for not having made the full mental transition to \"distributed VCS\"/DAG (apparently), but it sounds like I'm not the only one.... I'm talking about merging trunk to a feature branch, for example. I'd not expect any message other than 'merge' for that. I'd be satisfied if the commit messages listed the issue numbers involved in the merge, especially if someone (like \u00c3\u0089ric) is merging more than one change at a time. But as I think about this, frankly I'd rather see atomic commits, even on merges. That was something I disliked about svnmerge, the fact that often an svnmerge commit involved many changesets from the other branch. That was especially painful in exactly the same situation: trying to backtrack a change starting from 'svn blame'. I limited my own use of multiple-changeset-svnmerge to doc changes and changesets that were actually related, despite the</pre>", "group_id": 8954, "id": 981886}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304991328.883275, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/6h6yyk7 - Marvin Humphrey - <pre> To solve this problem in a similar system (the Clownfish object system used by Apache Lucy) we used the keywords \"incremented\" and \"decremented\". Applied to some Python C API function documentation: incremented PyObject* PyTuple_New(Py_ssize_t len) int PyTuple_SetItem(PyObject *p, Py_ssize_t pos, decremented PyObject *o) With \"incremented\" and \"decremented\", the perspective is always that of the caller. incremented: The caller has to account for an additional refcount. decremented: The caller has to account for a lost refcount. Marvin Humphrey </pre>", "group_id": 8954, "id": 981697}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304990426.512512, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/6cbqnyb - Neil Hodgson - <pre>Victor Stinner: Yes, Windows will use UTF-16 as it does for almost everything. From a user's point of view, these should both just be seen as Unicode. Neil </pre>", "group_id": 8954, "id": 981500}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304991325.4784091, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/6g76kv4 - Greg Ewing - <pre> I'm not sure that really clarifies anything. These terms sound like they're talking about the reference count of the object, but if they correspond to borrowed/stolen, they don't necessarily correlate with what actually happens to the reference count. </pre>", "group_id": 8954, "id": 981694}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304993124.8074069, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/3z4skhx - Marvin Humphrey - <pre> Hmm, they don't correspond to borrowed/stolen. stolen from the caller -&gt; decremented stolen from the callee -&gt; incremented borrowed -&gt; [no modifier] We don't have a modifier keyword which is analogous to \"borrowed\". The user is expected to understand object lifespan issues for borrowed references without explicit guidance. With regards to \"what actually happens to the reference count\", I would argue that \"incremented\" and \"decremented\" are accurate descriptions. * When a function returns an \"incremented\" object, that function has added a refcount to it. * When a function accepts a \"decremented\" object as an argument, it will consume a refcount from it -- either right away, or at some point in the future. In my view, it is not desirable to label arguments or return values as \"borrowed\"; it is only necessary to advise the user when they must take action to account for a refcount, gained or lost. Cheers, Marvin Humphrey </pre>", "group_id": 8954, "id": 982032}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304995825.7752991, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/6hg4ta8 - Stephen J. Turnbull - <pre> &gt; On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson &lt;benjamin&lt; at &gt;python.org&gt; wrote: &gt; &gt; *cough* http://mercurial.selenic.com/wiki/GraphlogExtension &gt; &gt; I'm sorry, but I've looked at the output of that and the mental overhead &gt; has so far proven too high for it to be of any use to me. How about the hgk extension, and \"hg view\"? http://mercurial.selenic.com/wiki/HgkExtension &gt; But as I think about this, frankly I'd rather see atomic commits, even &gt; on merges. That was something I disliked about svnmerge, the fact that &gt; often an svnmerge commit involved many changesets from the other branch. &gt; That was especially painful in exactly the same situation: trying to &gt; backtrack a change starting from 'svn blame'. I don't understand the issue. In my experience, hg annotate will point to the commit on the branch, not to the merge, unless there was a conflict, in which case the merge is the \"right\" place (although not necessarily the most useful place) to point. </pre>", "group_id": 8954, "id": 982605}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1304998526.5310459, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/6akx2xk - Michael Urman - <pre> I'm not convinced this is correct for this case. GetProcAddress takes an \"ANSI\" string, meaning while it could theoretically use UTF-8, in practice I doubt it uses anything outside of ASCII safely. So while the name of the library would be encoded in UTF-16, the name of the function loaded from the library would not be. http://msdn.microsoft.com/en-us/library/ms683212(v=vs.85).aspx </pre>", "group_id": 8954, "id": 983511}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305001228.1679151, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/623tes8 - Neil Hodgson - <pre>Michael Urman: Yes you are right: http://scintilla.org/NarrowName.png Neil </pre>", "group_id": 8954, "id": 984163}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305002127.742502, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/693bfex - Michael Urman - <pre> That screenshot seems to show UTF-8 is being used. This may just be the literal bytes in the .c file, but could it be something more dependable? http://unicode.org/cgi-bin/GetUnihanData.pl?codepoint=6728 _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 984343}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305003027.1580861, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/3vonn8a - Neil Hodgson - <pre>Michael Urman: The file is in UTF-8 so the compiler may just be copying the bytes. There is a setlocale pragma but that seems to be just for string literals. Neil </pre>", "group_id": 8954, "id": 984621}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305006627.6256959, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/3lrjqk6 - Eli Bendersky - <pre> Alright, I now understand the problems with the suggestion. Indeed, conditional assignments that are only really resolved at runtime are the big stumbling block here. However, maybe the error message/reporting can still be improved? ISTM the UnboundLocalError exception gets raised only in those weird and confusing cases. After all, why would Python decide an access to some name is to a local? Only if it found an assignment to that local in the scope. But that assignment clearly didn't happen yet, so the error is thrown. So cases like these: x = 2 def foo1(): x += 1 def foo2(): print(x) x = 10 def foo3(): if something_that_didnot_happen: x = 10 print(x) All belong to the category. With an unlimited error message length it could make sense to say \"Hey, I see 'x' may be assigned in this scope, so I mark it local. But this access to 'x' happens before assignment - so ERROR\". This isn't realistic, of course, so I'm wondering: 1. Does this error message (although unrealistic) capture all p</pre>", "group_id": 8954, "id": 985484}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305008487.4619019, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/6yl8w4z - Stefan Behnel - <pre>[forwarded to the python-ideas list] Stefan </pre>", "group_id": 8954, "id": 985806}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305014791.6950669, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/3krzlmb - Victor Stinner - <pre>Le lundi 09 mai 2011 \u00e0 22:18 -0500, Michael Urman a \u00e9crit : If GetProcAddress() expects a byte string encoded to the ANSI code page, my patch is correct because the function used the UTF-8 encoding, not the ANSI code page. We can maybe use GetProcAddressW() to pass a Unicode string. I don't know which encoding is used by GetProcAddressW()... I already patched _PyImport_GetDynLoadFunc() for Windows: the path is now a Unicode object instead of a byte string encoded to the filesystem encoding. _PyImport_GetDynLoadWindows() uses GetFullPathNameW() and LoadLibraryExW(). The work to be fully Unicode compliant (for the path field, not for the name) is not completly done... but I have a pending patch, see: http://bugs.python.org/issue11619 But this patch is huge and creates many functions. I am not sure that we need it, I will work on this later. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: </pre>", "group_id": 8954, "id": 986614}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305017486.5685141, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12039: Add end_headers() call to avoid BadStatusLine. - http://tinyurl.com/6e7t4ka - Senthil Kumaran - <pre> This is accurate. It should have resulted from the change made in the http.server, because the headers are now cached and then written to the output stream in one-shot when end_headers/flush_headers are called. Thanks, Senthil </pre>", "group_id": 8954, "id": 986964}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305029189.6293631, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/3ouw94k - Aur\u00e9lien Camp\u00e9as - <pre>Le 10/05/2011 04:51, Stephen J. Turnbull a \u00e9crit : or, FWIW, \"hgview\" (http://www.logilab.org/project/hgview) </pre>", "group_id": 8954, "id": 988333}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305031887.8458419, "message": "[devel] - Re: Borrowed and Stolen References in API - http://tinyurl.com/64sfu7w - Nick Coghlan - <pre>On Tue, May 10, 2011 at 11:53 AM, Marvin Humphrey &lt;marvin&lt; at &gt;rectangular.com&gt; wrote: Except that's not quite true in cases like PySet_Pop(). In that case, the net effect on the refcount is neutral. The significant point is that the set no longer holds a reference, it has passed that responsibility back to the caller. Agreed on this part, though. Callers need to know when: 1. The return value is a new reference that must be decremented (currently indicated in the docs by \"Return value: New reference\") 2. An input parameter transfers responsibility for the reference to the callee (the only example I noticed in the docs is PyList_SetItem, which uses an explicit note rather than any kind of markup or the refcount data) I believe the current refcount data covers the first case reasonably well, but not the latter (and still has the problem of being separated from the documentation of the functions themselves). Cheers, Nick. </pre>", "group_id": 8954, "id": 988770}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305030988.995631, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/5uzsbzc - Nick Coghlan - <pre> I believe I've actually seen it in NEWS entries as well (although thankfully not often and I can't recall any specific instances off the top of my head). I'm also a fan of including the word \"now\" and describing the new behaviour, although I'll sometimes use \"no longer\" and describe the old behaviour for some bugs where that seems more appropriate. Cheers, Nick. </pre>", "group_id": 8954, "id": 988579}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305032791.031842, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/4ypbvoq - R. David Murray - <pre> I think the problem is in my brain, not the graphical tools :) With rare exceptions I don't use tools that require a mouse to operate, though, so unless I feel like doing tcl hacking to make good keyboard bindings that particular tool won't help me anyway. That's what I get for reasoning about hg based on my svn experience. Someone on IRC also pointed this out. I haven't done this often enough in HG for the difference to have penetrated my brain. I have a feeling I'm still going to get confused occasionally, but then I'm sure I did with svn too... -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 988996}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305032795.260561, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/3z55gbx - Nick Coghlan - <pre>On Tue, May 10, 2011 at 12:51 PM, Stephen J. Turnbull &lt;stephen&lt; at &gt;xemacs.org&gt; wrote: I don't think it's really a jump up to the \"graphical\" level that we're after. It's more a matter of: 1. Display commit message for current commit 2. Notice that this commit has two parents 3. Ignore any parent commit in the same branch as the current commit 4. For a parent commit in another branch, also display that commit message 5. If the commit in step 4 also has multiple parents, repeat from step 3 (but based off that parent commit) So a standard 3.1-&gt;3.2-&gt;default merge could be displayed along the lines of: Merge from 3.2 3.2: Merge from 3.1 3.1: Issue #123456: mod.func now works correctly when argument is negative It won't help if the last commit on the initial branch was something boring like \"Fix whitespace\", but it will be adequate for our typical single-commit bug fix workflow. (If nobody does anything before then, I'll see what I can do with the email hook next week) Cheers, Nick. </pre>", "group_id": 8954, "id": 988999}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305033688.3767381, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/6eoh2o3 - R. David Murray - <pre> How about: \"reference to variable 'y' precedes an assignment that makes it a local variable\" IMO this still leaves room for confusion, but is better because it indicates the causation more clearly. (I don't think it is necessary to capture the subtlety of conditional assignment in the error message.) -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 989227}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305034589.5850911, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/3tz7zkr - R. David Murray - <pre> I generally don't use the same text for commit and NEWS, because I like to stick to one-liners for the first line of the commit, possibly with more detail in the body, while for NEWS items I'm aiming for a one to three line description. But in both cases what I'm thinking about is \"what have I *changed*\". In the commit message that will probably focus more on code changes, while the NEWS item will focus more on behavior changes, but the results are generally similar. So for example my most recent two comments look like this: commit: 11999: sync based on comparing mtimes, not mtime to system clock NEWS: Issue 11999: fixed sporadic sync failure mailbox.Maildir due to its trying to detect mtime changes by comparing to the system clock instead of to the previous value of the mtime. commit: #11873: Improve test regex so random directory names don't cause test to fail NEWS: Issue #11873: Change regex in test_compileall to fix occasional failures when when the randomly generated te</pre>", "group_id": 8954, "id": 989387}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305035489.663584, "message": "[devel] - Re: [Python-checkins] cpython: _PyImport_LoadDynamicModule() encodes the module name explicitly to ASCII - http://tinyurl.com/6gnbec8 - Michael Urman - <pre>On Tue, May 10, 2011 at 03:03, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: While I can find references to a GetProcAddressW, most of them seem to agree it doesn't exist. \"My kernel32.dll only exports GetProcAddress.\" This suggests to me it accepts a null-terminated bytestring instead of specifically an ANSI string. What data ends up in the export table is likely similar to the linux filesystem case, only with less likelihood of the environment telling you its encoding. I'm comfortable with the idea of requiring UTF-8 encoding for the initmodule entry points of modules named with non-ASCII identifiers, especially if there is nothing which works consistently today. I've only seen pure-ASCII library names in all my C++ work, so I feel it borders on YAGNI (but I like it in theory). As an alternate approach, one article I read suggested to use ordinals instead of names if you wanted to use non-ASCII names. Python could certainly try to load by ordinal on Windows, and fall back to loading by name. I d</pre>", "group_id": 8954, "id": 989547}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305036388.6087019, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/69y7k87 - Oleg Broytman - <pre> Why \"fixed\" is in the past tense, but \"improve\", and \"change\" are in present tense? I use past tense to describe what I did on the code, and present simple to describe what the new code does when running. For example: \"Fixed a bug in time comparison: compare mtime to mtime, not mtime to system clock\" I.e., \"fixed\" - that what I did, and \"compare\" is what the code does. (I used an excerpt from above only for the example, not to correct something.) Oleg. </pre>", "group_id": 8954, "id": 989837}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305036391.1774051, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/6ex85eb - Eli Bendersky - <pre> Yes, this is much better and not too long IMHO Eli </pre>", "group_id": 8954, "id": 989841}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305039090.585351, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/3v3mvxx - R. David Murray - <pre> Yes, that's a good point. I'll try to be more consistent about that in the future. Change should have been Changed. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 990814}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305039990.14152, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/3enwjal - Nick Coghlan - <pre> For comparison, the error messages I was able to elicit from 2.7 were as follows: # Module level NameError: name 'bob' is not defined # Function level reference to implicit global NameError: global name 'bob' is not defined # Early reference to local UnboundLocalError: local variable 'bob' referenced before assignment # Early reference from closure NameError: free variable 'bob' referenced before assignment in enclosing scope Personally, I would just add \"in current scope\" to the existing error message for the unbound local case (and potentially collapse the exception hierarchy a bit by setting UnboundLocalError = NameError). Cheers, Nick. </pre>", "group_id": 8954, "id": 991027}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305049951.7684641, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/4x9fmgo - R. David Murray - <pre> I don't think adding that phrase would add any clarity, myself. The mental disconnect comes from the fact that the UnboundLocal error message is emitted for the reference, but it is not immediately obvious *why* the variable is considered local. My rephrasing emphasizes that it is the assignment statement that led to that classification and therefore the error. This disconnect doesn't apply in the global cases. It applies less strongly in the free variable case because there is visibly another scope involved (that is, the triggering assignment isn't in the same scope as the reference producing the error message). -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 993593}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305050849.954509, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/5uvm74n - Terry Reedy - <pre> I would change this to \"local name 'bob' used before the assignment that makes it a local name\" Calling names 'variables' is itself a point of confusion. </pre>", "group_id": 8954, "id": 993726}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305052708.315968, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/6botl8n - R. David Murray - <pre> Yes, your phrasing is much better. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 994214}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305054510.8563039, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/6hjtakl - Eli Bendersky - <pre>&lt;snip&gt; +1 </pre>", "group_id": 8954, "id": 994568}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305068070.9927411, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/3pbavdt - Steven D'Aprano - <pre> -0 That was the case prior to Python 2.0. Reverting is potentially a semantic change that will break any code that distinguishes between (global) NameError and (local) UnboundLocalError. But personally, I don't know why it was thought necessary to distinguish between them in the first place. </pre>", "group_id": 8954, "id": 997198}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305071670.225579, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/6zvxuu7 - Fred Drake - <pre> New users almost constantly expressed confusion by NameError when the name was clearly bound at global scope, and a subsequent assignment caused it to be considered a local in their function. -Fred </pre>", "group_id": 8954, "id": 998034}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305107975.130347, "message": "[devel] - EuroPython: Early Bird will end in 2 days! - http://tinyurl.com/6e65pao - Palla - <pre>Hi all, If you plan to attend, you could save quite a bit on registration fees! The end of Early bird is on May 12th, Friday, 23:59:59 CEST. We'd like to ask to you to forward this post to anyone that you feel may be interested. We have an amazing lineup of tutorials, events and talks. We have some excellent keynote speakers and a very complete partner program... but early bird registration ends in 2 days! Right now, you still get discounts on talks and tutorials so if you plan to attend Register Now: http://ep2011.europython.eu/registration/ While you are booking, remember to have a look at the partner program and our offer for a prepaid, data+voice+tethering SIM. We'd like to ask to you to forward this post to anyone that you feel may be interested. All the best, </pre>", "group_id": 8954, "id": 1004965}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305132578.0297339, "message": "[devel] - Re: Commit changelog: issue number and merges - http://tinyurl.com/678pdwv - \u00c9ric Araujo - <pre> Le 09/05/2011 19:54, R. David Murray a \u00e9crit : No commit message is ever in the checkout, so I don\u2019t follow you. Ah, I understand your problem now. I would not object to a policy requiring to put helpful information in merge changesets commit messages, like \u201cMerge fixes for #4444 and #5555\u201d or \u201cMerge doc fixes\u201d when there are no bug reports. I\u2019m not sure about the \u201catomic\u201d merge changesets idea that someone else expressed; I don\u2019t think it would be that useful. I tend to use graphical tools for history viewing. I like the GTK version of TortoiseHg, or failing that the graph displayed by \u201chg serve\u201d if you enable the graphlog extension and use a browser with JavaScript. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1010085}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305134375.6806769, "message": "[devel] - Re: [Python-checkins] cpython (2.7): (Merge 3.1) Issue #12012: ssl.PROTOCOL_SSLv2 becomes optional - http://tinyurl.com/65pmj49 - \u00c9ric Araujo - <pre> Le 10/05/2011 01:52, victor.stinner a \u00e9crit : \u201c(Merge 3.1)\u201d is inaccurate for 2.7. Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1010608}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305133475.5931931, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/3ly4ozj - \u00c9ric Araujo - <pre> Hi, I think I\u2019ll aim for simplicity. We\u2019ll document that we use the logger \u201cpackaging\u201d throughout and let people use getLogger and addHandler with that. I thought that if we set the level on the logger, we would prevent third-party code to get some messages. E.g., we set level to INFO but pip uses some packaging functions and would like to get DEBUG messages. Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1010360}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305133479.0480549, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/6gfywpr - \u00c9ric Araujo - <pre> Le 10/05/2011 16:46, R. David Murray a \u00e9crit : Funny, I always use the present tense, to convey what the code does now. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1010361}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305136174.6479061, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/3qpmsa8 - Terry Reedy - <pre> Which code ;-). At the moment you write a push message, your private clone does something different from the public repository (and other private clones). At the moment people read a push message, they may not have pulled the change, so that there is a difference between the repository and *their* clone. Besides the ambiguity, there is also inconsistency between writers. Hence my request for a few clarifying keystrokes when needed. </pre>", "group_id": 8954, "id": 1011101}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305137978.1309969, "message": "[devel] - Re: [Python-checkins] cpython (2.7): (Merge 3.1) Issue #12012: ssl.PROTOCOL_SSLv2 becomes optional - http://tinyurl.com/6afvqp9 - Victor Stinner - <pre>Le mercredi 11 mai 2011 \u00e0 19:05 +0200, \u00c9ric Araujo a \u00e9crit : Ah, why? I did not use \"hg merge\" command (but hg export|hg import), but it's a \"merge\" between two branches. Which term would you use? Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1011575}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305141575.7773931, "message": "[devel] - Re: Commit messages: please avoid temporal ambiguity - http://tinyurl.com/6kzho9s - Guido van Rossum - <pre> Yeah, and that's exactly what I am objecting to. Please describe what changed how, since that is the focus of the patch. </pre>", "group_id": 8954, "id": 1012601}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305144276.2137239, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/63dtmzv - Vinay Sajip - <pre> Then pip can set the level of the packaging logger as it wishes, perhaps in response to command-line arguments for verbosity. It'd be easier for pip to do that, regardless of which handlers are attached. And pip itself might be being used, say by virtualenv. It's hard in general to say what the top-level code will be, and generally that's the code which should set the handlers. The levels set by a library for its loggers are merely defaults. Applications using the library can choose to override those levels as they wish. Regards, Vinay Sajip _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1013379}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305148776.400166, "message": "[devel] - Re: [Python-checkins] cpython (2.7): (Merge 3.1) Issue #12012: ssl.PROTOCOL_SSLv2 becomes optional - http://tinyurl.com/6a8tzc7 - Terry Reedy - <pre> export/import sounds like transport: \"(transport from 3.1)\" would be clear enough to me. </pre>", "group_id": 8954, "id": 1014635}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305168698.684514, "message": "[devel] - py3k buffered I/O - flush() required betweenread/write? - http://tinyurl.com/4xcahm5 - Genstein - <pre>Hi all, Sincere apologies for posting a question without lurking for a while first. I'm not sure whether I'm being dumb (which is very plausible) or whether this is a potential bug. I asked on comp.lang.python but responses were equivocal, so I'm following the README.txt advice and asking here. If I'm out of line, do feel free to slap me down viciously, remove me from the list, or whatever seems most appropriate. Under py3k, is it necessary to flush() a file between buffered read/write calls in order to see consistent results? I have a case under Python 3.2 (r32:88445) where I see different results depending on whether buffering is active, on Gentoo Linux and Windows Vista. Perusing the docs and PEPs I couldn't seem to find an answer; I did find bufferedio.c's comment: \"BufferedReader, BufferedWriter and BufferedRandom...share a single buffer...this enables interleaved reads and writes without flushing\" which is suggestive but I may be taking it out of context. The following is the smallest c</pre>", "group_id": 8954, "id": 1018187}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305197786.499207, "message": "[devel] - Re: py3k buffered I/O - flush() required betweenread/write? - http://tinyurl.com/4yyrsjm - Antoine Pitrou - <pre> Hello, On Thu, 12 May 2011 03:35:16 +0100 Genstein &lt;pythondev&lt; at &gt;genstein.net&gt; wrote: This is a bug indeed. Can you report it on http://bugs.python.org ? Thanks a lot for finding this, Antoine. </pre>", "group_id": 8954, "id": 1023657}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305207819.631475, "message": "[devel] - Re: py3k buffered I/O - flush() requiredbetweenread/write? - http://tinyurl.com/3aol354 - Genstein - <pre>Duly reported as http://bugs.python.org/issue12062. I'm glad it wasn't me being dumb(er than usual). It took a while to pin down to a small reproducible case. Thanks for the fast and definite response, I'll cheerfully revert to lurking now ;) All the best, -eg. </pre>", "group_id": 8954, "id": 1024588}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305218620.6485441, "message": "[devel] - Could these restrictions be removed? - http://tinyurl.com/6feexsp - Skip Montanaro - <pre> A friend at work who is new to Python wondered why this didn't work with pickle: class Outer: Class Inner: ... def __init__(self): self.i = Outer.Inner() I explained: I've never questions this, but I wonder, is this a fundamental restriction or could it be overcome with a modest amount of work? Just curious... Skip </pre>", "group_id": 8954, "id": 1026226}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305220525.2067549, "message": "[devel] - Re: Could these restrictions be removed? - http://tinyurl.com/3pj8a6v - Antoine Pitrou - <pre>On Thu, 12 May 2011 11:33:37 -0500 (CDT) Skip Montanaro &lt;skip&lt; at &gt;montanaro.dyndns.org&gt; wrote: [...] pickle uses heuristics to try to find out the \"official name\" of a class or function. It would be a matter of improving these heuristics. There are other cases in which pickle similarly fails: b'\\x80\\x03crandom\\nrandom\\nq\\x00.' Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt; _pickle.PicklingError: Can't pickle &lt;class 'method'&gt;: attribute lookup builtins.method failed Regards Antoine. </pre>", "group_id": 8954, "id": 1026507}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305221382.076457, "message": "[devel] - Re: Could these restrictions be removed? - http://tinyurl.com/6et9bu3 - Walter D\u00f6rwald - <pre> This is related to http://bugs.python.org/issue633930 Servus, Walter </pre>", "group_id": 8954, "id": 1026682}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305220522.0816541, "message": "[devel] - Re: Could these restrictions be removed? - http://tinyurl.com/6zgfyyd - Walter D\u00f6rwald - <pre> See also the thread started at: http://mail.python.org/pipermail/python-dev/2005-March/052454.html Servus, Walter _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1026505}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305280485.4052041, "message": "[devel] - Python Support on OpenVMS - http://tinyurl.com/4y3gy85 - Mathew, Sandeep (OpenVMS - <pre>Hi Folks, I am Sandeep Mathew from OpenVMS engineering in Hewlett-Packard. I have worked on various components of the OpenVMS operating system including MONITOR, TDF, EXEC, LIBRTL, DCL and SYSMAN. I happened to read this blog post about dropping OpenVMS support for further releases of python here: http://blog.python.org/2011/05/python-33-to-drop-support-for-os2.html. I am willing to spend time and effort to ensure that python remains supported on OpenVMS. Please let me know what needs to be done for continued OpenVMS Support in Python. Looking forward to working with the Python community. Regards Sandeep Mathew </pre>", "group_id": 8954, "id": 1039251}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305282287.7150919, "message": "[devel] - Re: Python Support on OpenVMS - http://tinyurl.com/43may3r - Antoine Pitrou - <pre> Welcome Sandeep, The first thing would be to check whether the current development tree (the future Python 3.3) compiles and works fine for OpenVMS. Given that 3.x has had many changes compared to 2.x, this is not guaranteed. Instructions for getting the source tree are here: http://docs.python.org/devguide/setup.html Once the interpreter compiled fine, the second step is to run the test suite: http://docs.python.org/devguide/runtests.html Any compilation errors and test suite failures should be reported to the bug tracker (http://bugs.python.org/), preferably with patches since I doubt any of us would be able to fix the issues themselves. If you have any questions, don't hesitate to ask. Regards Antoine. </pre>", "group_id": 8954, "id": 1039406}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305300407.2045369, "message": "[devel] - Re: [Python-checkins] cpython (2.7): (Merge 3.1) Issue #12012: ssl.PROTOCOL_SSLv2 becomes optional - http://tinyurl.com/6knhz6c - \u00c9ric Araujo - <pre>Le 11/05/2011 20:08, Victor Stinner a \u00e9crit : I prefer to use merge only to refer to hg merges. The 2.7 and 3.x lines are independent, so I wouldn\u2019t put any marker in the commit message, just use the same as the message used in 3.1. Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1042985}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305302327.32956, "message": "[devel] - Re: [Python-checkins] cpython (3.1): Fix for issue 10684: Folders get deleted when trying to change case with - http://tinyurl.com/3drvx5n - \u00c9ric Araujo - <pre>Hi, Le 06/05/2011 11:32, ronald.oussoren a \u00e9crit : Is this change a debugging leftover? Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1043421}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305301427.0347099, "message": "[devel] - Re: [Python-checkins] Python Regression Test Failuresdoc (1) - http://tinyurl.com/3eakf8x - \u00c9ric Araujo - <pre>Hi, Le 08/05/2011 22:00, Neal Norwitz a \u00e9crit : I always wonder about these messages. They\u2019re mostly error messages recently; what are python-checkins subscribers supposed to do in reaction? In non-error mode, what are they useful for? Thanks in advance for enlightening me. Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1043238}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305303230.6970961, "message": "[devel] - Summary of Python tracker Issues - http://tinyurl.com/3ce2bxs - Python tracker - <pre> ACTIVITY SUMMARY (2011-05-06 - 2011-05-13) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2784 ( +1) closed 21069 (+52) total 23853 (+53) Open issues with patches: 1198 Issues opened (36) ================== #6011: python doesn't build if prefix contains non-ascii characters http://bugs.python.org/issue6011 reopened by haypo #11786: ConfigParser.[Raw]ConfigParser optionxform() http://bugs.python.org/issue11786 reopened by eric.araujo #11873: test_regexp() of test_compileall fails occassionally http://bugs.python.org/issue11873 reopened by haypo #11977: Document int.conjugate, .denominator, ... http://bugs.python.org/issue11977 reopened by georg.brandl #12019: Dead or buggy code in importlib.test.__main__ http://bugs.python.org/issue12019 opened by eric.araujo #12020: Attribute error with flush on stdout,stderr http://bugs.python.org/issue12020 opened </pre>", "group_id": 8954, "id": 1043578}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305310434.775583, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/4xr8glq - \u00c9ric Araujo - <pre>Le 11/05/2011 21:45, Vinay Sajip a \u00e9crit : Okay. I\u2019ll go ahead and remove handlers (except for the command-line script), and set the level on the logger. If it turns out that the code in packaging incorrectly resets the level set by calling code, we\u2019ll fix it later; now we want to fix the tests to produce the patch that will add packaging to CPython. The conflict here is that there\u2019s a class setting the logging level on instantiation, which could reset the level set by calling code. Thanks again for your messages (and blog). _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1045078}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305311328.5834041, "message": "[devel] - Re: Problems with regrtest and with logging - http://tinyurl.com/6fqgmtk - \u00c9ric Araujo - <pre> A quick follow-up: I talked about regrtest with RDM on IRC, and I will use the context manager that detects changes in the \u201cif __name__ == '__main__'\u201d blocks of our test files to find the guilty ones. Some warnings are subtle to track down: the test runs a command which instantiates a class which calls a function and here\u2019s the code that sets an environment variable. In the future, I\u2019ll take part in the efforts to reimplement parts of regrtest with new unittest features. Right now it\u2019s quite painful to have to use either unittest to run just one file or regrtest to get the warnings. Cheers _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1045290}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305316727.2474711, "message": "[devel] - Re: Summary of Python tracker Issues - http://tinyurl.com/3tn3qku - Steffen Daode Nurpmeso - <pre>The summary mails part 1 was declared as US-ASCII, 8bit, but it contained a UTF-8 character: This is handled without any problem by Python 3000 due to David Murrays patch of issue 11605 for 3.2 and 3.3. (It however broke my obviously insufficient non-postman thing :(, and it's of course not a valid mail, strictly speaking. So i report this just in case your stricken MUAs simply do the right thing and noone recognizes it at all.) May the juice be with you -- Steffen, sdaoden(*)(gmail.com) </pre>", "group_id": 8954, "id": 1046443}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305356557.2135999, "message": "[devel] - Re: Python Support on OpenVMS - http://tinyurl.com/6aku4ww - Nick Coghlan - <pre> For ongoing support, it would also be *really* helpful if HP could provide an OpenVMS buildbot. Cheers, Nick. </pre>", "group_id": 8954, "id": 1050708}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305391178.2687891, "message": "[devel] - AUTO: Jon K Peck is out of the office (returning05/18/2011) - http://tinyurl.com/64z7u8t - Jon K Peck - <pre> I am out of the office until 05/18/2011. I am out of the office traveling Wed - Thursday, May 11-12 and Saturday-Tuesday, May 14-17. I will have limited access to email during this time, so I will be delayed in responding. Note: This is an automated response to your message \"Python-Dev Digest, Vol 94, Issue 25\" sent on 5/14/11 4:00:03. This is the only notification you will receive while this person is away.</pre>", "group_id": 8954, "id": 1053347}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305449995.4971559, "message": "[devel] - Re: more timely detection of unbound locals - http://tinyurl.com/6aadf5b - Vinay Sajip - <pre> +1 </pre>", "group_id": 8954, "id": 1058706}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305512775.531996, "message": "[devel] - Re: Python Support on OpenVMS - http://tinyurl.com/63cwxwh - Senthil Kumaran - <pre> Yes, that would be best first step in the on-going struggle to support OpenVMS platform. The problem in the first place is no one has the hardware to try install python, leaving alone fixing the bugs in that. So, Sandeep, if you can setup a buildbot ( http://python.org/dev/buildbot/) and be the owner of the buildbot, it would be really helpful. </pre>", "group_id": 8954, "id": 1065553}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305531078.9668751, "message": "[devel] - Re: Python Support on OpenVMS - http://tinyurl.com/3es3sag - Martin v. L\u00f6wis - <pre>Am 16.05.2011 04:15, schrieb Senthil Kumaran: I guess the best first step would be to make it compile at all. Then try to make it pass the test suite. This may well take several months to complete. Regards, Martin </pre>", "group_id": 8954, "id": 1068366}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305533775.918236, "message": "[devel] - Re: Python Support on OpenVMS - http://tinyurl.com/6749pg3 - Nick Coghlan - <pre> And then make sure the buildbot client runs properly. Still, having someone start down that path now (with a green stable buildbot as the target end state) provides a specific goal that any patches can work towards. Cheers, Nick. </pre>", "group_id": 8954, "id": 1068596}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305534676.703738, "message": "[devel] - Re: Python Support on OpenVMS - http://tinyurl.com/6f4wp2z - Mathew, Sandeep (OpenVMS - <pre>Hi All, Thanks for your responses!. First thing on my radar is to get buildbot working on OpenVMS. I had a quick glance at source, although buildbot is written purely in python it has many platform specific issues. See: https://github.com/buildbot/buildbot/blob/master/master/README.w32 However I am guessing that it may not be very difficult to resolve. I will concentrating on Itanium systems initially and will later port it to Alpha in a similar way. I have requested for an account in HP's OpenVMS cluster meant for open source development. I will kick off my work after the account has been activated! Regards Sandeep Mathew </pre>", "group_id": 8954, "id": 1068698}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305553760.471925, "message": "[devel] - Re: Python Support on OpenVMS - http://tinyurl.com/6fxa9dh - Antoine Pitrou - <pre>On Mon, 16 May 2011 08:08:27 +0000 \"Mathew, Sandeep (OpenVMS)\" &lt;sandeep.mathew&lt; at &gt;hp.com&gt; wrote: I think this file is way out of date. We have Windows buildbots running fine, and I don't think they required a modification of the buildbot software. Furthermore, you only need the buildbot slave, not master. See http://wiki.python.org/moin/BuildBot for more info Regards Antoine. </pre>", "group_id": 8954, "id": 1070855}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305570980.0335031, "message": "[devel] - Re: Simple XML-RPC server over SSL/TLS - http://tinyurl.com/3q2vkaa - Dariusz Suchojad - <pre> Hello, I know it's been some time but I've only now spotted the thread and just in case it could be helpful to anyone, Spring Python project has implemented the feature last year for Python 2.x http://static.springsource.org/spring-python/1.2.x/sphinx/html/remoting.html#secure-xml-rpc cheers, </pre>", "group_id": 8954, "id": 1073361}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305588263.816891, "message": "[devel] - [OT] Server Side Clone mode - http://tinyurl.com/3tzlsob - Dj Gilcrease - <pre>I was wondering if there was a place I could get the modifications that have been made at hg.python.org to add the Server Side Clone to the hgweb interface. Dj Gilcrease \u00a0____ ( | \u00a0 \u00a0 \\ \u00a0o \u00a0 \u00a0() \u00a0 | \u00a0o \u00a0|`| \u00a0 | \u00a0 \u00a0 \u00a0| \u00a0 \u00a0 \u00a0/`\\_/| \u00a0 \u00a0 \u00a0| | \u00a0 ,__ \u00a0 ,_, \u00a0 ,_, \u00a0 __, \u00a0 \u00a0, \u00a0 ,_, _| \u00a0 \u00a0 \u00a0| | \u00a0 \u00a0/ \u00a0 \u00a0 \u00a0| \u00a0| \u00a0 |/ \u00a0 / \u00a0 \u00a0 \u00a0/ \u00a0 | \u00a0 |_/ \u00a0/ \u00a0 \u00a0| \u00a0 / \\_|_/ (/\\___/ \u00a0|/ \u00a0/(__,/ \u00a0|_/|__/\\___/ \u00a0 \u00a0|_/|__/\\__/|_/\\,/ \u00a0|__/ \u00a0 \u00a0 \u00a0 \u00a0 \u00a0/| \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\\| </pre>", "group_id": 8954, "id": 1076021}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305619162.7405939, "message": "[devel] - Updated version of PEP-0397 - Python launcher forWindows. - http://tinyurl.com/3wmwo3z - Mark Hammond - <pre>Hi all, I've updated PEP-0397 to try and address some of the comments from the last draft. I've checked the new version into hg, so you can find a full diff there, but the key items I've changed are: * Spelled out the \"version qualifier\" rules for the shebang lines. * Spelled out some customization options, both for fine-tuning the specific Python version selected and for supporting other Python implementations via \"custom\" commands. * Indicated the launcher is not supported at all on Win2k or earlier. * Removed some cruft. The new version is attached and I welcome all comments, including bike-shedding on the environment variable names and INI section/value names. Note that the reference implementation has not changed - I'll update that once there is general agreement on the functionality described in the PEP. Thanks, Mark PEP: 397 Title: Python launcher for Windows Version: $Revision$ Last-Modified: $Date$ Author: Mark Hammond &lt;mhammond&lt; at &gt;skippinet.com.au&gt; Status: Draft Type: Standards Track C</pre>", "group_id": 8954, "id": 1079995}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305644425.8778861, "message": "[devel] - Success x86 XP-4 2.7 buildbot without any log andshould be a failure - http://tinyurl.com/6j4wp97 - Victor Stinner - <pre>Hi, I broke recently all tests of CJK encodings (#12057) in Python 2.7 (sorry, it is now fixed). But the \"x86 XP-4 2.7\" buildbot is green, I don't understand how (the bug was not fixed in the build 894): http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%202.7/builds/894 This build doesn't contain any log. Victor </pre>", "group_id": 8954, "id": 1083909}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305647128.4641359, "message": "[devel] - \"packaging\" merge imminent - http://tinyurl.com/3jjnqnl - Tarek Ziad\u00e9 - <pre>Hello I am about to merge packaging in the stdlib, and we will continue our work there :) The impact is: - addition of Lib/packaging - addition of test/test_packaging.py - changes in Lib/sysconfig.py - addition of Lib/sysconfig.cfg For the last one, I would like to make sure again that everyone is ok with having a .cfg file added in the Lib/ directory. If not, we need to discuss how to do this differently. == purpose of sysconfig.cfg == The sysconfig.cfg file is a ini-like file that sysconfig.py reads to get the installation paths. We currently have these paths harcoded in the python module. The next change I have planned is to allow several levels of configuration, like distutils.cfg does. sysconfig.py will look for a sysconfig.cfg file in these places: 1. the current working directory -- so can be potentially included in a project source release 2. the user home (specific location be defined, maybe in ~/local) [inherits from the previous one] 3. the global [inherits fro</pre>", "group_id": 8954, "id": 1084404}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305651624.1107759, "message": "[devel] - Re: \"packaging\" merge imminent - http://tinyurl.com/658azg7 - Christian Heimes - <pre>Am 17.05.2011 17:36, schrieb Tarek Ziad\u00e9: You may want to study my site package PEP [1] regarding possible security implications. I recommend that you ignore the current working directory and user's home directory under conditions like different effective user or the -E option. A good place for a local sysconfig.cfg could be the user's stdlib directory (e.g. ~/.local/lib/python3.2/sysconfig.cfg). Christian [1] http://www.python.org/dev/peps/pep-0370 </pre>", "group_id": 8954, "id": 1085050}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305655226.5851531, "message": "[devel] - Bug in json (the format and the module) - http://tinyurl.com/68h6djy - Jeremy Dunck - <pre>This blog post describes a bug in a common usage pattern of JSON: http://timelessrepo.com/json-isnt-a-javascript-subset That is, there are some characters which are legal in JSON serializations, but not in JavaScript strings. This works OK for JSON parsers, but a common use case of JSON is JSONP, where the result of a request is presumed to be executable javascript: &lt;script src=\"http://someapi.com/jsonp?callback=foo\"&gt; might return a response: foo({\"some_json\":\"which might or might not be legal javascript\"}) The post also suggests a solution -- to replace literal U+2028 - Line separator and U+2029 - Paragraph separator with their escape sequences \\u2028 and \\u2029. This is a nice solution in that it makes the JSON valid JS while keeping the same semantics. Of course there's the annoyance of processing the full string, comparable in overhead to utf-8 encoding, I presume. So, to start with, is there a maintainer for the json module, or how should I go about discussing implementing this solution? </pre>", "group_id": 8954, "id": 1085635}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305657029.7443719, "message": "[devel] - Re: Bug in json (the format and the module) - http://tinyurl.com/3mpsxm2 - Dirkjan Ochtman - <pre> Your subject states that there is an actual bug in the json module, but your message fails to mention any actual bug. Is this what you mean? Python 2.7.1 (r271:86832, Mar 28 2011, 09:54:04) [GCC 4.4.5] on linux2 Type \"help\", \"copyright\", \"credits\" or \"license\" for more information. \"foo\\u2028bar\" Cheers, Dirkjan </pre>", "group_id": 8954, "id": 1086126}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305657026.6582119, "message": "[devel] - Re: Bug in json (the format and the module) - http://tinyurl.com/3dqlavu - Bob Ippolito - <pre>By default the json module already escapes anything outside of 7-bit ASCII, so unless you're using ensure_ascii=False then this is a non-issue. I implemented a workaround for ensure_ascii=False in simplejson here, it would be pretty trivial to add this feature to the json module as well: https://github.com/simplejson/simplejson/commit/4989e693bab39b1ce5cf6fc0b21dbacd108c312c On Tue, May 17, 2011 at 11:40 AM, Jeremy Dunck &lt;jdunck&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1086123}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305657924.515805, "message": "[devel] - Re: \"packaging\" merge imminent - http://tinyurl.com/3hxkant - Ronald Oussoren - <pre> On 17 May, 2011, at 17:36, Tarek Ziad\u00e9 wrote: Does this mean that python behaves differently when there happens to be a sysconfig.cfg file in the current working directory? That's a potentional security risk. How hard would it be to disable this behavior for tools like virtualenv and py2app? Ronald</pre>", "group_id": 8954, "id": 1086430}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305660627.36938, "message": "[devel] - Re: Bug in json (the format and the module) - http://tinyurl.com/3lmkzqo - Jeremy Dunck - <pre> Actually, that would be fine, and Bob's right that this is a non-issue with ensure_ascii=True (the default). His change upstream seems good for the ensure_ascii=False case. To be complete, this is what I meant: '{\"JSON\":\"ro\\xe2\\x80\\xa8cks!\"}' '\"{\\\\\"JSON\\\\\":\\\\\"ro\\\\u2028cks!\\\\\"}\"' '\"{\\\\\"JSON\\\\\":\\\\\"ro\\xe2\\x80\\xa8cks!\\\\\"}\"' _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1087129}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305667046.299355, "message": "[devel] - Re: \"packaging\" merge imminent - http://tinyurl.com/5usuajc - Victor Stinner - <pre>Le mardi 17 mai 2011 \u00e0 17:36 +0200, Tarek Ziad\u00e9 a \u00e9crit : Does setup.py continue to use the \"old\" distutils module? I fixed recently some bugs in distutils. Should I also fix them in the packaging module, or are both modules already \"synchronized\"? Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1088361}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305670716.6059761, "message": "[devel] - Re: \"packaging\" merge imminent - http://tinyurl.com/3bbaje2 - Tarek Ziad\u00e9 - <pre> Sounds good, thanks Yes, so, part of the packaging imcoming work will be to relocate all user .cfg files in the same, python-specific place. That includes pydistutils.cfg, and pypirc. I remember we did talk about that a few months ago, and will restart this discussion asap </pre>", "group_id": 8954, "id": 1089082}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305670711.3497951, "message": "[devel] - Re: \"packaging\" merge imminent - http://tinyurl.com/3elvmgr - Tarek Ziad\u00e9 - <pre>On Tue, May 17, 2011 at 10:40 PM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: Yes. The plan is to keep distutils support, so projects with setup.py still work. For the new packaging, people will have to provide new sections in setup.cfg. The pysetup script will detect at installation time if the project has the required bits in the cfg, and if not will fallback to executing setup.py They need to be backported yes. We did some, but we'll need to double check distutils timeline to make sure it's synced </pre>", "group_id": 8954, "id": 1089080}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305670706.9101391, "message": "[devel] - Re: \"packaging\" merge imminent - http://tinyurl.com/44w6ms6 - Tarek Ziad\u00e9 - <pre>... The use case is to have it there at install time so packaging can have alternative locations if needed. We could also drop the working dir scanning and have it: 1- passed explicitly to the pysetup script via an option. 2- used only if found in a root of a project at installation time, and only then Not hard at all, just an option. And the goal is also to allow virtualenv to have its own copy, like it does for distutils.cfg </pre>", "group_id": 8954, "id": 1089077}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305673406.073235, "message": "[devel] - Python 3.x and bytes - http://tinyurl.com/6y98rc7 - Ethan Furman - <pre>The bytes type in Python 3 does not feel very consistent. For example: --&gt; some_var = 'abcdef' --&gt; some_var 'abcdef' --&gt; some_var[3] 'd' --&gt; some_other_var = b'abcdef' --&gt; some_other_var b'abcdef' --&gt; some_other_var[3] 100 On the one hand we have the 'bytes are ascii data' type interface, and on the other we have the 'bytes are a list of integers between 0 - 256' interface. And trying to use the two is not intuitive: --&gt; some_other_var[3] == b'd' False When I'm parsing a .dbf file and extracting field types from the byte stream, I'm not thinking, \"okay, 67 is a Character field\" -- what I'm thinking is, \"b'C' is a Character field\". Considering that ord() still works fine, I'm not sure why it was done this way. Is there code out there that is using this \"list of int's\" interface, or is there time to make changes to bytes? ~Ethan~ </pre>", "group_id": 8954, "id": 1089711}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305674307.6854999, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/686vnn5 - Raymond Hettinger - <pre> On May 17, 2011, at 5:27 PM, Ethan Furman wrote: This is incidental. Bytes can and often do contain data with non-ascii encoded text, plain binary data, or structs, or raw data read off a disk, etc. Yes. No. Raymond </pre>", "group_id": 8954, "id": 1089832}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305675212.6810131, "message": "[devel] - Re: \"packaging\" merge imminent - http://tinyurl.com/6zpveau - Ned Deily - <pre>In article &lt;BANLkTikjoaU=HoG3OsSOvJ5UzOWPTwT=vg&lt; at &gt;mail.gmail.com&gt;, Tarek Ziad\u00e9 &lt;ziade.tarek&lt; at &gt;gmail.com&gt; wrote: Just to be clear: what about for the build of the interpreter itself, i.e. its setup.py for the standard library extension modules? Will the existing distutils code continue to be used for that? Or is it being replaced by code in packaging? If so, have Python builds been tested yet on the various platforms? </pre>", "group_id": 8954, "id": 1089941}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305674305.0005651, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6hdf45a - Benjamin Peterson - <pre>2011/5/17 Ethan Furman &lt;ethan&lt; at &gt;stoneleaf.us&gt;: I agree that this change was unfortunate and not too useful in practice. I don't doubt there is, and I'm afraid it's far to late to change this. </pre>", "group_id": 8954, "id": 1089830}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305676110.3337719, "message": "[devel] - Re: \"packaging\" merge imminent - http://tinyurl.com/663y877 - Tarek Ziad\u00e9 - <pre>... It will remain distutils-based for now. Moving it to packaging is not our top priority. Cheers Tarek </pre>", "group_id": 8954, "id": 1090054}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305677188.1868651, "message": "[devel] - Re: \"packaging\" merge imminent - http://tinyurl.com/6dwm6j4 - Ned Deily - <pre>In article &lt;BANLkTikhNDSPPdeOce5KF18G+vbjcwqwEw&lt; at &gt;mail.gmail.com&gt;, Tarek Ziad\u00e9 &lt;ziade.tarek&lt; at &gt;gmail.com&gt; wrote: +1. Thanks! </pre>", "group_id": 8954, "id": 1090202}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305689008.716722, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/5u366os - Nick Coghlan - <pre> No. Bytes are a list of integers between 0-256. End of story. Using them to represent text as well was precisely the problem with 2.x 8-bit strings, since the boundaries got blurred. However, as a matter of practicality, many byte-oriented protocols use ASCII to make elements of the protocol readable by humans. The \"text-like\" elements of the bytes and bytearray types are a concession to the existence of those protocols. However, that doesn't make them text - they're still binary data streams. If you want to treat them as text, convert them to \"str\" objects first (e.g. that's what urlib.urlparse does internally in order to operate on bytes and bytearray instances). Cheers, Nick. </pre>", "group_id": 8954, "id": 1092135}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305689906.7616451, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6zvhuck - Robert Collins - <pre> This is a not a useful argument - its an implementation choice in Python 3, and urlparse converting bytes to 'str' to operate on them is at best a kludge - you're forcing 5 times the storage (the original bytes + 4 bytes-per-byte when its decoded into unicode) to work on something which is defined as a BNF * that uses ascii *. The Python 2 confusion was deplorable, but it doesn't make the Python 3 situation better: its different, but still very awkward for people to write code that is correct and fast in. Its probably too late to change, but please don't try to argue that its correct: the continued confusion of folk running into this is evidence that confusion *is happening*. Treat that as evidence and think about how to fix it going forward. _Rob </pre>", "group_id": 8954, "id": 1092247}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305690807.2406881, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6yqag83 - Nick Coghlan - <pre>On Wed, May 18, 2011 at 1:23 PM, Robert Collins &lt;robertc&lt; at &gt;robertcollins.net&gt; wrote: When Python 3 goes wrong, it raises exceptions or executes the wrong control flow. That's a vast improvement over silently corrupting the data stream the way that 2.x does. If it really bothers anyone, they should feel free to implement and promote their own \"ascii\" data type on PyPI. If it is explicitly restricted to 7 bit characters, it may even avoid many of the problems of silent corruption that the 2.x str had. Speculation on python-dev isn't going to be convincing here, though: only code in real use will be effective on that front. As far as the memory and runtime overhead goes, yes, that's a real problem (indeed, that overhead is *why* bytes and bytearray have as many str-like features as they do). PEP 393 is intended to at least alleviate the memory burden of the Unicode text. Cheers, Nick. </pre>", "group_id": 8954, "id": 1092383}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305698131.6010001, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6bwazpx - Greg Ewing - <pre> That is itself an implementation detail of current Python, though, due to it only having one internal representation of unicode. In principle there could be a form of str that keeps its data encoded in latin1, in which case constructing it from a byte string could simply involve storing a pointer to the original bytes data. </pre>", "group_id": 8954, "id": 1093237}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305698127.849858, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6xgta8y - Greg Ewing - <pre> I think the weird part is that there exists a literal for writing a byte array as an ascii string, and furthermore that it's the *only* kind of literal available for bytes. Personally I think that the default literal syntax for bytes, and also the form produced by repr(), should have been something more neutral, such as hex, with the ascii form available for use when it makes sense. Currently if you want to write a bytes literal in hex, you have to say something like some_var = b'\\xde\\xad\\xbe\\xef' which is ugly and unreadable. Much nicer would be some_var = x'deadbeef' As for there ought to be a literal for specifying an integer using an ascii character, so you could say something like if some_other_var[3] == c'd': which would be equivalent to if some_other_var[3] == ord(b'd') but without the overhead of computing the value each time at run time. </pre>", "group_id": 8954, "id": 1093235}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305698135.2806611, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6hcuzf4 - Glenn Linderman - <pre> +1 Seems this could be added compatibly? </pre>", "group_id": 8954, "id": 1093239}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305699933.1038921, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6gg5axh - Amaury Forgeot d'Arc - <pre>Hi, 2011/5/18 anatoly techtonik &lt;techtonik&lt; at &gt;gmail.com&gt;: All changes are always listed in the Misc/NEWS file. A \"Change log\" link on every download page displays this file. </pre>", "group_id": 8954, "id": 1093505}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305699028.7039449, "message": "[devel] - how do you find out what version of Python a PEPlanded in? - http://tinyurl.com/6fncbhz - Chris Withers - <pre>Hi All, A friend of mine is coming over to Python and asked a question I thought would have a better answer than it appears to: How do I know which version of Python a PEP lands in? I was expecting there to be a note at the bottom of the PEP, 342 in this case, but that doesn't appear to be the case. What is the policy on this? Where should we be looking? cheers, Chris </pre>", "group_id": 8954, "id": 1093427}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305699031.483449, "message": "[devel] - Re: how do you find out what version of Python a PEP landed in? - http://tinyurl.com/6am4s4s - Amaury Forgeot d'Arc - <pre>Hi, 2011/5/18 Chris Withers &lt;chris&lt; at &gt;simplistix.co.uk&gt;: Normally PEPs are important enough to be mentioned in the \"whatsnew\" document of each release. Googling for \"what's new pep 342\" suggests that it was released with Python 2.5. Now, an \"official\" way to get this information would probably be better... </pre>", "group_id": 8954, "id": 1093428}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305699930.291446, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6ynw49r - anatoly techtonik - <pre>That's great, but where is the list if changes? -- anatoly t. On Tue, May 17, 2011 at 9:50 PM, Georg Brandl &lt;georg&lt; at &gt;python.org&gt; wrote: _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1093504}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305700827.194963, "message": "[devel] - Re: how do you find out what version of Python a PEP landed in? - http://tinyurl.com/6jheksu - Martin v. L\u00f6wis - <pre> You should look at the Python-Version header of the PEP. Regards, Martin </pre>", "group_id": 8954, "id": 1093605}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305700864.3802221, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6eo5odg - Martin v. L\u00f6wis - <pre> Just in case this isn't clear yet: yes, certainly. Any non-trivial piece of Python 3 code that has been written already (and there is some) will have run into that issue. Regards, Martin </pre>", "group_id": 8954, "id": 1093609}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305700829.6180539, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/62pr9yw - Georg Brandl - <pre> We do have bytes.fromhex('deadbeef') Georg </pre>", "group_id": 8954, "id": 1093606}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305701788.192296, "message": "[devel] - Re: how do you find out what version of Python a PEP landed in? - http://tinyurl.com/6df74px - Amaury Forgeot d'Arc - <pre>2011/5/18 \"Martin v. L\u00f6wis\" &lt;martin&lt; at &gt;v.loewis.de&gt;: But some PEPs don't have it: 341, 342, 343, 353... </pre>", "group_id": 8954, "id": 1093726}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305700866.7813921, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/5svj4fx - Martin v. L\u00f6wis - <pre> I think it would be good if the release announcement made some summary statement, though, like \"NNN bugs have been fixed, in MMM modules; see NEWS for details\", or some such. Regards, Martin </pre>", "group_id": 8954, "id": 1093614}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305701791.7425539, "message": "[devel] - Re: how do you find out what version of Python a PEP landed in? - http://tinyurl.com/5uaut5p - Nick Coghlan - <pre> Which is unfortunately missing from some PEPs (including PEP 342). PEP 344 shows where this information *should* be, though. Cheers, Nick. </pre>", "group_id": 8954, "id": 1093728}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305706292.4344449, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6deyeqs - anatoly techtonik - <pre>On Wed, May 18, 2011 at 9:18 AM, Amaury Forgeot d'Arc &lt;amauryfa&lt; at &gt;gmail.com&gt; wrote: I actually followed http://docs.python.org/3.2/whatsnew/3.2.html to Misc/NEWS, but it doesn't contain any references of 3.2.1 -- anatoly t. </pre>", "group_id": 8954, "id": 1094626}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305706289.2514999, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6hp9aap - Georg Brandl - <pre> It does say \"over NNN bugs have been fixed\", not sure if the MMM modules add anything of value. I agree that a link to the NEWS file should be present though. Georg </pre>", "group_id": 8954, "id": 1094624}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305711709.7415731, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/3qqwu98 - anatoly techtonik - <pre> That's a good idea. But for such kind of query Roundup should be module aware [1,2]. I'd say if Jesse could make a competition on best announcement format - we could easily see what information we tend to skip while preparing the releases (and improve NEWS format [3]). [1] http://code.google.com/p/pydotorg/issues/detail?id=8 [2] http://psf.upfronthosting.co.za/roundup/meta/issue373 [3] https://convore.com/the-changelog/the-best-changelog/ -- anatoly t. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1095570}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305716200.881304, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6hb2fpq - anatoly techtonik - <pre> I believe you misunderstood. If you follow what's new link above, you will see a link to Misc/NEWS, but this one leads to http://hg.python.org/cpython/file/default/Misc/NEWS where no references to 3.2.1 are available. There is nothing bad in linking to major release notes (i.e. What's New). IIRC, Mozilla does that for their minor releases, but they explicitly mention changes since last minor release. -- anatoly t. </pre>", "group_id": 8954, "id": 1095993}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305716192.421998, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/5sx3fzy - Nick Coghlan - <pre> What's New and Misc/NEWS are not the same thing. Misc/NEWS is the second info link on the download page (\"Change log for this release\"). (In this case, it lands at http://hg.python.org/releasing/3.2.1/file/v3.2.1rc1/Misc/NEWS) Agreed that What's New isn't a hugely useful thing to link from a point release announcement, though. It sounds like Georg is going to change that for the actual release. Cheers, Nick. </pre>", "group_id": 8954, "id": 1095991}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305716194.7293251, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6eso2sx - Nick Coghlan - <pre> Wishlist item: How hard would it be to run a ReST parser over Misc/NEWS and create a HTML version for inclusion in the release pages? (Bonus points if it steals the issue reference linkification code from the tracker...) Cheers, Nick. </pre>", "group_id": 8954, "id": 1095992}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305717152.2864211, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/3nfky44 - Nick Coghlan - <pre> I quite like that! What would we need to do to make it part of the docs build process? Cheers, Nick. </pre>", "group_id": 8954, "id": 1096052}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305717155.225836, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/3zechoe - Georg Brandl - <pre> This link is wrong, it should point to /cpython/file/3.2/Misc/NEWS. (But you'll still not see 3.2.1 changes until the 3.2.1 final release, because the rc is made from a separate clone.) Georg </pre>", "group_id": 8954, "id": 1096053}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305717149.2026751, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6afrvwd - Georg Brandl - <pre> See http://dev.pocoo.org/~gbrandl/news.html which I made as an experiment a while ago. Georg </pre>", "group_id": 8954, "id": 1096050}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305718950.671196, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/5vpqked - Victor Stinner - <pre>Le mercredi 18 mai 2011 \u00e0 12:58 +0200, Georg Brandl a \u00e9crit : Oh, I like it. But the output should be reST to be able to include it directly in the Python documentation. Sphinx would generate a new table of contents with links to each release. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1096200}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305718048.2641079, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6cd3bg9 - Nick Coghlan - <pre> Ah, I see what you mean. That actually looks to be a bug in the \":source:\" tag that generates the file links. It should really generate version appropriate links, but it currently just always links to \"default\". (This wasn't an issue until 3.2 was released and 3.3 development started. Older versions didn't have that tag, and hence referenced the specific release directly). The source code links in the module docs have the same problem (e.g. see http://docs.python.org/3.2/library/functools) Cheers, Nick. </pre>", "group_id": 8954, "id": 1096154}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305718952.9283991, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/68vqanu - Senthil Kumaran - <pre> Interesting ideas! It would be really useful too. +1 </pre>", "group_id": 8954, "id": 1096201}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305718955.287173, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/66z79z6 - Georg Brandl - <pre> The output of processing reST should be reST? Now I'm confused. Georg </pre>", "group_id": 8954, "id": 1096202}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305720809.085984, "message": "[devel] - Inconsistent case in directory names for installedPython on Windows - http://tinyurl.com/5u7x67f - anatoly techtonik - <pre>Greetings, While studying `virtualenv` code I've noticed that in Python directory tree `include`, `libs` and `tcl` are lowercased while other dirs are capitalized. It doesn't seem important (especially for developers here), but it still can leave an unpleasant image for people new to Python (and programming in general). \u251c[Python27] \u2502 \u251c\u2500DLLs \u2502 \u251c\u2500Doc \u2502 \u251c\u2500include \u2502 \u251c\u2500Lib \u2502 \u251c\u2500libs \u2502 \u251c\u2500Scripts \u2502 \u251c\u2500tcl \u2502 \u2514\u2500Tools How about making a consistent lowercased or uppercased scheme? Windows filesystems are case-insensitive, so the change shouldn't affect anybody. Another candidate for normalization is Tools/Scripts dir, which I'd lowercase FWIW: \u2514\u2500Tools \u251c\u2500i18n \u251c\u2500pynche \u251c\u2500Scripts \u251c\u2500versioncheck \u2514\u2500webchecker Lowercased dirs on a top level seem to contains files that are relevant to C developers only. However, I can not say for sure. It seems that there could be a better place for them like top level directory named Dev or C-API. -- anat</pre>", "group_id": 8954, "id": 1096306}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305720813.152292, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6erqe2d - Victor Stinner - <pre>Le mercredi 18 mai 2011 \u00e0 13:35 +0200, Georg Brandl a \u00e9crit : Misc/NEWS is already formatted to reST? It doesn't contain any link (to the issues). We may replace \"Issue #xxx\" by :issue:`xxx` (directly in Misc/NEWS) to simplify the process? And maybe move Misc/NEWS to Doc? http://dev.pocoo.org/~gbrandl/news.html is an HTML document. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1096307}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305721709.7063041, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6g6vq5c - Georg Brandl - <pre> Yes, it is. Replacing the issue links is the only preprocessing that I did. I don't think people would like that :) As the file name says :) Georg _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1096405}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305721712.711226, "message": "[devel] - Don't set local variable in a list comprehension orgenerator - http://tinyurl.com/6caovjw - Victor Stinner - <pre>Hi, ''.join(c for c in 'abc') and ''.join([c for c in 'abc']) do create a temporary c variable. In this case, the variable is useless and requires two opcodes: STORE_FAST(c), LOAD_FAST(c). The variable is not available outside the list comprehension/generator. I would like to remove the variable in these cases to speed up (micro-optimize!) Python. Remove the variable breaks code using introspection like: list([locals()['x'] for x in range(3)]) We may detect the usage of introspection (I don't know how hard it is), only optimize trivial cases (like \"x for x in ...\"), or only optmize with Python is running in optimize mode (python -O or python -OO). What do you think? Is it useless and/or stupid? I heard about optimization in the AST tree instead of working on the bytecode. What is the status of this project? Victor </pre>", "group_id": 8954, "id": 1096406}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305723512.112932, "message": "[devel] - Re: Inconsistent case in directory names for installed Python on Windows - http://tinyurl.com/67swmu9 - Brian Curtin - <pre> In theory there are probably a lot of things that might seem unpleasant but are actually non-issues. I don't believe there have been any complaints about actual unpleasantries with directory case. Some Macs have case-sensitive file systems, and some people use case-sensitive file systems on various flavors of UNIX. The change would probably require a thorough look through the build chain. Overall I think it boils down to a cosmetic change that I'm not sure we need to make, which could unnecessarily break people's work. -1 </pre>", "group_id": 8954, "id": 1096639}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305727109.344595, "message": "[devel] - Re: Don't set local variable in a list comprehensionor generator - http://tinyurl.com/3v8gh3o - Benjamin Peterson - <pre>2011/5/18 Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt;: Far more useful would be figuring out how to remove the call. </pre>", "group_id": 8954, "id": 1097286}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305728015.0060639, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6dfgl7o - Nick Coghlan - <pre>On Wed, May 18, 2011 at 9:26 PM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: As Georg noted, Misc/NEWS is already ReST. My proposal was essentially to add an extra step to the docs build process that invoked the same commands that Georg used to generate the sample version (with appropriate additions to Doc/tools as needed to make that work). The generated NEWS.html file could easily live inside the whatsnew directory alongside the actual What's New document. Cheers, Nick. </pre>", "group_id": 8954, "id": 1097472}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305728911.6232691, "message": "[devel] - 2.7.2 and 3.1.4 - http://tinyurl.com/5u3k5sb - Benjamin Peterson - <pre>It's time to continue 2.7.* point releases with 2.7.2 and finish off 3.1.* with 3.1.4. I plan to do a RC for both on May 28th and a final on June 11th. </pre>", "group_id": 8954, "id": 1097687}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305728914.6268139, "message": "[devel] - Re: Don't set local variable in a list comprehensionor generator - http://tinyurl.com/3vnxsyg - Nick Coghlan - <pre>On Wed, May 18, 2011 at 10:21 PM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: I wouldn't call it useless or stupid - merely \"lost in the noise\". In small cases, I expect it would be swamped completely by the high fixed overhead of entering the new scope and in all generator expressions I expected it would be swamped by the cost of resuming the generator on each iteration, and even for comprehensions any time spent on the unneeded variable assignment is likely still going to be dominated by the __next__() call overhead. First step is getting back to Eugene Toder's AST cleanup patch and working on getting that in. It's a big patch though, and I'd like to see it broken up into a couple of distinct phases before we proceed. Cheers, Nick. </pre>", "group_id": 8954, "id": 1097688}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305728919.7624619, "message": "[devel] - Re: Don't set local variable in a list comprehensionor generator - http://tinyurl.com/3v8swwx - Nadeem Vawda - <pre>On Wed, May 18, 2011 at 2:21 PM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: I'm not sure why you would encounter code like that in the first place. Surely any code of the form: ''.join(c for c in my_string) would just return my_string? Or am I missing something? Are you referring to issue11549? There was some related discussion [1] on python-dev about six weeks ago, but I haven't seen anything on the topic since then. Cheers, Nadeem [1] http://mail.python.org/pipermail/python-dev/2011-April/110399.html </pre>", "group_id": 8954, "id": 1097691}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305731609.43801, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3bodspu - Bill Janssen - <pre> Sort of reminds me of Java's Integer.parseInt(), and not in a good way. Bill </pre>", "group_id": 8954, "id": 1098674}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305735211.534539, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/5vkrzje - Stephen J. Turnbull - <pre> &gt; Its probably too late to change, but please don't try to argue that &gt; its correct: the continued confusion of folk running into this is &gt; evidence that confusion *is happening*. Treat that as evidence and &gt; think about how to fix it going forward. Sorry, Rob, but you're just wrong here, and Nick is right. It's possible to improve Python 3, but not to \"fix\" it in this respect. The Python 3 solution is correct, the Python 2 approach is not. There's no way to avoid discontinuity and confusion here. Confusion is indeed happening, but it's real confusion in the way people think about the problem space, not a language design cockup. The problem can't be solved by embedding ASCII in Unicode, because non-ASCII bytes don't have a canonical embedding in Unicode. Ie, the situation is inherently confusing. You can't wish it away, you can only choose to impose more or less of it on particular constituencies. Now, it's quite possible that there are other correct approaches that allow straightforward manipulat</pre>", "group_id": 8954, "id": 1099738}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305734311.3776979, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6xh4fws - Ethan Furman - <pre> That is the point I was trying to make -- thank you for stating it more clearly than I managed to. :) Agreed. It is surprising to extract an element out of bytes, and not end up with bytes, but with an int -- if the repr used something besides the plain ascii representation, this would not be an expectation. For comparison, when one extracts an element out of a str one gets a str -- not the int representing the unicode code point. Given that we can't change the behavior of b'abc'[1], that would be better than what we have. +1 ~Ethan~ </pre>", "group_id": 8954, "id": 1099457}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305737912.624155, "message": "[devel] - Re: [Python-checkins] cpython: Skip some more tests in the absence of threading. - http://tinyurl.com/63vegp7 - \u00c9ric Araujo - <pre>Hi, I guess \u201cfor tests which use threading\u201d I wonder if you could have saved yourself all this reindenting if your import had fallen back to dummy_threading. I\u2019d have used lower-case threading, to make it a bit clearer that it\u2019s the threading module that\u2019s require, not some abstract notion of threading. But they may be the same thing, I\u2019m not sure. Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1100211}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305737917.0240569, "message": "[devel] - Re: [Python-checkins] cpython: Skip some tests in the absence of multiprocessing. - http://tinyurl.com/6x4t6ru - \u00c9ric Araujo - <pre>Hi again, Who wins, the commit message or the code? :) Isn\u2019t support.import_module or somesuch useful for this kind of checks? Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1100213}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305738810.7239561, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/69f9dhy - R. David Murray - <pre> Note that the more common idiom (not that I can measure it, mind) when dealing with byte strings is something analogous to if my_byte_string[i:i+1] == b'x': rather than if my_byte_string[i] == 170: and the former is a lot more readable than the latter, even though you have to stare at the slice for a couple seconds the first time you encounter it to realize what is going on. So *something* is wrong with Python3's approach. Python2 was wronger, though :) --David </pre>", "group_id": 8954, "id": 1100405}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305741573.1344061, "message": "[devel] - Re: \"packaging\" merge imminent - http://tinyurl.com/6b5genr - \u00c9ric Araujo - <pre>Le 17/05/2011 18:42, Christian Heimes a \u00e9crit : I don\u2019t think so. See http://bugs.python.org/issue7175 and http://mail.python.org/pipermail/python-dev/2010-August/103011.html Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1100749}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305741581.412179, "message": "[devel] - Re: \"packaging\" merge imminent - http://tinyurl.com/6ze3o4y - \u00c9ric Araujo - <pre> I ported some fixes, especially in sysconfig; for distutils, I have a number of them marked for backport in the bug tracker (distutils2 component) or in personal bookmarks. There are not very many. Cheers </pre>", "group_id": 8954, "id": 1100751}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305745170.7760141, "message": "[devel] - Equality testing - http://tinyurl.com/6jldo4f - Ethan Furman - <pre>In Python 3 inequality comparisons became forbidden. --&gt; 123 &lt; [1, 2, 3] Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt; TypeError: unorderable types: int() &lt; list() However, equality comparisons are still allowed --&gt; 123 == [1, 2, 3] False But you can't mix them (inequality wins) --&gt; 123 &lt;= [1, 2, 3] Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt; TypeError: unorderable types: int() &lt;= list() I realize this is probably a Py4000 change if it happens at all, but does this make sense? Shouldn't an attempt to compare to unlike objects be a TypeError, just like trying to order them is? It bit me when I tried to compare a byte string element with a single character byte string (of course they should have matched, but since the element was an int, the match was not longer True). ~Ethan~ </pre>", "group_id": 8954, "id": 1101519}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305747871.524909, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/62gnvyn - Martin v. L\u00f6wis - <pre>Am 18.05.2011 20:39, schrieb Hagen F\u00fcrstenau: http://hg.python.org/releasing/3.2.1/ Regards, Martin P.S. \"Shouldn't\" makes it sound as if there was a mistake. </pre>", "group_id": 8954, "id": 1102364}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305746075.017473, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/43sjx3d - Hagen F\u00fcrstenau - <pre> Shouldn't there be a tag \"v3.2.1rc1\" in the hg repo? Cheers, Hagen </pre>", "group_id": 8954, "id": 1101847}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305746971.1964059, "message": "[devel] - Re: how do you find out what version of Python a PEP landed in? - http://tinyurl.com/5t986rz - Martin v. L\u00f6wis - <pre>Am 18.05.2011 08:38, schrieb Amaury Forgeot d'Arc: In these cases, the respective authors (or somebody else who cares) should add it. Regards, Martin </pre>", "group_id": 8954, "id": 1102114}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305746974.4416311, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/64vnusc - Martin v. L\u00f6wis - <pre> FWIW, Another spelling of this is if my_byte_string[i] == ord(b'x') but less twisted. Regards, Martin </pre>", "group_id": 8954, "id": 1102115}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305748783.5041029, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6jbu8p3 - Georg Brandl - <pre> To clarify: once the final is done, the repo Martin mentioned will be merged back to main and then vanish. Georg </pre>", "group_id": 8954, "id": 1102516}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305748781.179564, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/63mtas4 - Hagen F\u00fcrstenau - <pre> Well, I thought there was. When do these tags get merged into \"cpython\" then? \"v3.2.1b1\" is there, but \"v3.2.1rc1\" isn't: http://hg.python.org/cpython/tags Cheers, Hagen </pre>", "group_id": 8954, "id": 1102514}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305748770.6907699, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3ezqagf - Eric Smith - <pre> I don't think there's any connection between the way 2.x confused text strings and binary data (which certainly needed addressing) with the way that 3.x returns a different type for byte_str[i] than it does for byte_str[i:i+1]. I think it's the latter that's confusing to people. There's no particular requirement for different types that's needed to fix the byte/str problem. And of course it's too late to make any change to this. Eric. </pre>", "group_id": 8954, "id": 1102510}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305748774.243058, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/67ujfru - Ethan Furman - <pre> Here's another thought, that perhaps is not backwards-incompatible... some_var[3] == b'd' At some point, the bytes class' __eq__ will be called -- is there a reason why we cannot have 1) a check to see if the bytes instance is length 1 2) a check to see if i) the other object is an int, and 2) 0 &lt;= other_obj &lt; 256 3) if 1 and 2, make the comparison instead of returning NotImplemented? This makes sense to me -- after all, the bytes class is an array of ints in range(256); it is a special case, but doesn't feel any more special than passing an int into bytes() giving a string of that many null bytes; and it would get rid of the, in my opinion ugly, idiom of some_var[i:i+1] == b'd' It would also not require a new literal syntax. ~Ethan~ </pre>", "group_id": 8954, "id": 1102511}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305748777.5419779, "message": "[devel] - Re: Equality testing - http://tinyurl.com/5w9t3j5 - Benjamin Peterson - <pre>2011/5/18 Ethan Furman &lt;ethan&lt; at &gt;stoneleaf.us&gt;: No. Ordering for types which completely different doesn't make any sense, but equality testing is just fine because it has an obvious answer: no. </pre>", "group_id": 8954, "id": 1102513}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305749670.1414521, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6dqlktj - Georg Brandl - <pre> Probably more twisted: if my_byte_string[i] == b'x'[0]: :) Georg </pre>", "group_id": 8954, "id": 1102624}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305750570.8300929, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/66bzou7 - Ethan Furman - <pre> [...] Also posted to Python-Ideas. ~Ethan~ </pre>", "group_id": 8954, "id": 1102808}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305750573.676352, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6fyyfvy - Martin v. L\u00f6wis - <pre>Am 18.05.2011 21:37, schrieb Hagen F\u00fcrstenau: See PEP 101 Regards, Martin </pre>", "group_id": 8954, "id": 1102809}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305751474.692838, "message": "[devel] - Re: how do you find out what version of Python a PEPlanded in? - http://tinyurl.com/3fvkyr5 - Laura Creighton - <pre>Politely ask them to add it. (just my suggrestion). Laura </pre>", "group_id": 8954, "id": 1103014}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305751471.869235, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3z8lcfp - Martin v. L\u00f6wis - <pre> Immutable objects that compare equal should hash equal; so we would also have to change the hashing of byte strings. Not sure whether that, in turn, has undesirable consequences. In addition, equality should be transitive, so b'A' == 65.0. Regards, Martin </pre>", "group_id": 8954, "id": 1103013}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305753270.88485, "message": "[devel] - Re: Equality testing - http://tinyurl.com/3pfdbap - Terry Reedy - <pre> Questions/comments like this that are not about developing the next versions of Python, as you acknowledge above, really belong elsewhere, like on the ideas list. </pre>", "group_id": 8954, "id": 1103338}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305752372.8915379, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3nt4skr - Ethan Furman - <pre> I thought it was the other-way-round -- if they hash equal, they should compare equal? Or is this just for immutables? I'm not sure what you're getting at... we could certainly have step 2 check for a number instead of an int, and then step 3 could extract the one element, giving an int, and then let that int compare itself with the other number, whether it be int, float, fraction, what-have-you. ~Ethan~ </pre>", "group_id": 8954, "id": 1103215}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305752376.2872069, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3appofx - Terry Reedy - <pre> Good. That is where it should have gone in the first place, as this is about ideas not yet even in the PEP stage. </pre>", "group_id": 8954, "id": 1103217}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305754170.5775101, "message": "[devel] - Re: Don't set local variable in a list comprehensionor generator - http://tinyurl.com/42ygt3f - Terry Reedy - <pre> Good question. Anything useful like \"'-'.join(c for c in 'abc')\" is the same as \"'-'.join('abc'). The same, as far as I can think of, for anything like list() or set() taking an iterable arg. </pre>", "group_id": 8954, "id": 1103463}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305755971.1366119, "message": "[devel] - Re: Don't set local variable in a list comprehensionor generator - http://tinyurl.com/3uehlkt - Amaury Forgeot d'Arc - <pre>Hi, 2011/5/18 Terry Reedy &lt;tjreedy&lt; at &gt;udel.edu&gt;: With a little imagination you can build something non trivial. For example, a join_words function: def join_words(words): return ', '.join(w.strip() for w in words) Like Victor says, the code of the generator object contains a STORE_FAST followed by LOAD_FAST. This pair of opcodes could be removed, and the value left on the stack. 1 0 SETUP_LOOP 24 (to 27) 3 LOAD_FAST 0 (.0) &gt;&gt; 6 FOR_ITER 17 (to 26) 9 STORE_FAST 1 (w) 12 LOAD_FAST 1 (w) 15 LOAD_ATTR 0 (strip) 18 CALL_FUNCTION 0 21 YIELD_VALUE 22 POP_TOP 23 JUMP_ABSOLUTE 6 &gt;&gt; 26 POP_BLOCK &gt;&gt; 27 LOAD_CONST 0 (None) 30 RETURN_VALUE It's probably not easy to do though. Think of expressions where the variable appears several tim</pre>", "group_id": 8954, "id": 1103725}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305755072.210794, "message": "[devel] - Re: Equality testing - http://tinyurl.com/44twka3 - Ethan Furman - <pre> My apologies. I'll be more careful. ~Ethan~ </pre>", "group_id": 8954, "id": 1103577}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305756931.834111, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3qdees4 - Martin v. L\u00f6wis - <pre> No no no. If they hash equal, it could just be a hash collision - objects of a class could all hash to 42, if they wanted to. Dictionaries require the property I mentioned. If they compare equal, but hash differently, a dictionary lookup would fail to find the key. That it is counter-intuitive to have a bytes object compare equal to a floating-point number. Regards, Martin </pre>", "group_id": 8954, "id": 1103861}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305755076.2890921, "message": "[devel] - Re: Don't set local variable in a list comprehension or generator - http://tinyurl.com/3d6pb75 - Victor Stinner - <pre>Le mercredi 18 mai 2011 \u00e0 16:19 +0200, Nadeem Vawda a \u00e9crit : Well, I found the STORE_FAST/LOAD_FAST \"issue\" while trying to optimize the this module which reimplements rot13 using a dict in Python 3: d = {} for c in (65, 97): for i in range(26): d[chr(i+c)] = chr((i+13) % 26 + c) I tried: d = {chr(i+c): chr((i+13) % 26 + c) for i in range(26) for c in (65, 97)} But it is slower whereas I read somewhere than generators are faster than loops. By the way, (c for c in ...) is slower than [c for c in ...]. I suppose that a generator is slower because it exits/reenter into PyEval_EvalFrameEx() at each step, whereas [c for c ...] uses BUILD_LIST in a dummy (but fast) loop. (c for c in ...) and [c for c in ...] is stupid, but I used a simplified example to explain the problem. A more realistic example would be: squares = (x*x for x in range(10000)) You don't really need the \"x\" variable, you just want the square. Another example is the syntax using a if the filter the data set: </pre>", "group_id": 8954, "id": 1103578}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305756935.9945569, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3ohhw9x - Greg Ewing - <pre> But again, there is a run-time overhead to this. </pre>", "group_id": 8954, "id": 1103863}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305759630.2050641, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6e2ukm8 - Greg Ewing - <pre> It might seem convenient, but I'd worry that it would lead to even more confusion in other ways. If someone sees that some_var[3] == b'd' is true, and that some_var[3] == 100 is also true, they might expect to be able to do things like n = b'd' + 1 and get 101... or maybe b'e'... </pre>", "group_id": 8954, "id": 1104321}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305758731.4777291, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/44z4fdc - Greg Ewing - <pre> It's too late to change the meaning of b'...', but is it really too late to introduce an x'...' literal and change the repr() to produce it? </pre>", "group_id": 8954, "id": 1104126}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305759632.62216, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6ybyqur - Eric Smith - <pre> My \"this\" was the different types returned by b[i] and b[i:i+1]. Eric. </pre>", "group_id": 8954, "id": 1104322}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305759635.0066259, "message": "[devel] - Re: Don't set local variable in a list comprehension or generator - http://tinyurl.com/6fgzpj3 - Greg Ewing - <pre> What bytecode would you optimise that into? </pre>", "group_id": 8954, "id": 1104324}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305762391.679117, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/65owff5 - Robert Collins - <pre> The top level description: 'bytes is a different type to text[unicode] and casting between them must be explicit' is completely correct in Python 3: I didn't (and have never AFAIK) quibbled about that. Thats separate to the implementation issues I have mentioned in this thread and previous. Arguing that implicit casting is a good idea isn't what I was doing, nor what Nick was rebutting, AFAICT. -Rob </pre>", "group_id": 8954, "id": 1104721}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305769652.5741739, "message": "[devel] - Re: Don't set local variable in a list comprehensionor generator - http://tinyurl.com/65w47jt - Terry Reedy - <pre> You initial example gave me the impression that the issue has something to do with join in particular, or even comprehensions in particular. It is really about for loops. &gt;&gt;&gt; dis('for x in range(3): y = x*x') 1 0 SETUP_LOOP 30 (to 33) 3 LOAD_NAME 0 (range) 6 LOAD_CONST 0 (3) 9 CALL_FUNCTION 1 12 GET_ITER &gt;&gt; 13 FOR_ITER 16 (to 32) 16 STORE_NAME 1 (x) 19 LOAD_NAME 1 (x) 22 LOAD_NAME 1 (x) 25 BINARY_MULTIPLY 26 STORE_NAME 2 (y) 29 JUMP_ABSOLUTE 13 &gt;&gt; 32 POP_BLOCK &gt;&gt; 33 LOAD_CONST 1 (None) 36 RETURN_VALUE It is nothing new that hand-crafted assembler (which mnemonic bytecode is) can sometimes beat a compiler. In this case, you want store, load, load before</pre>", "group_id": 8954, "id": 1105782}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305770611.9562221, "message": "[devel] - Re: Don't set local variable in a list comprehensionor generator - http://tinyurl.com/6c2hxgh - Terry Reedy - <pre> As I pointed out in response to Victor, you get nearly the same with bytecode with regular old for loops; in particular, the store x/load x pair. Where first means first in left-to-right order rather than in innermost to outermost order. (OT: I think Python is a bit unusual in this way.) </pre>", "group_id": 8954, "id": 1105970}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305773314.471343, "message": "[devel] - Re: Inconsistent case in directory names for installed Python on Windows - http://tinyurl.com/5ujfyr5 - anatoly techtonik - <pre> Among web folks there are no people who care less about typography than those who spend most of their time in text terminals. =) I think that probability of receiving such complaint is very low even if everybody notices that. \"Why should I bother about consistency if Python developers are not giving damn about it?\" But we are speaking only about Windows. That's right - I started that without cosmetic changes the project becomes ugly and start to accumulate a lot of garbage. With due attention to improving an image of Python from perspective of project layout organization, this change could be made in Python 3. It is something to keep in mind for the future. </pre>", "group_id": 8954, "id": 1106708}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305774217.1562531, "message": "[devel] - Re: Inconsistent case in directory names for installed Python on Windows - http://tinyurl.com/6byxug6 - Brian Curtin - <pre> Definitely -1 to change the folder names only on Windows. </pre>", "group_id": 8954, "id": 1106902}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305774214.586832, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6cpggm5 - anatoly techtonik - <pre> Can't this work be done in the branch of main repo, so that everybody can track the progress in place? Is there any picture of the process similar to http://nvie.com/posts/a-successful-git-branching-model/ ? -- anatoly t. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1106900}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305776015.6551991, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/65apc39 - Terry Reedy - <pre> As I understand it, this is a snapshot that George hopes will require No work between the candidate and final release and which will get only the minimum needed. </pre>", "group_id": 8954, "id": 1107209}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305776011.9829171, "message": "[devel] - Re: Inconsistent case in directory names for installed Python on Windows - http://tinyurl.com/62kxpqn - Terry Reedy - <pre> Except for DLLs and tcl, these are the platform-independent names in the source tree. They are copied directly over to the installations, and I would not want it any way. Since I suspect change on *nix is out, I would feel the same for winX. I actually like having 'Lib' uppercase versus 'libs' lowercase, to make it easier to pick out 'Lib'. Most users have little reason to look as this directory list very often. Certainly, Doc, Lib, Scripts, and Tools are ones they might want to look in, which include, libs, and tcl have nothing to look at. Notice the pattern? Hmmm. By the same logic, DLLs should have been dlls, but I suspect someone wanted to distinguish the plural s from dll. </pre>", "group_id": 8954, "id": 1107205}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305777812.4483709, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/62t3wuw - Martin v. L\u00f6wis - <pre> It *is* a branch of the main repo, so everybody *can* track the progress (not sure what \"track in place\" means). If you are asking for a named branch: no, that shouldn't be done. Regards, Martin </pre>", "group_id": 8954, "id": 1107500}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305783274.8836191, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/425nn2b - Georg Brandl - <pre> Maybe they should :) Georg </pre>", "group_id": 8954, "id": 1108493}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305784175.2800729, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/3c5fa8h - Georg Brandl - <pre> 3.2.1b1 was already merged back. (And 3.2.1rc1 will also be merged back soon, since there will be a 3.2.1rc2.) Georg </pre>", "group_id": 8954, "id": 1108610}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305785972.9186089, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/68ht2fp - Stefan Behnel - <pre>Greg Ewing, 19.05.2011 00:02: Well, yes, but it's negligible if you assign it to a suitable variable first. Stefan </pre>", "group_id": 8954, "id": 1108841}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305788734.1153109, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/66ahe2f - Hagen F\u00fcrstenau - <pre> Thanks for the clarification! :-) Cheers, Hagen </pre>", "group_id": 8954, "id": 1109056}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305791435.297328, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/633t6ov - Xavier Morel - <pre> But why wouldn't \"they\" expect `b'de' + 1` to work as well in this case? If a 1-byte bytes is equivalent to an integer, why not an arbitrary one as well? </pre>", "group_id": 8954, "id": 1109266}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305792335.5809619, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6e9utnn - Nick Coghlan - <pre> It's a mental model problem. People try to think of bytes as equivalent to 2.x str and that's just wrong, wrong, wrong. It's far closer to array.array('c'). Strings are basically *unique* in returning a length 1 instance of themselves for indexing operations. For every other sequence type, including tuples, lists and arrays, slicing returns a new instance of the same type, while indexing will typically return something different. Now, we definitely didn't *help* matters by keeping so many of the default behaviours of bytes() and bytearray() coupled to ASCII-encoded text, but that was a matter of practicality beating purity: there really *are* a lot of wire protocols out there that are ASCII based. In hindsight, perhaps we should have gone further in breaking things to try to make the point about the mental model shift more forcefully. (However, that idea carries with it its own problems). Cheers, Nick. </pre>", "group_id": 8954, "id": 1109340}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305792340.680289, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3oq83as - Stephen J. Turnbull - <pre> &gt; Thats separate to the implementation issues I have mentioned in this &gt; thread and previous. Oops, sorry. Nevertheless, I personally think that b'a'[0] == 97 is a good idea, and consistent with everything else in Python. It's Unicode (str) that is weird, it's str is surprising when first encountered by a C or Lisp programmer at first, but not enough to cause a heart attack given how weird natural language is. But I don't see why that weirdness (an element of LIST of TYPE is a LIST of TYPE, hey, young man, you're very smart but *it's turtles all the way down!*) should be replicated elsewhere. If you want your bytes object to behave like a str, it's very easy to get that (.decode('latin1')), and nobody has yet demonstrated that this is too time-inefficient for real work, given the other overhead imposed by Python. The space inefficiency could be dealt with as Greg points out (by internally having a Unicode representation using 1 byte instead of 2 or 4). But if you want your bytes object to *be* a st</pre>", "group_id": 8954, "id": 1109342}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305793233.958868, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/5subuq4 - Xavier Morel - <pre> For what it's worth, Erlang's approach to the subject is \u2014 in my opinion \u2014 excellent: binaries (whose literals are called \"bit syntax\" there) are quite distinct from strings in both syntax and API, but you can put chunks of strings within binaries (the bit syntax acts as a container, in which you can put a literal or non-literal string). This simultaneously impresses upon the user that binaries are *not* strings and that they can still easily create binaries from strings. </pre>", "group_id": 8954, "id": 1109430}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305795936.0414181, "message": "[devel] - Re: [Python-checkins] cpython: Skip some tests in the absence of multiprocessing. - http://tinyurl.com/4yz7x26 - Nick Coghlan - <pre> You have to restructure your tests into the appropriate files for that to work, as support.import_module() throws SkipTest if the module isn't available. Cheers, Nick. </pre>", "group_id": 8954, "id": 1109709}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305795034.354666, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6jhv6ad - Stefan Behnel - <pre>Xavier Morel, 19.05.2011 09:41: The result of this must obviously be b\"de1\". Stefan </pre>", "group_id": 8954, "id": 1109616}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305795037.362469, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3tkpexb - Nick Coghlan - <pre>OK, summarising the thread so far from my point of view. 1. There are some aspects of the behavior of bytes() objects that tempt people to think of them as string-like objects (primarily the b'' literals and their use in repr(), along with the fact that they fill roles that were filled by str in it's \"arbitrary binary data\" incarnation in Python 2.x). The mental model this creates in the reader is incorrect, as bytes() are far closer to array.array('c') in their underlying behaviour (and deliberately so - cf. PEP 358, 3112, 3137). One proposal for addressing this is to add a x'deadbeef' literal and using that in repr() rather than the bytestring. Another would be to escape all characters, even printable ASCII, in the bytes() representation. Both of these are undesirable, as they miss the original purpose of this behaviour: making it easier to work with the many ASCII based wire protocols that are in widespread use. To be honest, I don't think there is a lot we can do here except to further emphasise in th</pre>", "group_id": 8954, "id": 1109617}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305795940.280216, "message": "[devel] - Re: Don't set local variable in a list comprehensionor generator - http://tinyurl.com/3d7d5r2 - Nick Coghlan - <pre>On Thu, May 19, 2011 at 7:34 AM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: Are you sure it wasn't that generator expressions can be faster than list comprehensions (if the memory savings are significant)? Or that a reduction function with a generator expression can be faster than a module-level explicit loop (due to the replacement of dict-based variable assignment with fast locals in the generator and C looping in the reduction function)? In general, as long as both are using fast locals and looping in Python, I would expect inline looping code to be faster than the equivalent generator (but often harder to maintain due to lack of reusability). Cheers, Nick. </pre>", "group_id": 8954, "id": 1109710}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305799533.962503, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6h33ap6 - \u0141ukasz Langa - <pre>Wiadomo\u015b\u0107 napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37: I hope you're joking. At best, the result should be b\"de\\x01\". But I don't think such construct should be allowed. Just like you can't do `[1, 2, 3] + 4`. I wouldn't ever expect that a single byte behaves like a sequence of bytes. In the case of bytes b'a' is obviously still a sequence of bytes, just happening to store a single one. Indexing should return a byte so I'm not surprised it returns a number. Slicing on the other hand returns a sub-sequence. However inconvenient, I find the current behaviour logical and predictable. A shortcut for b'a'[0] would obviously be nice but that's for python-ideas. </pre>", "group_id": 8954, "id": 1110084}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305800436.0653999, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/69ppvrb - Stefan Behnel - <pre>\u0141ukasz Langa, 19.05.2011 11:25: I \"obviously\" was. My point is that expectations and \"obvious behaviour\" may not be obvious to everyone. Nick summed it up very nicely IMHO. Stefan _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1110123}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305800440.7824881, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6yr6yzb - Xavier Morel - <pre> Actually, if `b'd'+1` returns `b'e'` an equivalent behavior should be that `b'de'+1` returns `b'df'`. </pre>", "group_id": 8954, "id": 1110124}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305802235.5987549, "message": "[devel] - Re: Don't set local variable in a list comprehension or generator - http://tinyurl.com/662r9e6 - Victor Stinner - <pre>Le jeudi 19 mai 2011 \u00e0 10:47 +1200, Greg Ewing a \u00e9crit : I suppose that you have the current value of range(10000) on the stack: DUP_TOP; BINARY_MULTIPLY; gives you the square. You don't need the x variable (LOAD_FAST/STORE_FAST). Full example using a function (instead of loop, so I need to load x): ----------- import dis, opcode, struct def f(x): return x*x def patch_bytecode(f, bytecode): fcode = f.__code__ code_type = type(f.__code__) new_code = code_type( fcode.co_argcount, fcode.co_kwonlyargcount, fcode.co_nlocals, fcode.co_stacksize, fcode.co_flags, bytecode, fcode.co_consts, fcode.co_names, fcode.co_varnames, fcode.co_filename, fcode.co_name, fcode.co_firstlineno, fcode.co_lnotab, ) f.__code__ = new_code print(\"Original:\") print(\"f(4) = %s\" % f(4)) dis.dis(f) print() LOAD_FAST = opcode.opmap['LOAD_FAST'] DUP_TOP = opcode.opmap['DUP_TOP'] BINARY_MULTIPLY = opcode.opmap['BI</pre>", "group_id": 8954, "id": 1110227}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305802238.2333319, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6455f3x - Antoine Pitrou - <pre>On Thu, 19 May 2011 17:49:47 +1000 Nick Coghlan &lt;ncoghlan&lt; at &gt;gmail.com&gt; wrote: I think \"practicality beating purity\" should have been extended to __getitem__ as well. I have almost never had a use for treating a bytestring as a sequence of integers, while treating a bytestring as a sequence of one-byte strings is *very* common. (and, as you say, if you want a sequence of integers you can already use array.array() which gives you more flexibility as to the width and signedness of integers) Regards Antoine. </pre>", "group_id": 8954, "id": 1110228}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305802242.0794461, "message": "[devel] - Re: Don't set local variable in a list comprehension or generator - http://tinyurl.com/6hwddxl - Victor Stinner - <pre>Le mercredi 18 mai 2011 \u00e0 21:44 -0400, Terry Reedy a \u00e9crit : Yeah, \"STORE_NAME; LOAD_NAME; LOAD_NAME\" can be replaced by a single opcode: DUP_TOP. But the user expects x to be defined outside the loop: ... 2 Well, it is possible to detect if x is used or not after the loop, but it is a little more complex to optimize than list comprehension/generator :-) Yes, I would like to write a smarter optimizer. But I first asked if it would accepted to avoid the temporary loop variable because it changes the Python language: the user can expect a loop variable using introspection or a debugger. That's why I suggested to only enable the optimization if Python is running in optimized mode (python -O or python -OO). Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1110229}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305803137.017926, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/69gxnrl - Nick Coghlan - <pre> On further reflection, the key collision and semantics blurring problems mean I am at best -0 on this particular solution to the problem (and heading fairly rapidly in the direction of -1). Best to just go with b'a'[0] and let the optimiser sort it out (PyPy should handle it automatically, CPython would need work). Cheers, Nick. </pre>", "group_id": 8954, "id": 1110274}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305804934.6963899, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3g2vrsr - Michael Foord - <pre>The behaviour Stefan suggests is what some \"weakly typed\" languages like perl (and possibly php?) do, which masks errors and is rightly abhorred by Python programmers (although semantically not *so* different from 1 + 1.0 == 2.0). I think it's safe to say that Stefan was joking. Michael </pre>", "group_id": 8954, "id": 1110470}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305805836.866034, "message": "[devel] - packaging landed in stdlib - http://tinyurl.com/6dtvjt7 - Tarek Ziad\u00e9 - <pre>Hey I've pushed packaging in stdlib. There are a few buildbots errors we're fixing right now. We will continue our work in their directly for now on. The next \"big\" commit will be for the documentation, Cheers Tarek </pre>", "group_id": 8954, "id": 1110540}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305807696.4069519, "message": "[devel] - Re: Don't set local variable in a list comprehension or generator - http://tinyurl.com/6bdby9j - Greg Ewing - <pre> That seems far too special-purpose to be worth it to me. </pre>", "group_id": 8954, "id": 1110704}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305811298.2769279, "message": "[devel] - looking for a contact at Google on the Blogger team - http://tinyurl.com/6ek5jbr - Doug Hellmann - <pre>Several of the PSF blogs hosted on Google's Blogger platform are experiencing issues as fallout from the recent maintenance problems they had. We have already had to recreate at least one of the translations for Python Insider in order to be able to publish to it, and now we can't edit posts on Python Insider itself. Can anyone put me in contact with someone at Google from the Blogger team? I would at least like to know whether the \"bX-qpvq7q\" problem is being worked on, so I can decide whether to take a hiatus or start moving us to another platform. There are a lot of posts about the error on the support forums, but no obvious response from Google. Thanks, Doug -- Doug Hellmann Communications Director Python Software Foundation http://python.org/psf/ </pre>", "group_id": 8954, "id": 1111023}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305825758.1786389, "message": "[devel] - Re: [RELEASED] Python 3.2.1 rc 1 - http://tinyurl.com/6xw4wgc - Tres Seaver - <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/18/2011 10:46 PM, anatoly techtonik wrote: Note that in that writeup, 'release-*' (and 'hotfix-*') branches are not shown as pushed to the 'origin' repository. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver&lt; at &gt;palladion.com Palladion Software \"Excellence by Design\" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3VTeAACgkQ+gerLs4ltQ42kgCeMbIDH6zRU5uyd0Su28Nb9E5q WAMAniWnrvzRReDa+b3mYtavbyaywGVJ =Dr2p -----END PGP SIGNATURE----- </pre>", "group_id": 8954, "id": 1113986}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305825761.8539331, "message": "[devel] - Re: packaging landed in stdlib - http://tinyurl.com/5s9n6wv - Tarek Ziad\u00e9 - <pre> FYI. there are still some failures we're fixing. Thanks for your patience and thanks to the folks that are helping me on this :) I expect the bbots to be back on track later today Cheers Tarek </pre>", "group_id": 8954, "id": 1113987}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305827559.610292, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/69clu4k - Guido van Rossum - <pre> I think most of this \"wrong mental model\" is actually due to people not having completely internalized the Python 3 way. Indeed, -1 on both. +1 -1; the result is not a *character* but an integer. I'm personally favoring using b'a'[0] and possibly hiding this in a constant definition. I'm not convinced that that problem is any worse than other comparison-related problems. E.g. b'a' == 'a' also always returns False (most likely it'll be disguised by at least one operand being a variable of course.) My gut feeling about this is that this will probably introduce some confusing or unintended side effect elsewhere, and I am -1 on this change. </pre>", "group_id": 8954, "id": 1114276}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305828458.714236, "message": "[devel] - Re: Don't set local variable in a list comprehensionor generator - http://tinyurl.com/3ddvevt - Guido van Rossum - <pre>On Wed, May 18, 2011 at 2:34 PM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: I'm curious where you read that. The explicit loop should be faster or equally fast *except* when you can avoid a loop in bytecode by applying map() to a built-in function. However map() with a lambda is significantly slower. Maybe what you recall actually (correctly) said that a comprehension is faster than map+lambda? Did you test this in Python 2 or 3? In 2 the genexpr is definitely slower than the comprehension; in 3 I'm not sure there's much difference any more. Hm, probably. </pre>", "group_id": 8954, "id": 1114370}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305827556.5528669, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/69job5s - Ethan Furman - <pre> [snip] I think this would be a big help. [snip] Nick Coghlan also wrote: &gt; On further reflection, the key collision and semantics blurring &gt; problems mean I am at best -0 on this particular solution to the &gt; problem (and heading fairly rapidly in the direction of -1). Last thought I have for a possible 'solution' -- when a bytes object is tested for equality against an int raise TypeError. Precedent being sum() raising a TypeError when passed a list of strings because performance is so poor. Reason here being that the intuitive behavior will never work and will always produce silent bugs. ~Ethan~ </pre>", "group_id": 8954, "id": 1114275}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305827562.2425439, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6fp3agr - Guido van Rossum - <pre> Not the same thing at all. The == operator is special, and should not raise exceptions; too many things would start randomly failing (e.g. membership tests for a dict that has both ints and bytes as keys, or for a list containing a variety of types). </pre>", "group_id": 8954, "id": 1114278}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305830317.8621149, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6he75h4 - Glyph Lefkowitz - <pre> On May 19, 2011, at 1:43 PM, Guido van Rossum wrote: Well, really the result ought to be an octet, but I suppose adding an 'octet' type is beyond the scope of even this sprawling discussion :). As someone who spends a frankly unfortunate amount of time handling protocols where things like this are necessary, I agree with this recommendation. In protocols where one needs to compare network data with one-byte type identifiers or packet prefixes, more (documented) constants and less inscrutable junk like if p == 'c': ... elif p == 'j': ... elif p == 'J': # for compatibility ... would definitely be a good thing. Of course, I realize that this sort of programmer will most likely replace those constants with 99, 106, 74 than take a moment to document what they mean, but at least they'll have to pause for a moment and realize that they have now lost _all_ mnemonics... In fact, I feel like I would want to push in the opposite direction: don't treat one-byte bytes slices less like integers; I wish </pre>", "group_id": 8954, "id": 1114695}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305830321.069577, "message": "[devel] - Re: packaging landed in stdlib - http://tinyurl.com/6zdyj67 - Georg Brandl - <pre> Rock on! Georg </pre>", "group_id": 8954, "id": 1114696}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305833917.6549261, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6fcep5p - Georg Brandl - <pre> To clarify my original one-liner: if bytes objects (but only one-char bytes objects) equal integers, you should rightly expect to treat them as integers. This is obviously *not* desirable from a strong-typing POV. Georg </pre>", "group_id": 8954, "id": 1115297}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305838539.024524, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3kuhvwy - Terry Reedy - <pre> Or like C char arrays I still remember having to work that out and get used to it. </pre>", "group_id": 8954, "id": 1116349}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305849398.7048149, "message": "[devel] - Re: Don't set local variable in a list comprehension or generator - http://tinyurl.com/6dew9ws - skip< at >pobox.com - <pre> You might more-or-less legitimately encounter it if the generator expression originally contained a condition which got removed. Skip </pre>", "group_id": 8954, "id": 1118001}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305849402.321337, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12120, Issue #12119: tests were missing a sys.dont_write_bytecode check - http://tinyurl.com/656mq5w - Victor Stinner - <pre>Python 3.3 is not supposed to create .pyc files in the same directory than the .py files. So I don't understand the following code. Le jeudi 19 mai 2011 \u00e0 19:56 +0200, tarek.ziade a \u00e9crit : _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1118003}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305852156.479754, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/5vjz77f - Ethan Furman - <pre> Several folk have said that objects that compare equal must hash equal... Why? It's an honest question. Here's what I have tried: --&gt; class Wierd(): ... def __init__(self, value): ... self.value = value ... def __eq__(self, other): ... return self.value == other ... def __hash__(self): ... return hash((self.value + 13) ** 3) ... --&gt; one = Wierd(1) --&gt; two = Wierd(2) --&gt; three = Wierd(3) --&gt; one &lt;Wierd object at 0x00BFE710&gt; --&gt; one == 1 True --&gt; one == 2 False --&gt; two == 2 True --&gt; three == 3 True --&gt; d = dict() --&gt; d[one] = '1' --&gt; d[two] = '2' --&gt; d[three] = '3' --&gt; d {&lt;Wierd object at 0x00BFE710&gt;: '1', &lt;Wierd object at 0x00BFE870&gt;: '3', &lt;Wierd object at 0x00BFE830&gt;: '2'} --&gt; d[1] = '1.0' --&gt; d[2] = '2.0' --&gt; d[3] = '3.0' --&gt; d {&lt;Wierd object at 0x00BFE870&gt;: '3', 1: '1.0', 2: '2.0', 3: '3.0', &lt;Wierd object at 0x00BFE830&gt;: '2', &lt;Wierd object at 0x00BFE710&gt;: '1'} --&gt; d[2] '2.0' --&gt; d[two] '2' This behavior matches what I was imagining for having b'a' == </pre>", "group_id": 8954, "id": 1118240}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305853057.3051829, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/636os5u - Benjamin Peterson - <pre>2011/5/19 Ethan Furman &lt;ethan&lt; at &gt;stoneleaf.us&gt;: https://secure.wikimedia.org/wikipedia/en/wiki/Hash_table </pre>", "group_id": 8954, "id": 1118409}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305862119.331321, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3sjztlg - Raymond Hettinger - <pre> On May 19, 2011, at 7:40 PM, Ethan Furman wrote: And so do the docs: http://docs.python.org/dev/reference/datamodel.html#object.__hash__ , \"the only required property is that objects which compare equal have the same hash value\". Raymond </pre>", "group_id": 8954, "id": 1120097}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305876143.2169321, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/5tmmpcj - Eli Bendersky - <pre> With respect to Google Blogger, I don't see a good reason to use it as the platform for the blog. IMHO it would be much better to go for a less-dependencies approach and just deploy a Wordpress installation, or possibly even something Python-based (if volunteers to maintain it are found. Eli </pre>", "group_id": 8954, "id": 1121878}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305881545.157304, "message": "[devel] - os.access on Windows - http://tinyurl.com/6d4lo4u - Tim Golden - <pre>There's a thread on python-list at the moment: http://mail.python.org/pipermail/python-list/2011-May/1272505.html which is discussing the validity of os.access results on Windows. Now we've been here before: I raised issue2528 for a previous enquiry some years ago and proffered a patch which uses the AccessCheck API to perform the equivalent check, but didn't follow through. Someone on the new thread is suggesting -- validly -- that the docs should highlight the limitations of this call on Windows. But the docs for that call are already fairly involved: http://docs.python.org/library/os.html#os.access We seem to have a few options in increasing order of difficulty: * Do nothing - inform the occasional enquirer of the situation and leave it at that. * Update the docs to add something which describes what the function actually does on the Windows platform. (Whether or not we change any code). * Apply the patch in issue2528 to 3.3 and maybe 2.7 * Leave os.access alone but offer alternative Wind</pre>", "group_id": 8954, "id": 1123010}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305881540.0339, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/3pa7zof - Nick Coghlan - <pre> As with any infrastructure, there is a reasonably high cost in changing, as people have become used to a certain way of doing things, and porting the contents from the old system to the new one requires additional effort. Blogger has its problems, but it typically gets the job done well enough (modulo cases like the one currently affecting Doug and his team). Cheers, Nick. </pre>", "group_id": 8954, "id": 1123007}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305885140.5804701, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/6e94vgm - Eli Bendersky - <pre> Has the Python insider blog really accumulated enough history and cruft to make this move problematic? It's a fairly new blog, with not much content in it. From my blogging experience, Blogger has other limitations which eventually bite you, and since it's not very flexible you can either live with it or move to a more flexible platform. All of this completely IMHO, of course. Just friendly advice ;-) Eli </pre>", "group_id": 8954, "id": 1123802}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305884238.6894929, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/5wwgtum - Nick Coghlan - <pre> Because whether or not two objects can coexist in the same hash table should *not* depend on their hash values - it should depend on whether or not they compare equal to each other. The use of hashing should just be an optimisation, not fundamentally change the nature of the comparison operation. (i.e. \"hash(a) == hash(b) and a == b\" is meant to be a fast alternative to \"a == b\", not a completely different check). Cheers, Nick. </pre>", "group_id": 8954, "id": 1123683}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305905060.812742, "message": "[devel] - Re: os.access on Windows - http://tinyurl.com/3rkr6zy - Brian Curtin - <pre> I think we should tread lightly in the documentation area. We already have two note boxes, and adding a third probably scares everyone away. Maybe there should be a bullet list of considerations to be made when using os.access? * Apply the patch in issue2528 to 3.3 and maybe 2.7 I'd vote in favor of this. If we can be a bit smarter in determining os.access results, let's do it. I haven't reviewed the patch other than 1 minute scan, but I'll put this on my radar and try to get you a review. </pre>", "group_id": 8954, "id": 1126804}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305902359.61098, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/6eoum7v - Jesse Noller - <pre> There is ongoing work for an RFP by the board to improve the python.org publishing system/site to allow us to self-host these things. Moving PSF properties off of it, and onto another \"hosted by someone else\" site is probably not a good idea, but our hands may be forced if google/blogger can not resolve the issues. jesse </pre>", "group_id": 8954, "id": 1126298}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305905965.2218821, "message": "[devel] - Re: packaging landed in stdlib - http://tinyurl.com/3jp9npu - Tarek Ziad\u00e9 - <pre> Thanks :) Still working on some issues under windows and solaris bbots today, but we're getting there. Sorry for the inconvenience Tarek </pre>", "group_id": 8954, "id": 1127021}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305905960.5963609, "message": "[devel] - Re: os.access on Windows - http://tinyurl.com/3kmqc4f - Tim Golden - <pre> (Sorry about that; I had no idea I'd sent that from my work account) I entirely agree. (That's what I meant by \"involved\" above) Thanks. To be honest I wrote the patch 3 years ago; I haven't even tried to apply it to either of the current posixmodule.c. Let's see if I can dust it off and mould it into shape, or you'll be left fighting patch errors instead of reviewing code :) TJG </pre>", "group_id": 8954, "id": 1127019}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305905970.1917701, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/3fhjzq4 - Eli Bendersky - <pre> The whole idea of a Wordpress-(or similar)-based solution is self hosting, and less reliance on outside providers like blogger. Wordpress is just a bunch of PHP code you place in a directory on your server and you have a blog. You don't depend on anyone, except your own hosting. Eli </pre>", "group_id": 8954, "id": 1127022}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305908719.9952061, "message": "[devel] - Re: os.access on Windows - http://tinyurl.com/3h2gwp7 - Guido van Rossum - <pre> TBH I think the less attractive we can make os.access() look the better. It uses the real uid instead of the effective uid, it encourages LBYL behavior, the outcome may be incorrect, it doesn't work on Windows... The ONLY reason to ever use it is in a setuid() program. But who writes those any more? (Esp. in Python!) </pre>", "group_id": 8954, "id": 1127513}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305906860.089694, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/43wrf2j - Nick Coghlan - <pre> It's not just the Python Insider blog that is affected (and *any* effort directed towards platform changes is effort that isn't going towards writing new articles. Of course, if Blogger don't fix the currrent problems, then that will be a moot point - moving will be necessary to get *anything* done). In general, though, infrastructure changes start from a position of \"not worth the hassle\", just like code changes. It takes a pretty compelling set of features to justify switching, and, while Blogger isn't the best engine out there, it isn't terrible either (especially once you replace their lousy comment system with something that is at least half usable like DISQUS). Cheers, Nick. </pre>", "group_id": 8954, "id": 1127209}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305906864.6117549, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/3aowo45 - Nick Coghlan - <pre> As Jesse has said, there is an RFP in development to improve python.org to the point where we can self-host blogs and the like and deal with the associated user account administration appropriately. But when it comes to collaborative blogs, it *isn't* just a matter of dropping a blogging engine in and running with it. Cheers, Nick. </pre>", "group_id": 8954, "id": 1127210}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305907820.84905, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/3db48uy - Tres Seaver - <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/20/2011 11:35 AM, Eli Bendersky wrote: And your own sysadmins now have to chase fixes for remotely-exploitable WP bugs: http://www.wordpressexploit.com/ Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver&lt; at &gt;palladion.com Palladion Software \"Excellence by Design\" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3WkBQACgkQ+gerLs4ltQ72iwCeIhkCLXm26ujJJ3kqh9vKB4fr dMYAn05qsoyiNxio02UAYJ7luLjVaSML =OFdv -----END PGP SIGNATURE----- </pre>", "group_id": 8954, "id": 1127312}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305907827.9357359, "message": "[devel] - Summary of Python tracker Issues - http://tinyurl.com/3ef8osa - Python tracker - <pre> ACTIVITY SUMMARY (2011-05-13 - 2011-05-20) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2794 (+10) closed 21115 (+46) total 23909 (+56) Open issues with patches: 1201 Issues opened (37) ================== #8796: Deprecate codecs.open() http://bugs.python.org/issue8796 reopened by haypo #11377: Deprecate platform.popen() http://bugs.python.org/issue11377 reopened by eric.araujo #12068: test_logging failure in test_rollover http://bugs.python.org/issue12068 reopened by pitrou #12073: regrtest: use faulthandler to dump the tracebacks on SIGUSR1 http://bugs.python.org/issue12073 opened by haypo #12074: regrtest: display the current number of failures http://bugs.python.org/issue12074 opened by haypo #12075: python3.2 memory leak when setting integer key in dictionary http://bugs.python.org/issue12075 opened by kaizhu #12077: Harmonizing descriptor pro</pre>", "group_id": 8954, "id": 1127315}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305916823.8496621, "message": "[devel] - Hello! - http://tinyurl.com/3zbd3k2 - Charles-Fran\u00e7ois Natali - <pre>Hi, My name is Charles-Fran\u00e7ois Natali, I've been using Python for a couple years, and I've recently been granted commit priviledge. I just wanted to say hi to everyone on this list, and let you know that I'm really happy and proud of joining this great community. Cheers, cf </pre>", "group_id": 8954, "id": 1128966}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305919522.38744, "message": "[devel] - in latest Py3k site.py: configparser.NoSectionError: No section: 'posix_prefix' - http://tinyurl.com/3mnf7yv - Stefan Behnel - <pre>Hi, since May 19, I get the exception below in the latest py3k site.py when trying to run a distutils build with it (building Cython). The changelog since the previous (working) CPython build is here: https://sage.math.washington.edu:8091/hudson/job/py3k-hg/374/ The failing build is here: https://sage.math.washington.edu:8091/hudson/job/cython-devel-build-py3k/1313/console This is on 64bit Linux. I tried with a clean checkout, no difference. Is this problem obvious to someone, is there anything that needs adaptation on our side (I hope not), or should I file a bug report? Thanks, Stefan \"\"\" $ python setup.py bdist --formats=gztar --cython-profile Traceback (most recent call last): File \"/.../python/lib/python3.3/configparser.py\", line 842, in items d.update(self._sections[section]) KeyError: 'posix_prefix' During handling of the above exception, another exception occurred: Traceback (most recent call last): File \"/.../python/lib/python3.3/site.py\", line 537, in &lt;module&gt; main() </pre>", "group_id": 8954, "id": 1129376}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305924021.511173, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/3tp2xnk - Georg Brandl - <pre> That's exactly the problem. Georg </pre>", "group_id": 8954, "id": 1130111}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305928522.7245281, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/4x7wpu4 - Martin v. L\u00f6wis - <pre> To run a blog on www.python.org, a PEP is not needed. If anybody would volunteer to set this up, it could be done in no time. Regards, Martin </pre>", "group_id": 8954, "id": 1130950}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305929482.6534071, "message": "[devel] - Re: os.access on Windows - http://tinyurl.com/3hap8qd - Martin v. L\u00f6wis - <pre> +1. The best way to determine \"could I access this file\" is to try to access it, and be prepared to get an exception. So we might deprecate-then-delete it on Windows. People who *really* need to know in advance should use the Windows API for that on Windows (i.e. call AccessCheck). Regards, Martin </pre>", "group_id": 8954, "id": 1131083}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305931282.0836921, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/3fpspsa - Doug Hellmann - <pre> On May 20, 2011, at 5:47 PM, Martin v. L\u00f6wis wrote: The blog is working again, so we can continue using the tool chain we have. Thanks, Doug -- Doug Hellmann Communications Director Python Software Foundation http://python.org/psf/ </pre>", "group_id": 8954, "id": 1131189}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305939438.9215629, "message": "[devel] - Python 2.6.7 release candidate 2 now available - http://tinyurl.com/3fsalfa - Barry Warsaw - <pre>Hello to all you Pythoneers and Pythonistas, I'm happy to announce the availability of Python 2.6.7 release candidate 2. Release candidate 1 was not widely announced due to a mismatch between the Mercurial and Subversion branches. Barring any unforeseen issues, this will be the last release candidate before 2.6.7 final, which is currently scheduled for June 3, 2011. As previously announced, Python 2.6 is in security-fix only mode. This means that general bug fix maintenance has ended, and only critical security fixes are supported. We will support Python 2.6 in security-fix only mode until October 2013. Also, this is a source-only release; no installers for Windows or Mac OS X will be provided. Please download and test this release candidate. http://www.python.org/download/releases/2.6.7/ The NEWS file contains a list of changes since 2.6.6. http://www.python.org/download/releases/2.6.7/NEWS.txt Many thanks go out to the entire Python community for their contributions great and small. Enj</pre>", "group_id": 8954, "id": 1131516}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305948444.579273, "message": "[devel] - Re: in latest Py3k site.py:configparser.NoSectionError: No section: 'posix_prefix' - http://tinyurl.com/42mr6tc - Ned Deily - <pre>In article &lt;ir6e0i$hn6$1&lt; at &gt;dough.gmane.org&gt;, Stefan Behnel &lt;stefan_ml&lt; at &gt;behnel.de&gt; wrote: It's a bug introduced by the packaging (Distutils2) feature. Thanks for finding it first. http://bugs.python.org/issue12131 </pre>", "group_id": 8954, "id": 1132101}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305953845.7154059, "message": "[devel] - Re: Hello! - http://tinyurl.com/44e3rzx - Ross Lagerwall - <pre> Congratulations, welcome. Ross _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1132666}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305976526.2194099, "message": "[devel] - Re: cpython: Added SSL test for HTTPHandler. - http://tinyurl.com/3pudklm - Antoine Pitrou - <pre>On Sat, 21 May 2011 12:32:21 +0200 vinay.sajip &lt;python-checkins&lt; at &gt;python.org&gt; wrote: We already bundle a couple of cert files in Lib/test, so you shouldn't have to use your own (see e.g. Lib/test/keycert.pem). If you want real security, HTTPHandler should configure its SSLContext in CERT_REQUIRED mode (and be given the proper root certificate(s)). Otherwise you are vulnerable to man-in-the-middle attacks. See the \"context\" and \"check_hostname\" arguments to HTTPSConnection: http://docs.python.org/dev/library/http.client.html#http.client.HTTPSConnection Regards Antoine. </pre>", "group_id": 8954, "id": 1133536}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305980125.279537, "message": "[devel] - Re: Hello! - http://tinyurl.com/3mbop6b - Antoine Pitrou - <pre>On Fri, 20 May 2011 19:01:26 +0200 Charles-Fran\u00e7ois Natali &lt;cf.natali&lt; at &gt;gmail.com&gt; wrote: Welcome, and keep up the good work. Regards Antoine. </pre>", "group_id": 8954, "id": 1133646}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305989189.420054, "message": "[devel] - Stable buildbots update - http://tinyurl.com/3zw8mc7 - Antoine Pitrou - <pre> Hello, We recently got a couple of new stable buildbots: - R. David Murray's \"x86 Gentoo\" machine, which builds in non-debug mode and therefore checks that release Pythons work fine - Stefan Krah's \"AMD64 FreeBSD 8.2\" machine - Bill Janssen's \"AMD64 Snow Leopard\" machine Many stable buildbots on the default branch (*) are currently red because of test_packaging issues. (*) http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable Regards Antoine. </pre>", "group_id": 8954, "id": 1134341}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305990987.5875781, "message": "[devel] - The socket HOWTO - http://tinyurl.com/433ojrm - Antoine Pitrou - <pre> Hello, I would like to suggest that we remove the socket HOWTO (currently at http://docs.python.org/dev/howto/sockets.html) My main issue with this document is that it doesn't seem to have a well-defined destination: - people who know sockets won't learn anything from it - but people who don't know sockets will probably find it clear as mud (for example, what's an \"INET\" or \"STREAM\" socket? what's \"select\"?) I have other issues, such as the style/tone it's written in. I'm sure the author had fun writing it but it doesn't fit well with the rest of the documentation. Also, the author gives a lot of \"advice\" without explaining or justifying it (\"if somewhere in those input lists of sockets is one which has died a nasty death, the select will fail\" -&gt; is that really true? what is a \"nasty death\" and how is that supposed to happen? couldn't the author have put a 3-line example to demonstrate this supposed drawback and how it manifests?). And, finally, many statements seem arbitrary (\"There\u2019s no question th</pre>", "group_id": 8954, "id": 1134451}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305992787.818496, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3hugtzl - Georg Brandl - <pre> +1, or a big rewrite. Georg </pre>", "group_id": 8954, "id": 1134629}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305993752.565856, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3jau26x - Ross Lagerwall - <pre> While I agree with most of what you said, I actually did find it very useful when first learning sockets. It's in the top page on google for \"socket programming\" or \"socket how to\". Also, it hinted at some concepts that could then be googled for more information like select, nonblocking sockets, etc. However, I would agree that this should be moved out of the documentation and as suggested in the issue, into the wiki. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1134797}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305993746.113487, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3hu8u95 - Eli Bendersky - <pre>&lt;snip&gt; I definitely recall finding this document useful when I first learned Python. I knew socket programming from other languages, and the document helped to see how it maps to Python. That said, I must agree that there is probably no place for such a tutorial in Python's official documentation. Python is a widely-general purpose language, and sockets programming is just one of a plethora of things it supports, so a special treatment for sockets probably isn't warranted, especially given that the `socket` module itself is a relatively thin wrapper over the OS socket interface. I don't think a rewrite will help either. To describe socket programming in full, without missing anything and being accurate will require no less than a small book (and in fact many such books already exist). Therefore, I'm +1 on removing it from the official docs. It can be relegated to the Python wiki, where it can be improved if someone wishes to contribute to that. Eli </pre>", "group_id": 8954, "id": 1134794}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1305994648.806741, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3wocf88 - Senthil Kumaran - <pre> I favor a rewrite over removal. I have read it once/twice and have never revisited it (the probably the reason that it was not helpful enough for a revisit), but still gives some important pointers. One document cannot cover it all, there are many pointers (examples at effbot.org, Python MoTW docs) all serve as good introduction to sockets in python. So a rewrite with good pointers would be more appropriate. </pre>", "group_id": 8954, "id": 1134890}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306000108.160898, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/4xko45d - Georg Brandl - <pre> Even then, it's better off in the Wiki until the rewrite is complete. Georg </pre>", "group_id": 8954, "id": 1135346}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306002869.991215, "message": "[devel] - Re: Stable buildbots update - http://tinyurl.com/3bmfgel - Tarek Ziad\u00e9 - <pre> Yes, I am aware of this. I have fixed today most remaining issues, and fixing the final ones right now. </pre>", "group_id": 8954, "id": 1135587}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306022848.564086, "message": "[devel] - CPython optimization: storing reference countersoutside of objects - http://tinyurl.com/3kwmmor - Artur Siekielski - <pre>Hi. The problem with reference counters is that they are very often incremented/decremented, even for read-only algorithms (like traversal of a list). It has two drawbacks: 1. CPU cache lines (64 bytes on X86) containing a beginning of a PyObject are very often invalidated, resulting in loosing many chances to use the CPU caches 2. The copy-on-write after fork() optimization (Linux) is almost useless in CPython, because even if you don't modify data directly, refcounts are modified, and PyObjects with refcounts inside are spread all over process' memory (and one small refcount modification causes the whole page - 4kB - to be copied into a child process). So an idea I would like to try is to move reference counts outside of PyObjects, to a contiguous block(s) of memory. PyObjects would have a pointer to a reference count inside this block. Doing this I think that 1. The beginning of PyObject structs could be CPU-cached for a much longer time (small objects like ints could be fully cached). I don't know if ha</pre>", "group_id": 8954, "id": 1138840}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306069050.919102, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3k7gqfv - Antoine Pitrou - <pre> Hello, On Sun, 22 May 2011 01:57:55 +0200 Artur Siekielski &lt;artur.siekielski&lt; at &gt;gmail.com&gt; wrote: Mutating data doesn't invalidate a cache line. It just makes it necessary to write it back to memory at some point. Indeed. This has already been proposed a couple of times. I guess what's needed is for someone to experiment and post benchmark results. Regards Antoine. </pre>", "group_id": 8954, "id": 1141505}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306074514.00073, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3ta8v5x - Charles-Fran\u00e7ois Natali - <pre> I think he's referring to the multi-core case. In MESI terminology, the cache line will become modified in the current cache (current thread), but invalid in other cores' caches. But given that objects are accessed serialized by the GIL (which will issue a memory barrier anyway), I'm not sure that the performance impact will be noticeable. Furthermore, given that threads are actually serialized, I suspect that the scheduler tends to bind them naturally to the same CPU. There's been a bug report a couple months ago from someone using large datasets for some scientific application. He was suggesting to add support for Linux's MADV_MERGEABLE, but the root cause is really the reference count being incremented even when objects are treated read-only. For the record, it's http://bugs.python.org/issue9942 (and this idea was brought up here). cf </pre>", "group_id": 8954, "id": 1142096}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306112625.5610819, "message": "[devel] - Re: Stable buildbots update - http://tinyurl.com/3cm74v7 - Bill Janssen - <pre> Just FYI: the \"AMD64 Snow Leopard\" buildbot and \"PPC Leopard\" buildbots are now green, but the \"PPC Tiger\" buildbot is still failing for all branches because of packaging errors: ====================================================================== FAIL: test_user_site (packaging.tests.test_command_install_dist.InstallTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File \"/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/packaging/tests/test_command_install_dist.py\", line 95, in test_user_site self._test_user_site() File \"/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/packaging/tests/test_command_install_dist.py\", line 124, in _test_user_site self.assertTrue(os.path.exists(self.user_base)) AssertionError: False is not true ====================================================================== FAIL: test_get_outputs (packaging.tests.test_command_install_lib.InstallLibTestCase) ----------------------------------------</pre>", "group_id": 8954, "id": 1146545}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306127145.4532089, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3qluvgn - Martin v. L\u00f6wis - <pre> My expectation is that your approach would likely make the issues worse in a multi-CPU setting. If you put multiple reference counters into a contiguous block of memory, unrelated reference counters will live in the same cache line. Consequentially, changing one reference counter on one CPU will invalidate the cached reference counters of that cache line on other CPU, making your problem a) actually worse. Regards, Martin </pre>", "group_id": 8954, "id": 1148581}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306129845.9264481, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3e9cpxn - Cesare Di Mauro - <pre>2011/5/23 \"Martin v. L\u00f6wis\" &lt;martin&lt; at &gt;v.loewis.de&gt; I don't think that moving ob_refcnt to a proper memory pool will solve the problem of cache pollution anyway. ob_refcnt is obviously the most stressed field in PyObject, but it's not the only one. We have , that is needed to model each object (instance) \"behavior\", which is massively accessed too, so a cache line will be loaded as well when the object will be used. Also, only a few of simple objects have just ob_refcnt and ob_type. Most of them have other fields too, and accessing them means a line cache load. Regards, Cesare P.S. Memory allocation granularity can help sometimes, leaving some data (ob_refcnt and/or ob_type) on one cache line, and the other on the next one. </pre>", "group_id": 8954, "id": 1148773}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306131650.5447991, "message": "[devel] - Re: Hello! - http://tinyurl.com/3kn3byp - Nick Coghlan - <pre> Indeed! Cheers, Nick. </pre>", "group_id": 8954, "id": 1149147}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306131647.0407541, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/3ealumz - Nick Coghlan - <pre> If I understand correctly, the RFP is more about improving the entire python.org toolchain to make it something that non-programmers can easily provide content for (and even *programmers* don't particularly like the current toolchain). Cheers, Nick. </pre>", "group_id": 8954, "id": 1149146}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306132546.18062, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3h2snwd - Nick Coghlan - <pre> Perhaps replacing it with a placeholder page that refers to the Wiki would be appropriate? A simple summary saying that the HOWTO had not aged well, and hence had been removed from the official documentation until it had been updated on the Wiki would allow people looking for it to better understand the situation, and also how to help improve it. Cheers, Nick. </pre>", "group_id": 8954, "id": 1149299}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306134346.2603121, "message": "[devel] - Re: Stable buildbots update - http://tinyurl.com/3mq7qw2 - Tarek Ziad\u00e9 - <pre> All the linux and windows stable slaves are now green, and I have a few issues left to be fixed for all solaris flavors and the two you are showing, that are also failing under Free BSD. Thanks Tarek </pre>", "group_id": 8954, "id": 1149447}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306140646.360518, "message": "[devel] - Re: os.access on Windows - http://tinyurl.com/3o6nly8 - Tim Golden - <pre> FWIW the OP knew this but -- for some reason specific to his use case -- wanted to avoid updating the mod dates of the containing directory. Obviously that's his problem, not ours... &gt; So we might deprecate-then-delete it on Windows. I'll rework that patch to be a DeprecationWarning in that case. And indeed this is what I've recommended to the OP. I'll follow this up in that python-list thread. I see that Benjamin's updated the os.access docs so I'll let this thread die and talk the OP through the AccessCheck route (which is, unfortunately, more tricky because it's not exposed by pywin32. Also not our problem...) TJG </pre>", "group_id": 8954, "id": 1150395}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306145148.8969741, "message": "[devel] - the distutils2 repo and 3to2 - http://tinyurl.com/3tea6db - Tarek Ziad\u00e9 - <pre>Hey, Now that packaging has landed, the distutils2 repo is going to be re-seted and will be the python 2.x / 3.1 / 3.2 backport of packaging. In theory, we want to automate the extraction of packaging from the stdlib and a few other modules, and run 3to2 at install time. Or should I say 3.3tosomething. I want to do this to avoid maintaining yet another code base. In practice, I don't really know the current state of 3to2 so we'll see.. Any help/hint in this project would be appreciated. Thanks Tarek </pre>", "group_id": 8954, "id": 1150884}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306148747.3039401, "message": "[devel] - Re: the distutils2 repo and 3to2 - http://tinyurl.com/4xvr9zt - \u0141ukasz Langa - <pre> Wiadomo\u015b\u0107 napisana przez Tarek Ziad\u00e9 w dniu 2011-05-23, o godz. 11:58: I'm maintaining a configparser 3.2+ backport for 2.6-2.7 using 3to2. A fully automatic conversion is not really possible, partly because the 3to2 tool is not perfect, and partly because there are parts of the code (esp. in the tests) which no mechanical converter could have figured out on its own. Anyway, the backport is available here: http://pypi.python.org/pypi/configparser There's some documentation there on the conversion process I came up with. As for distutils2, I was already contacted by \u00c9ric Araujo and will help him improve 3to2. We are yet to contact its authors to see if they believe merging our changes upstream will be possible. </pre>", "group_id": 8954, "id": 1151106}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306148751.4020901, "message": "[devel] - Re: the distutils2 repo and 3to2 - http://tinyurl.com/3ee8d8q - Tarek Ziad\u00e9 - <pre>2011/5/23 \u0141ukasz Langa &lt;lukasz&lt; at &gt;langa.pl&gt;: .. Do you backport to 3.1 ? .. Awesome, will look up, thanks Great, anything was started already ? If so, we should sync to see how we can initiate the d2 repo Cheers Tarek </pre>", "group_id": 8954, "id": 1151108}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306149706.216764, "message": "[devel] - Re: the distutils2 repo and 3to2 - http://tinyurl.com/3d9sjom - \u0141ukasz Langa - <pre> Wiadomo\u015b\u0107 napisana przez Tarek Ziad\u00e9 w dniu 2011-05-23, o godz. 12:58: Not really. I personally think people already using py3k will migrate sooner (even if they have to do it on their own) than the folk on 2.x. The new Ubuntu already ships with Python 3.2. As for Python 2.x I've learnt that keeping compatibility with a Python version without decorators, `io` library, abstract base classes, etc. would mean either diverging branches or reproducing and maintaining bits of the newer stdlib. This is something 3to2 won't help you with as it's out of scope for that tool. For configparser I only support 2.6+ and none the less the backport has a helpers module with a couple of things copied over from 2.7 or 3.1. There's also an external dependency on ordereddict, etc. You see where this is going. I've heard you're targetting 2.4 compatibility so be prepared that this is not going to be easy. </pre>", "group_id": 8954, "id": 1151157}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306150613.424511, "message": "[devel] - Re: the distutils2 repo and 3to2 - http://tinyurl.com/3l55pqy - Tarek Ziad\u00e9 - <pre>2011/5/23 \u0141ukasz Langa &lt;lukasz&lt; at &gt;langa.pl&gt;: ... yeah well, we might raise the bar to 2.5 and use some __future__ statements. I am not sure that keeping 2.4 support is that useful anymore. Cheers Tarek </pre>", "group_id": 8954, "id": 1151203}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306153309.637224, "message": "[devel] - Re: the distutils2 repo and 3to2 - http://tinyurl.com/3hbnka2 - Nick Coghlan - <pre>2011/5/23 Tarek Ziad\u00e9 &lt;ziade.tarek&lt; at &gt;gmail.com&gt;: Anyone still stuck with 2.4 at this point in time is probably going to struggle to switch their packaging support library from distutils to distutils2 anyway. Cheers, Nick. </pre>", "group_id": 8954, "id": 1151508}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306154213.0507629, "message": "[devel] - Re: the distutils2 repo and 3to2 - http://tinyurl.com/4428qaw - Fred Drake - <pre>2011/5/23 \u0141ukasz Langa &lt;lukasz&lt; at &gt;langa.pl&gt;: Uptake on Ubuntu 11.04 will take longer than 10.10 uptake, given the reliability issues and the reaction to the new user interface. That's not to say it won't be significant, but the strength of the indicator may be less significant than in the past. -Fred </pre>", "group_id": 8954, "id": 1151696}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306155108.236994, "message": "[devel] - Re: looking for a contact at Google on the Blogger team - http://tinyurl.com/4x3z73j - Jesse Noller - <pre> That is correct. </pre>", "group_id": 8954, "id": 1151790}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306162308.3207121, "message": "[devel] - Re: the distutils2 repo and 3to2 - http://tinyurl.com/3ex8lgo - Barry Warsaw - <pre>Okay, this reply is getting off-topic, so I won't belabor the point (please email me directly if you want to discuss further). On May 23, 2011, at 08:25 AM, Fred Drake wrote: You're not required to run the default desktop (Unity) of course. There are several options out of the box, including the classic desktop and Unity 2D, and there are a wide range of supported derivatives of Ubuntu offering additional desktops, such as KDE (Kubuntu) and Xfce (Xubuntu). Cheers, -Barry </pre>", "group_id": 8954, "id": 1153498}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306163207.086375, "message": "[devel] - Re: the distutils2 repo and 3to2 - http://tinyurl.com/4xcbt7n - Fred Drake - <pre> Of course, but I still think the default affects the rate of uptake. I'm not attacking Ubuntu, but I think the uptake rate is relevant to our current discussion. That said, the multi-monitor issues prevent my updating to 11.04. -Fred </pre>", "group_id": 8954, "id": 1153676}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306171372.0205729, "message": "[devel] - Re: Stable buildbots update - http://tinyurl.com/3pdfvbk - Tarek Ziad\u00e9 - <pre> I have now completed the cleanup and we're back on green-land for the stable bots. The red slaves should get green when they catch up with the latest rev (they are slow). If they're not and they are failing in packaging or sysconfig let me know. Sorry again if it has taken so long. Setting up Solaris and BSD VMs took some time ;) Cheers Tarek </pre>", "group_id": 8954, "id": 1154781}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306171368.762816, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3s4m42n - Ethan Furman - <pre> So are you thinking that bytes([01,56])[:2] == 120 ? Or more along the lines of a .to_int() method? ~Ethan~ </pre>", "group_id": 8954, "id": 1154777}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306174069.7881739, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3qddgb4 - Terry Reedy - <pre> I believe that such things can be handled by the struct module. </pre>", "group_id": 8954, "id": 1155096}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306184931.123312, "message": "[devel] - Re: CPython optimization: storing reference countersoutside of objects - http://tinyurl.com/3h6ahyw - Artur Siekielski - <pre>Ok, I managed to make a quick but working patch (sufficient to get working interpreter, it segfaults for extension modules). It uses the \"ememoa\" allocator (http://code.google.com/p/ememoa/) which seems a reasonable pool allocator. The patch: http://dpaste.org/K8en/. The main obstacle was that there isn't a single function/macro that can be used to initialize all PyObjects, so I had to initialize static PyObjects (mainly PyTypeObjects) by hand. I used a naive quicksort algorithm as a benchmark: http://dpaste.org/qquh/ . The result is that after patching it runs 50% SLOWER. I profiled it and allocator methods used 35% time. So there is still 15% performance loss even if the allocator is poor. Anyway, I'd like to have working copy-on-write in CPython - in the presence of GIL I find it important to have multiprocess programs optimized (and I think it's a common idiom that a parent process prepares some big data structure, and child \"worker\" processes do some read-only quering). Artur </pre>", "group_id": 8954, "id": 1157145}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306185831.4990079, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3ztrslo - Guido van Rossum - <pre>On Mon, May 23, 2011 at 1:55 PM, Artur Siekielski &lt;artur.siekielski&lt; at &gt;gmail.com&gt; wrote: That is the question though -- *is* the idiom commonly used? It doesn't seem to me that it would scale all that far, since it only works as long as all forked copies live on the same machine and run on the same symmetrical multi-core processor. </pre>", "group_id": 8954, "id": 1157300}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306189428.6354859, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3e3dbxa - Artur Siekielski - <pre>2011/5/23 Guido van Rossum &lt;guido&lt; at &gt;python.org&gt;: In fact I came to the whole idea with this optimization because the idiom didn't work for me. I had a big word index built by a parent process, and than wanted the children to enable querying this index (I wanted to use all cores on a server). The index consumed 50% of RAM and after a few minutes the children consumed all RAM. I find it common in languages like Java to use thread pools, in Python+Linux we have multiprocess pools if we want to use all cores, and in this setting having a working copy-on-write is really valuable. Oh, and using explicit shared memory or mmap is much harder, because you have to map the whole object graph into bytes. ? I don't know about multi-processor systems, but on single-processor multi-core systems (which are common even on servers) and Linux it works. Artur </pre>", "group_id": 8954, "id": 1157924}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306193029.8157201, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3bnfk68 - Sturla Molden - <pre>Den 24.05.2011 00:07, skrev Artur Siekielski: It sounds like you need PYRO, POSH or multiprocessing's proxy objects. Sturla </pre>", "group_id": 8954, "id": 1158598}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306196629.7215321, "message": "[devel] - Deprecate codecs.open() and StreamWriter/StreamReader - http://tinyurl.com/3gmnpef - Victor Stinner - <pre>Hi, In Python 2, codecs.open() is the best way to read and/or write files using Unicode. But in Python 3, open() is preferred with its fast io module. I would like to deprecate codecs.open() because it can be replaced by open() and io.TextIOWrapper. I would like your opinion and that's why I'm writing this email. -- codecs.open() and StreamReader, StreamWriter and StreamReaderWriter classes of the codecs module don't support universal newlines, still have some issues with stateful codecs (like UTF-16/32 BOMs), and each codec has to implement a StreamReader and a StreamWriter class. StreamReader and StreamWriter are stateless codecs (no reset() or setstate() method), and so it's not possible to write a generic fix for all child classes in the codecs module. Each stateful codec has to handle special cases like seek() problems. For example, UTF-16 codec duplicates some IncrementalEncoder/IncrementalDecoder code into its StreamWriter/StreamReader class. The io module is well tested, supports non-seekable st</pre>", "group_id": 8954, "id": 1159364}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306202930.597198, "message": "[devel] - Re: Stable buildbots update - http://tinyurl.com/3l6axfv - Stephen J. Turnbull - <pre> &gt; I have now completed the cleanup and we're back on green-land for the &gt; stable bots. Are you saying you expect Mac OS X 10.4 \"Tiger\" to go green once the bots update? If so, I'm impressed, and \"thank you!\" to all involved. Apple and MacPorts have long since washed their hands of that release. </pre>", "group_id": 8954, "id": 1160163}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306205689.573936, "message": "[devel] - Re: Stable buildbots update - http://tinyurl.com/3f9pkrj - R. David Murray - <pre> You will note that Tiger is *not* in the stable set :) -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 1160710}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306213851.2348051, "message": "[devel] - Re: Stable buildbots update - http://tinyurl.com/3e4jar9 - Ned Deily - <pre>In article &lt;87zkmcalt8.fsf&lt; at &gt;uwakimon.sk.tsukuba.ac.jp&gt;, \"Stephen J. Turnbull\" &lt;stephen&lt; at &gt;xemacs.org&gt; wrote: OS X 10.4 does have its quirks that makes it challenging to get all of the tests to run without a few cornercase failures but, besides the buildbots, I still test regularly with 10.4 and occasionally build there, too. And, FWIW, while top-of-trunk MacPorts may not officially support 10.4, many ports work there just fine including python2.6, 2.7, and 3.1. (3.2 has a build issue that may get fixed in 3.2.1). </pre>", "group_id": 8954, "id": 1161822}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306213854.8532259, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3baokf3 - Nick Coghlan - <pre> Indeed. Abstractions over mmap (local machine sharing) and serialisation (remote sharing) are likely to be far more beneficial in this area than trying to change the underlying memory model to support copy-on-write. Cheers, Nick. </pre>", "group_id": 8954, "id": 1161824}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306215651.1027901, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3dmhyge - Nick Coghlan - <pre>On Tue, May 24, 2011 at 10:08 AM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: Is there any reason that codecs.open() can't become a thin wrapper around builtin open in 3.3? How API compatible is TextIOWrapper with StreamReader/StreamWriter? How hard would it to be change them to be adapters over the main IO machinery rather than independent classes? Rather than deprecating them, that seems like a more profitable direction to take them. Cheers, Nick. </pre>", "group_id": 8954, "id": 1162100}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306219312.4309371, "message": "[devel] - Re: cpython: Issue #11377: platform.popen() emits aDeprecationWarning - http://tinyurl.com/4y5f59f - Georg Brandl - <pre> Please see http://mail.python.org/pipermail/python-dev/2011-May/111303.html about the style of your commit messages. 9a16fa0c9548 is another example. Georg </pre>", "group_id": 8954, "id": 1162558}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306222010.3271079, "message": "[devel] - Re: Deprecate codecs.open() and StreamWriter/StreamReader - http://tinyurl.com/3ra879m - Victor Stinner - <pre>Le mardi 24 mai 2011 \u00e0 15:24 +1000, Nick Coghlan a \u00e9crit : Yes, it's trivial to implement codecs.open using: def open(filename, mode='rb', encoding=None, errors='strict', buffering=1): return builtins.open(filename, mode, buffering, encoding, errors, newline='') But do you we really need two ways to open a file? Extract of import this: \"There should be one-- and preferably only one --obvious way to do it.\" Another example: Python 3.2 has subprocess.Popen, os.popen and platform.popen to open a subprocess. platform.popen is now deprecated in Python 3.3. Well, it's already better than Python 2.5 which has os.popen(), os.popen2(), os.popen3(), os.popen4(), os.spawnl(), os.spawnle(), os.spawnlp(), os.spawnlpe(), os.spawnv(), os.spawnve(), os.spawnvp(), os.spawnvpe(), subprocess.Popen, platform.popen and maybe others :-) It's fully compatible. I don't understand your proposition. We don't need StreamReader and StreamWriter to open a stream as a file text, only incremental de</pre>", "group_id": 8954, "id": 1162979}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306224711.0574901, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3zdy469 - M.-A. Lemburg - <pre> I think you should have moved this part of your email further up, since it explains the reason why this idea was rejected for now: And now for something completely different: Please read PEP 100 regarding StreamReader and StreamWriter. Those codecs parts were explicitly designed to be stateful, unlike the stateless encoder/decoder methods. Please read my reply on the ticket: \"\"\" StreamReader and StreamWriter classes provide the base codec implementations for stateful interaction with streams. They define the interface and provide a working implementation for those codecs that choose not to implement their own variants. Each codec can, however, implement variants which are optimized for the specific encoding or intercept certain stream methods to add functionality or improve the encoding/decoding performance. Both are essential parts of the codec interface. TextIOWrapper and StreamReaderWriter are merely wrappers around streams that make use of the codecs. They don't provide any codec logic themselv</pre>", "group_id": 8954, "id": 1163359}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306225612.54317, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3q4ttqy - Vinay Sajip - <pre> What's \"non-trivial\"? Both pip and virtualenv (widely used programs) were ported to Python 3 using a single codebase for 2.x and 3.x, because it seemed to involve the least ongoing maintenance burden. Though these particular programs don't use codecs.open, I don't see much value in making it harder to write programs which can run under both 2.x and 3.x; that's not going to speed adoption of 3.x. I find 2to3 very useful indeed for showing where changes may need to be made for 2.x/3.x portability, but do not use it as an automatic conversion tool. The six module is very useful, too, but some projects won't necessarily want to add it as an additional dependency, and reimplement just the parts they need from that bag of tricks. So I would also want to keep codecs.open() and friends, at least for now - though it makes seems to make sense to implement them as wrappers (as Nick suggested). Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 1163555}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306226512.6309609, "message": "[devel] - Re: Deprecate codecs.open() and StreamWriter/StreamReader - http://tinyurl.com/3qocvou - Victor Stinner - <pre>Le mardi 24 mai 2011 \u00e0 08:16 +0000, Vinay Sajip a \u00e9crit : Well, I would agree to keep codecs.open() (if we patch it to reuse TextIOWrapper and add a note to say that it is kept for backward compatibiltiy and open() should be preferred in Python 3), but deprecate StreamReader, StreamWriter and EncodedFile. As I wrote, codecs.open() is useful in Python 2. But I don't know any program or library using directly StreamReader or StreamWriter. I found some projects (ex: twisted-mail, feeds2imap, pyflag, pygsm, ...) implementing their own Python codec (cool!) and their codec has their StreamReader and StreamWriter class, but I don't think that these classes are used. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1163762}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306228311.5350361, "message": "[devel] - Re: Deprecate codecs.open() and StreamWriter/StreamReader - http://tinyurl.com/3qy8b32 - Victor Stinner - <pre>Le mardi 24 mai 2011 \u00e0 10:03 +0200, M.-A. Lemburg a \u00e9crit : Yes, it is possible to implement stateful StreamReader and StreamWriter classes and we have such codecs (I gave the example of UTF-16), but the state is not exposed (getstate / setstate), and so it's not possible to write generic code to handle the codec state in the base StreamReader and StreamWriter classes. io.TextIOWrapper requires encoder.setstate(0) for example. Can you give me some examples? StreamReader, StreamWriter, TextIOWrapper and StreamReaderWriter all have a file-like API: tell(), seek(), read(), readline(), write(), etc. The implementation is maybe different, but the API is just the same, and so the usecases are just the same. I don't see in which case I should use StreamReader or StreamWriter instead TextIOWrapper. I thought that TextIOWrapper is specific to files on disk, but TextIOWrapper is already used for other usages like sockets. Why do you want to write a duplicate feature? TextIOWrapper is already here, it's work</pre>", "group_id": 8954, "id": 1164180}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306231919.3500719, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/44tjou8 - Artur Siekielski - <pre>2011/5/24 Sturla Molden &lt;sturla&lt; at &gt;molden.no&gt;: PYRO/multiprocessing proxies isn't a comparable solution because of ORDERS OF MAGNITUDE worser performance. You compare here direct memory access vs serialization/message passing through sockets/pipes. POSH might be good, but the project is dead for 8 years. And this copy-on-write is nice because you don't need changes/restrictions to your code, or a special garbage collector. Artur </pre>", "group_id": 8954, "id": 1164663}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306233716.1802001, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3eoyugu - Nick Coghlan - <pre>On Tue, May 24, 2011 at 6:58 PM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: Back up a step here. It's important to remember that the codecs module *long* predates the existence of the Python 3 I/O model and the io module in particular. Just as PEP 302 defines how module importers should be written, PEP 100 defines how text codecs should be written (i.e. in terms of StreamReader and StreamWriter). PEP 3116 then defines how such codecs can be used as part of the overall I/O stack as redesigned for Python 3. Now, there may be an opportunity here to rationalise things a bit and re-use the *new* io module interfaces as the basis for an updated codec API PEP, but we shouldn't be hasty in deprecating an old API that is about \"how to write codecs\" just because it is similar to a shiny new one that is about \"how to process I/O data\". Cheers, Nick. </pre>", "group_id": 8954, "id": 1164794}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306231916.3887489, "message": "[devel] - Re: Stable buildbots update - http://tinyurl.com/3dyvje5 - Antoine Pitrou - <pre>On Mon, 23 May 2011 19:16:36 +0200 Tarek Ziad\u00e9 &lt;ziade.tarek&lt; at &gt;gmail.com&gt; wrote: Thank you very much! What a beautiful sight this is: http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable (until a sporadic failure comes up, that is) Regards Antoine. </pre>", "group_id": 8954, "id": 1164660}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306233711.991637, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3cef69r - M.-A. Lemburg - <pre> So instead of always suggesting to deprecate everything, how about you come up with a proposal to add meaningful new methods to those base classes ? See the UTF-16 codec in the stdlib for example. This uses some of the available possibilities to interpret the BOM mark and then switches the encoder/decoder methods accordingly. A lot more could be done for other variable length encoding codecs, e.g. UTF-8, since these often have problems near the end of a read due to missing bytes. The base class implementation provides a general purpose implementation to cover the case, but it's not efficient, since it doesn't know anything about the encoding characteristics. Such an implementation would have to be done per codec and that's why we have per codec StreamReader/Writer APIs. I have no idea why TextIOWrapper was added to the stdlib instead of making StreamReaderWriter more capable, since StreamReaderWriter had already been available in Python since Python 1.6 (and this is being used by codecs.open()). Per</pre>", "group_id": 8954, "id": 1164793}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306233723.686131, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3cnozhl - Walter D\u00f6rwald - <pre> They *are* stateful, they just don't expose their state to the public. Yes, which in theory makes it possible to implement shortcuts for certain codecs (e.g. the UTF-32-BE/LE codecs could simply multiply the character position by 4 to get the byte position). However AFAICR none of the readers/writers does that. Actually it's the other way round: When I implemented the incremental codecs, I copied code from the StreamReader/StreamWriter classes. This could be be partially fixed by implementing generic StreamReader/StreamWriter classes that reuse the incremental codecs, but I don't think thats worth it. Servus, Walter </pre>", "group_id": 8954, "id": 1164796}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306232814.691344, "message": "[devel] - \"streams\" vs \"buffers\" - http://tinyurl.com/3phqmpw - Antoine Pitrou - <pre>On Tue, 24 May 2011 10:03:22 +0200 \"M.-A. Lemburg\" &lt;mal&lt; at &gt;egenix.com&gt; wrote: I think you are trying to make a conceptual distinction which doesn't exist in practice. Your OS uses buffers to represent \"streams\" to you. Also, how come StreamReader has internal members named \"bytebuffer\", \"charbuffer\" and \"linebuffer\"? There certainly seems to be some (non-trivial) amount of buffering going on there, and probably quite slow and inefficient since it's pure Python (TextIOWrapper is written in C). Regards Antoine. </pre>", "group_id": 8954, "id": 1164740}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306235514.987062, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3kjtzaj - Antoine Pitrou - <pre>On Tue, 24 May 2011 12:16:49 +0200 Walter D\u00f6rwald &lt;walter&lt; at &gt;livinglogic.de&gt; wrote: And in practice, TextIOWrapper.tell() does a similar optimization in a generic way. I'm linking to the Python implementation for readability: http://hg.python.org/cpython/file/5c716437a83a/Lib/_pyio.py#l1741 TextIOWrapper.seek() is straightforward due to the structure of the integer \"cookie\" returned by TextIOWrapper.tell(). In practice, TextIOWrapper gets much more love than Stream{Reader,Writer} because it's an essential part of the new I/O stack. As Victor said, problems which Stream* have had for years are solved neatly in TextIOWrapper. Therefore, leaving Stream{Reader,Writer} in is not a matter of \"choice\" and \"freedom given to users\". It's giving people the misleading possibility of using non-optimized, poorly debugged, less featureful implementations of the same basic idea (an unicode stream abstraction). Regards Antoine. </pre>", "group_id": 8954, "id": 1164941}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306234612.2737639, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3qb5vqg - Antoine Pitrou - <pre>On Tue, 24 May 2011 20:25:11 +1000 Nick Coghlan &lt;ncoghlan&lt; at &gt;gmail.com&gt; wrote: The I/O stack doesn't use StreamReader and StreamWriter. That's the whole point. Stream* have been made useless by the new I/O stack. Ok, can you explain us the difference, concretely? Thanks Antoine. </pre>", "group_id": 8954, "id": 1164888}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306234615.582104, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3r4na6d - \u0141ukasz Langa - <pre> Wiadomo\u015b\u0107 napisana przez Walter D\u00f6rwald w dniu 2011-05-24, o godz. 12:16: Why not? </pre>", "group_id": 8954, "id": 1164889}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306233720.5315931, "message": "[devel] - Re: Stable buildbots update - http://tinyurl.com/3qbq8a2 - Nick Coghlan - <pre> I could turn test_crashers back on if you like ;) Great work to all involved in tidying things up post-merge! Cheers, Nick. </pre>", "group_id": 8954, "id": 1164795}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306234619.4294381, "message": "[devel] - Re: Deprecate codecs.open() and StreamWriter/StreamReader - http://tinyurl.com/3mhklt6 - Victor Stinner - <pre>Le mardi 24 mai 2011 \u00e0 08:16 +0000, Vinay Sajip a \u00e9crit : pip has a pip.backwardcompat module which is vey similar to six. If codecs.open() is deprecated or removed, it will be trivial to add a wrapper for codecs.open() or open() to six and pip.backwardcompat. virtualenv.py starts also with a thin compatibility layer. But yes, each program using a compatibily layer/module will have to be updated. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1164891}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306235520.345376, "message": "[devel] - Re: Deprecate codecs.open() and StreamWriter/StreamReader - http://tinyurl.com/3c3yrlj - Victor Stinner - <pre>Le mardi 24 mai 2011 \u00e0 12:42 +0200, \u0141ukasz Langa a \u00e9crit : We have already an implementation of this idea, it is called io.TextIOWrapper. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1164942}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306237312.125659, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3pehnx4 - Maciej Fijalkowski - <pre>On Sun, May 22, 2011 at 1:57 AM, Artur Siekielski &lt;artur.siekielski&lt; at &gt;gmail.com&gt; wrote: Not sure what scenario exactly are you discussing here, but storing reference counts outside of objects has (at least on a single processor) worse cache locality than inside objects. That would almost certainly be slower for most use cases, except for the copy-on-write fork. I guess recycler papers might be an interesting read: http://www.research.ibm.com/people/d/dfb/recycler.html This is the best reference-counting GC I'm aware of. CPython was not designed for CPU cache usage as far as I'm aware. to perform such experiments (and PyPy has been profiled for CPU cache usage). The main advantage is that you can code your GC without the need to modify the interpreter. On the other hand you obviously don't get benefits on CPython, but maybe it's worth experimenting. Cheers, fijal </pre>", "group_id": 8954, "id": 1165064}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306239115.1079249, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3hndysy - Walter D\u00f6rwald - <pre> Exactly. From another post by Victor: So: implementing this is a lot of work, duplicates existing functionality and is mostly unused. Servus, Walter _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1165193}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306239119.553757, "message": "[devel] - Re: CPython optimization: storing reference countersoutside of objects - http://tinyurl.com/3ofhtka - Stefan Behnel - <pre>Maciej Fijalkowski, 24.05.2011 13:31: That's a pretty bold statement to make on this list. Even if it wasn't originally \"designed\" for (efficient?) CPU cache usage, it's certainly been around for long enough to have received numerous performance tweaks in that regard. I doubt that efficient CPU cache usage was a major design goal of PyPy right from the start. IMHO, the project has changed its objectives way too many times to claim something like that, especially at the low level where the CPU cache becomes relevant. I remember that not so long ago, PyPy was hugely memory hungry compared to CPython. Although, one could certainly call *that* \"designed for CPU cache usage\"... ;) Stefan </pre>", "group_id": 8954, "id": 1165195}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306240921.1770821, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3o3dnso - Antoine Pitrou - <pre>On Tue, 24 May 2011 14:05:26 +0200 Stefan Behnel &lt;stefan_ml&lt; at &gt;behnel.de&gt; wrote: Well, to be honest, \"hugely memory hungry\" doesn't necessarily mean cache-averse. It depends on the locality of memory access patterns. Regards Antoine. </pre>", "group_id": 8954, "id": 1165339}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306240914.1809299, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3bbwgzr - Sturla Molden - <pre>Den 24.05.2011 13:31, skrev Maciej Fijalkowski: Artur Siekielski is not talking about cache locality, but copy-on-write fork on Linux et al. When reference counts are updated after forking, memory pages marked copy-on-write are copied if they store reference counts. And then he quickly runs out of memory. He wants to put reference counts and PyObjects in different pages, so only the pages with reference counts get copied. I don't think he cares about cache locality at all, but the rest of us do :-) Sturla </pre>", "group_id": 8954, "id": 1165336}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306240011.876636, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/427ohwx - Sturla Molden - <pre>Den 24.05.2011 11:55, skrev Artur Siekielski: The bottleneck is likely the serialization, but only if you serialize large objects. IPC is always very fast, at least on localhost . Just out of curiosity, have you considered using a database? Sqlite and BSD DB can even be put in shared memory if you want. It sounds like you are trying to solve a database problem using os.fork, something which is more or less doomed to fail (i.e. you have to replicate all effort put into scaling up databases). If a database is too slow, I am rather sure you need something else than Python as well. Sturla </pre>", "group_id": 8954, "id": 1165260}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306240918.1696601, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/44wexze - Sturla Molden - <pre>Den 24.05.2011 11:55, skrev Artur Siekielski: Then I have a solution for you, one that is cheaper than anything else you are trying to do (taking work hours into account): BUY MORE RAM! RAM is damn cheap. You just need more of it. And 64-bit Python :-) Sturla </pre>", "group_id": 8954, "id": 1165338}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306242712.297106, "message": "[devel] - Re: CPython optimization: storing reference countersoutside of objects - http://tinyurl.com/3nt74z2 - Stefan Behnel - <pre>Antoine Pitrou, 24.05.2011 14:32: Sure. AFAIR (and Maciej is certainly the right person to prove me wrong), the problem at the time was that the overall memory footprint of objects was too high. That, at least, speaks against efficient cache usage and makes it's more likely to result in cache thrashing. In any case, we're talking about a historical problem they already fixed. Stefan </pre>", "group_id": 8954, "id": 1165588}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306248114.147532, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3ht7ec4 - Nick Coghlan - <pre> As a statement of Guido's original intent, I'd side with Maciej (Guido has made it pretty clear that he subscribes to the \"first, make it work, and only worry about making it faster if that first approach isn't good enough\" school of thought). Various *parts* of CPython, on the other hand, have indeed been optimised over the years to be quite aware of potential low level CPU and RAM effects (e.g. dicts, sorting, the small object allocator). Cheers, Nick. </pre>", "group_id": 8954, "id": 1166590}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306251715.7462161, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/44cftly - Artur Siekielski - <pre>2011/5/24 Sturla Molden &lt;sturla&lt; at &gt;molden.no&gt;: It cannot be \"fast\" compared to direct memory access. Here is a benchmark: summing numbers in a small list in a child process using multiprocessing \"manager\": http://dpaste.org/QzKr/ , and using implicit copy of the structure after fork(): http://dpaste.org/q3eh/. The first is 200 TIMES SLOWER. It means if the work finishes in 20 seconds using fork(), the same work will require more than one hour using multiprocessing manager. Disk access is about 1000x slower than memory access in C, and Python in a worst case is 50x slower than C, so there is still a huge win (not to mention that in a common case Python is only a few times slower). Artur </pre>", "group_id": 8954, "id": 1167256}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306252613.753063, "message": "[devel] - Re: CPython optimization: storing reference countersoutside of objects - http://tinyurl.com/3prxyr3 - Terry Reedy - <pre> It seems clear that separating reference counts from objects satisfies a specialized need and should be done in a spedial, patched version of CPython rather than the general distribution. </pre>", "group_id": 8954, "id": 1167417}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306254415.282845, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl - http://tinyurl.com/454uvue - Victor Stinner - <pre>Le mardi 24 mai 2011 \u00e0 11:27 -0400, Terry Reedy a \u00e9crit : An important feature of a CPRNG (cryptographic pseudo-random number generator) is that even if you know all of its output, you cannot rebuild its internal state to guess next (or maybe previous number). The CPRNG can for example hash its output using SHA-1: you will have to \"break\" the SHA-1 hash (maybe using \"salt\"). Another important feature is that even if you know the internal state, you will not be able to guess all previous and next numbers, because the internal state is regulary updated using an external source of entropy. Use RAND_add() to do that explicitly. We may add a link to Wikipedia: http://en.wikipedia.org/wiki/CPRNG Read the \"Requirements\" section, it's maybe more correct than my explanation: http://en.wikipedia.org/wiki/CPRNG#Requirements About the random module, it must not be used to generate passwords or certificates, because it is easy to rebuild the internal state of a Mersenne Twister generator if you know the previous 6</pre>", "group_id": 8954, "id": 1167625}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306257117.2681501, "message": "[devel] - Re: Stable buildbots update - http://permalink.gmane.org/gmane.comp.python.devel/124773 - Terry Reedy - <pre> No need. One xp (but not the other) and win7 turned red again. </pre>", "group_id": 8954, "id": 1168142}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306258073.228157, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3rgv7jf - geremy condra - <pre> I'm not sure I agree, especially given that the classical answer to GIL woes has been to tell people to fork() themselves. There has to be a lot of code out there that would benefit from this. Geremy Condra </pre>", "group_id": 8954, "id": 1168310}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306257113.2032311, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3qhrfge - Terry Reedy - <pre> As I understand it, you (and others) wrote codecs long ago and recently other people wrote the new i/o stack, which sometimes uses codecs, and when they needed to add a few details, they 'naturally' added them to the module they were working on and understood (and planned to rewrite in C) rather than to the older module that they maybe did not completely understand and which is only in Python. The Victor comes along to do maintenance on some of the Asian codecs and discovers that he needs to make changes in two (or more?) places rather than one, which he naturally finds unsatifactory. I think we should separate two issues: removing internal implementation duplication and removing external api duplication. I should think that the former should not be too controversial. The latter, I know, is more contentious. One problem is that stdlib changes that perhaps 'should' have been made in 3.0/1 could not be discovered until the moratorium and greater focus on the stdlib. </pre>", "group_id": 8954, "id": 1168138}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306259874.1291699, "message": "[devel] - Re: cpython: move specialized dir implementations into __dir__ methods (closes #12166) - http://tinyurl.com/4xnueey - Benjamin Peterson - <pre>2011/5/24 Georg Brandl &lt;g.brandl&lt; at &gt;gmx.net&gt;: Yes, I was wondering about that, so I just picked one. :) \"-&gt;\" seems to be better for return values, though, given the resemblance to annotations. </pre>", "group_id": 8954, "id": 1168651}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306259877.3040459, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3t22ebp - Cesare Di Mauro - <pre>2011/5/24 Stefan Behnel &lt;stefan_ml&lt; at &gt;behnel.de&gt; Maybe a change on memory allocation granularity can help here. Raising it to 16 and 32 bytes for 32 and 64 bits system respectively guarantees that an access to ob_refcnt and/or ob_type will put on the cache line some other information for the same object, which is usually required by itself (except for very simple ones, such as PyNone, PyEllipsis, etc.). Think about a long, a tuple, a list, a dictionary, ecc.: all of them have some critical data after these fields, that most likely will be accessed after INCRef or type checking. Regards, Cesare </pre>", "group_id": 8954, "id": 1168654}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306258973.7367029, "message": "[devel] - Re: cpython: move specialized dir implementations into __dir__ methods (closes #12166) - http://tinyurl.com/3c5wrx7 - Georg Brandl - <pre> This is interesting: I though we use \"-&gt;\" to specify the return value (or its type). __instancecheck__ and __subclasscheck__ set a different precedent, while __sizeof__ follows. I didn't look at the files to check for other examples. Georg </pre>", "group_id": 8954, "id": 1168471}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306259880.2256811, "message": "[devel] - Re: Stable buildbots update - http://tinyurl.com/3njn2tj - Bill Janssen - <pre> Perhaps more importantly, parc-leopard-1 and parc-tiger-1 are two of the very few usually-connected buildbots we have running on big-endian architectures, along with loewis-sun (I *think* Solaris-10 on SPARC is still big-endian). Bill </pre>", "group_id": 8954, "id": 1168655}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306260773.466378, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl - http://tinyurl.com/3wmookp - Terry Reedy - <pre> So it is presumably slower. I still do not get RAND_pseudo_bytes, which somehow decides internally what to do. That would be helpful </pre>", "group_id": 8954, "id": 1168850}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306262575.137141, "message": "[devel] - Re: CPython optimization: storing reference counters outside of objects - http://tinyurl.com/3ju992e - Sturla Molden - <pre>Den 24.05.2011 17:39, skrev Artur Siekielski: You can put databases in shared memory (e.g. Sqlite and BSDDB have options for this). On linux you can also mount /dev/shm as ramdisk. Also, why do you distrust the database developers of Oracle et al. not to do the suffient optimizations? Sturla </pre>", "group_id": 8954, "id": 1169154}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306266235.1837161, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3w2xvc6 - Martin (gzlist - <pre> There are some modules that try to stay compatible with Python 2 and 3 without a source translation step. Removing the codecs classes would mean they'd have to add a few more compatibility hacks, but could be done. As an aside, I'm still not sure how the io module should be used. Example, a simple task I've used StreamWriter classes for is to wrap stdout. If the stdout.encoding can't represent a character, using \"replace\" means you can write any unicode string without throwing a UnicodeEncodeError. With the io module, it seems you need to construct a new TextIOWrapper object, passing the attributes of the old one as parameters, and as soon as someone passes something that's not a TextIOWrapper (say, a StringIO object) your code breaks. Is the intention that code dealing with streams needs to be covered in isinstance checks in Python 3? Martin </pre>", "group_id": 8954, "id": 1169821}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306271694.303709, "message": "[devel] - [pyodbc] Setting values to SQL_* constants while creating a connection object - http://tinyurl.com/3lrhkyt - srinivasan munisamy - <pre>Hi, I would like to know how to set values to values to SQL_* constants while creatinga db connection through pyodbc module. For example, i am getting a connection object like below: In [27]: dbh1 = pyodbc.connect(\"DSN=&lt;dsn&gt;;UID=&lt;uid&gt;;PWD=&lt;pwd&gt;;DATABASE=&lt;database&gt;;APP=&lt;app_name&gt;\") In [28]: dbh1.getinfo(pyodbc.SQL_DESCRIBE_PARAMETER) Out[28]: True I want to set this SQL_DESCRIBE_PARAMETER to false for this connection object. How could i do that? Please help me in figuring it out. Thanks, Srini </pre>", "group_id": 8954, "id": 1170739}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306276194.3070419, "message": "[devel] - Re: [pyodbc] Setting values to SQL_* constants while creating a connection object - http://tinyurl.com/3dmrkxy - Terry Reedy - <pre> Please direct Python use questions to python-listor other user discussion forums. Py-dev is for discussion of development of the next versions of Python. </pre>", "group_id": 8954, "id": 1171428}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306300495.8694019, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl - http://tinyurl.com/43qmmmj - Nick Coghlan - <pre> The more important feature here is that it is exposing *OpenSSL's* random number generation, rather than our own. A CPRNG isn't *necessarily* slower than a non-crypto one (particularly on systems with dedicated crypto hardware), but they can definitely fail to return data if there isn't enough entropy available in the pool (and the system has to have a usable entropy source in the first place). The RAND_bytes() documentation should probably make it clearer that unlike the random module and RAND_pseudo_bytes(), RAND_bytes() can *fail* (by raising SSLError) if it isn't in a position to provide the requested random data. The pseudo_bytes version just encapsulates a fallback technique that may be suitable in some circumstances: if crypto quality random data is not available, fall back on PRNG data instead of failing. It is most suitable for tasks like prototyping an algorithm in Python for later conversion to C, or similar tasks where it is desirable to use the OpenSSL PRNG over the one in the random module. </pre>", "group_id": 8954, "id": 1174498}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306304096.0174389, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl - http://tinyurl.com/3tgxzd7 - Petri Lehtinen - <pre> According to the RAND_bytes manual page from OpenSSL: RAND_bytes() puts num cryptographically strong pseudo-random bytes into buf. An error occurs if the PRNG has not been seeded with enough randomness to ensure an unpredictable byte sequence. RAND_pseudo_bytes() puts num pseudo-random bytes into buf. Pseudo-random byte sequences generated by RAND_pseudo_bytes() will be unique if they are of sufficient length, but are not necessarily unpredictable. They can be used for non-cryptographic purposes and for certain purposes in cryptographic protocols, but usually not for key generation etc. And: RAND_bytes() returns 1 on success, 0 otherwise. The error code can be obtained by ERR_get_error(3). RAND_pseudo_bytes() returns 1 if the bytes generated are cryptographically strong, 0 otherwise. Both functions return -1 if they are not supported by the current RAND method. So it seems to me that RAND_bytes() either returns cryptographically strong data or</pre>", "group_id": 8954, "id": 1175085}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306313217.826453, "message": "[devel] - Extending os.chown() to accept user/group names - http://tinyurl.com/44f7888 - Sandro Tosi - <pre>Hi all, before opening an issue to track the request, I'd like to ask advice here about this: extend os.chown() to accept even user/group names instead of just uid and gid. On a Unix system, you can call chown command passing either id or names, so it seems (to me at least) natural to expect os.chown() to behave similarly; but that's not the case. I can see os module wants to be a thin wrapper around OS syscalls and chown(2) accepts only uid/gid as input, so what would be best: extend os.chown() or provide a chown() function in shutil module for this purpose? Thanks in advance, </pre>", "group_id": 8954, "id": 1175916}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306316817.8432069, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3kfcp47 - M.-A. Lemburg - <pre> You are missing the point: we have StreamReader and StreamWriter APIs on codecs to allow each codecs to implement more efficient ways of encoding and decoding streams. Examples of such optimizations are reading the stream in chunks that can be decoded in one piece, or writing to the stream in a way that doesn't generate encoding state problems on the receiving end by ending transmission half-way through a shift block. Of course, you won't find many direct uses of these APIs, since most of the time, applications will simply use codecs.open() to automatically benefit from these optimizations. OTOH, TextIOWrapper doesn't know anything about specific encodings and thus does not allow for such optimizations to be implemented by codecs. We don't have many such specialized implementations in the stdlib, but this doesn't mean that there's no use for them. It just means that developers and users are simply unaware of the possibilities opened by these stateful stream APIs. </pre>", "group_id": 8954, "id": 1176208}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306316820.8311851, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl - http://tinyurl.com/3h7d6mz - Victor Stinner - <pre>Le mercredi 25 mai 2011 \u00e0 08:59 +0300, Petri Lehtinen a \u00e9crit : RAND_bytes() raises an SSLError on error. You can check if there is enough entropy before calling RAND_bytes() using RAND_status(). I documented this two infos. No, it can fail if the RAND method was changed and the current RAND method doesn't support this operation. Example: ---- c_void_p), ('bytes', c_void_p), ('cleanup', c_void_p), ('add', c_void_p), ('pseudorand', c_void_p), ('status', c_void_p)) ... ... ssl.SSLError: [Errno 0] None ... ssl.SSLError: [Errno 0] None ------ Cool, ssl.RAND_pseudo_bytes() raises also an error, as expected :-) Yes, if the PRNG was not seed with enough data, the RAND_pseudo_bytes() Python function returns (random_bytes, False). I already patched the doc of the random module to add a security warning. Well, you don't really need to know how a CSPRNG is implemented, just that random cannot be used for security and that ssl.RAND_bytes() raises an error if was seeded with enough data. Tell me if my warnin</pre>", "group_id": 8954, "id": 1176209}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306315020.090775, "message": "[devel] - Re: [Python-checkins] Daily reference leaks(234021dcad93): sum=61 - http://tinyurl.com/3sagepm - Victor Stinner - <pre>Le mercredi 25 mai 2011 \u00e0 15:13 +1000, Nick Coghlan a \u00e9crit : See the issue http://bugs.python.org/issue12167 : Antoine listed tests leaking references, and I already fixed some of them. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1176095}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306315919.7370031, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl - http://tinyurl.com/3ph6h5d - Victor Stinner - <pre>Le mercredi 25 mai 2011 \u00e0 15:09 +1000, Nick Coghlan a \u00e9crit : According to the doc, both functions can fail, but it is more likely than RAND_bytes() fail. I disabled temporary Linux random devices to test RAND_bytes() error code: mv /dev/random /dev/random.xxx mv /dev/urandom /dev/urandom.xxx In this case, RAND_pseudo_bytes() generates non-cryptographic random numbers: it returns (random_bytes, False). I don't know how to test RAND_pseudo_bytes() error code. -- I patched test_ssl to test that RAND_bytes() raises an SSLError if there is not enough entropy, and I also improved the documentation to detail the error cases. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1176145}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306319517.3478689, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl - http://tinyurl.com/3vyfk6a - Petri Lehtinen - <pre> Looks good to me. Regarding style, you should probably make a link, like :func:`ssl.RAND_bytes()`. Petri </pre>", "group_id": 8954, "id": 1176355}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306321319.131207, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl - http://tinyurl.com/4xpn8qw - Eric Smith - <pre> Does \"are not cryptographic\" have any meaning? (I'm not an expert, just not sure). Should it not be \"cryptographically secure\", to match the next sentence? Eric. </pre>", "group_id": 8954, "id": 1176544}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306321325.0822721, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl - http://tinyurl.com/3sawqh2 - Petri Lehtinen - <pre> Or just remove \", they are not cryptographic\" altogether? </pre>", "group_id": 8954, "id": 1176546}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306322217.20557, "message": "[devel] - Re: Deprecate codecs.open() and StreamWriter/StreamReader - http://tinyurl.com/4ypxl2y - Victor Stinner - <pre>Le mercredi 25 mai 2011 \u00e0 11:38 +0200, M.-A. Lemburg a \u00e9crit : Does at least one codec implement such implementation in its StreamReader or StreamWriter class? And can't we implement such optimization in incremental encoders and decoders (or in TextIOWrapper)? I checked all multibyte codecs (UTF and CJK codecs) and I don't see any of such optimization. UTF codecs handle the BOM, but don't have anything looking like an optimization. CJK codecs use multibytecodec, MultibyteStreamReader and MultibyteStreamWriter, which don't look to be optimized. But I missed maybe something? TextIOWrapper has an advanced buffer algorithm to prefetch (readahead) some bytes at each read to speed up small read. It is difficult to implement such algorithm, but it's done and it works. -- Ok, let's stop to speak about theorical optimizations, and let's do a benchmark to compare codecs and the io modules on reading files! I tested Python 3.3 (70370:178d367c9733) compiled in release mode (gcc -O3) on a Pentium4 &lt; at &gt; 3 GHz with 2 </pre>", "group_id": 8954, "id": 1176645}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306328579.782537, "message": "[devel] - Re: [Python-checkins] Daily reference leaks (234021dcad93): sum=61 - http://tinyurl.com/4xoe7s9 - Nick Coghlan - <pre>On Wed, May 25, 2011 at 7:10 PM, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; wrote: Thanks for the issue link. I'd seen a few of these reports go by, so it's good to know that dealing with it is in progress. Cheers, Nick. </pre>", "group_id": 8954, "id": 1177385}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306329479.0214031, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl - http://tinyurl.com/3k89dyw - Eric Smith - <pre> Good call. That's a better change. Eric. </pre>", "group_id": 8954, "id": 1177585}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306332181.4256091, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3v2z2ty - Antoine Pitrou - <pre>On Wed, 25 May 2011 09:41:46 -0400 Barry Warsaw &lt;barry&lt; at &gt;python.org&gt; wrote: +1 for shutil.chown(). Regards Antoine. </pre>", "group_id": 8954, "id": 1178372}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306331282.563571, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3b9pkc6 - Barry Warsaw - <pre> I think it would be a nice feature, and I can see the conflict. OT1H you want to keep os.chown() a thin wrapper, but OTOH you'd rather not have to add a new, arguably more difficult to discover, function. Given those two choices, I still think I'd come down on adding a new function and shutil.chown() seems an appropriate place for it. Cheers, -Barry </pre>", "group_id": 8954, "id": 1178130}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306331285.4211359, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/4yq6ssp - M.-A. Lemburg - <pre> I don't see how, since you need control over the file API methods in order to implement such optimizations. OTOH, adding lots of special cases to TextIOWrapper isn't a good either, since these optimizations would then only trigger for a small number of codecs and completely leave out 3rd party codecs. No, you haven't missed such per-codec optimizations. The base classes implement general purpose support for reading from streams in chunks, but the support isn't optimized per codec. For UTF-16 it would e.g. make sense to always read data in blocks with even sizes, removing the trial-and-error decoding and extra buffering currently done by the base classes. For UTF-32, the blocks should have size % 4 == 0. For UTF-8 (and other variable length encodings) it would make sense looking at the end of the (bytes) data read from the stream to see whether a complete code point was read or not, rather than simply running the decoder on the complete data set, only to find that a few bytes at the end are missing. For</pre>", "group_id": 8954, "id": 1178132}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353861.1345789, "message": "[devel] - Re: [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl - http://tinyurl.com/3lvyu8o - Terry Reedy - <pre> I agree, thought from a different stance, I think. The issue is whether we should 'automatically' expose everything is a wrapped library, even if it duplicates existing functions. I think not. But in this case, at least one of the two functions is sufficiently different, and the newest doc patches clarify the situation. </pre>", "group_id": 8954, "id": 1183732}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353854.1353149, "message": "[devel] - Re: Deprecate codecs.open() and StreamWriter/StreamReader - http://tinyurl.com/3dwewwo - Victor Stinner - <pre>Le mercredi 25 mai 2011 \u00e0 15:43 +0200, M.-A. Lemburg a \u00e9crit : I think that the readahead algorithm is much more faster than trying to avoid partial input, and it's not a problem to have partial input if you use an incremental decoder. TextIOWrapper implements this optimization using its readahead algorithm. Do you mean that you would like to reimplement codecs in C? It is not revelant to compare codecs and _pyio, because codecs reuses BufferedReader (of the io module, not of the _pyio module), and io is the main I/O module of Python 3. But well, as you want, here is a benchmark comparing: _pyio.TextIOWrapper(io.open(filename, 'rb'), encoding) and codecs.open(filename, encoding) The only change with my previous bench.py script is the test_io() function : def test_io(test_func, chunk_size): with open(FILENAME, 'rb') as buffered: f = _pyio.TextIOWrapper(buffered, ENCODING) test_file(f, test_func, chunk_size) f.close() (1) Decode Objects/unicodeobject.c (317336 ch</pre>", "group_id": 8954, "id": 1183729}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353864.1209371, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3hw6z28 - Charles-Fran\u00e7ois Natali - <pre>While we're at it, adding a \"recursive\" argument to this shutil.chown could also be useful. </pre>", "group_id": 8954, "id": 1183733}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353867.262583, "message": "[devel] - Re: cpython: Fix closes issue #11109 - socketserver.ForkingMixIn leaves zombies, also fails - http://tinyurl.com/3w298q6 - Antoine Pitrou - <pre>On Wed, 25 May 2011 18:26:46 +0200 senthil.kumaran &lt;python-checkins&lt; at &gt;python.org&gt; wrote: Is it reasonable, performance-wise, to do this at every iteration of the loop (that is, at every incoming connection)? Regards Antoine. </pre>", "group_id": 8954, "id": 1183735}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353846.0421829, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3tl8l5v - Dirkjan Ochtman - <pre> Right. Please add a mention of shutil.chown() to the os.chown() docs, though. Cheers, Dirkjan _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1183725}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353850.8607669, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3htwjsm - Barry Warsaw - <pre> Brilliant! -Barry </pre>", "group_id": 8954, "id": 1183727}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353874.4187839, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3lh8x8t - Eric Smith - <pre> You can do all of this with an appropriate application of os.walk(). Eric. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1183741}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353878.1132491, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3nzez46 - Petri Lehtinen - <pre> FWIW, the chown program (in GNU coreutils at least) has a -R flag for recursive operation, and I've found it *extremely* useful on many situations. Petri _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1183742}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353881.4429691, "message": "[devel] - Re: Python 3.3 release schedule posted - http://tinyurl.com/3wonlsj - Michael Foord - <pre> Hey lvh, It's worth following this up. If Jim Fulton hasn't had time to move this forward and you have the bandwidth to work on it then it would be great to see some action. All the best, Michael Foord </pre>", "group_id": 8954, "id": 1183743}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353858.1501679, "message": "[devel] - Re: Deprecate codecs.open() and StreamWriter/StreamReader - http://tinyurl.com/3rhs542 - Victor Stinner - <pre>Le mercredi 25 mai 2011 \u00e0 13:10 +0200, Victor Stinner a \u00e9crit : Oh, I understood: it's maybe the universal newline mode of TextIOWrapper was enabled. If you disable is using open(..., newline='\\n'), io and codecs run at the same speed to read the whole content of the file (f.read()). Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1183730}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353870.806464, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3wd7be6 - Victor Stinner - <pre>Le mercredi 25 mai 2011 \u00e0 18:46 +0200, Charles-Fran\u00e7ois Natali a \u00e9crit : I don't like the idea of a recursive flag. I would prefer a \"map-like\" function to \"apply\" a function on all files of a directory. Something like shutil.apply_recursive(shutil.chown)... ... maybe with options to choose between deep-first search and breadth-first search, filter (filenames, file size, files only, directories only, other attributes?), directory before files (may be need for chmod(0o000)), etc. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1183739}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306353885.0044079, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3vhyfd6 - Charles-Fran\u00e7ois Natali - <pre> I was also thinking about this possibility. The advantage is that we could factor-out the recursive walk logic to make it available for other functions (chown, chmod...). It doesn't map well to the Unix command, though. Then, I wonder why shutil.copytree and shutil.rmtree are provided. Recursive rm/copy/chown/chmod are extremely useful in system administration scripts. Furthermore, it's not as simple as it seems because of symlinks, see for example http://bugs.python.org/issue4489 . </pre>", "group_id": 8954, "id": 1183745}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306358400.8898859, "message": "[devel] - Re: cpython: Fix closes issue #11109 - socketserver.ForkingMixIn leaves zombies, also fails - http://tinyurl.com/3bdd4jn - Charles-Fran\u00e7ois Natali - <pre> I haven't measured it, but it's O(N) where N is the number of children. It should be possible to optimize this by putting all the children in a process group (the other advantage is that we wouldn't wait() children not spawned by socketserver). cf </pre>", "group_id": 8954, "id": 1184458}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306360199.9492459, "message": "[devel] - multibytecodex - http://tinyurl.com/4y44243 - Laura Creighton - <pre> This just in from pypy-dev. I am reposting it here because I am fairly certain that nobody on the pypy-dev mailing list uses the multibytecodex, but there has got to be at least one person here who does. Please reply to the pypy-dev article, not here, or mail to pypy-dev&lt; at &gt;python.org if you are not on the pypy-dev mailing list (but have delivery turned off as many of you do.) Thank you, Laura ------- Forwarded Message From: Armin Rigo &lt;arigo&lt; at &gt;tunes.org&gt; Date: Wed, 25 May 2011 21:39:35 +0200 To: pypy-dev&lt; at &gt;python.org Subject: [pypy-dev] multibytecodec: missing features Hi all, Here are the missing features in multibytecodec: * support for ``errors !=3D \"strict\"''. * classes MultibyteIncrementalEncoder, MultibyteIncrementalDecoder, MultibyteStreamReader and MultibyteStreamWriter. One reason I didn't implement the classes yet is that I couldn't understand two points in how they are supposed to work. But it seems that there are really two bugs, as I've been pointed to: http://bugs.python.org/issue12100 a</pre>", "group_id": 8954, "id": 1184602}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306362000.671454, "message": "[devel] - Re: multibytecodex - http://tinyurl.com/3zqkezj - Victor Stinner - <pre>Le mercredi 25 mai 2011 \u00e0 23:41 +0200, Laura Creighton a \u00e9crit : I fixed #12100 in Python 2.7, 3.1, 3.2, 3.3 yesterday. I plan also to fix #12171 in these four versions, it should be done next days. Both bugs are related to encoders. I don't think that anyone is using Python CJK codecs to encode text (because nobody noticed these bugs before), but more likely to decode text. Anyway, you should implement a codec without these *bugs*. For your information, I added more tests to the CJK codecs (e.g. see #12057), and I plan to add more tests next weeks. I plan also to fix issue #12016, yet another CJK codec bug. You may want to wait until all of these bugs are fixed before working on your own implementation, or implement directly a version without all of these bugs, and then upgrade the test suite. The support of error handlers different than strict is far from being perfect. Issue #12016 is the main problem, but there are other minor issues. In some cases, invalid byte sequences are ignored even with</pre>", "group_id": 8954, "id": 1184845}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306362004.8866489, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3sgmvxz - Tim Delaney - <pre>2011/5/26 Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt; Pass an iterable to shutil.chown()? Then you could call it like: shutil.chown(os.walk(path)) Then of course you have the difficulty of wanting to pass either an iterator or a single path - probably prefer two functions e.g.: shutil.chown(path) shutil.chown_many(iter) Tim Delaney </pre>", "group_id": 8954, "id": 1184846}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306387560.174881, "message": "[devel] - Re: cpython: Fix closes issue #11109 - socketserver.ForkingMixIn leaves zombies, also fails - http://tinyurl.com/3og4kh2 - Senthil Kumaran - <pre> Antoine Pitrou wrote: If not here, the call was being done at the process_request level when creating a new child process and the wait would have been there. I am not sure, how much performance different (lag) this aggressive collection can bring. Charles-Fran\u00e7ois Natali wrote: +1. This is definitely a good idea. The change needs to be done in the collection_children routine which tries to wait for all children to finish instead of just the ones forked by the socketserver. Shall raise ticket for this. </pre>", "group_id": 8954, "id": 1188311}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306390260.1457751, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/43fpt73 - Nick Coghlan - <pre>2011/5/26 Charles-Fran\u00e7ois Natali &lt;neologix&lt; at &gt;free.fr&gt;: Rather than a fixed binary flag, I would suggest following the precedent of copytree and rmtree, and provide recursive functionality as a separate shutil function (i.e. shutil.chmodtree, shutil.chowntree). As noted, while these *can* be written manually, it is convenient to have the logic for handling symlinks dealt with for you, as well as not having to look up the particular incantation for correctly linking os.walk and the relevant operations. Cheers, Nick. </pre>", "group_id": 8954, "id": 1188648}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306391162.393398, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/43f2kuc - Petri Lehtinen - <pre> +1 This is exactly what I meant when saying that the -R option to chown and chmod shell commands is useful. I *could* do it without them, but writing the same logic every time with error handling would be cumbersome. Petri _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1188847}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306413783.3334651, "message": "[devel] - Re: [Python-checkins] cpython: Avoid useless \"++\" at the end of functions - http://tinyurl.com/3f2yknm - Victor Stinner - <pre>Le jeudi 26 mai 2011 \u00e0 08:13 -0400, Eric Smith a \u00e9crit : You don't have to remember. Test the result of the function, it will not give the expected output. I don't think that you need fuzzing or a complex tool to detect that the new code doesn't behave correctly. What? It's not a bug. Ading new non-tested code is a bug :-) It makes Python faster (!) and make silent the Clang Static Analyzer :-) Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1191409}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306419184.973752, "message": "[devel] - Re: [Python-checkins] cpython: Avoid useless \"++\" at the end of functions - http://tinyurl.com/3nwd5y9 - Eric Smith - <pre> True. But assuming all code additions will have 100% branch coverage in the C code is foolish. I doubt that. I care less about that than maintainability and future-proofing. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1192124}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306421883.3683031, "message": "[devel] - Re: [Python-checkins] cpython: Avoid useless \"++\" at the end of functions - http://tinyurl.com/3zdc3do - Benjamin Peterson - <pre>2011/5/26 Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt;: Surely, GCC can optimize that out. </pre>", "group_id": 8954, "id": 1192697}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306423743.9981019, "message": "[devel] - Re: [Python-checkins] cpython: Avoid useless \"++\" at the end of functions - http://tinyurl.com/3kaf6xw - Eric Smith - <pre> I have looked at it. I think the code was better before the patch. If I were looking at this, I'd have to wonder why the pointer was incremented everywhere else, but not here. This is especially true when the changed code isn't particularly near the end of the function. </pre>", "group_id": 8954, "id": 1193086}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306424642.9064431, "message": "[devel] - Re: [Python-checkins] cpython: Avoid useless \"++\" at the end of functions - http://tinyurl.com/3uxmmw9 - Ronald Oussoren - <pre> On 26 May, 2011, at 16:10, Eric Smith wrote: Have to looked at the patch? The patch and resulting code look sane to me, and if anything at most of the updated segments look cleaner after the patch. Ronald</pre>", "group_id": 8954, "id": 1193221}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306433642.4978909, "message": "[devel] - Re: [Python-checkins] cpython: Avoid useless \"++\" atthe end of functions - http://tinyurl.com/3vgjdme - Terry Reedy - <pre> Lets assume that the function currently does what it is supposed to do, as verified by tests. Then adding an unneeded increment in case the function is redefined in the future so that it needs more code strikes me as YAGNI. Certainly, reading it today with an unused increment suggests to me that something is missing that would use the incremented value. This strike me as different from adding a comma at the end of a Python sequence display. </pre>", "group_id": 8954, "id": 1194678}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306433645.469074, "message": "[devel] - Re: [Python-checkins] cpython: Avoid useless \"++\" at the end of functions - http://tinyurl.com/3pj6y8o - Guido van Rossum - <pre> Sorry to butt in here, but I agree with Eric that it was better before. There is a common idiom, *pointer++ = &lt;something&gt;, and whenever you see that you know that you are appending something to an output buffer. Perhaps the most important idea here is that this maintains the *invariant* \"pointer points just after the last thing in the buffer\". Always maintaining the invariant is better than trying to micro-optimize things so as to avoid updating dead values. The compiler is better at that. </pre>", "group_id": 8954, "id": 1194680}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306434549.7636609, "message": "[devel] - Re: cpython: Avoid useless \"++\" at the end of functions - http://tinyurl.com/3do6jc9 - Benjamin Peterson - <pre>2011/5/26 Terry Reedy &lt;tjreedy&lt; at &gt;udel.edu&gt;: I think a more general formulation would be: \"Idiomatic code is more important than making static analyzers happy.\" </pre>", "group_id": 8954, "id": 1194767}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306434542.5838439, "message": "[devel] - Re: [Python-checkins] cpython: Avoid useless \"++\" at the end of functions - http://tinyurl.com/3tx64qz - Alexander Belopolsky - <pre>.. +1 To me, *p++ = c is an idiomatic way to fill the buffer. I prefer to think of p as the state of the stream for which adding a character is impossible without advancing the state. Seeing *p = c will definitely make me pause and think whether or not it is a bug. </pre>", "group_id": 8954, "id": 1194765}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306434546.7480209, "message": "[devel] - Re: cpython: Avoid useless \"++\" at the end of functions - http://tinyurl.com/3lwhfak - Terry Reedy - <pre> This explanation makes sense (more than Eric's version of perhaps the same thing ;-). http://bugs.python.org/issue12188 \"A condensed version of the above added to PEP 7 would help new developers see the usage as local idiom rather than style bug.\" Terry J. Reedy </pre>", "group_id": 8954, "id": 1194766}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306441743.104342, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3pahles - Sandro Tosi - <pre> and so shutil.chown() be it: http://bugs.python.org/issue12191 Currently, only the function for a single file is implemented, let's look later what to do for a recursive one. Cheers, </pre>", "group_id": 8954, "id": 1195684}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306485338.430042, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3w4aoqj - M.-A. Lemburg - <pre> Depends on where you're coming from. For non-seekable streams such as sockets or pipes, readahead is not going to work. For seekable streams, I agree that readahead is better strategy. And of course, it also makes sense to use incremental decoders for these encodings. It does yes, but the above was an optimization specific to single character encodings, not all encodings and TextIOWrapper doesn't know anything about specific characteristics of the underlying encodings (except perhaps a few special cases). As use of Unicode codecs increases in Python applications, this would certainly be an approach to consider, yes. Looking at the current situation, it is better to use TextIOWrapper as it provides better performance, but since TextIOWrapper cannot (per desing) provide per-codec optimizations, this is likely to change with a codec rewrite in C of codecs that benefit a lot from such specific optimizations. They both use whatever stream you pass in as parameter, so your TextIOWrapper benchmark will al</pre>", "group_id": 8954, "id": 1202549}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306498961.121531, "message": "[devel] - Re: [Python-checkins] cpython: Avoid useless \"++\" atthe end of functions - http://tinyurl.com/3twymo7 - Eric Smith - <pre>So, given the discussions about this change, can you please revert it, Victor? Eric. On 05/26/2011 08:07 AM, victor.stinner wrote: </pre>", "group_id": 8954, "id": 1204215}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306503522.7586479, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3po6eth - Victor Stinner - <pre>Le vendredi 27 mai 2011 10:17:29, M.-A. Lemburg a \u00e9crit : I don't see how StreamReader/StreamWriter can do a better job than TextIOWrapper for non-seekable streams. Please give me numbers: how fast are your suggested optimizations? Are they faster than readahead? All of your argumentation is based on theorical facts. I am not sure that StreamReader is/can be faster than TextIOWrapper if it is reimplemented in C (see the updated benchmark below, codecs vs _pyio). Oh, I understood why codecs is always faster than _pyio (or even io): it's because of IncrementalNewlineDecoder. To be fair, the read(-1) should be tested without IncrementalNewlineDecoder: e.g. with newline='\\n'. newline='' cannot be used for the read(-1) test, because even if newline='' indicates that we don't want to translate newlines, read(-1) uses the IncrementalNewlineDecoder (which is slower than not calling it at all). We may optimize this specific case in TextIOWrapper. In the 4 tests, TextIOWrapper only calls the decoder</pre>", "group_id": 8954, "id": 1204881}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306504419.5153539, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3nbyajj - Benjamin Peterson - <pre>2011/5/27 Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt;: Please don't hold commits over someone's head. </pre>", "group_id": 8954, "id": 1205083}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306504422.6419089, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3cbh8u5 - M.-A. Lemburg - <pre> Victor, please revert the change. It has *not* been approved ! If we'd go by your reasoning for deprecating and eventually removing parts of the stdlib or Python's subsystems, we'll end up with a barebone version of Python. That's not what we want and it's not what our users want. I have tried to explain the design decisions and reasons for those codec APIs at great length. You've pretty much used up my patience. If you are not going to revert the patch, I will. Wrong order: first write a PEP, then discuss, then get approval, then patch. </pre>", "group_id": 8954, "id": 1205084}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306505321.701082, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3vmkb3s - Nick Coghlan - <pre> Indeed. If another committer says \"please revert and better justify this change\" then we revert it. We don't get into commit wars. Something does need to be done to resolve the duplication of functionality between the io and codecs modules, but it is *far* from clear that deprecating chunks of the longer standing API is the right way to go about it. This is especially true given Guido's explicit direction following the issues with the PyCObject removal in 3.2 that we be *very* conservative about introducing additional incompatibilities between Python 2 and Python 3. Cheers, Nick. </pre>", "group_id": 8954, "id": 1205302}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306510721.0113871, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3dbqge3 - Victor Stinner - <pre>Le vendredi 27 mai 2011 15:33:07, Benjamin Peterson a \u00e9crit : Tell me if I am wrong, but only Marc-Andre is against deprecating StreamReader and StreamWriter. Walter and Antoine are in favor of using TextIOWrapper instead of StreamReader/StreamWriter. Different people would like to be able to call codecs.open() in Python 2 and 3, so I kept the function with its API unchanged, and I documented that open() should be preferred (but I did not deprecated codecs.open). Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1206189}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306511619.345885, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3smo3mg - Benjamin Peterson - <pre>2011/5/27 Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt;: I'm am too. There does, however, seem to be significant disagreement, and it shouldn't be a race to see who can commit first. </pre>", "group_id": 8954, "id": 1206332}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306512526.419615, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3ttfcux - Victor Stinner - <pre>Le vendredi 27 mai 2011 15:42:10, M.-A. Lemburg a \u00e9crit : I don't want to deprecate the whole stdlib, just duplicate old API, to follow \"import this\" mantra: \"There should be one-- and preferably only one --obvious way to do it.\" It's difficult for an user to choose between between open() and codecs.open(). Victor </pre>", "group_id": 8954, "id": 1206514}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306512522.0033879, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3ftucn6 - Victor Stinner - <pre>Le vendredi 27 mai 2011 16:01:14, Nick Coghlan a \u00e9crit : I reverted my controversal commit. Yes, StreamReader &amp; friends are present in Python since Python 2.0. I did search for usage of these classes on the Internet, and except projects implementing their own codecs (and so implement their StreamReader/StreamWriter classes, even if they don't use it), I only found one project using directly StreamReader: pygment (*). I searched quickly, so don't trust these results :-) StreamReader &amp; friends are used indirectly through codecs.open(). My patch changes codecs.open() to make it reuse open (io.TextIOWrapper), so the deprecation of StreamReader would not be noticed by most users. I think that there are much more users of PyCObject than users using directly the StreamReader API (not through codecs.open()). (*) I also found Sphinx, but I was wrong: it doesn't use StreamReader, it just has a full copy of the UTF-8-SIG codec which has a StreamReader class. I don't think that the class is used. Vict</pre>", "group_id": 8954, "id": 1206513}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306514443.958868, "message": "[devel] - Summary of Python tracker Issues - http://tinyurl.com/3l3jkjy - Python tracker - <pre> ACTIVITY SUMMARY (2011-05-20 - 2011-05-27) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2813 (+19) closed 21165 (+50) total 23978 (+69) Open issues with patches: 1216 Issues opened (47) ================== #12128: Allow an abc.abstractproperty to be overridden by an instance http://bugs.python.org/issue12128 opened by cool-RR #12129: Document Object Model API - validation http://bugs.python.org/issue12129 opened by Kyle.Keating #12133: ResourceWarning in urllib.request http://bugs.python.org/issue12133 opened by ezio.melotti #12134: json.dump much slower than dumps http://bugs.python.org/issue12134 opened by poq #12135: The spawn function should return stderr. http://bugs.python.org/issue12135 opened by pitrou #12137: EBADF in test_urllibnet http://bugs.python.org/issue12137 opened by pitrou #12139: Add CCC command support to ftplib http://bugs.py</pre>", "group_id": 8954, "id": 1206809}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306523443.363292, "message": "[devel] - [ANN] Python 2.5.6 released - http://tinyurl.com/3ejoruy - Martin v. L\u00f6wis - <pre>On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.5.6. There were no changes since the release candidate. This is a source-only release that only includes security fixes. The last full bug-fix release of Python 2.5 was Python 2.5.4. Users are encouraged to upgrade to the latest release of Python 2.7 (which is 2.7.1 at this point). This release is most likely the final release of Python 2.5; under the current release policy, no security issues in Python 2.5 will be fixed after October, 2011. This releases fixes issues with the urllib, urllib2, SimpleHTTPServer, and audiop modules. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of bugs fixed. For more information on Python 2.5.6, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.5.6 Highlights of the previous major Python releases are available from the Python 2.5 p</pre>", "group_id": 8954, "id": 1208055}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306521642.2263811, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3dtkt3l - M.-A. Lemburg - <pre> What people tend to miss in this mantra is the last part: \"obvious\". It doesn't say: there should only be one way to do it. There can be many ways, but there should preferably be only one *obvious* way. Using codec.open() is not obvious in Python3, since the standard open() already provides a way to access an encoded stream. Using a builtin is the obvious way to go. It is obvious in Python2 where the standard open() doesn't provide a way to define an encoding, so the user has to explicitly look for this kind of API and then find it in the \"obvious\" (to some extent) codecs module, since that's where encodings happen in Python2. Having multiple ways to do things, is the most natural thing on earth and it's good that way. Python does not and should not force people into doing things in one dictated \"right\" way. It should, however, provide natural choices and obvious hints to find a good solution. And that's what the Zen mantra is all about. As I mentioned on the ticket and in my replies: I'm not against </pre>", "group_id": 8954, "id": 1207812}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306528842.3435869, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3rmajbq - Terry Reedy - <pre> While I am, in general, in favor of removing some duplication, I was and am against doing this change precipitously. So I was for the reversion (noted), at least temporarily. Given the disagreement, I think there should be a PEP with pro and con arguments. </pre>", "group_id": 8954, "id": 1208704}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306546002.393955, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/4yynufc - Nick Coghlan - <pre> Indeed. I'm also against any deprecation in this area, since that just means needless work for anyone that *do* use these APIs (even if those people are few and far between). If we can refactor to remove the duplication of functionality, that's a *much* better solution. If we can carry optparse style argument parsing and 2.x style string formatting, we can carry a couple of legacy codec interface definitions. Cheers, Nick. </pre>", "group_id": 8954, "id": 1210609}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306595504.1639619, "message": "[devel] - Re: Deprecate codecs.open() andStreamWriter/StreamReader - http://tinyurl.com/3kze9uo - Vinay Sajip - <pre> Is it? How about the following decision process? If writing code for Python 3.x only, use open(). If writing code which has to work under both Python 2.x and 3.x, use codecs.open(). BTW I have written code using StreamReader and StreamWriter in the past, though it may not have been published on the Internet. Python is used a lot by companies for internal systems. Such code is seldom published on the Internet, so it seems that there's no real way of knowing how much StreamReader/StreamWriter are used. When looking at porting projects to Python 3.x, I've always adopted a single code-base approach for 2.x and 3.x, as I feel it's the path of least ongoing maintenance and hence (in my experience) the path of least resistance to providing 3.x support. Though of course I've no objection to implementing their functionality in the most efficient way possible (which may well be TextIOWrapper), IMO deprecating StreamReader/StreamWriter will make 2.x/3.x portability harder to achieve, and so seems a step too far. </pre>", "group_id": 8954, "id": 1212753}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306661807.840327, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3w8762s - Gregory P. Smith - <pre> +1 on removal. +0.8 on the pointer with a disclaimer (please also add the disclaimer at the top of the socket howto as well). there's a lot of editorial misinformation in that page even if some parts of it are useful for the socket unaware... -gps </pre>", "group_id": 8954, "id": 1216591}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306683646.848217, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3zjkxpy - Martin v. L\u00f6wis - <pre> -1. I think there should be a Python-oriented introduction to sockets. You may have complaints about the specific wording of the text, but please understand that these are probably irrelevant to most first-time readers of this text. My observation is that people actually don't read the text that much, but instead try to imitate the examples. So if the examples are good (and I think they are, mostly), it's of minor relevance whether the text makes all sense the first time. True. People who know sockets just need to read the module documentation. It is a beauty of the Python library design that it exposes the API mostly as-is, so if you know Berkeley sockets, you will be immediately familiar with Python sockets (unlike, say, Java or .NET, where they decided to regroup the API into classes). See above - it doesn't really matter. You are probably referring to the sentence \"I\u2019m only going to talk about INET sockets, but they account for at least 99% of the sockets in use. And I\u2019ll only talk about STREA</pre>", "group_id": 8954, "id": 1218132}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306685506.0331299, "message": "[devel] - PhD ideas - http://tinyurl.com/3z2fxd3 - Tiago Boldt Sousa - <pre>Hi, I'm now currently finishing my MsC and am thinking about enrolling into the PhD program. I was wondering if any of you would like to suggest me some research topic that could benefit the scientific community, that might also result as a potential improvement for Python. I love everything that's web related (Django here) and software engineering but I\u00a0don't yet have any idea for a research topic that would be relevant\u00a0for a PhD so I'm completely open to suggestions. Please contact me directly. Best regards -- Tiago Boldt Sousa </pre>", "group_id": 8954, "id": 1218267}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306709871.3062451, "message": "[devel] - [RELEASE] 3.1.4 release candidate 1 - http://tinyurl.com/3w9y2wv - Benjamin Peterson - <pre>On behalf of the Python development team, I'm happy as a swallow to announce a release candidate for the fourth bugfix release for the Python 3.1 series, Python 3.1.4. 3.1.4 will the last bug fix release in the 3.1 series before 3.1. After 3.1.4, 3.1 will be in security-only fix mode. The Python 3.1 version series focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python distribution. This is a testing release. To download Python 3.1.4rc1 visit: http://www.python.org/download/releases/3.1.4/ A list of changes in 3.1.4 can be found here: </pre>", "group_id": 8954, "id": 1221366}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306709875.2538519, "message": "[devel] - [RELEASE] Python 2.7.2 release candidate 1 - http://tinyurl.com/3cg2xb2 - Benjamin Peterson - <pre>On behalf of the Python development team, I'm happy to announce the immediate availability of Python 2.7.2 release candidate 1. 2.7.2 is the second in bugfix release for the Python 2.7 series. 2.7 is the last major verison of the 2.x line and will be receiving bug fixes while new feature development focuses on 3.x. 2.7 includes many features that were first released in Python 3.1. The faster io module, the new nested with statement syntax, improved float repr, set literals, dictionary views, and the memoryview object have been backported from 3.1. Other features include an ordered dictionary implementation, unittests improvements, a new sysconfig module, auto-numbering of fields in the str/unicode format method, and support for ttk Tile in Tkinter. For a more extensive list of changes in 2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python distribution. To download Python 2.7.2rc1 visit: http://www.python.org/download/releases/2.7.1/ The 2.7.2 changelog is at: http</pre>", "group_id": 8954, "id": 1221368}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306711669.0675931, "message": "[devel] - Re: [RELEASE] Python 2.7.2 release candidate 1 - http://tinyurl.com/3zym8rv - Jack Diederich - <pre> It might not be clear to a casual reader that the features were released in 2.7.0 and not 2.7.2. We don't, but many projects do release new features with bugfix version numbers - I'm looking at you, Django. -Jack </pre>", "group_id": 8954, "id": 1221692}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306711672.0392549, "message": "[devel] - Re: [RELEASE] Python 2.7.2 release candidate 1 - http://tinyurl.com/3vsu6pj - Benjamin Peterson - <pre>2011/5/29 Jack Diederich &lt;jackdied&lt; at &gt;gmail.com&gt;: Okay. I suppose I can say \"The 2.7 series\" next time. </pre>", "group_id": 8954, "id": 1221695}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306717068.3178799, "message": "[devel] - Re: [RELEASE] Python 2.7.2 release candidate 1 - http://tinyurl.com/3en2aga - Carl Meyer - <pre> On 05/29/2011 06:11 PM, Jack Diederich wrote: Really? Do you have an example of a new Django feature that was released in a bugfix version number? Just curious, since that's certainly not the documented release policy. [1] Carl [1] https://docs.djangoproject.com/en/dev/internals/release-process/ </pre>", "group_id": 8954, "id": 1222441}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306731589.14803, "message": "[devel] - Re: [RELEASE] Python 2.7.2 release candidate 1 - http://tinyurl.com/3l9s5wc - Ralf Schmitt - <pre> The news file mentions that issue 1195 (\"Problems on Linux with Ctrl-D and Ctrl-C during raw_input\") is fixed. That's not true, see: http://bugs.python.org/msg135671 Does one need special roundup rights to reopen issues? Cheers, - Ralf </pre>", "group_id": 8954, "id": 1224299}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306744432.608494, "message": "[devel] - Re: [RELEASE] Python 2.7.2 release candidate 1 - http://tinyurl.com/3o4e8pw - Victor Stinner - <pre>Hi, Le lundi 30 mai 2011 06:47:40, Ralf Schmitt a \u00e9crit : Oh, I forgot that one. Please reopen the issue, I will apply your fix instead of mine. Victor </pre>", "group_id": 8954, "id": 1225309}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306745330.327678, "message": "[devel] - Re: [RELEASE] Python 2.7.2 release candidate 1 - http://tinyurl.com/3pmthdy - Ralf Schmitt - <pre> I would love to do that, but as my above question implies I'm either too stupid to do that or I'm missing the rights to do it :) Cheers, - Ralf </pre>", "group_id": 8954, "id": 1225394}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306746377.5796521, "message": "[devel] - Re: [RELEASE] Python 2.7.2 release candidate 1 - http://tinyurl.com/3jw4hel - Victor Stinner - <pre>Le lundi 30 mai 2011 10:46:39, Ralf Schmitt a \u00e9crit : Oops, I am stupid. I reopened the issue. Victor </pre>", "group_id": 8954, "id": 1225517}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306774432.7778311, "message": "[devel] - pysetup as a top script - http://tinyurl.com/3bduro2 - Tarek Ziad\u00e9 - <pre>Hello If no one objects, I'll promote Tools/scripts/pysetup3 to a top level script that gets installed in scripts/ like 2to3, pydoc etc.. That way, people will be able to use it directly when installing, removing projects, or studying what's installed Cheers Tarek </pre>", "group_id": 8954, "id": 1228986}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306775330.4809041, "message": "[devel] - Docs for the packaging module - http://tinyurl.com/3nlebcq - \u00c9ric Araujo - <pre> Hi, The docs were not added alongside the code when packaging was merged back into CPython because they were not in a shape conforming with the rest of the docs. I\u2019d like your input on layout so that I can fix this ASAP and merge the docs. (They would still require a lot of additions, fixes and improvements after that, but at least they\u2019d be in the repo.) The easiest part is the library documentation, i.e. the docs for developers of packaging-related tools that want to use for example packaging.version or packaging.metadata to do their own stuff. These documents should go into Doc/library/packaging.*, I think this is a no-brainer. (Distutils has only a stub here, its API docs is mixed with its usage docs.) There is a guide for end-users, which contains an outdated copy of the old \u201cInstalling Python Modules\u201d and a few documents about the new pysetup script (superseder of setup.py scripts), which are not integrated with the first document. I think those should supersede the e</pre>", "group_id": 8954, "id": 1229107}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306775333.748945, "message": "[devel] - Re: cpython: removed spurious output - http://tinyurl.com/43rfx6n - Georg Brandl - <pre> And even more importantly, shouldn't this be \"sys.stderr\" instead of \"sys.sterr\"? Really, what happened to testing before you push? Georg </pre>", "group_id": 8954, "id": 1229109}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306776291.69684, "message": "[devel] - Re: cpython: removed spurious output - http://tinyurl.com/3kvrjrf - Tarek Ziad\u00e9 - <pre> Yes, I did test it, before and after my push, sir. This was not to fix a test bug, but to avoid a spurious output in the tests. </pre>", "group_id": 8954, "id": 1229201}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306777190.6676991, "message": "[devel] - Re: cpython: removed spurious output - http://tinyurl.com/3utk2py - Georg Brandl - <pre> Well, I assumed changing sys.stderr would be noticed as changing the execution environment. But as I've now found out, the test class itself cleans up sys.stderr, so you couldn't have noticed the bug. I apologize. Georg </pre>", "group_id": 8954, "id": 1229353}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306819061.5478489, "message": "[devel] - Re: pysetup as a top script - http://tinyurl.com/4yy23md - Nick Coghlan - <pre> Cool. Now I'm trying to remember if it was a list discussion or the language summit where you got the initial consensus on that approach... Cheers, Nick. </pre>", "group_id": 8954, "id": 1234723}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306824523.010802, "message": "[devel] - Re: pysetup as a top script - http://tinyurl.com/3b2fqvm - Tarek Ziad\u00e9 - <pre> The thread starts here: http://mail.python.org/pipermail/python-dev/2010-October/104535.html The pysetup top-level script was mentioned here: http://mail.python.org/pipermail/python-dev/2010-October/104581.html Cheers Tarek </pre>", "group_id": 8954, "id": 1235195}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306827224.8788891, "message": "[devel] - Re: [Python-checkins] cpython: Close #12028: Make threading._get_ident() public, rename it to - http://tinyurl.com/3ro79hn - Charles-Fran\u00e7ois Natali - <pre> I'm not sure I understand, Nick. Since threads are started detached, their thread ID (e.g. returned by pthread_self() on pthreads) can be reused as soon as the underlying OS thread exits (i.e. returns from Modules/_threadmodule.c:t_boostrap) : On a Linux kernel with NPTL: $ cat /tmp/test.py import threading def print_ident(): print(threading._get_ident()) t1 = threading.Thread(target=print_ident) t2 = threading.Thread(target=print_ident) t1.start() t1.join() t2.start() t2.join() print(id(t1), id(t2)) $ ./python /tmp/test.py -1211954272 -1211954272 (3085561228L, 3083093028L) I'm just curious, maybe I missed something? Thanks, cf </pre>", "group_id": 8954, "id": 1235404}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306833581.747807, "message": "[devel] - Re: [Python-checkins] cpython: Close #12028: Makethreading._get_ident() public, rename it to - http://tinyurl.com/3tv7yrc - Victor Stinner - <pre>Le mardi 31 mai 2011 10:37:15, Nick Coghlan a \u00e9crit : Yes, I copy-pasted the doc from Python 2.7, from thread.get_ident(). Feel free to edit directly the doc. Victor </pre>", "group_id": 8954, "id": 1236191}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306848045.1066101, "message": "[devel] - Release pages malformed on python.org - http://tinyurl.com/3g9sj9q - Michael Foord - <pre>Hello all, I believe that the release manager is aware of this, but just in case... The web pages on python.org for the recent releases are malformatted: http://www.python.org/download/releases/3.1.4/ http://www.python.org/download/releases/2.7.2/ These are the pages linked to from the news on the front page. All the best, Michael Foord </pre>", "group_id": 8954, "id": 1237329}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306850744.400135, "message": "[devel] - Re: Release pages malformed on python.org - http://tinyurl.com/3dfhbzy - Benjamin Peterson - <pre>2011/5/31 Michael Foord &lt;fuzzyman&lt; at &gt;voidspace.org.uk&gt;: Wohaa. Martin, I think this is from your checkin? </pre>", "group_id": 8954, "id": 1237625}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306862445.251075, "message": "[devel] - Sniffing passwords from PyPI using insecure connection - http://tinyurl.com/3p8qq8e - anatoly techtonik - <pre>Hi, I'd like to escalate http://bugs.python.org/issue12226 : 'use secured channel for uploading packages to pypi' to be shipped with next Python 2.6+ This will prevent pydotorg password sniffing when submitting packages through public networks (such as hotels). -- anatoly t. </pre>", "group_id": 8954, "id": 1239114}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306866107.2077229, "message": "[devel] - Re: Release pages malformed on python.org - http://tinyurl.com/3sb7twx - Martin v. L\u00f6wis - <pre>Am 31.05.2011 16:01, schrieb Benjamin Peterson: Indeed... I have now fixed it. Regards, Martin </pre>", "group_id": 8954, "id": 1239771}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306869708.779907, "message": "[devel] - Re: Sniffing passwords from PyPI using insecureconnection - http://tinyurl.com/3gcbz3f - Terry Reedy - <pre> The requested one character change is - DEFAULT_REPOSITORY = 'http://pypi.python.org/pypi' + DEFAULT_REPOSITORY = 'https://pypi.python.org/pypi' If Tarek (or perhaps Eric) agree that it is appropriate and otherwise innocuous, then Martin and Barry can decide whether to include in 2.5/2.6. Terry Jan Reedy </pre>", "group_id": 8954, "id": 1240426}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306884345.150125, "message": "[devel] - Some additions to .hgignore - http://tinyurl.com/3zepbqd - Sandro Tosi - <pre>Hi all, following http://docs.python.org/devguide/coverage.html doc you'll end up with several \"new\" files/dirs in your checkout: - .coverage, used by coveragepy to save its info - coverage/ , the symlink to coveragepy/coverage - htmlcov/ , the dir where the coverage HTML pages are written I think they should be added to .hgignore so that hg st won't show them. I'm writing here since I don't think an issue is needed for such matter, if that's not the case, I apologize. Regards, </pre>", "group_id": 8954, "id": 1244519}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306906903.520432, "message": "[devel] - Re: Sniffing passwords from PyPI usinginsecureconnection - http://tinyurl.com/3fcux99 - Martin v. L\u00f6wis - <pre> I don't plan any further 2.5 releases, so unless a critical security issue pops up, 2.5.6 will have been the last release. Regards, Martin </pre>", "group_id": 8954, "id": 1249883}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306910623.4320049, "message": "[devel] - Re: Sniffing passwords from PyPI using insecureconnection - http://tinyurl.com/3ww295r - Terry Reedy - <pre> OK. I removed 2.5 from all open issues, closing a few. You could remove 2.5 from the displayed version list so that people cannot add it back or to new issues. </pre>", "group_id": 8954, "id": 1250689}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306911528.2763441, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3wferyz - Martin v. L\u00f6wis - <pre> I think shutil.chown should aim to mimic chown(1). At least GNU chown has a -R flag (not sure about POSIX chown), and it's useful in practice. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1250772}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306926165.4848461, "message": "[devel] - Re: Some additions to .hgignore - http://tinyurl.com/3zz3qmk - Michael Foord - <pre> That sounds good to me. An issue certainly wouldn't hurt. All the best, Michael </pre>", "group_id": 8954, "id": 1251978}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306927064.4943249, "message": "[devel] - Re: Sniffing passwords from PyPI using insecure connection - http://tinyurl.com/3lj4uo9 - Barry Warsaw - <pre> I followed up on the tracker. I'm +0 on adding this to 2.6, but not until after the 2.6.7 release on Friday. How well has this change been tested? Are there people for whom this could break things? -Barry </pre>", "group_id": 8954, "id": 1252036}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306940805.757061, "message": "[devel] - Re: Extending os.chown() to accept user/group names - http://tinyurl.com/3eplgcj - \u0141ukasz Langa - <pre> Wiadomo\u015b\u0107 napisana przez Martin v. L\u00f6wis w dniu 2011-06-01, o godz. 08:48: cp(1) and rm(1) also have \"-r\", still there are `shutil.copytree` and `shutil.rmtree`. I would like to keep that consistency, e.g. to have `shutil.chown` and `shutil.chowntree` as previously discussed by Charles-Fran\u00e7ois, Nick and Petri. </pre>", "group_id": 8954, "id": 1254067}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306952505.7049141, "message": "[devel] - Re: Docs for the packaging module - http://tinyurl.com/3n7lsuu - \u00c9ric Araujo - <pre>Hi Benjamin, Given that we haven\u2019t removed the code, I would prefer to keep the doc too. Tarek has given me the greenlight, so I will commit the new docs momentarily. Cheers _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1256262}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306951607.998884, "message": "[devel] - Re: Docs for the packaging module - http://tinyurl.com/3nu86mz - Benjamin Peterson - <pre>2011/6/1 \u00c9ric Araujo &lt;merwok&lt; at &gt;netwok.org&gt;: Perhaps your solutions are perfect already. :) Or we could just delete them and have people look at docs for old versions of Python. </pre>", "group_id": 8954, "id": 1256089}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306950708.2986131, "message": "[devel] - Re: Docs for the packaging module - http://tinyurl.com/3pxn3tr - \u00c9ric Araujo - <pre>Hi, Looks like nobody cares enough about the packaging docs :) If there is no feedback, here\u2019s what I propose to do: - Add new Doc/library/packaging* files (library reference for developers of packaging tools) - Add new packaging-based \u201cInstalling Python Projects\u201d to Doc/install, replacing old distutils docs - Add new packaging-based \u201cDistributing Python Projects\u201d Doc/packaging, replacing old distutils docs (+ link to it from the main HTML page instead of linking to Doc/distutils) For users needing the legacy distutils docs in 3.3, I would move the older distutils Doc/install/index.rst to Doc/distutils/install.rst, and add a link to Doc/distutils in Doc/library/distutils (because the main page would no longer link to Doc/distutils). Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1255909}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306953412.0755799, "message": "[devel] - Re: Docs for the packaging module - http://tinyurl.com/42wyo3c - R. David Murray - <pre> I think you should go ahead and make your changes, and then we'll be able to see what it really looks like and decide if anything ought to be tweaked. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 1256422}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306953408.7636859, "message": "[devel] - Re: Docs for the packaging module - http://tinyurl.com/3j96oyg - Tarek Ziad\u00e9 - <pre>I do care :) Looks fine Please push, as we can always change and fix things afterwards in the tip before 3.3 is out. Le 1 juin 2011 19:38, \"\u00c9ric Araujo\" &lt;merwok&lt; at &gt;netwok.org&gt; a \u00e9crit : http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com </pre>", "group_id": 8954, "id": 1256419}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306954366.3195419, "message": "[devel] - Question about Module Loading - http://tinyurl.com/4xbxo52 - Timothy Kadich - <pre>If a Python program imported a module, say numpy for example, where in the source is this line interpreted and then handled by import.c ? Thank you in advance! </pre>", "group_id": 8954, "id": 1256721}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306956169.814183, "message": "[devel] - Re: Question about Module Loading - http://tinyurl.com/3syja98 - Benjamin Peterson - <pre>2011/6/1 Timothy Kadich &lt;tdkadich&lt; at &gt;gmail.com&gt;: Many different files. Start from TARGET(IMPORT_NAME) in ceval.c. </pre>", "group_id": 8954, "id": 1257285}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306956166.3234861, "message": "[devel] - Re: Question about Module Loading - http://tinyurl.com/3ol9mzd - R. David Murray - <pre> Your question is not as simple as you think (I think), but I'm guessing you will want to look at Python/ceval.c. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 1257284}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306968766.407141, "message": "[devel] - Re: Question about Module Loading - http://tinyurl.com/3hv4csf - Timothy Kadich - <pre>I don't understand what you mean by \"TARGET(IMPORT_NAME)\". I can't find that string in ceval.c. On 1 June 2011 12:04, Benjamin Peterson &lt;benjamin&lt; at &gt;python.org&gt; wrote: </pre>", "group_id": 8954, "id": 1259784}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306969667.1427901, "message": "[devel] - Re: Question about Module Loading - http://tinyurl.com/44cl9n5 - Timothy Kadich - <pre>Nevermind. In 2.6 (what I'm working with) it's \"case IMPORT_NAME:\" Thank you for letting me know where to start. On 1 June 2011 15:43, Timothy Kadich &lt;tdkadich&lt; at &gt;gmail.com&gt; wrote: </pre>", "group_id": 8954, "id": 1259953}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1306979626.6109729, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Multiple clean-ups to the docs for builtin functions. - http://tinyurl.com/453jl4m - Terry Reedy - <pre> &gt; process_line(line) As noted on the tracker, this will always loop forever. Even if \"STOP\" is corrected to \"STOP\\n\", it will still loop forever if the file does not have the magic value. &gt; process_line(line) While I have a big problem with infinite loops, I have a (smaller) problem with useless code. The new loop line line is a roundabout way to spell \"for line in fp\". While this would have been useful before files were turned into iterables (if there was such a time after iter() was introduced), it is not now. What might be useful and what the example could show is how to stop early if a sentinel is present, while still stopping when the iterable runs out. The following alternate fix to the original does just that. with open(\"mydata.txt\") as fp: for line in iter(fp.__next__, \"STOP\\n\"): process_line(line) A tested a runnable variation with and without the exact sentinal. It generalizes to *any* iteration than one might want to stop early. Thi</pre>", "group_id": 8954, "id": 1261470}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307008548.7975359, "message": "[devel] - Windows download links not working for 2.7.2rc1 and3.1.4rc1 - http://tinyurl.com/3jpfk9j - Michael Foord - <pre>Hey all, The links to the Windows downloads for 2.7.2rc1 and 3.1.4rc1 are 404. (From the release pages.) http://python.org/ftp/python/3.1.3/python-3.1.4rc1.msi http://python.org/ftp/python/2.7.1/python-2.7.2rc1.msi All the best, Michael Foord </pre>", "group_id": 8954, "id": 1264799}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307023852.6535921, "message": "[devel] - Re: [Python-checkins] cpython: The compiler class forEMX was removed - http://tinyurl.com/6kfksj2 - Nick Coghlan - <pre> This is the kind of checkin comment where the phrasing is a little confusing. It could mean either \"was removed by mistake and has now been restored\" or else \"is no longer supported and has been removed\". (Checking the diff resolves the ambiguity in favour of the latter interpretation, but not all diffs are as simple as this one). It's worth trying to make the final state of the source tree explicit in the checkin message (no need to edit the history, just a note for future reference). Cheers, Nick. </pre>", "group_id": 8954, "id": 1267181}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307026551.9870629, "message": "[devel] - Re: [Python-checkins] cpython: The compiler class forEMX was removed - http://tinyurl.com/65emyjb - \u00c9ric Araujo - <pre>Le 02/06/2011 15:56, Nick Coghlan a \u00e9crit : Yep. Next time I\u2019ll be longer and use something like \u201cRemove obsolete mentions of a compiler that was removed\u201d. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1267754}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307041910.700604, "message": "[devel] - Re: [Python-checkins] peps: Add rules for indenting continuation lines. - http://tinyurl.com/3dzaozo - Glenn Linderman - <pre> One place a double indent is extremely nice is for lines that initiate a new indentation, but are themselves continued: if some_function( Some, Parameters, To, Pass, ) If_True_Operations() is much more readable than: if some_function( Some, Parameters, To, Pass, ) If_True_Operations() </pre>", "group_id": 8954, "id": 1270121}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307041913.9681871, "message": "[devel] - Re: [Python-checkins] peps: Add rules for indenting continuation lines. - http://tinyurl.com/3jr7edr - Guido van Rossum - <pre>Bingo. That's why. (Though you are missing some colons in your examples. :-) --Guido On Thu, Jun 2, 2011 at 11:50 AM, Glenn Linderman &lt;v+python&lt; at &gt;g.nevcal.com&gt; wrote: </pre>", "group_id": 8954, "id": 1270122}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307045569.8098681, "message": "[devel] - Re: [Python-checkins] peps: Add rules for indenting continuation lines. - http://tinyurl.com/6x38lau - Glenn Linderman - <pre> You operate as a good Python compiler :) </pre>", "group_id": 8954, "id": 1270653}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307044612.0596581, "message": "[devel] - Re: Windows download links not working for 2.7.2rc1 and3.1.4rc1 - http://tinyurl.com/3rtvptu - Martin v. L\u00f6wis - <pre> Thanks, fixed. Martin </pre>", "group_id": 8954, "id": 1270480}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307053669.593611, "message": "[devel] - Re: [Python-checkins] peps: Add rules for indenting continuation lines. - http://tinyurl.com/64bdel9 - Barry Warsaw - <pre> Actually, this is a key insight, which I just mentioned in a private response to Steve. How about this for the rule: If the hanging line ends in a colon, then double-indent (or \"more-ly indented\") seems appropriate. If not, then a single indent is sufficient. That handles cases like this, where double indent makes sense: def some_really_long_function_name( an_argument, another_argument, and_a_third_argument): foo() --- if some_really_long_function_name( an_argument, another_argument, and_a_third_argument): foo() --- and these cases where a single indent is fine: x = some_really_long_function_name( an_argument, another_argument, and_a_third_argument) foo(x) --- d = dict( a=1, b=2, c=3, d=4) return d Does that cover it? -Barry </pre>", "group_id": 8954, "id": 1272263}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307055471.7876279, "message": "[devel] - Re: [Python-checkins] peps: Add rules for indenting continuation lines. - http://tinyurl.com/3dwn4r8 - Guido van Rossum - <pre> Except that the rule gets more complicated. I don't think that always using the double indent is going to mean a lot more line breaks, so I don't think there's much benefit to the added complication. </pre>", "group_id": 8954, "id": 1272447}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307057271.842829, "message": "[devel] - Re: [Python-checkins] peps: Add rules for indenting continuation lines. - http://tinyurl.com/664ed6t - Glenn Linderman - <pre> Further, tools like python-mode would have to go back and fix the indent to be double indented when there are multiple lines, and the : is not typed until the last line... not impossible, but more complicated, and some of the intervening lines might be too long for the double indent, and then manual adjustments would have to happen. Ick. Double indent from the beginning, if there is nothing after the (. Or key the double indent off the leading keywords that end with : Here's a language question, though: if there are keywords that imply the need for a :, and it isn't on the same line, why is \\ needed to continue to the next line (or parentheses, etc.)? If the : is truly omitted, like I did in my example, there'll be other syntax errors to report. If it is just on a later line, why complain about it missing? With complex conditions, I wind up adding extra () rather than trailing \\, and that is about the only time I have ever found the need to use \\ (but my workaround is to add the ()). </pre>", "group_id": 8954, "id": 1272686}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307058170.2104139, "message": "[devel] - Re: [Python-checkins] peps: Add rules for indenting continuation lines. - http://tinyurl.com/66hur5j - Greg Ewing - <pre> Another way to approach that is if some_function( Some, Parameters, To, Pass, ): If_True_Operations() i.e. indent the *body* one more place. This avoids the jarriness of seeing an outdent that doesn't correspond to the closing of a suite. </pre>", "group_id": 8954, "id": 1272738}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307065494.098403, "message": "[devel] - Re: [Python-checkins] peps: Add rules for indenting continuation lines. - http://tinyurl.com/6gz93us - Glenn Linderman - <pre> -1. There are likely many more lines in the suite than in the conditional, that, by being double indented, would now need continuations themselves. </pre>", "group_id": 8954, "id": 1273536}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307068192.721827, "message": "[devel] - Re: [Python-checkins] peps: Add rules for indentingcontinuation lines. - http://tinyurl.com/3fc2266 - Ben Finney - <pre> \u22121. Continuation lines for a single statement *should* look different (I disagree with \u201cjarring\u201d) from a suite of statements. </pre>", "group_id": 8954, "id": 1273845}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307096213.847374, "message": "[devel] - Re: [Python-checkins] peps: Add rules for indenting continuation lines. - http://tinyurl.com/3rl26xj - Lennart Regebro - <pre> I like it. </pre>", "group_id": 8954, "id": 1276175}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307117938.698688, "message": "[devel] - Summary of Python tracker Issues - http://tinyurl.com/3cq437n - Python tracker - <pre> ACTIVITY SUMMARY (2011-05-27 - 2011-06-03) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2815 ( +2) closed 21221 (+56) total 24036 (+58) Open issues with patches: 1224 Issues opened (38) ================== #12197: non-blocking SSL write in Windows sends large data but raises http://bugs.python.org/issue12197 opened by dsiroky #12198: zipfile.py:1047: DeprecationWarning: 'H' format requires 0 &lt;= http://bugs.python.org/issue12198 opened by gnezdo #12200: bdist_wininst install_script not run on uninstall http://bugs.python.org/issue12200 opened by mhammond #12201: Returning FILETIME is unsupported in msilib.SummaryInformation http://bugs.python.org/issue12201 opened by markm #12202: Check status returns in msilib.SummaryInformation.GetProperty( http://bugs.python.org/issue12202 opened by markm #12204: str.upper converts to title http://bugs.python.org</pre>", "group_id": 8954, "id": 1278630}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307119794.9371419, "message": "[devel] - os.stat and nanosecond precision - http://tinyurl.com/43qb4n7 - Ross Lagerwall - <pre>With regards to http://bugs.python.org/issue11457 What should the name of the (seconds, nanoseconds) tuple be? st_atim, st_ctim and st_mtim has bee suggested and is what the POSIX specification uses. This is confusingly similar to the existing st_atime, st_ctime and st_mtime. Also, should it be that these attributes are always defined (and just have 0 for nanoseconds if the OS doesn't support it) or should it be that they are only defined if the OS supports nanosecond precision. If they are always defined, it would make usage simpler. Cheers Ross </pre>", "group_id": 8954, "id": 1278813}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307120696.317404, "message": "[devel] - Re: os.stat and nanosecond precision - http://tinyurl.com/3prayjp - Alexander Belopolsky - <pre>Still, inventing new names would make it even more confusing. +1 for POSIX names. +1 to have them always defined. </pre>", "group_id": 8954, "id": 1278894}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307123454.7278039, "message": "[devel] - Re: [Python-checkins] cpython: Fix reST label forcollections ABCs. - http://tinyurl.com/4xn97zh - Raymond Hettinger - <pre> On Jun 3, 2011, at 10:27 AM, eric.araujo wrote: I think the users are better served by links to collections.abc, io.abc, etc. For the most part, glossary readers will be interested in actual abstract classes than in the underlying implementation. IOW, I believe this edit makes the docs worse rather than better. Raymond</pre>", "group_id": 8954, "id": 1279282}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307124354.563998, "message": "[devel] - Re: [Python-checkins] cpython: Fix reST label for collections ABCs. - http://tinyurl.com/3kw3m3r - \u00c9ric Araujo - <pre>Le 03/06/2011 19:43, Raymond Hettinger a \u00e9crit : The specific problem I addressed was that :ref:`abstract-base-classes` was replaced by \u201cCollections Abstract Base Classes\u201d, which was wrong: the glossary entry talks about \u201cAbstract Base Classes\u201d. I will add links to abc submodules as you suggested tomorrow. Thanks for the review. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1279381}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307132574.8481691, "message": "[devel] - Re: os.stat and nanosecond precision - http://tinyurl.com/3bmxua2 - Martin v. L\u00f6wis - <pre> See my comment: -1 on having such a tuple in the first place. We have the decimal type to represent arbitrary-precision time stamps. That the POSIX spec uses it is IMO a strong argument. Definitely. There may be a day when ps, fs, or as resolution comes along. It would be good if a) the fields are always available, and b) have \"unspecified\"/\"best-effort\" precision, to accomodate future changes. I wish the decimal type would have been available in 2.3, when I changed the fields to be doubles instead of longs... Regards, Martin </pre>", "group_id": 8954, "id": 1280788}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307137974.8909609, "message": "[devel] - Re: Sniffing passwords from PyPI using insecureconnection - http://tinyurl.com/3uy95m8 - Martin v. L\u00f6wis - <pre> As others have pointed out: it would break systems that don't have the _ssl module built. Regards, Martin </pre>", "group_id": 8954, "id": 1281535}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307139774.3919561, "message": "[devel] - Re: [Python-checkins] cpython: Add NEWS and whatsnewentries for the packaging module - http://tinyurl.com/42fp3o5 - Victor Stinner - <pre>Le vendredi 03 juin 2011 17:28:48, eric.araujo a \u00e9crit : Even for Python 2.4, really? Do you really need to support this old Python release? Victor </pre>", "group_id": 8954, "id": 1281947}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307139787.3284931, "message": "[devel] - Re: Sniffing passwords from PyPI using insecureconnection - http://tinyurl.com/3pb35p6 - Tarek Ziad\u00e9 - <pre> yeah, we would need to fallback to http in that case. while using https by default is a nice addition, maybe we should also look at adding a scp-like upload/register command, since the server has now this ability. </pre>", "group_id": 8954, "id": 1281950}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307140675.2381871, "message": "[devel] - Re: [Python-checkins] cpython: Add NEWS and whatsnew entries for the packaging module - http://tinyurl.com/3zn9zv8 - Tres Seaver - <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/03/2011 06:06 PM, Victor Stinner wrote: Yes. Many projects distribute packages to folks still using 2.4. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver&lt; at &gt;palladion.com Palladion Software \"Excellence by Design\" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3pYC0ACgkQ+gerLs4ltQ638ACghJiU7Ts7D5PrcfA2r1ZoJklW 7zkAn2vJwI1W1N7GVTrpR6/8Lt48ltBz =xKNv -----END PGP SIGNATURE----- </pre>", "group_id": 8954, "id": 1282176}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307147875.5660269, "message": "[devel] - Released: Python 2.6.7 - http://permalink.gmane.org/gmane.comp.python.devel/124924 - Barry Warsaw - <pre>Hello Pythoneers and Pythonistas, I'm happy to announce the final release of Python 2.6.7. Python 2.6 is in security-fix only mode. This means that general bug maintenance has ended, and only critical security issues are being fixed. We will support Python 2.6 in security-fix only mode until October 2013. Also, this is a source-only release; no installers for Windows or Mac OS X will be provided. Please download the source from: http://www.python.org/download/releases/2.6.7/ The NEWS file contains the list of changes since 2.6.6: http://www.python.org/download/releases/2.6.7/NEWS.txt Many thanks go out to the entire Python community for their contributions and help in making Python 2.6.7 available. Enjoy, -Barry (on behalf of the Python development community) </pre>", "group_id": 8954, "id": 1283373}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307148776.260901, "message": "[devel] - Re: [Python-checkins] cpython: Add NEWS and whatsnew entries for the packaging module - http://tinyurl.com/3k58ahf - Dan Stromberg - <pre> Supporting detail: I recently installed the latest CentOS, 5.6, and found that it still Ships with CPython 2.4. I installed a CPython 3.2 in /usr/local almost immediately, but I can see how some might want 2.4 support yet. </pre>", "group_id": 8954, "id": 1283437}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307167878.5294781, "message": "[devel] - Re: [Python-checkins] cpython: Add NEWS and whatsnew entries for the packaging module - http://tinyurl.com/3uhd6nz - Nick Coghlan - <pre> Yeah, this came up at Brispy last week. Until CentOS 6 comes out and hosting providers based on CentOS make that version available to their customers, quite a few people are going to want 2.4 support. That's likely to take a while, since the last note from the CentOS folks was a month ago [1], and essentially just said \"soon\". Once it happens, CentOS 6 users will be able to join RHEL6 users on 2.6.2. [1] https://www.centos.org/modules/newbb/viewtopic.php?topic_id=25878&amp;forum=53#12 Cheers, Nick. </pre>", "group_id": 8954, "id": 1284720}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307214208.50842, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/66fxuot - Antoine Pitrou - <pre> Hello, On Sun, 29 May 2011 17:20:29 +0200 \"Martin v. L\u00f6wis\" &lt;martin&lt; at &gt;v.loewis.de&gt; wrote: So what you're saying is that the text is mostly useless (or at least quite dispensable), but you think it's fine that people waste their time trying to read it? Some of the people reading our docs are not fluent English readers, and it can be quite an effort for them to read some big chunk of text which will be ultimately pointless. I'm not sure why the examples are good (for example, modern client code should probably use create_connection() with a host name, not connect()). Also, really, to socket beginners, I think the primary advice should be: first try to find some high-level library that does the dirty work for you (for example some protocol-specific lib on the client side, or something like Twisted or asyncore on the server side). Not \"hey, here's how you write a threaded server in 4 lines of code, and wow, look, you can also write non-blocking code using select() too!\". Well... in a couple of months, so</pre>", "group_id": 8954, "id": 1288101}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307228780.5017281, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/5r7vunj - Neil Hodgson - <pre>Antoine Pitrou: I found it useful when starting to write socket code. Later on I learnt more but, as an introduction, this document was great. It is written in an approachable manner and doesn't spend time on details unimportant to initial understanding. Neil </pre>", "group_id": 8954, "id": 1289985}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307238801.1467741, "message": "[devel] - keyword-only arguments and varags - http://tinyurl.com/43etfuf - Benjamin Peterson - <pre>Currently, def f(*, kw, **kwargs): pass is valid syntax, but def f(*args, *, kw): pass is not. I don't see any mention of it in the PEP but perhaps there is a good reason this isn't allowed. It seems to be perfectly well-defined to me. </pre>", "group_id": 8954, "id": 1290591}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307254165.431366, "message": "[devel] - Re: keyword-only arguments and varags - http://tinyurl.com/3ex27vl - Nick Coghlan - <pre> Really? There's two single-stars there. One says \"accept arbitrary positional arguments and place them in a tuple named args\", the second says \"don't accept any more positional args\". You can't have it both ways, so the compiler complains. The following works fine to mix keyword-only arguments with arbitrary positional arguments, so I don't see a problem: def f(*args, kw): pass Cheers, Nick. </pre>", "group_id": 8954, "id": 1291742}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307255962.6472199, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3kpny9t - Martin v. L\u00f6wis - <pre> No, that's not what I said. I said the people actually *don't* read the text, so they won't waste time with it. They only glance at the text, enough to understand the examples. You completely misunderstood. I didn't say that the reading the text is pointless. I said that people don't read this text, nor any software documentation, in particular when they are not fluent in English. I disagree. create_connection is an advanced function - you shouldn't be using it unless you know what it is doing. As a socket tutorial, people do have to know about connect. No no no no no. Absolutely not. a) telling people who want to learn sockets \"don't learn sockets, learn some higher-level library\" is besides the point. What do you tell them when they did that, and now come back to learn sockets? b) telling people to use Twisted or asyncore on the server side if they are new to sockets is bad advice. People *first* have to understand sockets, and *then* can use these libraries and frameworks. Those l</pre>", "group_id": 8954, "id": 1291937}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307266942.645154, "message": "[devel] - Re: [Python-checkins] cpython (3.1): Do not add txtfiles twice. - http://tinyurl.com/3nfwteq - Victor Stinner - <pre>I added the \"if dir=='cjkencodings':\" to msi.py, based on tests for other subdirectories in Lib/tests/. Can you explain me why cjkencodings should not have a special case? The fix should maybe be ported to 3.2, 3.3 and 2.7. Victor Le dimanche 05 juin 2011 11:00:30, martin.v.loewis a \u00e9crit : </pre>", "group_id": 8954, "id": 1292415}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307270663.7421341, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3ts9mg3 - Antoine Pitrou - <pre>On Sun, 05 Jun 2011 08:32:38 +0200 \"Martin v. L\u00f6wis\" &lt;martin&lt; at &gt;v.loewis.de&gt; wrote: I'm sorry, that sounds like a very outlandish argument to make. Did you run a user survey? If people only \"glance at the text\", then what is the text for? Why not kill the text and rename the page \"socket examples\" so that there is no misunderstanding and so that we don't waste time trying to maintain (and argue about) it? Can you explain? I would certainly use it myself, and I don't understand how it's \"advanced\". It's simply higher-level. Actually, we've been actually replacing uses of connect() with create_connection() in various parts of the stdlib, so that our client modules get IPv6-compatible. You said yourself that the HOWTO doesn't claim to explain sockets, so how can you make such a point now? If people want to learn sockets for real, the HOWTO is hopeless for them. +1. Regards Antoine. </pre>", "group_id": 8954, "id": 1292550}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307288004.278127, "message": "[devel] - FWD: gpg keys have problems - http://tinyurl.com/3u2xuev - Aahz - <pre>I'm not currently reading python-dev, dunno if this has come up before: ----- Forwarded message from \"Michael J. Dinneen\" &lt;mjd&lt; at &gt;cs.auckland.ac.nz&gt; ----- ----- End forwarded message ----- </pre>", "group_id": 8954, "id": 1293690}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307292563.8122561, "message": "[devel] - Re: keyword-only arguments and varags - http://tinyurl.com/3lsxxga - Benjamin Peterson - <pre>2011/6/5 Nick Coghlan &lt;ncoghlan&lt; at &gt;gmail.com&gt;: Thank you. More proof I shouldn't write emails after 22:00 local time. Move along, nothing to see here... </pre>", "group_id": 8954, "id": 1294136}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307306123.3179581, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/5rqkbqr - Glyph Lefkowitz - <pre> First, Twisted doesn't always use the BSD sockets API; the Windows IOCP reactor, especially, starts off with the socket() function, but things go off in a different direction pretty quickly from there. So it's perfectly fine to introduce yourself to networking via Twisted, and many users have done just that. If you're using it idiomatically, you should never encounter a socket object or file descriptor poking through the API anywhere. Asyncore is different: you do need to know how sockets work in order to use it, because you're expected to call .send() and .recv() yourself. (And, in my opinion, this is a serious design flaw, for reasons which will hopefully be elucidated in the PEP that Laurens is now writing.) Second, it makes me a little sad that it appears to be folk wisdom that Twisted is only for servers. A lot of work has gone into making it equally appropriate for clients. This is especially true if your client has a GUI, where Twisted is often better than a protocol-specific library, which </pre>", "group_id": 8954, "id": 1295329}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307308824.8513479, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/4ypxeu4 - Raymond Hettinger - <pre> It would be fine to have a separate networking howto guide that covers libraries, frameworks, and high level APIs, but I agree with Martin that the Socket HOWTO needs to cover sockets. That's what a person expects to learn when they click on the Socket HOWTO link. Raymond </pre>", "group_id": 8954, "id": 1295745}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307313325.2980151, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3glf8ey - Martin v. L\u00f6wis - <pre> It uses getaddrinfo, which might return multiple addresses, which are then tried in sequence. So even though it's called \"create_connection\", it may actually attempt to create multiple connections. As a consequence, it may wait some time for one connection to complete, and then succeed on a different address. These phenomena can only be understood when you know what it is actually doing. And that's fine - the people making this changes most certainly where capable of using advanced API. Did I say that? If so, I didn't mean to. It explains how to use the socket API. Regards, Martin </pre>", "group_id": 8954, "id": 1296754}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307314226.144598, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3bdetv9 - Martin v. L\u00f6wis - <pre> Hmm. Are you saying it doesn't use listen, connect, bind, send, recv? To me, that's the core of BSD sockets. I can understand it doesn't use select(2). And that's all fine. I still claim that you have to *understand* sockets in order to use it properly. By this, I mean stuff like \"what is a TCP connection? how is it established?\", \"how is UDP different from TCP?\", \"when data arrives, what layers of software does it go through?\", \"what is a port number?\", etc. I think that's because many of the problems that Twisted solves don't exist in many of the client applications - in particular, you often don't have many simultaneous connections. GUI apps may be the interesting special case, but I expect that people dealing with these rather use separate threads. Wouldn't you agree that Twisted is very difficult to learn, and thus much heavier than sockets? And I don't blame the Twisted API for that, but rather the mental model of overlapping activities that people have severe problems with. Regards, Martin </pre>", "group_id": 8954, "id": 1296962}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307323226.404366, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3ww975m - exarkun< at >twistedmatrix.com - <pre> Yes, that's correct. Those aren't the best APIs to use on Windows, so they aren't necessarily used on Windows. These may be good things to understand. The current socket howto doesn't explain them, though. On the contrary, many of the problems do exist in client applications (every time I have to use virt-manager I want to throw it out a window). Some people certainly would rather use threading, but that doesn't say anything about whether Twisted solves problems relevant to clients, only about the fact that a lot of people like to use threads. This discussion has a significant problem, in taking \"Twisted\" as a monolithic all-or-nothing entity. Restricting the scope to merely the lowest-level socket replacement APIs - ie, the bare TCP, UDP, etc functionality - no, Twisted is not very difficult to learn. Expanding the scope to include the higher level functionality, it is much easier to learn than reimplementing line parsing and concurrency and so forth. However, does that really have anyth</pre>", "group_id": 8954, "id": 1298985}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307341526.305187, "message": "[devel] - Add LRUCache class to stdlib - http://tinyurl.com/3byrx4x - Nadeem Vawda - <pre>I would like to propose adding a class to the stdlib to provide a more flexible LRU caching mechanism. As things stand, the functools.lru_cache() decorator is fine for memoization of pure functions, but does not accommodate situations where cache entries become stale and must be invalidated/updated (e.g. filecmp.cmp(); cf. issue #11802). I was thinking it would be a good idea to factor out the the replacement code into a separate class that could then be reused by code for which the lru_cache() decorator is not applicable. The implementation of lru_cache() itself would also become considerably simpler. Implementation: class LRUCache: \"\"\"Least-recently-used cache class. See: http://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used \"\"\" def __init__(self, maxsize): \"\"\"Initialize an LRUCache. If *maxsize* is None, the LRU replacement mechanism is disabled, and the cache can grow without bound. \"\"\" if</pre>", "group_id": 8954, "id": 1300894}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307345126.4744749, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3dnqgja - Antoine Pitrou - <pre>On Mon, 06 Jun 2011 00:22:11 +0200 \"Martin v. L\u00f6wis\" &lt;martin&lt; at &gt;v.loewis.de&gt; wrote: So what? You can say the exact same thing about every API under the sun. Yet the sockets HOWTO *doesn't* explain what the socket APIs are actually doing. </pre>", "group_id": 8954, "id": 1301070}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307346929.6443491, "message": "[devel] - Re: cpython: always clear parser error - http://tinyurl.com/3tf2ha2 - Georg Brandl - <pre> This looks like a fixup of rev 3ffd8dea77bf; it would be nice to say so in the commit message: the current message is not obvious at all. Georg </pre>", "group_id": 8954, "id": 1301209}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307347831.22521, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3z2qm34 - Stephen J. Turnbull - <pre> &gt; Did you run a user survey? Martin undoubtedly has a lot of experience with users, and it's quite reasonable for him to express his opinions based on that informal sample, yes. The issue here is the difference between existential and universal quantifiers. Martin's arguments are not inconsistent. They simply acknowledge the existence of subsamples of users of the same document with different needs and/or approaches to reading the document. He does not and has never claimed that all of his arguments apply to all of the potential readers. You might question whether the same document should serve both the \"cargo cult the examples\" group and the \"read the fine print\" group. That's a valid question, but here my feeling is that the answer is \"yes\". I very often \"cargo cult\" my first program, then go back to the fine print and experiment by gradually changing that program to test my understanding of the detailed explanations. It is often easiest to use the same document for both purposes because I alread</pre>", "group_id": 8954, "id": 1301282}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307347828.1904769, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/43avx5p - Stephen J. Turnbull - <pre> &gt; However, does that really have anything to do with improving the socket &gt; howto? Thank you! &gt; The Python documentation can include a clear explanation of what &gt; functionality the socket module provides - without forcing you to read &gt; Stevens _or_ use Twisted, but it can still refer you to both, since it &gt; is very likely that you'll need at least one of them in addition to the &gt; socket module. +1 I suggest s/very likely/likely/, though. </pre>", "group_id": 8954, "id": 1301281}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307348726.8884599, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/6a5u7um - Antoine Pitrou - <pre>Le lundi 06 juin 2011 \u00e0 17:01 +0900, Stephen J. Turnbull a \u00e9crit : So did you read the discussion before posting? The sockets HOWTO *doesn't* serve both groups. Actually, I would argue that it serves neither of them. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1301375}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307349631.656146, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/6dp694f - Martin v. L\u00f6wis - <pre>Am 06.06.2011 10:11, schrieb Antoine Pitrou: How can you make such claims when several people have indicated that the howto *actually* helped them? Please let this rest. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1301442}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307349628.6806121, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/5s3q8sc - Martin v. L\u00f6wis - <pre> In particular, this is collected experience from interaction with students learning Python, or other languages. When they try to solve a problem, they don't read specification-style documentation. Instead they look for examples that they can imitate. [I notice that you (Stephen) also confirmed this from your own experience] Exactly so. I'd like to settle this discussion based on the anecdotal report of several users on this list that they considered the tutorial useful. In that spirit, I'd be in favor of removing outright errors from the document, and overly subjective and argumentative passages. Other than that, I still think its fine as it stands. Regards, Martin </pre>", "group_id": 8954, "id": 1301440}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307355927.2786691, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/624vhjv - Antoine Pitrou - <pre>On Mon, 06 Jun 2011 10:33:14 +0200 \"Martin v. L\u00f6wis\" &lt;martin&lt; at &gt;v.loewis.de&gt; wrote: The point here is that the examples in that document are very poor (the only substantial example actually duplicates existing functionality - in a sub-optimal manner - without even mentioning the existence of said functionality), and the technical explanations are nearly non-existent. So I'll happy stand by my claims. The Python documentation isn't meant to host any potentially helpful document, however flawed. We have the Internet for that. Regards Antoine. </pre>", "group_id": 8954, "id": 1301823}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307356828.1942761, "message": "[devel] - Buildbots and regrtest timeout - http://tinyurl.com/3brzbfp - Victor Stinner - <pre>Hi, Stephan Krah asked me to change how the default timeout is defined for regrtest (issue #12250): \"The implicit timeout in regrtest.py makes it harder to write automated test scripts for 3rd party modules. First, you have to remember to set --timeout=0 for long running tests. Then, you have to remember not to use the --timeout option when compiling --without-threads. I'd much prefer that there's no timeout unless explicitly specified. For the buildbots, I think this could be done in the Makefile.\" First I replaced the hardcoded constant in regrtest.py by a command line argument (--timeout=3600) in the TESTOPTS variable of the Makefile, so if you call regrtest directly (without make), there is no more default timeout. But today I saw a a buildbot timeout without any traceback: a possible hang in test_io on \"x86 FreeBSD 7.2 3.x\" buildbot, \"command timed out: 3900 seconds without output\". I realized that some buildbots (all buildbots?) override the TESTOPTS variable (\"make buildbottest TESTOPTS= TE</pre>", "group_id": 8954, "id": 1301889}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307361331.8106511, "message": "[devel] - Re: Buildbots and regrtest timeout - http://tinyurl.com/3ghshk9 - Paul Moore - <pre> How does this impact Windows buildbots? As they don't use the makefile, did you add an override to the Windows scripts as well, or will WIndows now use the default of no timeout? Paul. </pre>", "group_id": 8954, "id": 1302268}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307361327.444145, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3t5homa - Steven D'Aprano - <pre>[...] You know, for the amount of discussion about whether or not the doc is worth keeping, we probably could have fixed all the problems with it :) I believe that \"status quo wins\" is worth applying here. In the absence of evidence that the HOWTO is actively harmful, we should keep it. I'm of two minds whether it should go into the wiki. I would hate for the wiki to become the place where bad docs go to die, but on the other hand putting it in the wiki may encourage lightweight incremental fixes. I think the Socket HOWTO is important enough to fix, not throw out. I also dislike link-rot, and throwing it out causes link-rot. I'd rather see a bunch of concrete bug reports for the HOWTO than just a dismissive \"throw it out and start again\". I think it is unfair to dismiss the document as \"potentially\" helpful when a number of people have said that it *actually* did help them. </pre>", "group_id": 8954, "id": 1302267}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307369613.755368, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/6gvsvdh - Antoine Pitrou - <pre>Le lundi 06 juin 2011 \u00e0 22:59 +0900, Stephen J. Turnbull a \u00e9crit : Don't hesitate to contribute. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1303684}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307369607.1608739, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/5wnf6tx - Stephen J. Turnbull - <pre> &gt; So did you read the discussion before posting? Yes. It's rude to assume that those who disagree with you are irresponsible and uninformed. Would you please stop it? &gt; The sockets HOWTO *doesn't* serve both groups. &gt; Actually, I would argue that it serves neither of them. I know that is your opinion, because I've read your posts. I disagree. The document is imperfect, but for me it served a certain purpose. Therefore I stand with the camp that says improving the document is the way to go. </pre>", "group_id": 8954, "id": 1303682}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307376870.339417, "message": "[devel] - Re: packaging landed in stdlib - http://tinyurl.com/65gejrn - \u00c9ric Araujo - <pre>Hi, My GSoC student made me realize that it could be quite difficult to work with the packaging module codebase when you\u2019re familiar with the distutils code. I wrote a blog post about file-level changes from distutils to packaging, to help people find their way: https://wokslog.wordpress.com/2011/06/04/distutils-diff/ Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1305526}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307384072.056741, "message": "[devel] - Help requested for Python ISO Standard - http://tinyurl.com/6ca79q8 - kevin coyne - <pre> To whom it may concern: I am working on an ISO Annex of Vulnerabilities for the Python language and am asking for help getting a list of language features that exhibit: unspecified behavior, undefined behavior, or implementation defined behavior. I am also searching for a list of deprecated features. Guido (copied) had suggested I contact you folks for help as we are coming up on an ISO deadline and I have not been successful finding this information. Thanks very much in advance for your help! Regards, Kevin Coyne Cell: 703.901.6774 </pre>", "group_id": 8954, "id": 1308254}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307387671.248364, "message": "[devel] - Re: Buildbots and regrtest timeout - http://tinyurl.com/3b4ctzy - David Bolen - <pre> (...) Just a note, given the phrasing above. None of this is anything that I for example, as a buildbot operator, am actively controlling. That command, including the environment variable overrides, is exactly as provided by the master for a given test run. So I'd think you could adjust it if needed through changes in the master build configuration and probably without having to add an environment variable or Per Paul's follow-up on Windows, buildbot under Windows seems to impose a 1200s idle timeout (just for no output), but I'm not positive how it's calculated. The test process itself has never, I'm pretty sure, specified a timeout to regrtest (via the test.bat, rt.bat, regrtest.py path). (Oh, I guess the --timeout option itself in regrtest is fairly new) So if there's a change in defaults for regrtest that will change Windows behavior implicitly, and I believe at this point the buildbots will be inconsistent, since you're only overriding the regrtest default in a subset of buildbot types. </pre>", "group_id": 8954, "id": 1309537}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307388569.286324, "message": "[devel] - Re: FWD: gpg keys have problems - http://tinyurl.com/66teg8v - Barry Warsaw - <pre> This only looks like a problem with Anthony's key. He could update his key, but OTOH probably has little incentive to just for Python release management. Anthony was release manager for 2.5, but Martin took that over, and also, Python 2.5 is very near EOL even for security releases. -Barry </pre>", "group_id": 8954, "id": 1309852}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307393130.477634, "message": "[devel] - Re: Help requested for Python ISO Standard - http://tinyurl.com/5tdwnmz - skip< at >pobox.com - <pre> kevin&gt; I am working on an ISO Annex of Vulnerabilities for the Python kevin&gt; language and am asking for help getting a list of language kevin&gt; features that exhibit: kevin&gt; unspecified behavior, undefined behavior, or implementation kevin&gt; defined behavior. I am also searching for a list of deprecated kevin&gt; features. One place to search: http://svn.python.org/projects/python/branches/py3k/Lib/test/crashers/ </pre>", "group_id": 8954, "id": 1311199}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307395828.3345599, "message": "[devel] - AIX 5.3 - Build of Python 2.7.1 - http://tinyurl.com/5re48g4 - Anurag Chourasia - <pre>Hi All, Python2.7.1 build on AIX 5.3 ML 12 is failing at the make step with the error indicated below de -I./Include -I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o Parser/tokenizer_pgen.c gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses -DPy_BUILD_CORE -o Parser/printgrammar.o Parser/printgrammar.c gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses -DPy_BUILD_CORE -o Parser/pgenmain.o Parser/pgenmain.c gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Pars</pre>", "group_id": 8954, "id": 1312087}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307400328.96385, "message": "[devel] - Re: Help requested for Python ISO Standard - http://tinyurl.com/5wlk5gb - kevin coyne - <pre> Skip: Thanks, appreciate the link I've checked them all out and some may be useful to my task. Regards, Kevin Coyne Cell: 703.901.6774 </pre>", "group_id": 8954, "id": 1313620}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307399430.6100359, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/6axa5c3 - C McL - <pre> +1. I've been reading the postings on this discussion intently, as I have had experience with the socket HOWTO when I was first learning about sockets. I agree with the view that Martin v. L\u00f6wis expressed, that as a beginner I didn't read too much into the text at first because I was more concerned with trying out the examples and getting used to writing the code and such. I would also say that, I wasn't too bothered if the guide never went into too much detail about all the terms it was mentioning, it isn't after all a definitive guide on sockets, but the terms can always be googled later if one so wished. I wholeheartedly disagree with removing it, that would be a real shame and I dislike the idea of moving it to the wiki (I cannot even remember ever visiting the wiki). I may not be a Python Guru but I think my \"n00bishness\" helps in this particular discussion and I would say I would have to agree to an improvement over the suggested alternatives. Craig </pre>", "group_id": 8954, "id": 1313310}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307412093.6488521, "message": "[devel] - Re: Help requested for Python ISO Standard - http://tinyurl.com/3b3kgoy - Nick Coghlan - <pre> Another two scans to try would be to look for \"cpython\" in the test suite and \"impl-detail\" in the documentation. Cheers, Nick. </pre>", "group_id": 8954, "id": 1315850}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307430249.0030689, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/6jm2n9t - Georg Brandl - <pre> Swapping the comparison order here seems a bit inconsistent to me. There are lots of others around (e.g. \"len == 0\" in the patch context below). Why is this one so special? I think that another developer even got told off once for these kinds of comparisons. I hope the Clang warning is only about the parentheses. Georg </pre>", "group_id": 8954, "id": 1317605}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307435732.7327299, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/63lg9g7 - Antoine Pitrou - <pre>On Tue, 07 Jun 2011 08:57:10 +0200 Georg Brandl &lt;g.brandl&lt; at &gt;gmx.net&gt; wrote: Agreed. Either we do it wholesale (I find these \"reversed\" comparisons a bit ugly myself) or there's no point doing it on a single occurrence. Regards Antoine. </pre>", "group_id": 8954, "id": 1318258}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307437592.120785, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/3pl2arm - \u0141ukasz Langa - <pre> Wiadomo\u015b\u0107 napisana przez C McL w dniu 2011-06-07, o godz. 00:15: FWIW neither can I. The Wiki link on the front page is below Jobs and Merchandise so it's easy to miss it altogether ;-) </pre>", "group_id": 8954, "id": 1318497}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307437595.2280619, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/3tk8l3q - M.-A. Lemburg - <pre> I agree with Georg: \"if ('u' == typecode)\" is not well readable, since you usually put the variable part on the left and the constant part on the right of an equal comparison. If clang warns about this, clang needs to be fixed, not our C code :-) </pre>", "group_id": 8954, "id": 1318498}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307440411.4820011, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/3fxnsub - Eli Bendersky - <pre> +1 Placing the constant first in a comparison is a fundamental style issue. Personally I also don't like doing that, but whatever way is chosen must be consistent. It's definitely wrong to change this in a single place. We have PEP-7 for these things! AFAIK, Clang doesn't produce a warning for this, at least without special static-analysis warning levels. Eli </pre>", "group_id": 8954, "id": 1318921}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307467533.410037, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/6jh6qnd - Glyph Lefkowitz - <pre> Yes, these are all excellent concepts to be familiar with. But the word \"socket\" (and the socket HOWTO) refers to a specific way to interface with those concepts, the Berkeley socket API: &lt;http://en.wikipedia.org/wiki/Berkeley_sockets&gt;. Which you don't have to know anything about if you're going to use Twisted. You should know about IPC in general, and TCP/UDP specifically if you're going to use Twisted, but sockets are completely optional. Also, I feel that I should point out that the sockets HOWTO does not cover even a single one of these concepts in any useful depth. If you think that these are what it should be explaining, it needs some heavy editing. Here's what it has to say about each one: The only place that the characters \"TCP\" appear in the entire document is in the phrase \"... which is completely different from TCP_NODELAY ...\". Nowhere is a TCP connection explained at a conceptual level, except to say that it's something a web browser does. The phrase \"UDP\" never appears in the HOWTO</pre>", "group_id": 8954, "id": 1324576}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307468436.3422501, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/6d33fdp - Eli Bendersky - <pre>&lt;snip&gt; &lt;snip&gt; Just be careful not to reproduce http://www.apress.com/9781590593714 :-) These things tend to get out of hand very quickly. Eli </pre>", "group_id": 8954, "id": 1324906}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307476538.0783899, "message": "[devel] - Re: AIX 5.3 - Build of Python 2.7.1 - http://tinyurl.com/63eh4fj - Amaury Forgeot d'Arc - <pre>Hi, 2011/6/6 Anurag Chourasia &lt;anurag.chourasia&lt; at &gt;gmail.com&gt;: A quick Google search reveals a probable issue with gcc on recent AIX systems. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 A lot of users report this issue on various programs. Nothing Python can do about. You could try to disable the -g option. </pre>", "group_id": 8954, "id": 1327031}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307482054.928215, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/5ukgofw - Guido van Rossum - <pre> Right. I personally really despise putting the constant first. CLang shouldn't force our hand here. </pre>", "group_id": 8954, "id": 1328171}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307483854.372788, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/6cut3uw - Alexander Belopolsky - <pre>.. I appear to be in the minority here, but this particular example does not strike me as egregiously unreadable. To the contrary, by bringing the constant to the front, this form saves me from having to read to the end of the line. The same mental economy appears when constants are brought to the front of chained if-elif cases in Python: if 'a' == typecode: .. elif 'b' == typecode: .. is slightly more readable than the more traditional alternative. Probably because I can mentally ignore the \"== typecode\" part and see the switch structure more clearly. Either way, I don't see a big issue here and I would keep \"len == 0\" intact even if I reordered typecode == 'u' as Brett did. The only consistency that I would enforce is to use the same order in the chained if-elif cases, but otherwise this should be left to the discretion of the author. </pre>", "group_id": 8954, "id": 1328658}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307486673.16066, "message": "[devel] - Byte filenames in the posix module on Windows - http://tinyurl.com/3s86nmk - Victor Stinner - <pre>Hi, Last november, we \"decided\" (right?) to deprecate bytes filenames in the posix module on Windows in Python 3.2 and drop the support in 3.3: see \"Removal of Win32 ANSI API\" thread on python-dev. Python 3.2 has been released, so we should shift the versions numbers. I would like to take care of this. I propose three steps: 1) Remove the bytes implementation of each function (when the code is not shared with other OSes), decode bytes from MBCS and reuse the Unicode code. 2) Deprecate the bytes code in Python 3.3 3) Drop bytes support in Python 3.4 (I'm only talking about the posix module on Windows) The first step should not change anything for the user, but it will remove a lot of duplicated code. I expect something like removing the half of the code specific to Windows in the posix module. If we decide to keep bytes filenames on Windows, we can stop before the second step. -- One important point is the choice of the error handler: I would like to mimic the ANSI API and so I will use Mul</pre>", "group_id": 8954, "id": 1329729}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307487575.152503, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/3jct4kn - David Malcolm - <pre> [FWIW, I'm one of the reprobates that likes to put the constant on the LHS when I'm coding in C, but I see I'm in the minority here] I know that this style is unpopular, but if it helps, try mentally pronouncing \"==\" in C as \"is the value of\". In this example, when I read that line, my mind is thinking: \"if 'u' is the value of typecode\" After ~12 years of doing this, it comes naturally. I appreciate that this may come across as weird though :) [snip] Hope this is helpful Dave </pre>", "group_id": 8954, "id": 1330148}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307496636.8645351, "message": "[devel] - Re: cpython: Remove some extraneous parentheses andswap the comparison order to - http://tinyurl.com/3gumgnw - R. David Murray - <pre> I don't do much C coding, so I don't have the right to an opinion on that (FWIW, I find constant-first jarring). But I'd hate to see the above in python code. The fact that you like it because it makes it easier to read as a switch-like statement should instead tell you that it is time to refactor the code. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 1331828}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307502036.1324871, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/3om4z34 - Terry Reedy - <pre> Whereas I read it as 'has the value' (or just 'is' ;=). Not being tempted to reverse in Python is one advantage of not having assignment expressions. </pre>", "group_id": 8954, "id": 1332464}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307502935.1694911, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/3awejwx - Brett Cannon - <pre> Old habit on how to do comparisons in C. Because C treats assignment as an expression it means comparisons can accidentally become an assignment if you accidentally leave out an = sign. By reversing this order it is simply not possible to have that silent bug and instead you would get a compiler error about trying to assign to a constant. I'll revert that part of the change. Yes, Clang only warned about the parentheses. -Brett </pre>", "group_id": 8954, "id": 1332642}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307531856.41362, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/5u2msmy - Steven D'Aprano - <pre> Am I the only one who reads == as \"equals\"? </pre>", "group_id": 8954, "id": 1335885}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307546383.373019, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/69uowav - Nick Coghlan - <pre> I actually thought Brett's rationale in the checkin comment was reasonable (if you get in the habit of putting constants on the left, then the classic \"'=' instead of '=='\" typo is a compiler error instead of a reassignment). Call it a +0 in favour of letting people put constants on the left in C code if they prefer it that way, so long as any given if/elif chain is consistent in the style it uses. Cheers, Nick. </pre>", "group_id": 8954, "id": 1338195}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307545477.2986629, "message": "[devel] - Can we improve support for abstract base classes withdesciptors - http://tinyurl.com/3mqoj6a - Darren Dale - <pre>I would like to try to address some shortfalls with the way python deals with abstract base classes containing descriptors. I originally was just concerned with improving support for defining abstract properties with the decorator syntax and converting between abstract and concrete properties, but recently realized that the problem extends to descriptors in general. ABCs ---- First, a bit of background may be in order. An abstract base class is defined by specifying its metaclass as ABCMeta (or a subclass thereof):: class MyABC(metaclass=ABCMeta): &lt; at &gt;abstractmethod def foo(self): pass When trying to instantiate MyABC or any of its subclasses, ABCMeta inspects the current class namespace for items tagged with __isabstractmethod__=True:: class ABCMeta(type): #[...] def __new__(mcls, name, bases, namespace): cls = super().__new__(mcls, name, bases, namespace) # Compute set of abstract method names abstracts = {name </pre>", "group_id": 8954, "id": 1337982}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307546380.6287291, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/65jvn8z - Nick Coghlan - <pre> And if UDP starts sounding tempting due to excessively high latency, these days it's worth looking up the specs for the interplanetary internet instead. Cheers, Nick. </pre>", "group_id": 8954, "id": 1338191}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307546378.0088961, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/6jl927e - Nick Coghlan - <pre> At the level Glyph and Martin are talking about, you're more likely to end up with http://authors.phptr.com/tanenbaumcn4/ :) Cheers, Nick. </pre>", "group_id": 8954, "id": 1338189}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307546385.9123709, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/665wy5n - Alexander Belopolsky - <pre>.. If you are, you are the only one who reads it correctly. Consider True </pre>", "group_id": 8954, "id": 1338197}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307547279.2034869, "message": "[devel] - Re: cpython: Remove some extraneous parentheses andswap the comparison order to - http://tinyurl.com/3zs3ym3 - R. David Murray - <pre> No :) Especially considering that Python actually has an 'is' operator.... -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 1338416}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307549077.24951, "message": "[devel] - Re: Can we improve support for abstract base classes with desciptors - http://tinyurl.com/5ro6ahl - Nick Coghlan - <pre>[snip excellent analysis of the problem] I have some suggestions regarding a few details of your current code, but your basic proposal looks sound to me. I would tweak __new__ along the following lines though: def __new__(mcls, name, bases, namespace): cls = super().__new__(mcls, name, bases, namespace) # Compute set of abstract method names # CHANGE 1: refactor descriptor and abstract method scan to happen in a single pass def is_descriptor(value): return (hasattr(value, '__get__') or hasattr(value, '__set__') or hasattr(value, '__delete__')) def is_abstract(value): return getattr(value, \"__isabstractmethod__\", False) def get_abstract_names_for_item(item): name, value = item if is_abstract(value): return [name] elif is_descriptor(value): # CHANGE 2: Deliberately ignore descriptors on the descriptor objects # CHANGE 3: Use new-style string f</pre>", "group_id": 8954, "id": 1338802}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307557237.337954, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/6khfy2h - geremy condra - <pre> You say that like it's a bad thing. The first few chapters of that would make a great replacement for the howto. Geremy Condra </pre>", "group_id": 8954, "id": 1340040}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307562640.4885869, "message": "[devel] - fatal error callback issue - http://tinyurl.com/6xclh8e - Tom Whittock - <pre>I'm writing in regards to http://bugs.python.org/issue1195571 I'm embedding Python in my application and ran into a need for this functionality. I wrote a similar patch myself, and was about to submit it. When I searched for similar issues I found that this one has been available since 2005. I'd really like to help get this patch approved and integrated into the python sources. I'm sure many other python embedders have run into this in the past - it's a legitimate concern for any process which is not 100% hosted in the Python world. Thanks. Tom. </pre>", "group_id": 8954, "id": 1341608}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307574520.5963891, "message": "[devel] - Re: Can we improve support for abstract base classes with desciptors - http://tinyurl.com/3crdr75 - Darren Dale - <pre>[snip] Thank you, I agree. Concerning the following block: That should be \"get_abstract_names(namespace)\", since ns.items() gets called again in the for loop. I think the get_abstract_names function isn't needed though, since it is only ever called that one time. Any reason not replace the above block with:: abstract_names = [] for item in namespace.items(): abstract_names.extend(get_abstract_names_for_item(item)) Could you provide an example of weird naming? Darren _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1343640}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307580939.36377, "message": "[devel] - Re: [Python-checkins] cpython (2.7): Merge - http://tinyurl.com/6jntpl3 - Victor Stinner - <pre>Le jeudi 09 juin 2011 \u00e0 02:30 +0200, brian.curtin a \u00e9crit : FYI this commit has only one parent, it's not a merge. It should have a changelog describing the patch. ... whereas the following commit has two parents, it's a merge: You can use \"merge\", \"Merge 3.2\", or other similir changelog. I prefer to use \"(Merge 3.2)Fix #11583. Changed os.path._isdir ...\" : copy/paste the changelog of the original commit with \"(Merge 3.2) \" prefix. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1344515}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307580943.247817, "message": "[devel] - Re: fatal error callback issue - http://tinyurl.com/3wuo8r2 - Terry Reedy - <pre> Add a comment like this to the issue itself. Also review the most recent patch, considering Victor's comments. Is it better than yours? Can you improve it? Can you test it? </pre>", "group_id": 8954, "id": 1344517}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307585442.839793, "message": "[devel] - Re: Can we improve support for abstract base classes with desciptors - http://tinyurl.com/6abmr4e - Nick Coghlan - <pre> Nope, inlining that part makes sense. ... pass ... Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt; AttributeError: 'C' object has no attribute 'weird' Traceback (most recent call last): File \"&lt;stdin&gt;\", line 1, in &lt;module&gt; AttributeError: 'C' object has no attribute 'weird' 0 This is definitely something that could legitimately be dismissed as \"well, don't do that then\" (particularly since similarly weird names on the descriptors will still break). However, I also prefer the way partition based code reads over split-based code, so I still like the modified version. Full tolerance for weird naming would require storing 2-tuples in __abstractmethods__ which would cause a whole new set of problems and isn't worth the hassle. Cheers, Nick. </pre>", "group_id": 8954, "id": 1345074}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307594498.6689219, "message": "[devel] - Re: The socket HOWTO - http://tinyurl.com/6dx9qau - Eli Bendersky - <pre> Not a bad thing at all, and I'm sorry if I made it sound that way. I just meant that it may turn into a *whole book* if too many details are added. I had no intention to criticize this specific book. Frankly I didn't even read it, I just remembered that a book with this title came out recently. Eli </pre>", "group_id": 8954, "id": 1346370}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307600800.6298079, "message": "[devel] - Re: cpython (3.2): Fix #11583. Changed os.path.isdir to use GetFileAttributes instead of os.stat. - http://tinyurl.com/6z7arxq - Georg Brandl - <pre> Not that it matters, but ISTM that this would be faster as try: from nt import _isdir as isdir except ImportError: pass Georg </pre>", "group_id": 8954, "id": 1346826}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307610713.7327111, "message": "[devel] - Re: cpython (3.2): Fix #11583. Changed os.path.isdir to use GetFileAttributes instead of os.stat. - http://tinyurl.com/3h54g89 - Victor Stinner - <pre>Le jeudi 09 juin 2011 \u00e0 08:16 +0200, Georg Brandl a \u00e9crit : I would matter if _isdir() had a docstring, but it doesn't :-) genericpath.isdir() has the following doc: def isdir(s): \"\"\"Return true if the pathname refers to an existing directory.\"\"\" Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1347523}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307617924.1991041, "message": "[devel] - 3.2.1 and Issue 12291 - http://tinyurl.com/68lzxoh - Vinay Sajip - <pre>I just filed an issue which shows a serious breakage in the marshal module: \"file written using marshal in 3.2 can be read by 2.7, but not 3.2 or 3.3\" http://bugs.python.org/issue12291 Perhaps this issue should be marked as a release blocker for 3.2.1 - what do others (particularly Georg, of course) think? While it does appear to have been broken for some time, it seems a bit too serious to leave until a 3.2.2 release. Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 1348291}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307620635.7374101, "message": "[devel] - Re: Can we improve support for abstract base classes with desciptors - http://tinyurl.com/63jfv4g - Darren Dale - <pre>[...] Yes, I like your modified version as well. I just wanted to understand your concern, since it had never occurred to me to try something like \"setattr(C, 'pathological.name', ...)\". I'm glad you feel that way. I'll work on a patch that includes docs and unit tests and post it at http://bugs.python.org/issue11610. What do you think about deprecating abstractproperty, or removing it from the documentation? Darren _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1348668}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307623328.1866729, "message": "[devel] - Re: Can we improve support for abstract base classes with desciptors - http://tinyurl.com/6x2l2vw - Nick Coghlan - <pre> Unless anyone specifically howls at the idea, +1 to both (since abstractproperty doesn't actually achieve the intended purpose and will become redundant with the proper fix in 3.3). Cheers, Nick. </pre>", "group_id": 8954, "id": 1349358}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307633233.0552061, "message": "[devel] - Re: cpython (3.2): Fix #11583. Changed os.path.isdir to use GetFileAttributes instead of os.stat. - http://tinyurl.com/3b4h999 - Brian Curtin - <pre>On Thu, Jun 9, 2011 at 04:05, Victor Stinner &lt;victor.stinner&lt; at &gt;haypocalc.com&gt;wrote: http://hg.python.org/lookup/d40609dd01e0 adds the docstring back in and redoes the imports as Georg mentioned, which is better. Thanks for having a look. </pre>", "group_id": 8954, "id": 1351116}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307633229.0479469, "message": "[devel] - Re: 3.2.1 and Issue 12291 - http://tinyurl.com/43vtyag - Barry Warsaw - <pre> Sounds bad ;). I marked it a release blocker, but of course Georg will have the final say. -Barry </pre>", "group_id": 8954, "id": 1351114}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307723007.0587599, "message": "[devel] - Summary of Python tracker Issues - http://tinyurl.com/3ufdsen - Python tracker - <pre> ACTIVITY SUMMARY (2011-06-03 - 2011-06-10) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2826 (+11) closed 21268 (+47) total 24094 (+58) Open issues with patches: 1236 Issues opened (45) ================== #5906: Risk of confusion in multiprocessing module - daemonic process http://bugs.python.org/issue5906 reopened by pakal #9516: sysconfig: $MACOSX_DEPLOYMENT_TARGET mismatch: now \"10.3\" but http://bugs.python.org/issue9516 reopened by eric.araujo #12255: A few changes to .*ignore http://bugs.python.org/issue12255 opened by eric.araujo #12256: Link isinstance/issubclass doc to abc module http://bugs.python.org/issue12256 opened by eric.araujo #12257: Rework/replace use of DISTUTILS_USE_SDK in packaging http://bugs.python.org/issue12257 opened by eric.araujo #12258: Clean up bytes I/O in get_compiler_versions http://bugs.python.org/issue12258 opene</pre>", "group_id": 8954, "id": 1362615}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307736623.5787661, "message": "[devel] - Re: cpython: Remove some extraneous parentheses and swap the comparison order to - http://tinyurl.com/6knxprp - Guido van Rossum - <pre> I really like consistency across the code base. I really don't like constant-on-the-left, and it's basically not used in the current codebase. Please be consistent and don't start using it. Sorry, I give it a -1. (I'd like to be able to read the codebase still... :-) </pre>", "group_id": 8954, "id": 1365399}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307741124.1797061, "message": "[devel] - PEP 3101 implementation vs. documentation - http://tinyurl.com/3p4w2fd - Ben Wolfson - <pre>Hello, I'm writing because discussion in a bug report I submitted (&lt;http://bugs.python.org/issue12014&gt;) has suggested that, insofar as at least part of the issue revolves around the interpretation of PEP 3101, that aspect belonged on python-dev. In particular, I was told that the PEP, not the documentation, is authoritative. Since I'm the one who thinks something is wrong, it seems appropriate for me to be the one to bring it up. Basically, the issue is that the current behavior of str.format is at variance at least with the documentation &lt;http://docs.python.org/library/string.html#formatstrings&gt;, is almost certainly at variance with PEP3101 in one respect, and is in my opinion at variance with PEP3101 in another respect as well, regarding what characters can be present in what the grammar given in the documentation calls an element_index, that is, the bit between the square brackets in \"{0.attr[idx]}\". Both discovering the current behavior and interpreting the documentation are pretty straightforward; in</pre>", "group_id": 8954, "id": 1366132}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307753723.593555, "message": "[devel] - Re: Python jails - http://tinyurl.com/6j9ny4w - R. David Murray - <pre> Well, hopefully we won't bite, though of course I can't promise anything for anyone else :) I haven't read through your post, but if you don't know about it I suspect that you will be interested in the following: http://code.activestate.com/pypm/pysandbox/ I'm pretty sure Victor will be happy to have someone else interested in this topic. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 1367921}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307752822.2578051, "message": "[devel] - Python jails - http://tinyurl.com/6e4hjv3 - Sam Edwards - <pre>Hello! This is my first posting to the python-dev list, so please forgive me if I violate any unspoken etiquette here. :) I was looking at Python 2.x's f_restricted frame flag (or, rather, the numerous ways around it) and noticed that most (all?) of the attacks to escape restricted execution involved the attacker grabbing something he wasn't supposed to have. IMO, Python's extensive introspection features make that a losing battle, since it's simply too easy to forget to blacklist something and the attacker finding it. Not only that, even with a perfect vacuum-sealed jail, an attacker can still bring down the interpreter by exhausting memory or consuming excess CPU. I think I might have a way of securely sealing-in untrusted code. It's a fairly nascent idea, though, and I haven't worked out all of the details yet, so I'm posting what I have so far for feedback and for others to try to poke holes in it. Absolutely nothing here is final. I'm just framing out what I generally had in mind. Obviously, it will </pre>", "group_id": 8954, "id": 1367784}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307753727.3227761, "message": "[devel] - Re: Python jails - http://tinyurl.com/62vbbhg - Guido van Rossum - <pre>Hi Sam, Have you seen this? http://tav.espians.com/paving-the-way-to-securing-the-python-interpreter.html It might relate a similar idea. There were a few iterations of Tav's approach. --Guido On Fri, Jun 10, 2011 at 5:23 PM, Sam Edwards &lt;sam.edwards&lt; at &gt;colorado.edu&gt; wrote: </pre>", "group_id": 8954, "id": 1367922}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307753731.206331, "message": "[devel] - Re: Python jails - http://tinyurl.com/6l94787 - P.J. Eby - <pre> You might be able to answer some of them by looking at this project: http://pypi.python.org/pypi/RestrictedPython Which implements the necessary ground machinery for doing that sort of thing, in the form of a specialized Python compiler (implemented in Python, for 2.3 through 2.7) that allows you to implement whatever sorts of guards and security policies you want on top of it. Even if it doesn't answer all your questions in and of itself, it may prove a fruitful environment in which you can experiment with various approaches and see which ones you actually like, without first having to write a bunch of code yourself. Discussing an official implementation of this sort of thing as a language feature is probably best left to python-ideas, though, until and unless you actually have a PEP to propose. </pre>", "group_id": 8954, "id": 1367923}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307765546.5766561, "message": "[devel] - Re: Python jails - http://tinyurl.com/5r4dcmb - Sam Edwards - <pre>All, Thanks for the quick responses! I've skimmed the pysandbox code yesterday. I think Victor has the right idea with relying on a whitelist, as well as limiting execution time. The fact that untrusted code can still execute memory exhaustion attacks is the only thing that still worries me: It's hard to write a server that will run hundreds of scripts from untrusted users, since one of them can bring down the entire server by writing an infinite loop that allocates tons of objects. Python needs a way to hook the object-allocation process in order to (effectively) limit how much memory untrusted code can consume. Tav's blog post makes some interesting points... The object-capability model definitely has the benefit of efficiency; simply getting the reference to an object means the untrusted code is trusted with full capability to that object (which saves having to query the jail every time the object is touched) - it's just as fast as unrestricted Python, which I like. Perhaps my jails idea should then be</pre>", "group_id": 8954, "id": 1368517}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307784565.0881441, "message": "[devel] - Re: PEP 3101 implementation vs. documentation - http://tinyurl.com/5rv4jmz - Nick Coghlan - <pre>[snip very thorough analysis] To summarise (after both the above post and the discussion on the tracker) The current str.format implementation differs from the documentation in two ways: 1. It ignores the presence of an unclosed index field when processing a replacement field (placing additional restrictions on allowable characters in index strings). 2. Replacement fields that appear in name specifiers are processed by the parser for brace-matching purposes, but not substituted More accurate documentation would state that: 1. Numeric name fields start with a digit and are terminated by any non-numeric character. 2. An identifier name field is terminated by any one of: '}' (terminates the replacement field, unless preceded by a matching '{' character, in which case it is ignored and included in the string) '!' (terminates name field, starts conversion specifier) ':' (terminates name field, starts format specifier) '.' (terminates current name field, starts new name field for subattribute</pre>", "group_id": 8954, "id": 1369296}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307782707.163259, "message": "[devel] - Re: Python jails - http://tinyurl.com/3f7v4cm - Victor Stinner - <pre>Le 11/06/2011 02:41, R. David Murray a \u00e9crit : Yes, I am happy :-) The project URL is https://github.com/haypo/pysandbox/ Activestate page is wrong: pysanbox does support Python 3 (Python 2.5 - 3.3). pysandbox uses different policy depending on the problem. For example, whitelist for builtins, blacklist for object attributes. pysandbox is based on Tav's ideas. The main idea of pysandbox is to execute untrusted in a new empty namespace, the untrusted namespace. Objects imported into this namespace are imported as proxies to get a read-only view of the Python namespace. Importing modules is protected by a whitelist (modules and symbols names). To protect the namespace, some introspection attributes are hidden like __subclasses__ or __self__. Performances are supposed to be close to a classic Python interpreter (I didn't run a benchmark, I don't really care). An empty namespace is not enough to protect Python: pysandbox denies the execution of arbitrary bytecode, write files, write to stdout/std</pre>", "group_id": 8954, "id": 1369255}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307790926.422111, "message": "[devel] - Re: PEP 3101 implementation vs. documentation - http://tinyurl.com/62ejlww - Petri Lehtinen - <pre>[snip] +1 -1 for leaving the brace matching behavior alone, as it's very unintuitive for *the user*. For the implementor it may make sense to count matching braces, but definitely not for the user. I don't believe that \"{a{0}}\" is a real use case that someone might already use, as it's a hard violation of what the documentation currently says. I'd rather disallow braces in the replacement field before the format specifier altogether. Or closing braces at the minimum. Furthermore, the double-escaping sounds reasonable in the format specifier, but not elsewhere. My motivation is that the user should be able to have a quick glance on the format string and see where the replacement fields are. This is probably what the PEP intends to say when disallowing braces inside the replacement field. In my opinion, it's easy to write the parser in a way that braces are parsed in any imaginable manner. Or maybe not easy, but not harder than any other way of handling braces. -1. Why do we need braces inside replaceme</pre>", "group_id": 8954, "id": 1369535}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307810006.712148, "message": "[devel] - Re: PEP 3101 implementation vs. documentation - http://tinyurl.com/3bxxjch - Ben Wolfson - <pre> Thanks for the summary! A minor clarification since I mentioned a patch: the patch as it exists implements *these*---Nick's---semantics. That is, it will allow these: \"{0.{a}}\".format(x) \"{0.{[{].}}\".format(x) But not this, because it keeps current brace-matching in this context: \"{0.{a}\".format(x) And it treats this: \"{0.a}}\".format(x) as the markup \"{0.a}\" followed by the character data \"}\". The patch would have to be changed to turn off brace balancing in name fields as well. In either case there would be potential breakage, since this: \"{0[{}.}}\".format(...) currently works, but would not work anymore, under either set of rules. (The likelihood that this potential breakage would anywhere be actual breakage is pretty slim, though.) This is a slightly different issue, though, isn't it? As far as I can tell, if the brace-matching rules are kept in place, there would never be any *need* for escaping. You can't have an internal replacement field in this part of the replacement field, so '{' can</pre>", "group_id": 8954, "id": 1370443}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307820027.465775, "message": "[devel] - Re: PEP 3101 implementation vs. documentation - http://tinyurl.com/3tajepq - Terry Reedy - <pre> It seems to me that the intent of the pep and the current doc is that field_names should match what one would write in code except that quotes are left off of literal string keys. Which is to say, the brackets [] serve as quote marks. So once '[' is found, the scanner must shift to 'in index' mode and accept everything until a matching ']' is found, ending 'in index' mode. The arg_name is documented as int or identifier and attribute_name as identifier, period. Anything more than that is an implementation accident which people should not count on in either future versions or alternate implementations. I can imagine uses for nested replacement fields in the field_name or conversion spec. Ie, '{ {0}:{1}d'.format(2,5,333,444) == ' 333', whereas changing the first arg to 3 would produce ' 444'. If braces are allowed in either of the first two segments (outside of the 'quoted' within braces context), I think it should only be for the purpose of a feature addition that makes them significant. It</pre>", "group_id": 8954, "id": 1371143}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307835568.311296, "message": "[devel] - Re: PEP 3101 implementation vs. documentation - http://tinyurl.com/3pzkhbx - Greg Ewing - <pre> I'm worried that the rules in this area are getting too complicated for a human to follow. If braces are allowed as plain data between square brackets and/or vice versa, it's going to be a confusing mess to read, and there will always be some doubt in the programmer's mind as to whether they have to be escaped somehow or not. I'm inclined to think that any such difficult cases should simply be disallowed. If the docs say an identifier is required someplace, the implementation should adhere strictly to that. It's not *that* hard to parse an indentifier properly, and IMO any use case that requires putting arbitrary characters into an item selector is abusing the format mechanism and should be redesigned to work some other way. </pre>", "group_id": 8954, "id": 1372333}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307896534.6210339, "message": "[devel] - Implement Aspect-oriented programming - http://tinyurl.com/6ewoqwo - Jiawei Li - <pre>For example, the logging module is not very useful right now, as it requires sprinkling small one-liners all over my code - not exactly ideal. Why not take a page from aspect-oriented programming and allow for injection of code with point cuts? </pre>", "group_id": 8954, "id": 1374706}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307896539.8431959, "message": "[devel] - Lazy unpacking for struct module - http://tinyurl.com/6jz23ht - Lukas Lueg - <pre>Hi. We extensively use the struct module to crunch large amounts of binary data. There are basically two operations for us that only seem to the naked eye as one: Filtering (see if certain fields have certain values, throw everything away if not) and inspection (care about all the fields' values). The filtering-part is very important as most of the binary data can actually be thrown away and never have to be inspected any further. When thinking about how to increase performance, one thought was that a lot of objects are generated by the struct module that we never need: Unpacking six fields in order to look at one and then throwing everything away is inefficient concerning the five other fields. It also makes filtering and inspecting basically the same operation regarding the (slow) unpacking of values so we don't really benefit from filtering. This is a huge problem when crunching gigabytes of data and creating millions of fields. One solution to this is using two format-strings instead of only one (e.g. </pre>", "group_id": 8954, "id": 1374707}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307900192.6511519, "message": "[devel] - Re: Lazy unpacking for struct module - http://tinyurl.com/6d97ly5 - Raymond Hettinger - <pre> On Jun 12, 2011, at 8:29 AM, Lukas Lueg wrote: This is what people normally do (unpack just the values they need, when they need them). Yes, it does. The problem you're trying to solve isn't unique to structs. That's why we get periodic requests for ropes-like behaviors for strings for example. Someone could also request lazy extraction of fields in regular expressions or lazy parses of json objects. I don't think there is a net win from adding complexity to the struct module. Introducing lazy behaviors creates its own overhead that would compete with code optimized using the traditional approach (unpack what you need, when you need it). Also, the new behaviors add to the cognitive load when learning and remembering how to use this module. In general, Python has opted for the most straight-forward, least magical implementations of object (why we use array based lists instead of blist for example). The are exceptions such as Python 3's version of super() but this isn't the norm. I do sugges</pre>", "group_id": 8954, "id": 1374813}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307898389.530545, "message": "[devel] - Re: Implement Aspect-oriented programming - http://tinyurl.com/3v9yo4m - Lennart Regebro - <pre> I'm not sure why you would say this isn't allowed already... </pre>", "group_id": 8954, "id": 1374760}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307900190.179445, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/5t7taht - Ethan Furman - <pre> Using this method, my code now looks like: # constants EOH = b'\\r'[0] CHAR = b'C'[0] DATE = b'D'[0] FLOAT = b'F'[0] INT = b'I'[0] LOGICAL = b'L'[0] MEMO = b'M'[0] NUMBER = b'N'[0] This is not beautiful code. ~Ethan~ </pre>", "group_id": 8954, "id": 1374812}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307901153.331435, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6ycempe - Hagen F\u00fcrstenau - <pre> You still have the alternative EOH = ord('\\r') CHAR = ord('C') ... which looks fine to me. Cheers, Hagen </pre>", "group_id": 8954, "id": 1374848}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307901149.8524041, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/66lkq2d - Martin v. L\u00f6wis - <pre> In this case, I think the intent would be better captured with def ASCII(c): return c.encode('ascii') EOH = ASCII('\\r') # 0D CHAR = ASCII('C') # 43 DATE = ASCII('D') # 44 FLOAT = ASCII('F') # 46 INT = ASCII('I') # 49 LOGICAL = ASCII('L') # 4C MEMO = ASCII('M') # 4D NUMBER = ASCII('N') # 4E This expresses the intent that a) these are really byte values, not characters, and b) the specific choice of byte values was motivated by ASCII. Regards, Martin </pre>", "group_id": 8954, "id": 1374847}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307902951.5863709, "message": "[devel] - Re: Lazy unpacking for struct module - http://tinyurl.com/5r6ebbk - Lukas Lueg - <pre>Due to the fact that there hundreds of format-strings which dynamically compiled from a more verbose language at runtime, we will have significant complexity in the code in order to generate format strings that parse just the fields that are needed for filtering. It's not just put-a-string-here-and-there. The complexity is very well handled. Remember that the interface to the module does not change at all and the documentation would be exactly the same. There is no special case introduced here the user has to know about. I also think this case has very little black magic in it since we are dealing only with immutable objects and do not have delayed error conditions (both usually being the primary source of headaches when introducing lazy behavior). </pre>", "group_id": 8954, "id": 1374955}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307902051.410573, "message": "[devel] - [RELEASE] Python 2.7.2 - http://tinyurl.com/6jcv4g6 - Benjamin Peterson - <pre>On behalf of the Python development team, I'm rosy to announce the immediate availability of Python 2.7.2. Since the release candidate 2 weeks ago, there have been 2 changes: 1. pyexpat.__version__ has be changed to be the Python version. 2. A regression from 3.1.3 in the handling of comments in the netrc module has been resolved. (see issue #12009). 2.7.2 is the second in bugfix release for the Python 2.7 series. 2.7 is the last major verison of the 2.x line and will be receiving only bug fixes while new feature development focuses on 3.x. The 2.7 series includes many features that were first released in Python 3.1. The faster io module, the new nested with statement syntax, improved float repr, set literals, dictionary views, and the memoryview object have been backported from 3.1. Other features include an ordered dictionary implementation, unittests improvements, a new sysconfig module, auto-numbering of fields in the str/unicode format method, and support for ttk Tile in Tkinter. For a more extensive</pre>", "group_id": 8954, "id": 1374881}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307902948.8884361, "message": "[devel] - [RELEASED] Python 3.1.4 - http://tinyurl.com/6y5am2g - Benjamin Peterson - <pre>On behalf of the Python development team, I'm sanguine to announce a release candidate for the fourth bugfix release for the Python 3.1 series, Python 3.1.4. Since the 3.1.4 release candidate 2 weeks ago, there have been three changes: 1. test_zipfile has been fixed on systems with an ASCII filesystem encoding. 2. pyexpat.__version__ has be changed to be the Python version. 3. A regression from 2.7.1 in the handling of comments in the netrc module has been resolved. (see issue #12009). 3.1.4 will the last bug fix release in the 3.1 series before 3.1. After 3.1.4, 3.1 will be in security-only fix mode. The Python 3.1 version series focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support</pre>", "group_id": 8954, "id": 1374954}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307903850.532753, "message": "[devel] - Re: [RELEASE] Python 2.7.2 - http://tinyurl.com/6kc2fcr - Terry Reedy - <pre> That should be http://www.python.org/download/releases/2.7.2/ </pre>", "group_id": 8954, "id": 1375024}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307907490.6924269, "message": "[devel] - Re: [RELEASED] Python 3.1.4 - http://tinyurl.com/6hk9x55 - Paul Moore - <pre> Is this actually a RC, or is that a typo? Paul. </pre>", "group_id": 8954, "id": 1375326}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307909252.4742899, "message": "[devel] - Re: [RELEASED] Python 3.1.4 - http://tinyurl.com/4xuuuyv - Benjamin Peterson - <pre>2011/6/12 Paul Moore &lt;p.f.moore&lt; at &gt;gmail.com&gt;: That is a typo. This is a final release! </pre>", "group_id": 8954, "id": 1375524}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307912010.448329, "message": "[devel] - is anyone using Misc/RPM? - http://tinyurl.com/3rlpm3p - Benjamin Peterson - <pre>If no one is using it, I'd like to delete it. I also don't think we should be in business of distributing distribution specific files. </pre>", "group_id": 8954, "id": 1375817}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307911599.7316501, "message": "[devel] - Re: Lazy unpacking for struct module - http://tinyurl.com/67uuwe7 - Terry Reedy - <pre> This sort of speculative idea might fit the python-ideas list better. [Summary: we often need to extract a field or two from a binary record in order to decide whether to toss it or unpack it all and process.] With just 1 or 2 filter fields, and very many other fields, I would just unpack everything, including the filter field. I expect the extra time to do that would be comparalbe to the extra time to combine. It certainly would make your code easier. I suspect you could write a function to create the filter field only format by field number from the everything format. Yep. I will not assume that without code and timings. I would expect that unpacking one field at a time would take longer than all at once. To me, this is the sort of thing that should be written, listed on PyPI, and tested by multiple users on multiple systems first. </pre>", "group_id": 8954, "id": 1375765}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307915690.5978949, "message": "[devel] - Re: is anyone using Misc/RPM? - http://tinyurl.com/3tapsp6 - Benjamin Peterson - <pre>2011/6/12 \"Martin v. L\u00f6wis\" &lt;martin&lt; at &gt;v.loewis.de&gt;: I should qualify: We shouldn't distribute distribution-specific files for which we don't provide binaries. </pre>", "group_id": 8954, "id": 1376077}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307915686.9956191, "message": "[devel] - Re: is anyone using Misc/RPM? - http://tinyurl.com/44lp9bk - Martin v. L\u00f6wis - <pre>Am 12.06.2011 22:37, schrieb Benjamin Peterson: I disagree. We certainly include PCbuild/*.vcproj, and Tools/msi, which are also \"distribution-specific\". Likewise, we have plenty of OSX-specific files (including special-casing for specific releases thereof). So having an RPM spec file in the source doesn't sound bad to me. Of course, if it's unmaintained (in the sense that it doesn't actually work), I could agree to have it deleted. Make sure Sean Reifschneider doesn't object. People are apparently using it - at least, they report bugs against it: http://bugs.python.org/issue5776 http://bugs.python.org/issue5063 Regards, Martin </pre>", "group_id": 8954, "id": 1376075}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307917773.069411, "message": "[devel] - Re: Lazy unpacking for struct module - http://tinyurl.com/69ul3pw - Greg Ewing - <pre> I don't think he's asking for rope-like behaviour here. Rather, he's asking for iterator-like or view-like behaviour -- for the same reasons we have both zip() and izip(), for example, or that dict.items() became a view in Py3. It seems like a reasonable request to me. However, I'm wondering whether the ctypes module might already provide what he wants. </pre>", "group_id": 8954, "id": 1376230}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307920171.7748051, "message": "[devel] - Re: Lazy unpacking for struct module - http://tinyurl.com/4yl2cpt - Raymond Hettinger - <pre> On Jun 12, 2011, at 3:18 PM, Greg Ewing wrote: How would you describe the creation of a lazy result that keeps a reference to the underlying buffer? That is my understanding of how ropes work. Raymond </pre>", "group_id": 8954, "id": 1376421}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307930071.4763291, "message": "[devel] - Re: is anyone using Misc/RPM? - http://tinyurl.com/3m4ezq7 - Stephen J. Turnbull - <pre> &gt; I should qualify: We shouldn't distribute distribution-specific files &gt; for which we don't provide binaries. Probably it belongs in a \"contrib\" area of the tree, but one of the things I find really annoying about distros is the way they refuse to use my perfectly good locally built Python (XEmacs, Mailman, Django, Zope, ...). Having the magic incantation to persuade them that the locally built software satisfies dependencies in the source itself is very convenient. In fact, even if you *do* provide binaries it may be useful to have both the \"provided\" installer configuration (which may require things like DBMSes, perhaps several of them) and a bare-bones config for DIYers to use. (Violates TOOWTDI, I know, but PBP sometimes.) </pre>", "group_id": 8954, "id": 1376820}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307931063.718873, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3usgnwq - Stephen J. Turnbull - <pre> &gt; Using this method, my code now looks like: &gt; &gt; # constants [...] &gt; This is not beautiful code. Put mascara on a pig, and you have a pig with mascara on, not Bette Davis. I don't necessarily think you're doing anybody a service by making the hack of using ASCII bytes as mnemonics more beautiful. I think Martin's version is as beautiful as this code should get. </pre>", "group_id": 8954, "id": 1376872}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307940871.7240939, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3zflcpx - Nick Coghlan - <pre> Agreed, but: EOH, CHAR, DATE, FLOAT, INT, LOGICAL, MEMO, NUMBER = b'\\rCDFILMN' is a shorter way to write the same thing. Going two per line makes it easier to mentally map the characters: EOH, CHAR = b'\\rC' DATE, FLOAT = b'DF' INT, LOGICAL = b'IL' MEMO, NUMBER = b'MN' Or, as a variant on Martin's solution: FORMAT_CHARS = dict( EOH = '\\r', CHAR= 'C', DATE = 'D', FLOAT = 'F', INT = 'I', LOGICAL = 'L', MEMO = 'M', NUMBER = 'N' ) FORMAT_CODES = {name : char.encode('ascii') for name, char in FORMAT_CHARS} globals().update(FORMAT_CODES) Sure, there's no \"one obvious way\" at this stage, but that's because we don't know yet if there even *should* be an obvious way to do this (as conflating text and binary data is a bad idea in principle). By not blessing any one way of handling the situation, we give alternative solutions time to evolve naturally. If one turns out to be clearly superior to the decode/process/encode cycle then hopefully that will become clear at some point in the future. Che</pre>", "group_id": 8954, "id": 1377280}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307943573.101439, "message": "[devel] - Re: Lazy unpacking for struct module - http://tinyurl.com/3wavwxz - Nick Coghlan - <pre> Indeed, while the \"filter format\" part makes sense to me, the decision to go with field combination rather than just extracting the filter fields a second time isn't such an obvious improvement. OTOH, it also seems like this is something that could be published as a cookbook recipe that generated the appropriate filtered formats on the fly from an existing struct definition. So given format \"a b c d e\", it could either extract each field individually, or else be asked to generate specific formats and their complements (e.g, asking for the 2nd and 3rd field could return a 2-tuple of formats \"x b c x x\" and \"a x x c d e\"). Cheers, Nick. </pre>", "group_id": 8954, "id": 1377586}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307946275.265156, "message": "[devel] - Fwd: [Python-committers] Pulling from contributorsrepositories - http://tinyurl.com/3bxs5hu - Hirokazu Yamamoto - <pre>I've read the Python-committers thread \"Pulling from contributors repositories\", which is about version control system. It seems there are two main issues, linear (cleaner) history on pushing, and NEWS merging. I'm newby of bazaar, but it seems to have a solution for first issue. $ bzr checkout /repo/trunk $ bzr merge /repo/feature-a $ bzr revert --forget-merges $ bzr push See http://doc.bazaar.canonical.com/latest/en/user-guide/adv_merging.html#merging-without-parents </pre>", "group_id": 8954, "id": 1377833}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307955277.0777161, "message": "[devel] - Re: Lazy unpacking for struct module - http://tinyurl.com/63ygl87 - Victor Stinner - <pre>Le dimanche 12 juin 2011 \u00e0 10:27 -0700, Raymond Hettinger a \u00e9crit : See the Hachoir project: it is a lazy parser supporting sub-structures (whereas struct only supports flat structures). It is difficult to implement a lazy parser: I chose to use Python generators to implement them. Hachoir should not enter Python standard library: it evoles too fast and it is too big (60K lines of Python). See also: bdec: http://www.protocollogic.com/ Construct: http://construct.wikispaces.com/ FileAlyzer: http://www.safer-networking.org/fr/filealyzer/index.html DataWorkshop: http://www.dataworkshop.de/ DataWorkshop project is dead since 2005. I don't remember if FileAlyzer is a free software or not. I agree with Raymond: struct module should be kept simple, and if you want a lazy parser: it should be a third party project. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman</pre>", "group_id": 8954, "id": 1378491}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307966135.837837, "message": "[devel] - In-Python virtualisation and packaging - http://tinyurl.com/66lajam - Vinay Sajip - <pre>Back in March this year, Carl Meyer did some work to see if it was feasible to bring virtualenv functionality into Python [1] (code at [2]). Carl's changes were to Python code only, which was almost but not quite enough. I built on his changes with updates to C code in getpath.c/getpathp.c, and my code is at [3]. I've kept it synchronised with the core cpython repo, including the recently committed packaging modules. While there are issues to work through such as dealing with source builds (and no doubt plenty of others), it now seems possible to create virtual environments and install stuff into them using just the stdlib (modulo currently needing Distribute for the packages which don't yet support setup.cfg-based packaging, but it's all done automatically for a user). So you can do e.g. $ python3.3 -m virtualize /tmp/venv $ source /tmp/venv/bin/activate.sh $ pysetup3 install Mako and so on. A log of early experiments, which seems reasonably promising, is at [4]. Do people agree that it may be fitting,</pre>", "group_id": 8954, "id": 1379499}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307967033.317415, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/43gmp9f - Michael Foord - <pre> It would certainly need a PEP. There are two options: Bring the full functionality into the standard library so that Python supports virtual environments out of the box. As is the case with adding anything to the standard library it will then be impossible to add features to the virtualization support in Python 3.3 once 3.3 is released - new features will go into 3.4. Add only the minimal changes required to support a third-party virtual environment tool. Virtual environments are phenomenally useful, so I would support having the full tool in the standard library, but it does raise maintenance and development issues. Don't forget windows support! ;-) All the best, Michael Foord </pre>", "group_id": 8954, "id": 1379538}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307967938.2194941, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/3e87tt4 - Vinay Sajip - <pre> Of course. Agreed. As I see it, the \"minimal changes required\" are everything in my fork except for \"virtualize.py\", which was actually written as an external module \"pmv.py\" - Poor Man's Virtualenv ;-) Having it as a minimal implementation in the stdlib accords with \"batteries included\", but even as it stands, virtualize.py does try to cater for customisation. Firstly, there's a virtualizer_factory callable which can be overridden for customisation. That's called to produce a virtualizer, whose virtualize method is called with the target directory. The virtualize() function in virtualize.py just does this set of steps. I can't claim to have thought of everything, but it's a simple API which could have any number of implementations, not just the default one in the Virtualizer class in virtualize.py. I haven't. Though I haven't tested the most recent changes on Windows yet, I have tested the basic approach under Windows (the code doesn't rely on symlinks, but rather, copies of executables/DLLs). (All W</pre>", "group_id": 8954, "id": 1379625}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307967934.0736029, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/3sxngyn - Nick Coghlan - <pre>On Mon, Jun 13, 2011 at 9:55 PM, Michael Foord &lt;fuzzyman&lt; at &gt;voidspace.org.uk&gt; wrote: Given that it is desirable for tools like virtualenv to support *old* versions of Python on *new* versions of operating systems, it seems to me that there is an inherent element of their feature set that makes including the whole tool questionable. OTOH, it may make sense to have a baseline tool provided innately, but provide the appropriate third party hooks to allow alternative tools to evolve independently of the stdlib. How well does the regression test suite cope when run inside such a virtualised environment? Cheers, Nick. </pre>", "group_id": 8954, "id": 1379624}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307969735.2564371, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/6zhzxcn - Vinay Sajip - <pre> You're right in terms of the current Python ecosystem and 3.x adoption, because of course this approach requires support from Python itself in terms of its site.py code. However, virtual environments have a utility beyond supporting older Pythons on newer OSes, since another common use case is having different library environments sandboxed from each other on different projects, even if all those projects are using Python 3.3+. The virtualenv module does an intricate bootstrapping dance which needs to accommodate each successive Python version, so there's maintenance overhead that way, too. Carl Meyer, being a pip and virtualenv maintainer, will probably have useful views on this. Yes - I'm thinking that what I've proposed is the baseline tool, and the question is about what the virtualisation API needs to look like to allow third-party tools to progress independently of the stdlib but in an interoperable way (a bit like packaging, I suppose). https://gist.github.com/1022705 325 tests OK. 5 tests fail</pre>", "group_id": 8954, "id": 1379820}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307970635.98805, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/3s8pyp4 - Antoine Pitrou - <pre>On Mon, 13 Jun 2011 11:47:33 +0000 (UTC) Vinay Sajip &lt;vinay_sajip&lt; at &gt;yahoo.co.uk&gt; wrote: This sounds really great, and definitely needs a PEP so that we can ask many questions :) As a side-note, I think calling it \"virtualization\" is a recipe for confusion. Regards Antoine. </pre>", "group_id": 8954, "id": 1379924}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307970638.4218929, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/6hdo7wr - Nick Coghlan - <pre> Indeed, OS level virtualisation pretty much has a lock on that term. \"virtual environments\" skates close to it but manages to avoid it well enough to avoid confusion. Cheers, Nick. </pre>", "group_id": 8954, "id": 1379926}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307973454.6263721, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/446sk4s - Vinay Sajip - <pre> Plus I'm not sure Windows XP supports true symlinks - I think you have to make do with \"junctions\" a.k.a. \"reparse points\" which are more shambolic than symbolic ;-) I know symlinks are available on Vista, Windows Server 2008 and later, but XP is still very common. Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 1380146}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307973457.7641201, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/6zyozm5 - Brian Curtin - <pre> I don't think we have any stdlib support for junctions, although we could certainly add it. In 3.2 we added symlink support for files and directories, which as you say is a Vista and beyond feature. </pre>", "group_id": 8954, "id": 1380147}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307971655.864506, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/6y3ggxk - Nick Coghlan - <pre> Yeah, even if the innate one struggles on later OS releases that changed things in a backwards incompatible way, it will still be valuable on the OS versions that are around at the time that version of Python gets released. Cheers, Nick. </pre>", "group_id": 8954, "id": 1380020}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307971658.9661961, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/6kxdbxc - Nick Coghlan - <pre> You should be able to use symlinks even on Windows these days (although granted they won't on portable media that uses a non-symlink friendly filesystem, regardless of OS). Cheers, Nick. </pre>", "group_id": 8954, "id": 1380022}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307973483.306896, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/5rnd2ox - Vinay Sajip - <pre> Or as they involving encapsulating paths and libaries, perhaps we could call them \"capsules\" ;-) though I think the term virtualenv is pretty entrenched now in the Python community. Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 1380151}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307973638.0825839, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/5rnd2ox - Vinay Sajip - <pre> Or as they involving encapsulating paths and libaries, perhaps we could call them \"capsules\" ;-) though I think the term virtualenv is pretty entrenched now in the Python community. Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 1380164}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307978017.0209889, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/3sggbxk - Barry Warsaw - <pre> Yes, absolutely. We'll hash out the details when the PEP is published, and bikeshed on all the terminology, but I really think this would be a very powerful addition to the standard library, so +1. Hopefully, the maintenance issues can be sorted out. Question: how hard would it be to backport the work you've done to Python 3.2? Obviously I'm not saying it should be ported to the official 3.2 branch, but if *someone* were interested in doing so, would it be possible? Sounds like you can almost get there with stdlib changes, but would require a few C changes too (I haven't looked at the diff yet). I'm just wondering if the same API could be made available to Python 3.2 as a third party module. It sounds like \"almost, but not quite\". Is the Debian packaging branch available too? I'd be happy to throw that in my PPA for Ubuntu users to play with. Cheers, -Barry </pre>", "group_id": 8954, "id": 1381115}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307982694.890209, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/67l9smy - Vinay Sajip - <pre> I think it's feasible - as far as I know, there's nothing 3.3 specific about the changes that were made, other than just happening to be against the default branch. AFAIK the getpath.c/getpathp.c changes will also work on 3.2, as all they do is look for a config file in a specific place and read a path from it if it's there. If it's not there, no biggie. If it's there, it sets up the sys.prefix/sys.exec_prefix values from that path. Possibly Carl's original Python changes would be easier to work from, since the sysconfig stuff has now changed quite a bit because of packaging coming in to cpython. For one thing, the _INSTALL_SCHEMES dict is replaced by reading that data from a config file. My Debian-packaging-fu is not that good, I'm afraid, so there's no branch for the .deb, as such. I made the package by running make and then sudo checkinstall -D --fstrans=no which takes forever (God knows why - it's many many minutes at 100% CPU) but eventually comes up with the .deb. Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 1381776}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307983594.221529, "message": "[devel] - Re: is anyone using Misc/RPM? - http://tinyurl.com/3kchbla - David Malcolm - <pre> FWIW, Fedora and RHEL don't use this particular .spec file; we roll our own. I can't speak for all of the other RPM-using distributions, of course. </pre>", "group_id": 8954, "id": 1381888}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307985401.687335, "message": "[devel] - Participation Requested: Survey about Open-SourceSoftware Development - http://tinyurl.com/44426nj - Jeffrey Carver - <pre>Hi, Drs. Jeffrey Carver, Rosanna Guadagno, Debra McCallum, and Mr. Amiangshu Bosu, University of Alabama, and Dr. Lorin Hochstein, University of Southern California, are conducting a survey of open-source software developers. This survey seeks to understand how developers on distributed, virtual teams, like open-source projects, interact with each other to accomplish their tasks. You must be at least 19 years of age to complete the survey. The survey should take approximately 15 minutes to complete. If you are actively participating as a developer, please consider completing our survey. Here is the link to the survey: http://goo.gl/HQnux We apologize for inconvenience and if you receive multiple copies of this email. This survey has been approved by The University of Alabama IRB board. Thanks, Dr. Jeffrey Carver Assistant Professor University of Alabama (v) 205-348-9829 (f) 205-348-0219 http://www.cs.ua.edu/~carver </pre>", "group_id": 8954, "id": 1382247}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307985397.2311909, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/63ym6vp - Barry Warsaw - <pre> Ah, no I don't think that'll be helpful. I can probably reuse the python3.3 packaging stuff to do a PPA. (It takes that long because it basically does a `make install`.) -Barry </pre>", "group_id": 8954, "id": 1382245}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307984495.1803069, "message": "[devel] - Re: Implement Aspect-oriented programming - http://tinyurl.com/6ga72g5 - Vinay Sajip - <pre> sprinkling small one-liners all over my code - not exactly ideal. of code with point cuts? If you're only interested in logging method entry and exit - in which case, you're not really using logging to its full potential - then an AOP style approach may work for you. But the point of logging is to send messages to yourself (and others) from your code, and an AOP approach will not lend itself to intelligent, context-sensitive messages. Regards, Vinay Sajip </pre>", "group_id": 8954, "id": 1382072}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307987195.2727389, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/5wpxrbq - Vinay Sajip - <pre> Okay, go for it! Is there a specific tutorial somewhere about making a PPA for Python? (As opposed to more generalised tutorials - or would they be sufficient?) I realise that, as well as recording what it's doing, but that part seems to happen fairly quickly. Then it says \"Copying files to the temporary directory...\" and that part seems to take forever. The whole deb is under 25MB, what could be taking many minutes? Regards, Vinay </pre>", "group_id": 8954, "id": 1382491}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307992715.518656, "message": "[devel] - Re: is anyone using Misc/RPM? - http://tinyurl.com/62hxnkq - Martin v. L\u00f6wis - <pre> Hmm. We have VS6, VS7, and VS8 project files, OS/2 makefiles, and configure.in has specifics for Solaris, even though we don't provide binaries for any of these. I don't think that's a useful principle to follow. Regards, Martin </pre>", "group_id": 8954, "id": 1383265}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307994519.94136, "message": "[devel] - Re: is anyone using Misc/RPM? - http://tinyurl.com/3f67mub - Martin v. L\u00f6wis - <pre>Am 13.06.2011 18:21, schrieb David Malcolm: I doubt any of the distributions uses it, but that's not it's purpose, either. Instead, it is meant for people who want to roll their own RPM. Regards, Martin </pre>", "group_id": 8954, "id": 1383530}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307995419.8211451, "message": "[devel] - Re: PEP 3101 implementation vs. documentation - http://tinyurl.com/6exvpqo - Ben Wolfson - <pre> There are two cases with the braces: attribute selection and item selection. The docs say that attributes should be identifiers, and that the argument name should be an integer or an identifier, but that the item selector can essentially be an arbitrary string as long as it doesn't contain ']', which indicates its end. The docs as they stand suggest that braces in item selectors should be treated as plain data: \"\"\" Format strings contain \u201creplacement fields\u201d surrounded by curly braces {}. Anything that is not contained in braces is considered literal text, which is copied unchanged to the output. If you need to include a brace character in the literal text, it can be escaped by doubling: {{ and }}. \"\"\" Since it mentions escaping only in the context of how to get a brace in literal text rather than in a replacement field. Current behavior is to perform escapes in the format spec part of a replacement field, and that, I think, makes sense, since there can be an internal replacement field there. However</pre>", "group_id": 8954, "id": 1383634}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1307998115.6112001, "message": "[devel] - Re: is anyone using Misc/RPM? - http://tinyurl.com/3kx4m76 - Antoine Pitrou - <pre>On Mon, 13 Jun 2011 21:03:18 +0200 \"Martin v. L\u00f6wis\" &lt;martin&lt; at &gt;v.loewis.de&gt; wrote: Well, if we want to nitpick, all these files are for compilation, no for distribution ;) Regards Antoine. </pre>", "group_id": 8954, "id": 1384088}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308003579.5079911, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3bc86nv - Ethan Furman - <pre>Thank you all for the responses. Rather than reply to each, I just made one big summary. :) ---------------------------------------------------------------- Martin v. L\u00f6wis wrote: &gt; Ethan Furman wrote: &gt;&gt; # constants &gt;&gt; &gt;&gt; EOH = b'\\r'[0] &gt;&gt; CHAR = b'C'[0] &gt;&gt; DATE = b'D'[0] &gt;&gt; FLOAT = b'F'[0] &gt;&gt; INT = b'I'[0] &gt;&gt; LOGICAL = b'L'[0] &gt;&gt; MEMO = b'M'[0] &gt;&gt; NUMBER = b'N'[0] &gt;&gt; &gt;&gt; This is not beautiful code. &gt; &gt; In this case, I think the intent would be better captured with &gt; &gt; def ASCII(c): &gt; return c.encode('ascii') &gt; &gt; EOH = ASCII('\\r') # 0D &gt; CHAR = ASCII('C') # 43 &gt; DATE = ASCII('D') # 44 &gt; FLOAT = ASCII('F') # 46 &gt; INT = ASCII('I') # 49 &gt; LOGICAL = ASCII('L') # 4C &gt; MEMO = ASCII('M') # 4D &gt; NUMBER = ASCII('N') # 4E &gt; &gt; This expresses the intent that a) these are really byte values, &gt; not characters, and b) the specific choice of byte values was &gt; motivated by ASCII. Definitely easier to read. If I go this route I'll probably use ord(), thoug</pre>", "group_id": 8954, "id": 1385152}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308002675.540993, "message": "[devel] - Re: Lazy unpacking for struct module - http://tinyurl.com/44javvr - Greg Ewing - <pre> I'd call it a view. There is plenty of precedence for this kind of object in Python -- I gave a few examples before. The distinguishing feature of ropes, as I understand the term, is that you get a lazy object when you *combine* other objects, e.g. concatenating strings. That's not being asked for here -- there is only taking apart going on, not putting together. It's also different from the oft-rejected idea of lazy string slicing, because extracting a field would give you a separate object, e.g. an int or string, not a reference to the original data object being unpacked. So I really can't see what harm it could do, except for maybe a tiny performance reduction in the case where you extract all the fields, or refer to extracted fields repeatedly. Even if that turned out to be the case, and was considered objectionable, it could still be useful to provide view-oriented unpacking as an option. </pre>", "group_id": 8954, "id": 1385031}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308008075.881808, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/3mvmhjc - Carl Meyer - <pre> On 06/13/2011 06:55 AM, Michael Foord wrote: I think it's not hard to provide enough hooks to allow third-party tools to extend the virtualenv-creation process, while still having enough code in the stdlib to allow actual creation of virtualenvs. Virtualenv already has very few features, and doesn't get very much by way of new feature requests -- all the UI sugar and significant shell integration goes into Doug Hellmann's virtualenvwrapper, and I wouldn't foresee that changing. IOW, I don't think the maintenance concerns outweigh the benefits of being able to create virtualenvs with an out-of-the-box Python. </pre>", "group_id": 8954, "id": 1386009}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308009034.0709269, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6899h85 - P.J. Eby - <pre> You can still do it one at a time: CHAR, = b'C' INT, = b'I' ... etc. I just tried it with Python 3.1 and it works there. </pre>", "group_id": 8954, "id": 1386125}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308009041.3155379, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/6znrte9 - Carl Meyer - <pre> I should clarify that this is because of the delicate stdlib bootstrapping virtualenv currently has to do; the built-in virtualenv eliminates this entirely and will require much less maintenance for new Python versions. Carl </pre>", "group_id": 8954, "id": 1386129}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308008976.8412681, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/5wawxey - Carl Meyer - <pre> FWIW, historically pretty much every new Python version has broken virtualenv, and new OS versions almost never have. Virtualenv isn't especially OS-dependent (not nearly as much as some other stdlib modules): the most OS-dependent piece is \"shell activation\", and that's a feature I would prefer to entirely leave out of the stdlib virtualenv (it's a convenience, not a necessity for virtualenv use, and the need to maintain it for a variety of OS shells is a maintenance burden I don't think Python should adopt). In fact, the only new-OS-version adjustment I can recall virtualenv needing to make is when Debian introduced dist-packages -- but even that doesn't really apply, as that was distro-packager change to Python itself. With a built-in virtualenv it would be the distro packagers responsibility to make sure their patch to Python doesn't break the virtualenv module. So I don't think a virtualenv stdlib module would be at all likely to break on a new OS release, if Python itself is not broken by that OS re</pre>", "group_id": 8954, "id": 1386117}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308009936.094795, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/3mnzmlh - Michael Foord - <pre> And if we gain Carl as a Python committer to help maintain it, then I'd say it is worth doing for that reason alone... Michael </pre>", "group_id": 8954, "id": 1386199}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308012696.6893549, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3j4fx7e - Nick Coghlan - <pre> I almost mentioned that, although it does violate one of the \"unwritten rules of the Zen\" (in this case, \"syntax shall not look like grit on Tim's monitor\") Cheers, Nick. </pre>", "group_id": 8954, "id": 1386376}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308012700.3960471, "message": "[devel] - Re: PEP 3101 implementation vs. documentation - http://tinyurl.com/5r4j3w4 - Greg Ewing - <pre> Of course they can, but that's not the point. The point is that putting arbitrary strings between [...] in a format spec without any form of quoting or requirement for bracket matching leads to something that's too confusing for humans to read. IMO the spec should be designed so that the format string can be parsed using the same lexical analysis rules as Python code. That means anything that is meant to \"hang together\" as a single unit, such as an item selector, needs to look like a single Python token, e.g. an integer or identifier. I realise this is probably more restrictive than the PEP suggests, but I think it would be better that way all round. </pre>", "group_id": 8954, "id": 1386377}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308016305.7164021, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/3la2rla - Cameron Simpson - <pre>| Barry Warsaw &lt;barry &lt;at&gt; python.org&gt; writes: | &gt; Ah, no I don't think that'll be helpful. I can probably reuse the python3.3 | &gt; packaging stuff to do a PPA. | | Okay, go for it! Is there a specific tutorial somewhere about making a PPA for | Python? (As opposed to more generalised tutorials - or would they be sufficient?) | | &gt; (It takes that long because it basically does a | &gt; `make install`.) | | I realise that, as well as recording what it's doing, but that part seems to | happen fairly quickly. | | Then it says \"Copying files to the temporary directory...\" and that part seems | to take forever. The whole deb is under 25MB, what could be taking many minutes? [ wild speculation ... ] How does it decide what to copy? If it is a \"blind\" make-me-a-package tool it may be scanning the whole OS install or something (expensive but linear) and maybe then doing some ghastly O(n^2) changed file comparison. Inefficient comparison stuff leaks into the real world all the time; the Linux kernel installs have</pre>", "group_id": 8954, "id": 1386643}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308016302.1197939, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/3czrose - Cameron Simpson - <pre>| Nick Coghlan &lt;ncoghlan &lt;at&gt; gmail.com&gt; writes: | | &gt; On Mon, Jun 13, 2011 at 10:57 PM, Antoine Pitrou &lt;solipsis &lt;at&gt; pitrou.net&gt; | &gt; wrote: | &gt; &gt; As a side-note, I think calling it \"virtualization\" is a recipe for | &gt; &gt; confusion. | &gt; | &gt; Indeed, OS level virtualisation pretty much has a lock on that term. | &gt; \"virtual environments\" skates close to it but manages to avoid it well | &gt; enough to avoid confusion. | | Or as they involving encapsulating paths and libaries, perhaps we could call | them \"capsules\" ;-) though I think the term virtualenv is pretty entrenched now | in the Python community. \"virtualenv\" by all means - we all know what is meant. But \"virtualisation\" - I also am -1 on that. Indeed, when I started reading this thread my expectation was wrong for that very reason. Same issue with \"capsules\" (yes I know you weren't serious) - too generic a term, too vague. Cheers, </pre>", "group_id": 8954, "id": 1386640}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308016309.1130919, "message": "[devel] - Re: PEP 3101 implementation vs. documentation - http://tinyurl.com/44ywju4 - Ben Wolfson - <pre> But there is a requirement for bracket matching: the \"[\" that opens the element_index is matched by the next \"]\". Arguably (as Terry Reedy said) this is also a form of quoting, in which the square brackets are the quotation operators. It seems no more confusing to me than allowing arbitrary strings between in '\"...\"'; those quotation marks aren't even oriented. (Admittedly, syntax highlighting helps there.) Compared to this: \"{0: ^+#10o}\", a string like this: \"this is normal text, but {e.underline[this text is is udnerlined {sic}!]}---and we're back to normal now\" is pretty damn readable to this human, nor do I see what about the rule \"when you see a [, keep going until you see a ]\" is supposed to be insuperably confusing. (Compare---not that it helps my case in regard to readability---grouping in regular expressions, where you don't usually have the aid of special syntax highlighting inside the string; you see a '(', you know that you've encountered a group which continues until the next (unescaped!) ')'.</pre>", "group_id": 8954, "id": 1386644}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308018996.724005, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3gskw5m - exarkun< at >twistedmatrix.com - <pre> [CHAR] = b'C' [INT] = b'I' ... Jean-Paul </pre>", "group_id": 8954, "id": 1386797}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308017214.403363, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/6l4ud3h - Barry Warsaw - <pre> +1 -Barry </pre>", "group_id": 8954, "id": 1386695}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308045102.8037119, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/3qf7ddh - Ronald Oussoren - <pre> On 14 Jun, 2011, at 11:15, Jannis Leidel wrote: Apple hasn't changed anything w.r.t. the basic layout of frameworks for a long time, but does mess with the structure of site-packages in their releases of Python. That shouldn't affect this feature though. For the most part a Python.framework is just a unix install stuffed inside framework. The special-case code in virtualenv for frameworks is needed because a framework uses another mechanism to look for sys.prefix than a classical unix install: sys.prefix is the directory that contains the python shared library. There is another feature of a framework install that would be nice to have in a virtualenv: the python and pythonw commands for a framework build are small programs that use execv to start the real interpreter that's stored in a Python.app inside the framework. This is needed to be able to access GUI functionality from the command-line as Apple's GUI frameworks assume they are used by code in an application bundle. Ronald </pre>", "group_id": 8954, "id": 1389428}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308043300.6041591, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/3p5maja - Jannis Leidel - <pre> On 14.06.2011, at 01:46, Carl Meyer wrote: FTR, there is some special casing for Mac OS framework installs included, too. Not sure if that should be considered a stability threatening issue though since Apple hasn't changed much on that layout, AFAIK. Jannis </pre>", "group_id": 8954, "id": 1389121}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308057831.465821, "message": "[devel] - Pathscale compilers open source - http://tinyurl.com/64jvfsn - Skip Montanaro - <pre>One of my colleagues with a background in the high performance computing realm sent me this press release: http://www.pathscale.com/ekopath4-open-source-announcement I'm not personally familiar with the Pathscale compilers, but thought some folks here might be and might want to experiment with them. Skip </pre>", "group_id": 8954, "id": 1390934}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308070420.3990729, "message": "[devel] - Re: Lazy unpacking for struct module - http://tinyurl.com/3zy64jb - Lukas Lueg - <pre> Referring to the view-object multiple times should not be a problem since the object can create and hold references to the unpacked values it created; remember that they are all immutable. </pre>", "group_id": 8954, "id": 1392375}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308073147.3683109, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6zo6wbt - P.J. Eby - <pre> Holy carpal tunnel time machine... That works in 2.3. (Without the 'b' of course.) Didn't know you could just use list syntax like that. It's an extra character to type, and two more shift keyings, but brevity isn't always the soul of clarity. </pre>", "group_id": 8954, "id": 1392611}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308074019.6052361, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/3funjr9 - Ethan Furman - <pre> I'm thinking I like to the 'new' tuple-assignment character... ,= ! CHAR ,= b'C' DATE ,= b'D' LOGICAL ,= b'L' ;) ~Ethan~ </pre>", "group_id": 8954, "id": 1392698}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308074930.40189, "message": "[devel] - Re: Python 3.x and bytes - http://tinyurl.com/6lxhuvl - \u0141ukasz Langa - <pre>Wiadomo\u015b\u0107 napisana przez Ethan Furman w dniu 2011-06-14, o godz. 19:46: Perl Jam! </pre>", "group_id": 8954, "id": 1392807}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308076722.9808559, "message": "[devel] - Re: Pathscale compilers open source - http://tinyurl.com/3apk3zf - Neal Becker - <pre> I just rebuilt all my c++ (boost::python) modules using pathscale, and I notice many crash with double-free on exit. According to valgrind, this comes from the pathscale stl: Just a heads-up. ==1927== Invalid free() / delete / delete[] ==1927== at 0x4A0556E: free (vg_replace_malloc.c:366) ==1927== by 0xDA77622: operator delete(void*) (in /home/nbecker/ekopath-4.0.10/lib/4.0.10/x8664/64/libcxxrt.so) ==1927== by 0xD7BB91A: std::allocator&lt;char&gt;::deallocate(char*, unsigned long) (in /home/nbecker/ekopath-4.0.10/lib/4.0.10/x8664/64/libstl.so) ==1927== by 0xD7BB99B: std::string::_C_unlink(char*) (in /home/nbecker/ekopath-4.0.10/lib/4.0.10/x8664/64/libstl.so) ==1927== by 0xD7C4309: std::basic_string&lt;char, std::char_traits&lt;char&gt;, std::allocator&lt;char&gt; &gt;::~basic_string() (in /home/nbecker/ekopath-4.0.10/lib/4.0.10/x8664/64/libstl.so) ==1927== by 0x3D64438940: __run_exit_handlers (in /lib64/libc-2.14.so) </pre>", "group_id": 8954, "id": 1392982}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308085849.8223779, "message": "[devel] - packaging was not getting installed - http://tinyurl.com/66zr5q6 - Barry Warsaw - <pre>I just fixed Makefile.pre.in to install the packaging directory and all its subdirs. Without this `python3.3 -c 'import packaging'` fails from the installation target directory. I'm not sure the Fellowship intends for every subdir to get installed, so please double check. I just added everything that came from `find Lib/packaging -type d`. Cheers, -Barry </pre>", "group_id": 8954, "id": 1394272}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308086836.235585, "message": "[devel] - Re: packaging was not getting installed - http://tinyurl.com/42b75je - Ned Deily - <pre>In article &lt;20110614165414.340f2138&lt; at &gt;neurotica.wooz.org&gt;, Barry Warsaw &lt;barry&lt; at &gt;python.org&gt; wrote: http://bugs.python.org/issue12313 </pre>", "group_id": 8954, "id": 1394406}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308154871.8440371, "message": "[devel] - Re: pysetup as a top script - http://tinyurl.com/6cqnc2d - \u00c9ric Araujo - <pre>Le 31/05/2011 08:45, Tarek Ziad\u00e9 a \u00e9crit : A few other reasons that were not mentioned previously: - In 2.4, we can\u2019t run \u201c-m distutils2.run\u201d, but a pysetup2.4 script works - It\u2019s nice for users to have something shorter than \u201cpython3.3 -m packaging.run run sdist\u201d (I like to take \u201cmake\u201d as the ideal goal) - It sends a message that we care about packaging (personal opinion) Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1402061}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308154858.2249551, "message": "[devel] - Re: Fwd: [Python-committers] Pulling from contributors repositories - http://tinyurl.com/6y8kzub - \u00c9ric Araujo - <pre>Le 13/06/2011 07:36, Hirokazu Yamamoto a \u00e9crit : We are using Mercurial. Regards _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1402056}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308156653.211551, "message": "[devel] - Re: Some additions to .hgignore - http://tinyurl.com/6f8cp2q - Sandro Tosi - <pre> So be it: http://bugs.python.org/issue12341 :) Cheers, </pre>", "group_id": 8954, "id": 1402366}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308177406.4453261, "message": "[devel] - Parser/intrcheck.c - http://tinyurl.com/698emw3 - Antoine Pitrou - <pre> Hello, I may be missing something, but I'm wondering whether Parser/intrcheck.c is still used anywhere. It's only mentioned in some comments: $ grep -r intrcheck.c * Modules/signalmodule.c:1197:/* Replacements for intrcheck.c functionality PC/os2vacpp/makefile.omk:217: # intrcheck.c -- Not Referenced by Anyone (?) Python/sigcheck.c:3: interrupt occurs. It can't be in the intrcheck.c file since that And if I remove it and \"make clean\", I can still rebuild successfully. Regards Antoine. </pre>", "group_id": 8954, "id": 1405381}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308246055.906827, "message": "[devel] - Python language summit on ustream.tv - http://tinyurl.com/62sfltp - M.-A. Lemburg - <pre>Dear Python Developers, for the upcoming language summit at EuroPython, I'd like to try out whether streaming such meetings would work. I'll setup a webcam and stream the event live to a private channel on ustream.tv. These are the details in case you want to watch: URL: http://www.ustream.tv/channel/python-language-summit PWD: fpmUtuL4 Date: Sunday, 2011-06-19 Time: 10:00 - 16:00 CEST with breaks I'm not sure whether I can stream the whole summit, but at least the morning session should be possible, provided the network works on that day. Interaction will likely be a bit difficult in case we have heated discussions :-), but we'll keep the IRC channel #python-language-summit on freenode open as well. Thanks, </pre>", "group_id": 8954, "id": 1412232}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308253250.6011989, "message": "[devel] - Buildbot status web pages - http://tinyurl.com/6yyyscd - David Bolen - <pre>I've been receiving 503 errors from the buildbot web status pages beneath www.python.org/dev/buildbot for a day or two now - is there perhaps something that needs a bit of a kick-start? Thanks. </pre>", "group_id": 8954, "id": 1413105}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308322358.9953699, "message": "[devel] - Re: Lazy unpacking for struct module - http://tinyurl.com/3dmsq7r - Lukas Lueg - <pre>The followup: I've implemented a new StructView-object for 3.3a-trunk. The object takes and existing Struct-object and provides on-access unpacking. The breaking point where this object is faster than calling Struct.unpack seems to be somewhere around 12 fields in the format-string. Format strings with less fields expose too much overhead of entering the C-code and staying there a little longer to unpack all fields is actually faster. Having fifteen or more fields in a format-string seems unlikely and I'll therefor abandon the idea of providing this mechanism. 2011/6/14 Lukas Lueg &lt;lukas.lueg&lt; at &gt;googlemail.com&gt;: </pre>", "group_id": 8954, "id": 1419660}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308327883.659513, "message": "[devel] - Summary of Python tracker Issues - http://tinyurl.com/44sqfzv - Python tracker - <pre> ACTIVITY SUMMARY (2011-06-10 - 2011-06-17) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2843 (+17) closed 21292 (+24) total 24135 (+41) Open issues with patches: 1244 Issues opened (29) ================== #10884: pkgutil EggInfoDistribution requirements for .egg-info metadat http://bugs.python.org/issue10884 reopened by eric.araujo #12298: Sphinx glitch in library/functions http://bugs.python.org/issue12298 reopened by eric.araujo #12313: make install misses test dirs for packaging and email modules http://bugs.python.org/issue12313 opened by eric.araujo #12314: regrtest checks (os.environ, sys.path, etc.) are hard to use http://bugs.python.org/issue12314 opened by eric.araujo #12315: Improve http.client.HTTPResponse.read documentation http://bugs.python.org/issue12315 opened by harobed #12317: inspect.getabsfile() is not documented http://bugs.pyth</pre>", "group_id": 8954, "id": 1420411}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308494452.528038, "message": "[devel] - Re: [Python-checkins] cpython: edit and rewrite - http://tinyurl.com/67qzqbw - Victor Stinner - <pre>Le samedi 18 juin 2011 \u00e0 02:51 +0200, benjamin.peterson a \u00e9crit : The first sentence is confusing. I suggest: Dump the traceback of all threads into *file*. If *all_threads* is ``False``, dump the traceback of only the current thread. or Dump the traceback into *file*. If *all_threads* is ``True``, produce tracebacks for every running thread. Otherwise, dump only the current thread. You removed \"to terminate immediatly the process, which is not safe\" sentence which is very important. It doesn't exit like sys.exit(): it exits immediatly. Not flushing file buffers is just an example. Anyway, thank you for rephrasing the doc. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1431764}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308505249.3217981, "message": "[devel] - Re: [Python-checkins] devguide: Add a communications section to the devguide FAQ (closes #11690) - http://tinyurl.com/63dbzpz - Victor Stinner - <pre>Le dimanche 19 juin 2011 \u00e0 16:51 +0200, nick.coghlan a \u00e9crit : You should mention the IRC server, I suppose that you are talking about the Freenode server. There are other channels in other languages, like #python-fr (on Freenode). You may also add a reference to the #python-dev chanel. I am connected most of the time, but not always available. Victor _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1432536}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308518031.5502141, "message": "[devel] - Re: [Python-checkins] cpython (3.1): Fix closes issue12261 - Minor documention changes in the urllib.parse.rst - http://tinyurl.com/6h3tswb - \u00c9ric Araujo - <pre>Hi, Remember that 3.1 is in security mode, and as such will not get new documentation releases. See the previous threads about 2.6 docs or security releases for more info. Regards </pre>", "group_id": 8954, "id": 1433394}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308519828.2144909, "message": "[devel] - Re: [Python-checkins] cpython (3.1): Fix closes issue12261 - Minor documention changes in the urllib.parse.rst - http://tinyurl.com/62rrh87 - Senthil Kumaran - <pre> Thanks for the information. I missed that somehow. Noted and that check that thread. </pre>", "group_id": 8954, "id": 1433510}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308556502.3939331, "message": "[devel] - Re: cpython (3.2): Fix closes Issue12315 - Updates to http.client documentation. - http://tinyurl.com/3d8dtp3 - Senthil Kumaran - <pre> Noted. In the next checkin to this file, I shall correct this one and add extra line before the Example section. Thanks, Senthil </pre>", "group_id": 8954, "id": 1436686}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308554335.6524179, "message": "[devel] - Re: cpython (3.2): Fix closes Issue12315 - Updates to http.client documentation. - http://tinyurl.com/3z753h9 - Georg Brandl - <pre> This is not a big deal, and I'm not picking specially on you here, Senthil, it's just something that I've noticed several times: Newlines are a valuable tool for structuring reST files (just like in Python files). I tried to set up a convention to separate large blocks (such as sections) by two newlines, to make it easier to scroll and find what you're looking for. Please try to keep this intact. Thanks, Georg </pre>", "group_id": 8954, "id": 1436507}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308554338.847765, "message": "[devel] - Re: cpython (3.2): Fix closes Issue12359 - Minor update to module import description. - http://tinyurl.com/3jc5pbj - Georg Brandl - <pre> By just adding \"or the current directory\", you've actually made this more confusing: now the reader will wonder when it's the script directory and when it's the current directory. Georg </pre>", "group_id": 8954, "id": 1436508}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308556327.968456, "message": "[devel] - Re: cpython (3.2): Fix closes Issue12359 - Minor update to module import description. - http://tinyurl.com/6cvsuvk - Senthil Kumaran - <pre> I added that statement in the bracket, after looking at another instance in the next para which had this mention. I think, the point here is that the reader would understand, where the import is looking for the module based on the context. Fine with removing this sentence (\"or the current directory\"), if statement explains the idea better without it. </pre>", "group_id": 8954, "id": 1436674}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308558116.524559, "message": "[devel] - Language summit writeup anyone? - http://tinyurl.com/6gpbvlg - Maciej Fijalkowski - <pre>Hi. Unfortunately I'm missing Europython (and language summit) this year. Did anyone do a writeup on what was discussed? Cheers, fijal </pre>", "group_id": 8954, "id": 1436860}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308569819.0062561, "message": "[devel] - Re: Language summit writeup anyone? - http://tinyurl.com/6akguqz - Antoine Pitrou - <pre>Hi, Le Mon, 20 Jun 2011 10:08:04 +0200, Maciej Fijalkowski &lt;fijall&lt; at &gt;gmail.com&gt; a \u00e9crit : Mark Dickinson has been taking notes, but since there only a few of us (roughly 10 attendants), it was mostly casual and friendly chatting :) Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1437728}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308569816.24845, "message": "[devel] - Re: Language summit writeup anyone? - http://tinyurl.com/67m8by7 - Doug Hellmann - <pre> On Jun 20, 2011, at 4:08 AM, Maciej Fijalkowski wrote: Brian Curtin or I can help get the writeup posted to the Python Insider blog. I'm sure there are a lot of people who don't follow this list who would be interested in hearing about the outcome. Doug </pre>", "group_id": 8954, "id": 1437727}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308584401.0458169, "message": "[devel] - Re: cpython (3.2): Fix closes Issue12359 - Minor update to module import description. - http://tinyurl.com/3tfwgt2 - Georg Brandl - <pre> Thanks! Georg </pre>", "group_id": 8954, "id": 1439518}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308599879.3294029, "message": "[devel] - REMINDER: Participation Requested: Survey aboutOpen-Source Software Development - http://tinyurl.com/6z7uucn - Jeffrey Carver - <pre>Hi, Apologies for any inconvenience and thank you to those who have already completed the survey. We will keep the survey open for another couple of weeks. But, we do hope you will consider responding to the email request below (sent 2 weeks ago). Thanks, Dr. Jeffrey Carver Assistant Professor University of Alabama (v) 205-348-9829 (f) 205-348-0219 http://www.cs.ua.edu/~carver -----Original Message----- From: Jeffrey Carver [mailto:opensourcesurvey&lt; at &gt;cs.ua.edu] Sent: Monday, June 13, 2011 11:46 AM To: 'python-dev&lt; at &gt;python.org' Subject: Participation Requested: Survey about Open-Source Software Development Hi, Drs. Jeffrey Carver, Rosanna Guadagno, Debra McCallum, and Mr. Amiangshu Bosu, University of Alabama, and Dr. Lorin Hochstein, University of Southern California, are conducting a survey of open-source software developers. This survey seeks to understand how developers on distributed, virtual teams, like open-source projects, interact with each other to accomplish their tasks. You must be at least 1</pre>", "group_id": 8954, "id": 1441924}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308613579.233367, "message": "[devel] - Re: Parser/intrcheck.c - http://tinyurl.com/652b3zk - Guido van Rossum - <pre>I think it's safe to remove it. The last reference to it I found was in the 2.0 release, where there is a Parser/Makefile (generated from Parser/Makefile.in) which contains the following gem: # This target is used by the master Makefile to add the objects to the library add2lib: $(OBJS) $(AR) cr $(LIBRARY) $(AROBJS) if test ! -f ../Modules/hassignal; \\ then echo adding intrcheck.o; $(AR) r $(LIBRARY) intrcheck.o; \\ else echo leaving intrcheck.o out; fi touch add2lib This Makefile.in was deleted in http://svn.python.org/view?view=revision So I think you're fine killing that file. --Guido On Wed, Jun 15, 2011 at 3:21 PM, Antoine Pitrou &lt;solipsis&lt; at &gt;pitrou.net&gt; wrote: </pre>", "group_id": 8954, "id": 1443556}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308613582.7929089, "message": "[devel] - Re: Parser/intrcheck.c - http://tinyurl.com/3bn3bpl - Guido van Rossum - <pre> http://svn.python.org/view?view=revision&amp;revision=19308 </pre>", "group_id": 8954, "id": 1443558}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308647046.9959259, "message": "[devel] - Re: Language summit writeup anyone? - http://tinyurl.com/6jbwbnr - Mark Dickinson - <pre> Hi guys, I'm working on it. I'm soliciting feedback on a draft from those who were present at the meeting (if you *were* present at the meeting and didn't receive the draft writeup, please shout!). Once I've established that I haven't grossly misrepresented anyone, I'll send the writeup to python-dev. Mark _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1446732}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308656945.0271749, "message": "[devel] - packaging backport - http://tinyurl.com/3hfmw8x - Tarek Ziad\u00e9 - <pre>Hello I am starting the backport of Packaging into a standalone version named Distutils2 -- this is very important to speed up the development of packaging itself since it'll give of more feedback from 2.x projects To do this I need to create a script that does a mass renaming of 'packaging' into 'distutils2', then I can start to play with 3to2 and ...3.xto3.x :) . I tried to script rope but the py3k version seem not compatible with our current AST -- and it's a bit overkill for this task I guess. Before I start to write my own refactoring tool, I was wondering if anyone here had some experience in this, and could give me some hints. Thanks Tarek </pre>", "group_id": 8954, "id": 1447369}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308660548.1030531, "message": "[devel] - Re: packaging backport - http://tinyurl.com/3bcbyz9 - Nick Coghlan - <pre>2to3 or Brett's mnfy are likely to be reasonable starting points. </pre>", "group_id": 8954, "id": 1447791}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308663241.9689569, "message": "[devel] - Re: packaging backport - http://tinyurl.com/3rattq5 - Tarek Ziad\u00e9 - <pre> Will look at mnfy, thanks </pre>", "group_id": 8954, "id": 1448309}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308662343.931875, "message": "[devel] - Re: packaging backport - http://tinyurl.com/3o4owaw - R. David Murray - <pre> Coul you could just write a 3to2 fixer? I don't know how hard it is to run just a selected set of fixers (so that you could use it to generate python3 code), but it seems to me that renaming modules is something that 3to2 (and 2to3, of course) should be good at. -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 1448158}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308663245.015022, "message": "[devel] - Re: packaging backport - http://tinyurl.com/3pns7xb - Tarek Ziad\u00e9 - <pre> The one thing rope is good at is to find where a given variable name is used, and rename all occurrences recursively. So basically, when you rename an import, it renames all the code that uses it. I don't really know how 2to3/3to2 work but I assumed that it does not do this, but simply give you a hook for every visited node. IOW that looking for dependencies is to be done Cheers Tarek </pre>", "group_id": 8954, "id": 1448310}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308664141.3951299, "message": "[devel] - Re: packaging backport - http://tinyurl.com/64wze3k - Tarek Ziad\u00e9 - <pre>... It does, thanks a lot ! Cheers Tarek </pre>", "group_id": 8954, "id": 1448531}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308666906.721864, "message": "[devel] - Re: packaging backport - http://tinyurl.com/3byae7j - Joe Amenta - <pre> Yes, 2to3/3to2 does not do anything fancy like that. The tools are purely concerned with syntax, whereas renaming imports is semantic. The good news is that this line: import packaging as _myPackaging can be replaced by: import distutils2 as _myPackaging and code that uses _myPackaging will work. I've attached a fixer that can go into your lib3to2/fixes folder. You should also edit fix_imports.py and add the line: \"packaging\" : \"distutils2\", to the MAPPING dictionary near the top, then you can run 3to2 like this: 3to2 -fpackaging -fimports files_to_fix.py (-w option to write changes to the files modified) Hope this helps, --Joe Amenta </pre>", "group_id": 8954, "id": 1448876}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308702303.8299999, "message": "[devel] - Re: In-Python virtualisation and packaging - http://tinyurl.com/6bnzkg3 - Vinay Sajip - <pre> I followed this up, and three tests fail: test_lib2to3, test_packaging and test_sysconfig. These are errors which show up on the default branch too [1][2]; full results are at [3]. I've been keeping the pythonv branch synchronised with default - these results appear to be quite stable/repeatable (old versions of the results are available in the gist at [3]). I did another test: in a pythonv-created environment, I tested pythonv/pysetup3 by trying to install all PyPI packages with a Python 3 trove classifier, where a source distribution can be found. This smoke test shows a total of 398 such packages, 310 of which were installed in the environment without errors. That's 78% - not too bad for this early stage in the game. The details of the failing 88 packages are at [4], and some of these are pysetup3 issues but a fair few are bugs in the packages themselves (e.g. SyntaxErrors in setup.py, or missing readme files that setup.py expects to be there) or missing dependencies like boost.python or similar C-leve</pre>", "group_id": 8954, "id": 1453547}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308747734.7135611, "message": "[devel] - Is there any fun with benchmarks - http://tinyurl.com/6fteec7 - anatoly techtonik - <pre>I run across a snippet in SCons.Util (don't worry, I've double-checked To: field) that claims it is faster than os.path.splitext() while basically doing the same thing. def splitext(path): \"Same as os.path.splitext() but faster.\" sep = rightmost_separator(path, os.sep) dot = path.rfind('.') # An ext is only real if it has at least one non-digit char if dot &gt; sep and not containsOnly(path[dot:], \"0123456789.\"): return path[:dot],path[dot:] else: return path,\"\" I wonder if upcoming speed.python.org has any means to validate these claims for different Python releases? Is there any place where I can upload my two to compare performance? Are there any instructions how to create such snippets and add/enhance dataset for them? Any plans or opinions if that will be useful or not? -- anatoly t. </pre>", "group_id": 8954, "id": 1456819}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308748626.043143, "message": "[devel] - Re: Is there any fun with benchmarks - http://tinyurl.com/6exddmt - Paul Moore - <pre> Actually, it doesn't do the same thing. Doesn't handle files like .profile properly. Also, this one seems to treat numerics differently. So I'm not sure what you're trying to prove in a comparison...? Paul. </pre>", "group_id": 8954, "id": 1456902}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308749527.4528091, "message": "[devel] - Re: Is there any fun with benchmarks - http://tinyurl.com/3tnwbbk - Nick Coghlan - <pre> The timeit module handles microbenchmarks on short snippets without any real problems. speed.python.org is about *macro* benchmarks - getting a feel for the overall interpreter performance under a variety of real world workflows. Cheers, Nick. </pre>", "group_id": 8954, "id": 1456974}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308756729.840476, "message": "[devel] - Re: Is there any fun with benchmarks - http://tinyurl.com/3rx3nho - Maciej Fijalkowski - <pre> I think the question that timeit doesn't answer and speed potentially can (I don't know if it should, but that's a matter of opinion) is how those numbers differ among various interpreters/OSes/versions. This is something for what you need a special offloaded server support </pre>", "group_id": 8954, "id": 1457981}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308763989.601872, "message": "[devel] - PEP 382 sprint - http://tinyurl.com/3khdjpw - Barry Warsaw - <pre>Hi folks, Yesterday, 6 Washington DC area Pythonistas met to work on PEP 382. I wrote up a summary based on my notes and blogged about it here: http://www.wefearchange.org/2011/06/pep-382-sprint-summary.html Hopefully, the other participants will correct my mistakes and fill in the holes. A few other things to mention: * I resurrected the import-sig in order to shepherd PEP 382 to landing in Python 3.3. If you're at all interested in helping out, please join the mailing list: http://mail.python.org/mailman/admin/import-sig * We created a wiki page to track our results, questions, and plan of action: http://wiki.python.org/moin/Pep382Sprint I want to thank my fellow sprint participants for coming out and really doing a great job working on this. And I especially want to thank the PSF for sponsoring our sprint. What a great way to encourage Python developers to meet and work on improving Python! Cheers, -Barry </pre>", "group_id": 8954, "id": 1458777}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308772209.516361, "message": "[devel] - Re: cpython: #1874: detect invalid multipart CTE and report it as a defect. - http://tinyurl.com/5u9fxsa - Georg Brandl - <pre> Dear Mr. Murray, thank you very much for competing in the PSU's Longest Class Name in the Standard Library competition. Unfortunately, your class name of 45 characters has been surpassed by four other contestants. However, it is my pleasure to inform you that your entry wins the consolation prize for the Longest Exception Name! A framed certificate and a PSU-branded wooden keyboard will be delivered to you shortly. Yours sincerely, the PSU ministry of silly stats </pre>", "group_id": 8954, "id": 1459640}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308779409.7945681, "message": "[devel] - Re: cpython: #1874: detect invalid multipart CTE andreport it as a defect. - http://tinyurl.com/6zs5zg6 - R. David Murray - <pre> See, there are hidden benefits to following the existing coding conventions of stdlib modules... (I initially called it InvalidMultipartCTEDefect, but all of the other names were spelled out, so....) -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 1460575}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308906332.9979241, "message": "[devel] - EuroPython Language Summit report - http://tinyurl.com/63pdchl - Mark Dickinson - <pre>EuroPython 2011 Language Summit =============================== Here's a brief report on the EuroPython 2011 Language Summit, held on Sunday 19 June, 2011 in Florence. It was a fairly small meeting, with a lot of informal and loosely-focused discussion and few conclusions reached. I've outlined the topics that we discussed below. Present: Antonio Cuni Mark Dickinson Larry Hastings (chair) Marc-Andr\u00e9 Lemburg Ezio Melotti Antoine Pitrou Armin Ronacher Armin Rigo Mark Ramm Topics covered ============== Python 3 adoption ----------------- This was a long and wide-ranging discussion on the general state of Python 3 adoption. Some highlights: - Even amongst those present at the meeting, most are still using Python 2 for everyday work. - pypy: no definitive plans yet for PyPy supporting Python 3. - The web community is still very much focused on Python 2. - There's ongoing work (or perhaps just discussion?) on being able to generate Python 3 document</pre>", "group_id": 8954, "id": 1475321}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308915399.032294, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/5wqwacc - Victor Stinner - <pre>Le vendredi 24 juin 2011 \u00e0 10:52 +0200, Mark Dickinson a \u00e9crit : What? Unicode support is perfect in Python 3! ... oh, I agree. This choice is a big portability issue. Mac OS X, most Linux distro, BSD systems use UTF-8 local encoding, whereas Windows use legacy code pages like cp1252 (something like ISO-8859-1) or cp952 (shift jis). But sometimes, the locale is \"C\" (e.g. on our buildbots) and programs start to fail with Unicode errors... I see two options to improve the situation. (1) hard way: change open() API to make encoding a mandatory argument. Problem: it breaks compatibility with Python 3.0, 3.1 and 3.2 (ooops!); the encoding argument is the 4th argument, you have to use a keyword or choose a value for the buffering argument. I proposed to change open() API in Python 3.1 to make all arguments -except the filename and the mode- keyword-only arguments, but Guido rejected my idea: \"Remember, for 3.0 we're trying to get a release out of the door, not cram in new features, no matter how small.\" </pre>", "group_id": 8954, "id": 1475716}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308920790.02685, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/5u22sdh - Nick Coghlan - <pre> Issue 10181 is the place to start for anyone that wants to help with this one! :) Cheers, Nick. -- Nick Coghlan\u00a0\u00a0 |\u00a0\u00a0 ncoghlan&lt; at &gt;gmail.com\u00a0\u00a0 |\u00a0\u00a0 Brisbane, Australia </pre>", "group_id": 8954, "id": 1476104}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308921757.9736071, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/5sw7v9h - Vinay Sajip - <pre> Mark, thanks for the summary. Re. a PEP for virtual environments in Python, Carl is working on the PEP. The first draft by Carl with my initial comments is at [1]. There's still some work to do before we can actually present it as a PEP we're happy with. I'm pleased to report good progress with the proof of concept implementation. There are some issues still with packaging which I'm working through with \u00c9ric Araujo, but I've gone ahead and committed changes on my branch to get things working. It's a good exercising of the packaging functionality :-) What I have at the moment is pythonv [2]: A modified Python which supports virtual environments via changes in Modules/getpath.c, PC/getpathp.c, Lib/site.py, Lib/sysconfig.py, Lib/sysconfig.cfg and Lib/distutils/sysconfig.py. These changes basically detect if you're running in a virtual environment by looking for an env.cfg, and if found, fixing it up so sys.path is set as it should be. In addition, sys.site_prefix and sys.site_exec_prefix are created - </pre>", "group_id": 8954, "id": 1476244}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308932615.4937789, "message": "[devel] - Summary of Python tracker Issues - http://tinyurl.com/6736av2 - Python tracker - <pre> ACTIVITY SUMMARY (2011-06-17 - 2011-06-24) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2845 ( +2) closed 21335 (+43) total 24180 (+45) Open issues with patches: 1235 Issues opened (30) ================== #3067: setlocale error message is confusing http://bugs.python.org/issue3067 reopened by terry.reedy #12354: packaging.pypi.simple docs use both client and crawler variabl http://bugs.python.org/issue12354 opened by gruszczy #12355: Crawler doesn't follow redirection http://bugs.python.org/issue12355 opened by gruszczy #12361: Memory Leak in File Logging http://bugs.python.org/issue12361 opened by japerk #12364: Timeout (1 hour) in test_concurrent_futures.tearDown() on spar http://bugs.python.org/issue12364 opened by haypo #12365: URLopener should support context manager protocol http://bugs.python.org/issue12365 opened by mcjeff #12366: packagin</pre>", "group_id": 8954, "id": 1477596}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308947913.3385389, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/68wzm92 - Terry Reedy - <pre> The third is to make utf-8 the default. I believe this *is* the proper long term solution and both options are contrary to this. I believe that this is what I want for myself even on Windows. I believe utf-8 is the default or only storage by cross-platform international programs (certainly the ones I use). (3) In 3.3, if the default is used and it is not utf-8, add a warning that the default will become utf-8 always in 3.4. Actually, I would like a PendingDeprecationWarning in 3.2.1 if possible. </pre>", "group_id": 8954, "id": 1480043}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308948933.638128, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/5wbwnag - Glenn Linderman - <pre> +1 </pre>", "group_id": 8954, "id": 1480153}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308950734.3736529, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/5tx3qnb - Victor Stinner - <pre>Le vendredi 24 juin 2011 \u00e0 16:30 -0400, Terry Reedy a \u00e9crit : Oh yes, I also prefer this option, but I suspect that some people prefer to not break backward compatibility. Or should we consider this bad design choice as a bug? The UTF-8 encoder (of Python 3) raises an error if the text contains a surrogate character. The surrogatepass error handler should be used to encode surrogages. ... The surrogateescape can be used to encode back undecodable bytes (e.g. filename decoded by Python using the surrogateescape), but it is not a good idea to write illegal byte sequences (most programs will fail to open the file). Can you open a UTF-8 files in all Windows program (and the text is displayed correctly)? I remember that notepad.exe writes an evil UTF-8 BOM, but I don't know if it requires this BOM to detect the UTF-8 encoding. Or do some program expect text files encoded to the ANSI code page? If you want to write files in the ANSI code page, you can use encoding=\"mbcs\" (or use an explicit code page, li</pre>", "group_id": 8954, "id": 1480466}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1308964294.5907021, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/68p75kq - Nick Coghlan - <pre> [quoting VM summit notes] Indeed, PEP 380 is *really* hard to do properly without language support. The language moratorium and lack of a Python 3 compatible patch are the only reasons it didn't go into 3.2 (and there's a patch porting the implementation to 3.3 up on bitbucket, although we've been tinkering with the compiler so it is likely out of date at this point). I'm the author PEP 3150 and *I* think it's a highly questionable and most likely terrible idea (hence the Deferred status). However, it's a good place to gather the related discussions, since proposals in that vein recur often on python-ideas. PEP 3152 definitely fits into the \"let third parties experiment\" bucket, though - once PEP 380 makes generators first class peers to functions in their support for modularisation, then we need to let the wider community play with the concept for a while before we embed anything more into the core language or standard library. Cheers, Nick. </pre>", "group_id": 8954, "id": 1481981}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309002277.175204, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/6ya34av - Greg Ewing - <pre> Pardon? My original patch was for 3.1.2. </pre>", "group_id": 8954, "id": 1483709}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309006775.566633, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/5serfpf - Nick Coghlan - <pre> My mistake. We must have changed something else somewhere along the line that broke your patch... Cheers, Nick. </pre>", "group_id": 8954, "id": 1483907}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309016735.610023, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/6gcqkhx - P.J. Eby - <pre> No, it isn't. You add a decorator, a 'from_' class, and a 'return_' function, and there you go. (See my previous code sketches here in early PEP 380 discussions.) Python frameworks have been doing variations of the same thing (with varying features and APIs) for at least 7 years now -- even on Python versions that lack decorators or the ability to return values from yield statements. So the main benefit of a PEP for this functionality would be providing a common implementation/API - and that could be initially done in the stdlib, without any added syntax support. </pre>", "group_id": 8954, "id": 1484503}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309020338.6611011, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/5uyzc5q - R. David Murray - <pre> So your proposed code would allow me, when writing a generator in my code, do something that would allow me to yield up all the values from an arbitrary generator I'm calling, over which I have no control (ie: I can't modify its code)? -- R. David Murray http://www.bitdance.com </pre>", "group_id": 8954, "id": 1484776}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309021237.1166401, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/5taw4c5 - Guido van Rossum - <pre> Let me cut this short. PEP 380 is pretty much approved. I know there are a few details worth quibbling over, but they are not going to jeopardize acceptance of the PEP. We are waiting for an implementation in Python 3.3. In fact, I wouldn't mind at this point if someone took their best effort at an implementation and checked it into the 3.3 branch, and we can do the quibbling over the details while we have a working implementation to experiment with. </pre>", "group_id": 8954, "id": 1484827}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309020343.7431631, "message": "[devel] - ctypes: Configurable bitfield allocation strategy - http://tinyurl.com/6dtg4q3 - Vlad Riscutia - <pre>I recently started looking at some ctypes issues. I dug a bit into http://bugs.python.org/issue6069 and then I found http://bugs.python.org/issue11920. They both boil down to the fact that bitfield allocation is up to the compiler, which is different in GCC and MSVC. Currently we have hard-coded allocation strategy based on paltform in cfields.c: So when creating a bitfield structure, it's size can be different on Linux vs Windows. class MyStructure(ctypes.BigEndianStructure): _pack_ = 1 # aligned to 8 bits, not ctypes default of 32 _fields_ = [ (\"Data0\", ctypes.c_uint32, 32), (\"Data1\", ctypes.c_uint8, 3), (\"Data2\", ctypes.c_uint16, 12), ] sizeof for above structure is 6 on GCC build and 7 on MSVC build. This leads to some confusion and issues, because we can't always interop correctly with code compiled with different compiler than the one Python is compiled with on the platform. Short term solution is t</pre>", "group_id": 8954, "id": 1484780}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309029458.8141241, "message": "[devel] - Re: ctypes: Configurable bitfield allocation strategy - http://tinyurl.com/6gdl4cp - Terry Reedy - <pre> Just curious, are you saying that this is the 'cause' of the two bug reports, or 'just' something you discovered while investigating them? &gt; Short term solution is to add a warning in the documentation about this. For 2.7/3.2, yes. &gt; Longer term though, I think it If this would allow the MSVC-compilied Python to better access dlls compiled with gcc (cygwin) on Windows, definitely -- in 3.3. If the new feature is (currently) only useful on Windows, doc should say so. </pre>", "group_id": 8954, "id": 1485303}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309030357.9327769, "message": "[devel] - Re: ctypes: Configurable bitfield allocation strategy - http://tinyurl.com/5wfyaao - Vlad Riscutia - <pre>This is the cause of both bug reports and yes, it should improve interop with GCC-compiled code on Windows. My point is that this is not a platform thing, it's more of a compiler thing. Currently issues appear on Windows for interop between MSVC Python and other GCC code but since bitfield allocation is up to the compiler, it could appear on any other platform due to different compilers being used. On Sat, Jun 25, 2011 at 12:09 PM, Terry Reedy &lt;tjreedy&lt; at &gt;udel.edu&gt; wrote: </pre>", "group_id": 8954, "id": 1485348}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309045781.956635, "message": "[devel] - Re: ctypes: Configurable bitfield allocation strategy - http://tinyurl.com/5sn3ydo - Greg Ewing - <pre> It could also be good to have a mode which lets you specify *exactly* how the bits are laid out, independent of any particular compiler. </pre>", "group_id": 8954, "id": 1486320}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309045778.334655, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/6coebux - Greg Ewing - <pre> Will it handle *all* of the generator protocol correctly, including send(), exception handling, and generator closing? Also, how efficient would it be? A major benefit of a built-in implementation is that it can be almost as fast as using the sub-generator directly. </pre>", "group_id": 8954, "id": 1486319}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309058559.148767, "message": "[devel] - PEP 380 acceptance (was Re: EuroPython Language Summitreport) - http://tinyurl.com/68lncyq - Nick Coghlan - <pre> Based on this message, I've bumped PEP 380 to Accepted, and I'm now working on committing Renaud Blanch's forward port of Greg's original patch (see http://bugs.python.org/issue11682). Cheers, Nick. </pre>", "group_id": 8954, "id": 1486998}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309063119.9066291, "message": "[devel] - Re: PEP 380 acceptance (was Re: EuroPython Language Summit report) - http://tinyurl.com/69wnaju - Nick Coghlan - <pre> I hit a snag with this. The real tests of the PEP 380 functionality aren't currently part of the patch - they're a big set of \"golden output\" tests in the zipfile hosted on Greg's site. Those need to be refactored into proper unittest or doctest based additions to the test suite and incorporated into the patch before I could commit this with a clear conscience. That's not going to be as quick as I first thought. Renaud's patch mostly applies cleanly at the moment - the only change is that the \"#endif\" for the Py_LIMITED_API check needs to be moved in pyerrors.h so it also covers the new StopIteration struct definition. Regards, Nick. [1] http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yield_from.html </pre>", "group_id": 8954, "id": 1487254}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309097742.821393, "message": "[devel] - Re: [Python-checkins] cpython (3.2): #11669: rephrase footnote in the Compound Statements page. - http://tinyurl.com/6ycc74n - Sandro Tosi - <pre>Hi Nick, given I'm \"guilty\" for this patch, I'd reply :) On Sun, Jun 26, 2011 at 15:55, Nick Coghlan &lt;ncoghlan&lt; at &gt;gmail.com&gt; wrote: I gave my interpretation of the footnote at: http://bugs.python.org/issue11669#msg139092 . Does this clarify it? Cheers, </pre>", "group_id": 8954, "id": 1489008}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309115803.240253, "message": "[devel] - Issue10403 - using 'attributes' instead of members indocumentation - http://tinyurl.com/654jc9a - Senthil Kumaran - <pre>Hello! http://bugs.python.org/issue10403 is a documentation bug which talks about using the term 'attribute' instead of the term 'member' when it denotes the class attributes. Agreed. But the discussion goes on to mention that, \"Members and methods\" should just be \"attributes\". I find this bit odd. If the two terms are used together, then replacing it with attributes is fine. But the term 'methods' cannot be replaced with 'attributes' as it changes the meaning. Take this case, :class:`BZ2File` provides all of the methods specified by the :class:`io.BufferedIOBase`, except for :meth:`detach` and :meth:`truncate`. Iteration and the :keyword:`with` statement are supported. is correct, whereas replacing \"methods with attributes\" would make it as :class:`BZ2File` provides all of the attributes specified by the :class:`io.BufferedIOBase`, except for :meth:`detach` and :meth:`truncate`. Iteration and the :keyword:`with` statement are supported. It does not seem correct. My stance is, \"I</pre>", "group_id": 8954, "id": 1490251}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309125762.7600789, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of membersin documentation - http://tinyurl.com/6avwpwp - Terry Reedy - <pre> The terms 'member' ('data attribute' in modern terms) and 'method' go back to original Python when builtin types (or instances thereof) had members, methods, neither, or possibly both (but I do not remember anything with both). I believe there were separate builtin functions for retrieving them. \"Member' is obsolete; 'method' definitely is not. Agreed. Also agreed. It may not even be correct. I would leave it as is unless there are inherited data attributes so that the correction makes more sense than the original. A blind change of 'method' to 'attribute' is wrong. Yes. No. My strong history-based opinions ;-). </pre>", "group_id": 8954, "id": 1491314}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309136078.0114231, "message": "[devel] - Re: ctypes: Configurable bitfield allocation strategy - http://tinyurl.com/6dg2gcx - Vlad Riscutia - <pre>Well it's not really layout, because alignment is handled by pack option. It is how the field gets allocated. At this point I believe it will be more complex to come up with custom allocation option, precisely because it's up to each compiler to allocate the structure. Such flexibility will add a lot of complexity and it might not payoff. This is debatable, but I would go with a 3 option strategy at this point - native, GCC, MSVC and if we actually find interop issues with other compilers we can look into custom allocation. I will try to refactor the C code to more easily accommodate a mode option (while leaving behavior the same for now), then we can decide how the library interface should look like. Thank you, Vlad On Sat, Jun 25, 2011 at 4:37 PM, Greg Ewing &lt;greg.ewing&lt; at &gt;canterbury.ac.nz&gt;wrote: </pre>", "group_id": 8954, "id": 1491821}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309139789.1310229, "message": "[devel] - Re: EuroPython Language Summit report - http://tinyurl.com/6dthrjz - P.J. Eby - <pre> With a decorator on your own function, yes. See: http://mail.python.org/pipermail/python-dev/2010-July/102320.html for details. Mostly, though, that proposal was a suggestion for how the \"optimized\" implementation would work - i.e., a suggestion that PEP 380 be implemented that way under the hood, by implicitly turning 'yield from' into 'yield From()' and wrapping the generator itself with another From() instance. (IOW, that was a proposal for how to avoid the extra overhead of recursive yielding in a series of nested yield-from's.) </pre>", "group_id": 8954, "id": 1492056}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309138891.4344831, "message": "[devel] - Re: [Python-checkins] cpython (3.2): #11669: rephrase footnote in the Compound Statements page. - http://tinyurl.com/6jk99mc - Nick Coghlan - <pre> No, because while there *are* ways a finally clause can kill an exception completely, reraising another exception is not really one of them (as we set __context__ appropriately in that case, even if it means forcing instantiation of an as yet unrealised exception). \"This PEP handles exceptions that occur during 'except' blocks and 'finally' blocks in the same way. Reading the traceback makes it clear where the exceptions occurred, so additional mechanisms for distinguishing the two cases would only add unnecessary complexity.\" And from the interactive prompt: ... raise TypeError ... except TypeError: ... raise ValueError ... Traceback (most recent call last): File \"&lt;stdin&gt;\", line 2, in &lt;module&gt; TypeError During handling of the above exception, another exception occurred: Traceback (most recent call last): File \"&lt;stdin&gt;\", line 4, in &lt;module&gt; ValueError ... raise TypeError ... finally: ... raise ValueError ... Traceback (most recent call last): File \"&lt;stdin&gt;\", line 2, in &lt;module&gt; TypeErro</pre>", "group_id": 8954, "id": 1492007}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309138894.6843801, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of members in documentation - http://tinyurl.com/6c5fp3v - Nick Coghlan - <pre> +1 to what Terry said. \"Members\" is a historical relic that is best replaced by \"attributes\" or \"data attributes\" if we want to explicitly exclude methods for some reason. \"Methods\" is a subset of attributes that explicitly excludes data attributes. Cheers, Nick. </pre>", "group_id": 8954, "id": 1492008}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309163254.6776171, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of members in documentation - http://tinyurl.com/5wm6k66 - Antoine Pitrou - <pre>Le Mon, 27 Jun 2011 11:32:32 +1000, Nick Coghlan &lt;ncoghlan&lt; at &gt;gmail.com&gt; a \u00e9crit : While I know it is technically right, I find it a bit strange to refer to methods as \"attributes\". We're describing an API, not the inner working of the object model. Also, people just discovering Python will probably be a bit surprised if we start refer to methods as \"attributes\". FWIW, I tend to understand \"members\" as \"methods + attributes\", which makes it a nice term to use for that purpose. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev&lt; at &gt;python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org </pre>", "group_id": 8954, "id": 1493598}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309165052.7837441, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of members in documentation - http://tinyurl.com/6jhexho - Paul Moore - <pre> +1 +1 Paul. </pre>", "group_id": 8954, "id": 1493742}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309168676.4804821, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of members in documentation - http://tinyurl.com/6bxkanr - Michael Foord - <pre> That is my understanding / use of the terms as well. Michael </pre>", "group_id": 8954, "id": 1494083}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309168776.2233751, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of members in documentation - http://tinyurl.com/3dcq82y - Oleg Broytman - <pre> That's my feeling too. Oleg. </pre>", "group_id": 8954, "id": 1494093}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309172255.787991, "message": "[devel] - Patching builtin_id to allow for C proxy objects? - http://tinyurl.com/3zd2mgn - Tom Whittock - <pre>Hi all. I'm writing a module to proxy C++ objects into Python for a large C++ application. There are hundreds of thousands of C++ objects, some of which are temporary while others are very long lived. Currently every time one of these objects is accessed from Python, a new \"myproxy\" instance is created. So if I were to access the same field of an object twice, I would receive two python objects proxying the same underlying C++ object. This messes up \"id\" and \"is\", and is causing me issues when, for example, I run into circular references when enoding json or otherwise attempt to determine whether two proxy objects refer to the same C++ object. I can't see how to cache the \"myproxy\" objects instead of returning new instances - due to the architecture of the C++ application, there's no weak reference support at all, and the number of objects is very large. My current plan would be for me to override the id builtin to return the underlying C++ object instance pointer instead of the PyObject instance pointer</pre>", "group_id": 8954, "id": 1494447}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309174953.9382341, "message": "[devel] - Re: Patching builtin_id to allow for C proxy objects? - http://tinyurl.com/3vtu3yx - Stefan Behnel - <pre>Tom Whittock, 27.06.2011 12:48: Note that \"is\" actually compares the addresses, not the id(). Where would you get the proxy object from anyway? IMHO, there are two obvious way get what you want: map the C++ object address (integer!) to a proxy object using a dict, or use a backpointer from the C++ object to its proxy. The second is substantially faster, but may require changes to the C++ class struct. I don't see how changes to CPython's core can help you here. Stefan </pre>", "group_id": 8954, "id": 1494633}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309176754.8032739, "message": "[devel] - Re: Patching builtin_id to allow for C proxy objects? - http://tinyurl.com/6jb9p6l - Greg Ewing - <pre> Perhaps you could use a WeakValueDictionary to keep a mapping from a C++ object address to its Python proxy. Then as long as a proxy object is alive, accessing the same C++ object again will get you the same proxy object. When there are no longer any references to the proxy object from Python, it will go away. The next time you access that C++ object you'll get a new proxy, but that won't matter, because the original proxy is no longer around to compare it with. This depends on there being some way for the proxy object to ensure that the C++ object remains alive as long as it does. It also won't solve the problem of keeping the id of the proxy for longer than the proxy exists, but that's probably not something you should be relying on anyway. The id of *any* Python object is only valid while the object lives, and if it's still alive you have a real reference somewhere that you can use instead of the id for identity testing. </pre>", "group_id": 8954, "id": 1494769}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309178554.7147281, "message": "[devel] - Re: Patching builtin_id to allow for C proxy objects? - http://tinyurl.com/6cuahac - Tom Whittock - <pre>Hi Greg thanks for your quick reply. Thank you, I'll implement this and see whether it works out. I'll certainly be better off if it does. I was avoiding holding weak references due to perhaps unfounded concerns about increasing the lifetime and speed/memory impact of certain temporary objects which are created at very high frequency. I'll test it and see before diving into messing with id. But now I'm thinking about it again, I can see a plan for not needing to affect that pathway at all. Seems I fell into the trap of making things too complicated for myself. Thanks, yes. I'm actually kind of concerned about the usage of id in the markers set which the json library uses for circular referencing checks for exactly this reason. It seems to assume that the objects lifetime lasts for the duration of the encoding operation. I have no idea if that's actually the case in my situation, where data members are property getters producing probably very short lived proxies generated from C++. I guess I'll find out </pre>", "group_id": 8954, "id": 1494909}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309184211.399909, "message": "[devel] - Re: Patching builtin_id to allow for C proxy objects? - http://tinyurl.com/3r7bxd4 - Tom Whittock - <pre>Hi again. Just to let you know that Greg's suggestion worked beautifully - I guess my id idea was just me trying to make life hard for myself. My concerns over the json modules usage of id seem unjustified, as circular references are detected now that the weak reference dictionary is in place. Thanks for your help, and sorry for bothering dev with something which was a regular python programming issue after all. Tom. On 27 June 2011 13:31, Tom Whittock &lt;tom.whittock&lt; at &gt;gmail.com&gt; wrote: </pre>", "group_id": 8954, "id": 1495680}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309184215.653141, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of membersin documentation - http://tinyurl.com/65ry6b9 - R. David Murray - <pre> Wow, all these people who like 'members', and I can't think of ever using that term in a Python context. While I agree that using 'attribute' when only methods are being discussed would most likely be confusing, and that it can be tricky to clearly word things when both are being discussed, the existence in the language of getattr, setattr, and related methods argues against using the term 'members'. 'data attributes' can so easily become something else in Python...it seems to me that the only real difference between 'data attributes' and 'method attributes' in Python is that the latter can be called and the former can't. But even that is not an accurate distinction, since a 'data attribute' could, in fact, return a callable. I guess what I'm saying is that I am more comfortable calling them all attributes than calling them all members. The term 'members' isn't used anywhere in the language itself, as far as I can recall, whereas getattr and setattr are evidence that the language considers them all att</pre>", "group_id": 8954, "id": 1495682}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309185755.3736849, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of members in documentation - http://tinyurl.com/3eptj8v - Rob Cliffe - <pre>+1. 'function attributes' ? 'def attributes' ? Or just stick with 'method attributes' ? </pre>", "group_id": 8954, "id": 1495872}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309185758.3119719, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of members in documentation - http://tinyurl.com/3c9mxf4 - Michael Foord - <pre> Well perhaps, but where does the language draw the distinction between attributes and \"data attributes\" as you all them (a term entirely new to me)? Only in the descriptor protocol and that term isn't used there (data-descriptors and non data-descriptors is terminology used in the documentation there). If you're saying that data attributes isn't clear either (I couldn't quite tell from your email) then how *do* we draw a distinction. We could talk about instance attributes, non-descriptor class attributes and descriptors, but that terminology requires a reasonably advanced understanding of the Python data model. I don't think that \"all members, made up of attributes plus methods\" is hard to understand. That's a great benefit. The fact that you can technically treat methods as attributes too is a minor detail. All the best, Michael Foord </pre>", "group_id": 8954, "id": 1495875}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309185761.3551481, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of members in documentation - http://tinyurl.com/4xdddmx - Nick Coghlan - <pre> Yep, to me \"attribute\" just means \"something that can be accessed using attribute notation\". What it actually *is* is completely up for grabs at that point. It's worse than that - the specific meaning of \"members\" in the context of Python's history specifically *excludes* methods. The superset is \"attributes\" - as noted, the names of the builtins and magic methods make that terminology quite explicit. Cheers, Nick. </pre>", "group_id": 8954, "id": 1495876}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309185764.5285511, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of members in documentation - http://tinyurl.com/3wndpq7 - Nick Coghlan - <pre>On Tue, Jun 28, 2011 at 12:27 AM, Michael Foord &lt;fuzzyman&lt; at &gt;voidspace.org.uk&gt; wrote: It has almost no precedent in the Python context and what precedent it does have is wrong (since it excluded methods). And no, the fact that methods can be treated as attributes is not a minor detail. It is *fundamental* to Python's object model that *methods are not a special case of attribute access*. All attributes work the same way, it is just the way functions implement the descriptor protocol that makes instance methods behave the way they do. Cheers, Nick. </pre>", "group_id": 8954, "id": 1495877}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309187555.681886, "message": "[devel] - Re: PEP 380 acceptance (was Re: EuroPython LanguageSummit report) - http://tinyurl.com/3ohqy4m - renaud - <pre> let me know if i can help. if this helps, i've updated the patch to fix this. https://bitbucket.org/rndblnch/cpython-pep380/changeset/6014d1720625 renaud </pre>", "group_id": 8954, "id": 1496150}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309190266.728812, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of membersin documentation - http://tinyurl.com/5vutlev - Bill Janssen - <pre> Well put, Nick. This paragraph is a good thing to read a couple of times. Bill </pre>", "group_id": 8954, "id": 1496610}, {"user_id": 18979, "stars": [], "topic_id": 19697, "date_created": 1309190256.132143, "message": "[devel] - Re: Issue10403 - using 'attributes' instead of members in documentation - http://tinyurl.com/3obucpo - Stephen J. Turnbull - <pre> &gt; And no, the fact that methods can be treated as attributes is not a &gt; minor detail. It is *fundamental* to Python's object model that &gt; *methods are not a special case of attribute access*. That's ambiguous. I assume you mean \"just a case of attribute access, and not special in any way\"? </pre>", "group_id": 8954, "id": 1496607}]
Reference in New Issue View Git Blame Copy Permalink