Mailman 3 May 2008 - Python-Dev

Adding start to enumerate()
by Georg Brandl May 13, 2008

May 13, 2008

I believe the following is a common use-case for enumerate() (at least, I've used it quite some times): for lineno, line in enumerate(fileobject): ... For this, it would be nice to have a start parameter for enumerate(). The changes are minimal -- okay for 2.6? 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.

13 29

heads up on svn.python.org ssh keys - debian/ubuntu users may need new ones
by Gregory P. Smith May 13, 2008

May 13, 2008

Heads up. Debian screwed up. As a result all ssh and ssl keys generated in the last 18 months on debian and ubuntu systems may be compromised due to not using a good random number generator seed. http://lists.debian.org/debian-security-announce/2008/msg00152.html and http://www.links.org/?p=327 If you generated your python subversion ssh key during this time on a machine fitting the description above, please consider replacing your keys. apt-get update ; apt-get upgrade on debian will provide you with a ssh-vulnkey program that can be used to test if your ssh keys are valid or not. -gps

6 5

On quote styles
by skip＠pobox.com May 12, 2008

May 12, 2008

Moving from python-checkins and giving this topic a proper subject. The original thread started here with a checkin by Benjamin: http://mail.python.org/pipermail/python-checkins/2008-May/069181.html While Python doesn't have a char type (yet), I still find the distinction between 'c' and "abc" useful to show intent (especially given my C background and occasional but increasingly rare dip into the CPython implementation). I must admit though that I'm not as consistent with this as I used to be or would like to be. I guess that's because I'm lazy and the byte compiler doesn't enforce that style. I do prefer to use """ as the triple quote string delimiter because I find that for most of my uses it makes more sense as apostrophes tend to be the quote chars most frequently embedded in them (I don't do much, if any, HTML these days). This is, of course, all personal preference, and definitely not PEP-8-able. maybe-if-we-<wink>-uncle-timmy-will-sort-it-out-ly y'rs, Skip

9 10

Copying cgi.parse_qs() to the urllib.parse module
by Brett Cannon May 12, 2008

May 12, 2008

I just realized that PEP 3108 was missing one proposal from the stdlib SIG (originally proposed by Facundo Batista) of copying the cgi.parse_qs() function over to the new urllib.parse module so that people no longer need to import the cgi module just for that one parsing function. Does anyone object if I update the PEP to include that change? -Brett

8 15

Problems with the new super()
by Armin Ronacher May 12, 2008

May 12, 2008

Hi all, I blogged about that topic today which turned out to be a very bad idea, so I summarize it for the mailinglist here to hopefully start a discussion about the topic, which I think is rather important. In the last weeks something remarkable happened in the Python3 sources: self kinda became implicit. Not in function definitions, but in super calls. But not only self: also the class passed to `super`. That's interesting because it means that the language shifts into a completely different direction. `super` was rarely used in the past, mainly because it was weird to use. In the most common use case the current class and the current instance where passed to it, and the super typed returned looked up the parent methods on the MRO for you. It was useful for multiple inheritance and mixin classes that don't know their parent but confusing for many. I can see that a replacement is a good idea, but I'm not so sure if the current implementation is the way to go. The main problem with replacing `super(Foo, self).bar()` with something like `super.bar()` is obviously that self is explicit and the class (in that case Foo) can't be determined by the caller. Furthermore the Python principle was always against functions doing stack introspection to find the caller. There are few examples in the stdlib or builtins that do some sort of caller introspection. Those are the special functions `vars`, `locals`, `gloabal`, `vars` and some functions in the inspect module. And all of them do nothing more than getting the current frame and accessing the dict of locals or globals. What super in current Python 3 builds does goes way beyond that. The implementation of the automatic super currently has two ugly details that I think violate the Python Zen: The bytecode generated is differently if the name "super" is used in the function. `__class__` is only added as cell to the code if `super` or `__class__` is referenced. That and the fact that `f_localsplus` is completely unavailable from within python makes the whole process appear magical. This is way more magical than anything we've had in Python in the past and just doesn't fit into the language in my opinion. We do have an explicit self in methods and methods are more or less just functions. Python's methods are functions, just that a descriptor puts a method object around it to pass the self as first arguments. That's an incredible cool thing to have and makes things very simple and non-magical. Breaking that principle by introducing an automatic super seems to harm the concept. Another odd thing is that Python 3 starts keeping information on the C layer we can't access from within Python. Super is one example, another good one are methods. They don't have a descriptor that wraps them if they are accessed via their classes. This as such is not a problem as you can call them the same (just that you can call them with completely different receivers now) but it becomes a problem if some of the functions are marked as staticmethods. Then they look completely the same when looking at them from a classes perspective: | >>> class C: | ... normal = lambda x: None | ... static = staticmethod(lambda x: None) | ... | >>> type(C.normal) is type(C.static) | True | >>> C.normal | <function <lambda> at 0x4da150> As far as I can see a documentation tool has no chance to keep them apart even though they are completely different on an instance: | >>> type(C().normal) is type(C().static) | False | >>> C().normal | <bound method C.<lambda> of <__main__.C object at 0x4dbcf0>> | >>> C().static | <function <lambda> at 0x4da198> While I don't knwo about the method thing, I think an automatic super should at least be implementable from within Python. I could imagine that by adding __class__ and __self__ to scopes automatically a lot of that magic could be removed. Regards, Armin

12 17

Buildbots have trouble checking out the repository due to recent changes.
by Alexandre Vassalotti May 12, 2008

May 12, 2008

Hello, I have been working the module renaming for PEP-3108, and I just noticed that some buildbots are throwing errors while updating their checkout. It seems the method I use for renaming modules hits a subversion bug on certain platforms. The error thrown looks like this: ... svn: In directory 'build/Lib/plat-mac' svn: Can't move source to dest svn: Can't move 'build/Lib/plat-mac/.svn/tmp/prop-base/pixmapwrapper.py.svn-base' to 'build/Lib/plat-mac/.svn/prop-base/pixmapwrapper.py.svn-base': No such file or directory program finished with exit code 1 (http://www.python.org/dev/buildbot/all/x86 osx.5 trunk/builds/201/step-svn/0) When I rename a module I use "svn copy", since "svn remove" doesn't pick up changes made to the "deleted" file. For example, here is what I did for PixMapWrapper: svn copy ./Lib/plat-mac/PixMapWrapper.py ./Lib/plat-mac/pixmapwrapper.py edit ./Lib/plat-mac/PixMapWrapper.py svn commit It seems that I could avoid this error by using "cp" instead of "svn copy" (which I did use for renaming copy_reg). However, I am not sure if this method doesn't preserve the full history of file. So, how should I do to fix the failing buildbots? -- Alexandre

6 19

Re: [Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
by Alexandre Vassalotti May 12, 2008

May 12, 2008

On Sun, May 11, 2008 at 5:44 PM, Paul Moore <p.f.moore(a)gmail.com> wrote: > 2008/5/11 Alexandre Vassalotti <alexandre(a)peadrop.com>: >> When I rename a module I use "svn copy", since "svn remove" doesn't >> pick up changes made to the "deleted" file. For example, here is what >> I did for PixMapWrapper: >> >> svn copy ./Lib/plat-mac/PixMapWrapper.py ./Lib/plat-mac/pixmapwrapper.py >> edit ./Lib/plat-mac/PixMapWrapper.py >> svn commit > > That seems a very odd usage. You're renaming, not copying. Why aren't > you using svn rename (svn move)? I can well imagine this causing > serious confusion. > I wrote: > When I rename a module I use "svn copy", since "svn remove" doesn't > pick up changes made to the "deleted" file. For example, here is what > I did for PixMapWrapper: Oops, I meant "svn rename" when I said "svn remove". As I said, if I use "svn rename" I cannot make changes to the file being renamed. > Please be very careful here - if you introduce revisions which contain > multiple files with names that differ only in case, you're going to > really mess up history (and probably the only clean way to fix this > will be to actually go back and edit the history). Oh, you are right. I totally forgot about case-insensible filesystems. This is really going to make such case-change renamings nasty. -- Alexandre

3 5

How to help out with PEP 3108
by Brett Cannon May 11, 2008

May 11, 2008

I have tried to update PEP 3108 (http://www.python.org/dev/peps/pep-3108/) as best as I can to list what needs to be done for each module in order to get it removed if there is some extra step. The ones without comment most likely need no special work and thus I can take care of really quickly myself (have it down to instinct at this point). But anything with special needs I would appreciate the help in dealing with. I have also tried to make the steps necessary to deal with the various modules as clear as possible in the PEP itself. Although I created issue 2775 to track stuff, it is probably wiser to create individual issues for the modules that require any form of work to deal with. Just make sure that if you do that you make it a dependency in issue 2775 (and if you can, list it in the PEP). I would like to not have to hold up the betas just because of this PEP, but I don't know if I can finish the PEP completely on my own. So help is appreciated. Thanks to anyone who can help (or who already have)! -Brett

2 1

Re: [Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
by Paul Moore May 11, 2008

May 11, 2008

Sorry, should have gone to the list: 2008/5/11 Alexandre Vassalotti <alexandre(a)peadrop.com>: > When I rename a module I use "svn copy", since "svn remove" doesn't > pick up changes made to the "deleted" file. For example, here is what > I did for PixMapWrapper: > > svn copy ./Lib/plat-mac/PixMapWrapper.py ./Lib/plat-mac/pixmapwrapper.py > edit ./Lib/plat-mac/PixMapWrapper.py > svn commit That seems a very odd usage. You're renaming, not copying. Why aren't you using svn rename (svn move)? I can well imagine this causing serious confusion. Please be very careful here - if you introduce revisions which contain multiple files with names that differ only in case, you're going to really mess up history (and probably the only clean way to fix this will be to actually go back and edit the history). Paul (who has been bitten once too often with case clashes in history :-()

1 0

Trickery with moving urllib
by Brett Cannon May 11, 2008

May 11, 2008

There is going to be an issue with the current proposal for keeping around urllib. Since the package is to be named the same thing as the module, to handle the new name that means urllib.__init__ will need to gain the Py3K warning for the new name. But that doesn't quite work as the package's module will be imported automatically any time the module within the package is used. I see three solutions for dealing with this. 1. Have stubs for the entire urllib API in urllib.__init__ that raise a DeprecationWarning either specifying the new name or saying the function/class is deprecated. 2. Rename urllib to urllib.fetch or urllib.old_request to get people to move over to urllib.request (aka urllib2) at some point. 3. Ditch urllib completely and have people move to urllib.request directly from 2.6 going into 3.0. I was a fan of 3 in the stdlib SIG, but MAL argued well for 2 since so much code uses urllib (although I have always wondered how many *really* use urllib and how many could easily just move over to urllib2). The current solution of keeping around urllib's classes was a compromise, but I had not thought out the transition yet (and Jeremy Hylton will be running into this as he has volunteered to handle this). What do people think we should do? -Brett

7 11