Mailman 3 October 2010 - Python-Dev

Re: [Python-Dev] r85838 - python/branches/py3k/.gitignore
by Georg Brandl 29 Oct '10

29 Oct '10

Am 25.10.2010 19:37, schrieb victor.stinner: > Author: victor.stinner > Date: Mon Oct 25 19:37:18 2010 > New Revision: 85838 > > Log: > update gitignore > > Added: > python/branches/py3k/.gitignore This looks more like "Add gitignore". Do we really want to check in ignore files for every possible DVCS? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

12 17

Fwd: Fixing zipfile.BadZipfile to zipfile.BadZipFile
by Boštjan Mejak 29 Oct '10

29 Oct '10

Forwarded conversation Subject: Fixing zipfile.BadZipfile to zipfile.BadZipFile ------------------------ From: *Boštjan Mejak* <bostjan.mejak(a)gmail.com> Date: Fri, Oct 15, 2010 at 11:02 PM To: python-dev(a)python.org I am very glad you're reorganizing the Standard Library. Thumbs up! I hope everything will comply to PEP 8 after you're done. Since you're reorganizing, I have my own contribution. I have attached a patch. The issue7351 <http://bugs.python.org/issue7351> was not accepted at the time, so I hope you'll accept this fix now. My point is that every class name in the module zipfile is like this: - LargeZipFile - ZipFile - PyZipFile . . . So apply my patch to make the class name BadZipfile consistent to other class names in the zipfile module and let it be named BadZipFile. Thank you. Best regards, Boštjan Mejak ---------- From: *Éric Araujo* <merwok(a)netwok.org> Date: Sun, Oct 17, 2010 at 11:00 PM To: python-dev(a)python.org Cc: Boštjan Mejak <bostjan.mejak(a)gmail.com> Hello (A bit of context: The original message comes from bug #2775, “Implement PEP 3108”, a meta-bug tracking stdlib reorganization for py3k.) You may have missed the timeline: Most of the PEP 3108 changes have been done before the first 3.x release went out. Now that we have 3.1 out as a stable and supported, we cannot reorganize and break compatibility anymore. (A note about PEP 8 compliance: Module names have been mostly fixed, but not all function/method names, for example in logging and unittest. If I recall correctly, readability did not seem to make all the rewrites worth it.) > a patch. The issue7351 <http://bugs.python.org/issue7351> was not I’ve just re-read the answers there and they are still valid. Ezio and me: “Your patch need to include an alias (BadZipfile = BadZipFile) to preserve compatibility with old pickles, as explains msg95477.” Antoine: “I don't think changing it for the sake of aesthetics is a good deal given that many existing programs will have to be converted to the new spelling.” Regards ---------- From: *Boštjan Mejak* <bostjan.mejak(a)gmail.com> Date: Mon, Oct 18, 2010 at 9:25 AM To: Éric Araujo <merwok(a)netwok.org> Shoot. Well, too bad. I thought Python is all about readability, but I think you developers don't take it very seriously. If I was a developer, I would certainly go to the trouble of all the rewrittes of package/module/class/method/function names that do not comply to PEP 8 and have them done by the time the first sub-version of Python 3 would be released. ---------- From: *Éric Araujo* <merwok(a)netwok.org> Date: Mon, Oct 18, 2010 at 2:14 PM To: Boštjan Mejak <bostjan.mejak(a)gmail.com> Hi Could you repost your message to the mailing list, so that other people can see it and eventually react? Thanks. (P.S. please make sure not to top-post on the mailing list) Regards ---------- From: *Éric Araujo* <merwok(a)netwok.org> Date: Mon, Oct 18, 2010 at 2:45 PM To: python-dev(a)python.org Hello [Sorry if this comes twice, connection errors here] > a patch. The issue7351 <http://bugs.python.org/issue7351> was not _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/bostjan.mejak%40gmail.com ---------- From: *Nick Coghlan* <ncoghlan(a)gmail.com> Date: Mon, Oct 18, 2010 at 3:13 PM To: Éric Araujo <merwok(a)netwok.org> Cc: python-dev(a)python.org Correct. We went through this for one module that I recall (threading) and that was annoying enough that we mostly left things alone after that unless they were truly obnoxious. For threading we were able to clean a lot of things up in the process (such as adding properties where appropriate), but even so, we still made sure all the old names continued to work. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia ---------- From: *Boštjan Mejak* <bostjan.mejak(a)gmail.com> Date: Mon, Oct 18, 2010 at 4:36 PM To: Nick Coghlan <ncoghlan(a)gmail.com> Then please make an alias for this custom BadZipfile exception class. Add BadZipfile = BadZipFile in the zipfile module. ---------- From: *Boštjan Mejak* <bostjan.mejak(a)gmail.com> Date: Tue, Oct 19, 2010 at 10:34 PM To: Nick Coghlan <ncoghlan(a)gmail.com> Sorry, let me correct myself: Add BadZipFile = BadZipfile in the zipfile module. Please add the above assignment statement in the right place to the zipfile module and create an alias. Thank you. ---------- From: *Boštjan Mejak* <bostjan.mejak(a)gmail.com> Date: Wed, Oct 20, 2010 at 11:13 PM To: Nick Coghlan <ncoghlan(a)gmail.com> Ah, leave it as is. If in the future you will be able to rename BadZipfile to BadZipFile, please do. ---------- From: *Éric Araujo* <merwok(a)netwok.org> Date: Wed, Oct 27, 2010 at 6:26 PM To: python-dev <python-dev(a)python.org> Cc: Boštjan Mejak <bostjan.mejak(a)gmail.com> [Reply received off-list quoted here] Le 18/10/2010 09:25, Boštjan Mejak a écrit : Readability has to be balanced with other important things: maintainability, discoverability, compatibility, rapidity and other things ending in -ity. I’m personally glad that readability gets a huge place in the language definition itself (no braces, standard indentation), I follow 98 % of PEP 8 where I can, and have learned to accept that sometimes, a piece of code in the standard lib won’t get more readable. Still beats some languages that I won’t name because dissing Java is too easy. <wink> You are free to break compat in your code but it python-dev has a duty to its users. Renames in threading have been deemed a good thing, renames in unittest not. You can read the python-3000 archives to get an idea of the years of work and thousands of messages that went into py3k. At some point, a release had to be done. Now that there is a stable release in the 3.x line, compatibility rules apply. Practicality beats purity; now is better than never. Regards ---------- From: *Boštjan Mejak* <bostjan.mejak(a)gmail.com> Date: Wed, Oct 27, 2010 at 7:13 PM To: Éric Araujo <merwok(a)netwok.org> Since Python 3.2 accepts feature requests, take this fix as a feature request. Please forget about preserving the compatibility with old pickles. ---------- From: *Éric Araujo* <merwok(a)netwok.org> Date: Wed, Oct 27, 2010 at 7:16 PM To: Boštjan Mejak <bostjan.mejak(a)gmail.com> Again, please send a copy to your messages to the mailing list (choose “reply to all” or “reply to list”), and don’t leave the whole message after your reply. Thanks.

3 4

x86 Leopard buildbot
by Antoine Pitrou 29 Oct '10

29 Oct '10

Hello, As a leap of faith, I have added Stephen Hansen's x86 Leopard buildbot to the list of stable bots. Stephen has been very proactive in diagnosing and fixing issues (thank you!). Antoine.

1 0

A sad state of doctests in the python manual
by Alexander Belopolsky 28 Oct '10

28 Oct '10

I have just discovered that sphinx supports running doctests embedded in ReST documentation. It looks like it is as simple as "cd Doc; make doctest". The result, however is not encouraging: $ make doctest ... Doctest summary =============== 1162 tests 262 failures in tests 0 failures in setup code ...

2 5

Re: [Python-Dev] Continuing 2.x
by lutz＠rmi.net 28 Oct '10

28 Oct '10

Kristj?n Valur J?nsson <kristjan(a)ccpgames.com> writes: > James Y Knight said: > The python community has already decided many times over that Python2 is dead > and Python3 is the future > > But the patient is very much alive and kicking, no matter what the good doctor > declares. Python 2.x is in widespread use, with gazillion lines of .py code. > In, there is another gazillion lines of .c and .cpp code both in extensions and > embedding applications in use. I?m quite happy with the community at large > moving its development focus to 3.x but it is a bit harsh to deprive those left > behind of the keys to the old house. Exactly. Has anyone here analyzed download stats on py.org lately? Please feel free to prove me wrong, but by my reckoning, and at least for Windows MSI installer files, people are still downloading Python 2.X roughly 3 to 4 times more often than Python 3.X today, some 2 years after 3.X's release. This is from http://www.python.org/webstats for September and October, based on file size and bytes fetched for all significant versions. As one metric, roughly 439K people fetched 2.X MSI files in September, and 124K went for 3.X. Granted, there are plenty of variables such as preinstalled Pythons on Macs and Linux, though many would tend to skew 2.X dominance even higher. Moreover, downloads may be more reflective of new users, than existing users who are likely in the 2.X camp. But clearly, the 2.X patient is hardly dead; it still reflects the vast majority of the Python world today. I hope 3.X use expands; in fact, I've bet the future of at least one book on it. And even 1/4 of new users seems a large enough subset to care about too. But one can't help but wonder if most of the development community is focused on some imaginary future user base, at the expense of the much larger current user base. Then again, there's still plenty of Fortran77 code out there, so... --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz)

