Re: [Python-Dev] Trickery with moving urllib
On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: 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. On May 11, 2008, at 2:58 AM, Alexandre Vassalotti wrote: I am probably missing something, because I don't see how this solution would solve the problem. The warning in urllib.__init__ will still be issued when people will import urllib.fetch (or urllib.fetch). Were the warnings issued on import, yes, but I think Brett's suggestion was really about issuing warnings when the stub functions were called. For classes, I guess this could be handled using the __init__ methods, but I'm not sure I like that, or that it will be easy to get exactly the right behavior in all cases. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
Fred Drake schrieb: On May 10, 2008, at 11:49 PM, Guido van Rossum wrote: Works for me. The other thing I always use from cgi is escape() -- will that be available somewhere else too? xml.sax.saxutils.escape() would be an appropriate replacement, though the location is a little funky. Ideally it would be xml.escape(). Perhaps there are more of these generally- useful XML thingies to put there? 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trickery with moving urllib
Brett Cannon schrieb: 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. In this context, what's become of PEP 364? Is it still alive? Does it cover this case? 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trickery with moving urllib
On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > 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? I am migrating all the stdlib code to use urllib2 APIs when possible. It seems straightforward enough to keep the old urllib classes in urllib.request, but change the standard API functions (urlopen, urlretrieve) to use the urllib2 implementation. We could probably have a big collection of deprecation warnings in the urllib/__init__ without much trouble. It doesn't have any code at this point. Jeremy > > -Brett > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trickery with moving urllib
On 10-May-08, at 20:43, [EMAIL PROTECTED] wrote: Brett> There is going to be an issue with the current proposal for Brett> keeping around urllib. Since the package is to be named the same Brett> thing as the module Is this the only module morphing into a package of the same name? Yes. -Brett Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
-Brett [from his iPod touch] On 10-May-08, at 20:49, "Guido van Rossum" <[EMAIL PROTECTED]> wrote: Works for me. The other thing I always use from cgi is escape() -- will that be available somewhere else too? It can be. =) -Brett On Sat, May 10, 2008 at 8:30 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: 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? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trickery with moving urllib
-Brett [from his iPod touch] On 10-May-08, at 23:46, "Alexandre Vassalotti" <[EMAIL PROTECTED]> wrote: On Sat, May 10, 2008 at 11:43 PM, <[EMAIL PROTECTED]> wrote: Brett> There is going to be an issue with the current proposal for Brett> keeping around urllib. Since the package is to be named the same Brett> thing as the module Is this the only module morphing into a package of the same name? No, it is not. The dbm package will have the same issue. Ah nuts, forgot about that one. -Brett -- Alexandre ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trickery with moving urllib
-Brett [from his iPod touch] On 10-May-08, at 23:58, "Alexandre Vassalotti" <[EMAIL PROTECTED]> wrote: On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: 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. I am probably missing something, because I don't see how this solution would solve the problem. The warning in urllib.__init__ will still be issued when people will import urllib.fetch (or urllib.fetch). No, you are probably right. My brain is mush at the moment. -brett -- Alexandre ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trickery with moving urllib
-Brett [from his iPod touch] On 11-May-08, at 0:04, Fred Drake <[EMAIL PROTECTED]> wrote: On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: 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. On May 11, 2008, at 2:58 AM, Alexandre Vassalotti wrote: I am probably missing something, because I don't see how this solution would solve the problem. The warning in urllib.__init__ will still be issued when people will import urllib.fetch (or urllib.fetch). Were the warnings issued on import, yes, but I think Brett's suggestion was really about issuing warnings when the stub functions were called. For classes, I guess this could be handled using the __init__ methods, but I'm not sure I like that, or that it will be easy to get exactly the right behavior in all cases. Another option is to not worry about warnings in this specific case and fully rely on 2to3. The issue of urllib and splitting its API across 2 files stands, though. That could be solved with a urllib._old module for now that eventually gets a deprecation warning. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trickery with moving urllib
On Sun, May 11, 2008 at 8:31 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: >> >> 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. > > In this context, what's become of PEP 364? Is it still alive? Does it > cover this case? > PEP 364 was pre-2to3 (Barry and I came up with that solution at the same PyCon 2to3 was conceived). A 2to3 fixer that handles the renames does the same thing; so no, it doesn't solve the issue directly. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encoding detection in the standard library?
Bill Janssen: Since the site that receives the POST doesn't necessarily have access to the Web page that originally contained the form, that's not really helpful. However, POSTs can use the MIME type "multipart/form-data" for non-Latin-1 content, and should. That contains facilities for indicating the encoding and other things as well. Yup, but DrProject (the target application) also serves as a relay and archive for email. We have no control over the agent used for composition, and AFAIK there's no standard way to include encoding information. Thanks, Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with the new super()
On May 2, 7:54 am, Greg Ewing <[EMAIL PROTECTED]> wrote: > > I can only speak from my own experience, which is that > whenever I've had a problem involving multiple inheritance, > super() didn't solve it. What did solve it was either > refactoring so that the classes being mixed were more > independent, or finding another solution that didn't > require multiple inheritance. > > Usually the new solution turned out to be better in > other ways as well, so I've come to regard multiple > inheritance issues as a code smell suggesting that > I need to rethink something. This is my experience as well. I have not found a real life problem yet that I could not solve with single inheritance + composition/delegation in a better and more maintainable way than using multiple inheritance. Also, I have come to believe that cooperative methods are a wart (it is too difficult to reason about them, they are fragile, and overall I see them as an unneeded complication in everyday coding). But we are stuck with multiple inheritance now and there is already a lot of code out there using it, so in the present situation we have to cope with it and to make it more usable, so I welcome the new super. I think that it should be made a keyword tough (it is too magic now not to be one). Michele Simionato ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reminder: last alphas next Wednesday 07-May-2008
Jeroen Ruigrok van der Werven wrote: -On [20080502 10:50], Steve Holden ([EMAIL PROTECTED]) wrote: Groan. Then everyone else realizes what a "great idea" this is, and we see ~/Perl/, ~/Ruby/, ~/C# (that'll screw the Microsoft users, a directory with a comment market in its name), ~/Lisp/ and the rest? I don't think people would thank us for that in the long term. I'm +1 on just using $HOME/.local, but otherwise $HOME/.python makes sense too. $HOME/.python.d doesn't do it for me, too clunky (and hardly used if I look at my .files in $HOME). I'd vote for $HOME/.local if asked. I agree with most, if not all, of the arguments posted in favour of this, but would also like to point out the XDG-basedir specification: http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html This specification concerns where to put data files rather than libraries, but the relevance here is that the default location to put user-specific files according to it is in $HOME/.local/share Whilst by no means universally followed, uptake amongst Gnome and GTK applications seems to be rising - I certainly have a load of stuff in .local/share/ without ever having configured anything away from the Ubuntu install defaults. So, on Ubuntu computers at least, it seems likely that a $HOME/.local/ directory will already exist, with the beginnings of a unix style layout inside it. -- Richard ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
Sorry, should have gone to the list: 2008/5/11 Alexandre Vassalotti <[EMAIL PROTECTED]>: > 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 :-() ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
Alexandre Vassalotti schrieb: 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? In any case, how does SVN on Windows handle this situation, having two identical filenames -- except for case -- in one directory? 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
On Sun, May 11, 2008 at 11:45:03PM +0200, Georg Brandl wrote: > In any case, how does SVN on Windows handle this situation, having two > identical filenames -- except for case -- in one directory? Very bad. It's completely confused. It can checkout one of the files and commit the other. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
On Sun, May 11, 2008 at 5:44 PM, Paul Moore <[EMAIL PROTECTED]> wrote: > 2008/5/11 Alexandre Vassalotti <[EMAIL PROTECTED]>: >> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding start to enumerate()
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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
On Sun, May 11, 2008 at 3:16 PM, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 5:44 PM, Paul Moore <[EMAIL PROTECTED]> wrote: >> 2008/5/11 Alexandre Vassalotti <[EMAIL PROTECTED]>: >>> 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. The PEP specifies the lib-old directory to hold the old case name so that the svn rename won't lead to two files in the same directory. I was hoping that creating the stub in lib-old would allow a simple ``svn rename`` for the original module on a case-sensitive file-system and the case-insensitive file-systems would just be able to deal with it. Is that just not going to work? Oh, and I am really sorry, Alexandre, but the PixMapWrapper rename should have been taken out of the PEP as the entire Mac directory is going away, so the rename is kind of pointless since the module is going to be deleted. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
On Sun, May 11, 2008 at 6:31 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > The PEP specifies the lib-old directory to hold the old case name so > that the svn rename won't lead to two files in the same directory. I > was hoping that creating the stub in lib-old would allow a simple > ``svn rename`` for the original module on a case-sensitive file-system > and the case-insensitive file-systems would just be able to deal with > it. Is that just not going to work? > > Oh, and I am really sorry, Alexandre, but the PixMapWrapper rename > should have been taken out of the PEP as the entire Mac directory is > going away, so the rename is kind of pointless since the module is > going to be deleted. > Well, I guess I really messed up on that one. So, do you have any idea on how to revert the changes? -- Alexandre ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
On Sun, May 11, 2008 at 3:38 PM, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 6:31 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> The PEP specifies the lib-old directory to hold the old case name so >> that the svn rename won't lead to two files in the same directory. I >> was hoping that creating the stub in lib-old would allow a simple >> ``svn rename`` for the original module on a case-sensitive file-system >> and the case-insensitive file-systems would just be able to deal with >> it. Is that just not going to work? >> >> Oh, and I am really sorry, Alexandre, but the PixMapWrapper rename >> should have been taken out of the PEP as the entire Mac directory is >> going away, so the rename is kind of pointless since the module is >> going to be deleted. >> > > Well, I guess I really messed up on that one. Eh, how were you to know? It's something I sometimes forget on my Mac since it is case-preserving but case-insensitive. Hopefully the lib-old trick will solve the problem as PixMapWrapper was the only one that is in any form of a package and that module is no longer an issue. > So, do you have any idea > on how to revert the changes? See if having you move Queue.py into lib-old fixes things. Otherwise the patch will need to be reverted. I am on GTalk right now so you can IM me as soon as you have tried if you want and I can see if it fixes the problem on OS X. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
On Sun, May 11, 2008 at 3:20 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: > 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? > Taking a new argument that has a default shouldn't be an issue. +1 from me. I assume it is just going to start the count at that number, not advance the iterable to that point, right? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
Brett Cannon schrieb: On Sun, May 11, 2008 at 3:20 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: 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? Taking a new argument that has a default shouldn't be an issue. +1 from me. I assume it is just going to start the count at that number, not advance the iterable to that point, right? Exactly. 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots have trouble checking out the repository due to recent changes.
On Sun, May 11, 2008 at 5:29 PM, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote: > 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: [SNIP] > So, how should I do to fix the failing buildbots? > I reverted the all problematic changes and the buildbots are green again. Thank you all for you support! -- Alexandre ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
On Mon, 12 May 2008 08:20:51 am Georg Brandl wrote: > 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(). Why would it be nice? What would you use it for? The only thing I can think of is printing lines with line numbers, and starting those line numbers at one instead of zero. If that's the only use-case, should it require built-in support? -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
On Sun, May 11, 2008 at 12:00 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Fred Drake schrieb: >> >> On May 10, 2008, at 11:49 PM, Guido van Rossum wrote: >>> >>> Works for me. The other thing I always use from cgi is escape() -- >>> will that be available somewhere else too? >> >> >> xml.sax.saxutils.escape() would be an appropriate replacement, though the >> location is a little funky. More than a little IMO. :-( > Ideally it would be xml.escape(). Perhaps there are more of these generally- > useful XML thingies to put there? Not really -- I'd rather see the xml package as a pure container, with all its contents in submodules (or subpackages). Also, I don't see this exclusive to XML -- HTML isn't XML (yet). > 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. > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
On Sun, May 11, 2008 at 4:42 PM, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > On Mon, 12 May 2008 08:20:51 am Georg Brandl wrote: >> 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(). > > Why would it be nice? What would you use it for? > > The only thing I can think of is printing lines with line numbers, and > starting those line numbers at one instead of zero. If that's the only > use-case, should it require built-in support? It's a common enough use-case, so I think it makes sense. With the cost being so minimal to add support I think this one use-case alone is enough to justify adding the support. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
On Sun, May 11, 2008 at 4:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 12:00 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: >> Fred Drake schrieb: >>> >>> On May 10, 2008, at 11:49 PM, Guido van Rossum wrote: Works for me. The other thing I always use from cgi is escape() -- will that be available somewhere else too? >>> >>> >>> xml.sax.saxutils.escape() would be an appropriate replacement, though the >>> location is a little funky. > > More than a little IMO. :-( > Well, if that function is better than who cares about the location; it will end up in urllib.parse as some function. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
2008/5/11, Brett Cannon <[EMAIL PROTECTED]>: > It's a common enough use-case, so I think it makes sense. With the > cost being so minimal to add support I think this one use-case alone > is enough to justify adding the support. +1 -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
Steven D'Aprano wrote: The only thing I can think of is printing lines with line numbers Parsing a file and wanting to be able to print error messages with line numbers would seem to be a fairly likely use. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
Brett Cannon wrote: Taking a new argument that has a default shouldn't be an issue. +1 from me. I assume it is just going to start the count at that number, not advance the iterable to that point, right? I wonder if it would be best for it to be a keyword-only argument. So many of the utility functions on iterables are foo(*iterables) that I might be inclined to think enumerate(foo, bar) is equivalent to enumerate(chain(foo, bar)), but enumerate(foo, start=bar) is pretty obvious. And if you consider that the enumeration is prepended to the values of foo, enumerate(foo, bar) is "backwards." Just saying.. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
On Sun, May 11, 2008 at 5:01 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 4:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On Sun, May 11, 2008 at 12:00 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: >>> Fred Drake schrieb: On May 10, 2008, at 11:49 PM, Guido van Rossum wrote: > > Works for me. The other thing I always use from cgi is escape() -- > will that be available somewhere else too? xml.sax.saxutils.escape() would be an appropriate replacement, though the location is a little funky. >> >> More than a little IMO. :-( >> > > Well, if that function is better than who cares about the location; it > will end up in urllib.parse as some function. It's a trivial function; it shouldn't pull in three packages and lots of other cruft. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
+1 to this. On Sun, May 11, 2008 at 6:23 PM, Scott Dial <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: >> >> Taking a new argument that has a default shouldn't be an issue. +1 >> from me. I assume it is just going to start the count at that number, >> not advance the iterable to that point, right? > > I wonder if it would be best for it to be a keyword-only argument. So > many of the utility functions on iterables are foo(*iterables) that I > might be inclined to think enumerate(foo, bar) is equivalent to > enumerate(chain(foo, bar)), but enumerate(foo, start=bar) is pretty > obvious. And if you consider that the enumeration is prepended to the > values of foo, enumerate(foo, bar) is "backwards." Just saying.. > > -Scott > > -- > Scott Dial > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
On Sun, May 11, 2008 at 6:23 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 5:01 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> On Sun, May 11, 2008 at 4:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >>> On Sun, May 11, 2008 at 12:00 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: Fred Drake schrieb: > > On May 10, 2008, at 11:49 PM, Guido van Rossum wrote: >> >> Works for me. The other thing I always use from cgi is escape() -- >> will that be available somewhere else too? > > > xml.sax.saxutils.escape() would be an appropriate replacement, though the > location is a little funky. >>> >>> More than a little IMO. :-( >>> >> >> Well, if that function is better than who cares about the location; it >> will end up in urllib.parse as some function. > > It's a trivial function; it shouldn't pull in three packages and lots > of other cruft. So are you saying that it isn't that much better in urllib.parse? That only cuts the package count down by one. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
On Sun, May 11, 2008 at 6:34 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 6:23 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On Sun, May 11, 2008 at 5:01 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >>> On Sun, May 11, 2008 at 4:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: On Sun, May 11, 2008 at 12:00 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Fred Drake schrieb: >> >> On May 10, 2008, at 11:49 PM, Guido van Rossum wrote: >>> >>> Works for me. The other thing I always use from cgi is escape() -- >>> will that be available somewhere else too? >> >> >> xml.sax.saxutils.escape() would be an appropriate replacement, though the >> location is a little funky. More than a little IMO. :-( >>> >>> Well, if that function is better than who cares about the location; it >>> will end up in urllib.parse as some function. >> >> It's a trivial function; it shouldn't pull in three packages and lots >> of other cruft. > > So are you saying that it isn't that much better in urllib.parse? That > only cuts the package count down by one. I didn't mean to say, but it does seem the wrong module -- escape() is for HTML, not for URLs. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
On Sun, May 11, 2008 at 6:23 PM, Scott Dial <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: >> >> Taking a new argument that has a default shouldn't be an issue. +1 >> from me. I assume it is just going to start the count at that number, >> not advance the iterable to that point, right? > > I wonder if it would be best for it to be a keyword-only argument. So > many of the utility functions on iterables are foo(*iterables) that I > might be inclined to think enumerate(foo, bar) is equivalent to > enumerate(chain(foo, bar)), but enumerate(foo, start=bar) is pretty > obvious. And if you consider that the enumeration is prepended to the > values of foo, enumerate(foo, bar) is "backwards." Just saying.. > Sure, making it 'start' or something and having it be keyword-only makes sense. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
On Sun, May 11, 2008 at 6:35 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 6:34 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> On Sun, May 11, 2008 at 6:23 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >>> On Sun, May 11, 2008 at 5:01 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: On Sun, May 11, 2008 at 4:43 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 12:00 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: >> Fred Drake schrieb: >>> >>> On May 10, 2008, at 11:49 PM, Guido van Rossum wrote: Works for me. The other thing I always use from cgi is escape() -- will that be available somewhere else too? >>> >>> >>> xml.sax.saxutils.escape() would be an appropriate replacement, > though the >>> location is a little funky. > > More than a little IMO. :-( > Well, if that function is better than who cares about the location; it will end up in urllib.parse as some function. >>> >>> It's a trivial function; it shouldn't pull in three packages and lots >>> of other cruft. >> >> So are you saying that it isn't that much better in urllib.parse? That >> only cuts the package count down by one. > > I didn't mean to say, but it does seem the wrong module -- escape() is > for HTML, not for URLs. OK. I will only worry about moving cgi.parse_qs() to urllib.parse and cgi.escape() to the html package somewhere (either 'html', 'html.parser' which is currently HTMLParser, or some new module; I prefer the first option). -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How to help out with PEP 3108
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
On Sun, May 11, 2008 at 06:39:02PM -0700, Brett Cannon wrote: > cgi.escape() to the html package somewhere (either 'html', > 'html.parser' which is currently HTMLParser, or some new module; html.parser.escape() seems a bit backward; html.escape() fits the best! Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
On Sun, May 11, 2008 at 6:50 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 06:39:02PM -0700, Brett Cannon wrote: >> cgi.escape() to the html package somewhere (either 'html', >> 'html.parser' which is currently HTMLParser, or some new module; > > html.parser.escape() seems a bit backward; html.escape() fits the best! +1 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
On Mon, May 12, 2008 at 12:21:00PM +1200, Greg Ewing wrote: > Parsing a file and wanting to be able to print > error messages with line numbers would seem to > be a fairly likely use. Couldn't people be using the fileinput module for this, though? --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to help out with PEP 3108
2008/5/11 Brett Cannon <[EMAIL PROTECTED]>: > 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 Hi Brett, I've sent a patch regarding the move of Tkinter to the tkinter package. But I'm in doubt about stub modules for this case, I'm not sure if using lib-old is good for Tkinter specifically, since lib-tk is included in sys.path. How should I proceed on this ? -- -- Guilherme H. Polo Goncalves ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How best to handle the docs for a renamed module?
For the sake of argument, let's consider the Queue module. It is now named queue. For 2.6 I plan on having both Queue and queue listed in the index, with Queue deprecated with instructions to use the new name. But what to do about all the references. Should we leave them pointing at Queue to lessen confusion for people who read about some module on some other site that isn't using the new name, or update everything in 2.6 to use the new name? -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How best to handle the docs for a renamed module?
On a sunny day, Brett Cannon <[EMAIL PROTECTED]> wrote: > For the sake of argument, let's consider the Queue module. It is now > named queue. For 2.6 I plan on having both Queue and queue listed in > the index, with Queue deprecated with instructions to use the new > name. > > But what to do about all the references. Should we leave them pointing > at Queue to lessen confusion for people who read about some module on > some other site that isn't using the new name, or update everything in > 2.6 to use the new name? I'd say use the new names, so people can get used to them sooner -- otherwise all you do is postpone the confusion until they're going to use 3.0. People who've only head of Queue will be fine as long as searching for Queue in the index and TOC will find them a pointer to queue (and that one has a "versionadded 2.6 -- renamed from Queue" note). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How best to handle the docs for a renamed module?
On Sun, May 11, 2008 at 8:17 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On a sunny day, Brett Cannon <[EMAIL PROTECTED]> wrote: >> For the sake of argument, let's consider the Queue module. It is now >> named queue. For 2.6 I plan on having both Queue and queue listed in >> the index, with Queue deprecated with instructions to use the new >> name. >> >> But what to do about all the references. Should we leave them pointing >> at Queue to lessen confusion for people who read about some module on >> some other site that isn't using the new name, or update everything in >> 2.6 to use the new name? > > I'd say use the new names, so people can get used to them sooner -- > otherwise all you do is postpone the confusion until they're going to > use 3.0. People who've only head of Queue will be fine as long as > searching for Queue in the index and TOC will find them a pointer to > queue (and that one has a "versionadded 2.6 -- renamed from Queue" > note). > OK, documented as such. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module
On Sun, May 11, 2008 at 7:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Sun, May 11, 2008 at 6:50 PM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: >> On Sun, May 11, 2008 at 06:39:02PM -0700, Brett Cannon wrote: >>> cgi.escape() to the html package somewhere (either 'html', >>> 'html.parser' which is currently HTMLParser, or some new module; >> >> html.parser.escape() seems a bit backward; html.escape() fits the best! > > +1 Issue 2829 is a bug report for copying cgi.parse_qs() to urllib.parse and 2830 for copying cgi.escape() to html. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding start to enumerate()
Brett Cannon wrote: Sure, making it 'start' or something and having it be keyword-only makes sense. http://bugs.python.org/issue2831 -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