8 7

MemoryError... how much memory?
by Facundo Batista 28 Oct '10

28 Oct '10

There are a lot of places where Python or modules do something like: self->buf = (char *)malloc(size); if (!self->buf) { PyErr_SetString(PyExc_MemoryError, "out of memory"); At job, we're having some MemoryErrors, and one thing that we would love to know, if how much memory it was asking when that happened. So, I thought about doing something like: char message[50]; ... self->buf = (char *)malloc(size); if (!self->buf) { snprintf(message, 50, "out of memory (asked: %lld)", size); PyErr_SetString(PyExc_MemoryError, &message); Is any inherent problem in doing this? May it be a good idea to make it generic, like providing a PyErr_MemoryError that could accept a message and a number, and stores that number in the exception objects internals? Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

8 11

http://bugs.python.org/issue9981
by Kristján Valur Jónsson 28 Oct '10

28 Oct '10

I didn't get any response to this. I know that it is a 2.7 patch, but I´m willing to port it to 3.x, if there is interest. Supporting parallel compilation is a big win. K

1 0

Re: [Python-Dev] Fixing zipfile.BadZipfile to zipfile.BadZipFile
by Éric Araujo 27 Oct '10

27 Oct '10

[Reply received off-list quoted here] Le 18/10/2010 09:25, Boštjan Mejak a écrit : > Shoot. Well, too bad. I thought Python is all about readability, but I think > you developers don't take it very seriously. Readability has to be balanced with other important things: maintainability, discoverability, compatibility, rapidity and other things ending in -ity. I’m personally glad that readability gets a huge place in the language definition itself (no braces, standard indentation), I follow 98 % of PEP 8 where I can, and have learned to accept that sometimes, a piece of code in the standard lib won’t get more readable. Still beats some languages that I won’t name because dissing Java is too easy. <wink> > If I was a developer, I would > certainly go to the trouble of all the rewrittes of > package/module/class/method/function names that do not comply to PEP 8 and > have them done by the time the first sub-version of Python 3 would be > released. You are free to break compat in your code but it python-dev has a duty to its users. Renames in threading have been deemed a good thing, renames in unittest not. You can read the python-3000 archives to get an idea of the years of work and thousands of messages that went into py3k. At some point, a release had to be done. Now that there is a stable release in the 3.x line, compatibility rules apply. Practicality beats purity; now is better than never. Regards

1 0

Re: [Python-Dev] [Python-ideas] Move Demo scripts under Lib
by Alexander Belopolsky 27 Oct '10

27 Oct '10

I would like to report a conclusion reached on the tracker to a wider audience before committing the changes. The new home for Demo/turtle is Lib/turtledemo. (Lib/turtle/demo alternative received no support and Lib/demo/turtle was not even in the running.) If anyone is interested in reviewing the patch, please see http://bugs.python.org/issue10199. Note that I tried to limit changes to what was necessary for running the demo script as python -m demoturtle. Running the scripts as unit tests and from python prompt will be subject of a separate issue. On Tue, Oct 26, 2010 at 11:49 AM, Alexander Belopolsky <alexander.belopolsky(a)gmail.com> wrote: > On Tue, Oct 26, 2010 at 11:18 AM, Guido van Rossum <guido(a)python.org> wrote: >> On Tue, Oct 26, 2010 at 8:13 AM, Alexander Belopolsky >> <alexander.belopolsky(a)gmail.com> wrote: >>> The one demo that I want to find a better place for is Demo/turtle. >> >> Sure, go for it. It is a special case because the turtle module is >> also in the stdlib and these are intended for a particular novice >> audience. > > Please see http://bugs.python.org/issue10199 for further discussion. >

1 0

Issue 10194 - Adding a gc.remap() function
by Peter Ingebretson 27 Oct '10

27 Oct '10

I have a patch that adds a new function to the gc module. The gc.remap() function uses the tp_traverse mechanism to find all references to any keys in a provided mapping, and remaps these references in-place to instead point to the value corresponding to each key. The motivation for adding this method is to enable writing a module that provide an enhanced version of imp.reload. The builtin reload function is very useful for iterating on a single module within the Python interpreter shell, but in more complex situations it very limited. In particular, instances of classes declared in the reloaded module will continue to reference the old versions of the classes, and other modules that imported elements of the old module using the 'from ... import ...' syntax will continue to refer to the stale version of the functions or classes that they imported. The gc.remap() function enables writing a new version of reload which uses imp.reload to reload a module and then replaces all references to stale objects from the old module to instead point to equivalent newly defined objects. This still has many limitations, for instance if an __init__ function has been changed the new __init__ will not be run on old instances. On the other hand, in many cases this is sufficient to continue iterating on code without needing to restart the Python environment, which can be a significant time savings. I initially tried to implement this reloading strategy entirely in Python using gc.getreferrers() to find references to objects defined in the old module, but I found it was too difficult to reliably replace references in objects once they had been found. Since the GC already has a way to find all fields that refer to objects, it seemed fairly straightforward to extend that mechanism to additionally modify references. This reloading strategy is documented in more detail here: http://doublestar.org/in-place-python-reloading/ A potentially controversial aspect of this change is that the signature of the visitproc has been modified to take (PyObject **) as an argument instead of (PyObject *) so that a visitor can modify fields visited with Py_VISIT. A few traverse functions in the standard library also had to be changed to use Py_VISIT on the actual members rather than on aliased pointers. I also have a prototype of an enhanced reload function using gc.remap. This is only a partial implementation of the proposal, in particular it does not rehash dictionaries that have been invalidated as a result of reloading, and it does not support custom __reload__ hooks. A link to the code as well as some examples are here: http://doublestar.org/python-hot-loading-prototype/ Please let me know if you have any feedback on the reloading proposal, the hot loading prototype, or on the patch. Thanks, Peter

7 15