Re: [Python-Dev] converting the stdlib to str.format
Martin v. Löwis schrieb: In any case, I'm willing to give the TLC to convert the whole stdlib to str.format, so I just need your permission! Please don't - not before % is actually deprecated (which I hope won't happen until Python 4, with removal of % in Python 5, in the year when I retire, i.e. 2037). Now this is news to me -- was there a discussion that changed the lifetime expectancy of str.__mod__? I'd always supposed it being deprecated at some point in 3.x. Not that I'm opposed to keeping it... it *will* be a pain to migrate. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] converting the stdlib to str.format
> In any case, I'm willing to give the TLC to convert the whole stdlib > to str.format, so I just need your permission! Please don't - not before % is actually deprecated (which I hope won't happen until Python 4, with removal of % in Python 5, in the year when I retire, i.e. 2037). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] converting the stdlib to str.format
Georg Brandl wrote: Martin v. Löwis schrieb: In any case, I'm willing to give the TLC to convert the whole stdlib to str.format, so I just need your permission! Please don't - not before % is actually deprecated (which I hope won't happen until Python 4, with removal of % in Python 5, in the year when I retire, i.e. 2037). Now this is news to me -- was there a discussion that changed the lifetime expectancy of str.__mod__? I'd always supposed it being deprecated at some point in 3.x. Not that I'm opposed to keeping it... it *will* be a pain to migrate. Guido has previously said he wouldn't mind adding a PendingDeprecationWarning to %-formatting in 3.0. I've attempted to do that in http://bugs.python.org/issue2772. For a reason I don't understand, my change broke test_doctest.py, so I've never applied it. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mini-Pep: An Empty String ABC
Raymond Hettinger rcn.com> writes: > > By subclassing Sequence, we get index() and count() mixins for free. > It seems to me that Sequence.index()/count() and String.index()/count() shouldn't have the same semantics. In the former case they search for items in the Sequence, in the latter case they search for substrings of the String. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mini-Pep: An Empty String ABC
From: "Antoine Pitrou" <[EMAIL PROTECTED]> It seems to me that Sequence.index()/count() and String.index()/count() shouldn't have the same semantics. In the former case they search for items in the Sequence, in the latter case they search for substrings of the String. And the same applies to __contains__(). Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
Guido van Rossum python.org> writes: > I'd prefer the 2.6 code base to > stay true to 2.x, and the 3.0 code base start afresh where it makes > sense. We should reindent more of the 3.0 code base to use > 4-space-indents in C code too. Is there any reason reindenting shouldn't be done for 2.6 too? (apart from "staying true to 2.x" :-)) Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
Antoine Pitrou schrieb: Guido van Rossum python.org> writes: I'd prefer the 2.6 code base to stay true to 2.x, and the 3.0 code base start afresh where it makes sense. We should reindent more of the 3.0 code base to use 4-space-indents in C code too. Is there any reason reindenting shouldn't be done for 2.6 too? (apart from "staying true to 2.x" :-)) It would make svn blame useless, for a start. (SVN could really use a feature to exclude certain revisions from showing up in svn blame.) Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Missing checkin emails
Did some checkin emails get lost yesterday? I didn't see mail for a checkin of mine, r63895. Looking at http://mail.python.org/pipermail/python-checkins/2008-June/date.html, it looks like r63887-r63898 are missing from the archive, too. We should probably make an effort to review those checkins. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Missing checkin emails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 3, 2008, at 6:55 AM, Eric Smith wrote: Did some checkin emails get lost yesterday? I didn't see mail for a checkin of mine, r63895. Looking at http://mail.python.org/pipermail/python-checkins/2008-June/date.html , it looks like r63887-r63898 are missing from the archive, too. We should probably make an effort to review those checkins. mail.python.org had problems yesterday, so if the mail client doesn't resend, it's very possible that messages got lost. Everything is back to normal now. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSEUsKnEjvBPtnXfVAQKPbwP+MQGUbxyydoa0OAwMM58mS1IhzLubwCpy IUd5AQulh4FPRLn04CdOQQzYlmOJg9gtkQUIlQx4iiap75H4QqM91ubSdEnzPrPH vUXIXvnujKLwEZ4PN08ZQJffp7o5w8ARLso9U0ttYAtlXjx4QYEmxpyKVVe/V/dB zemVnvW4qfE= =eojc -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Missing checkin emails
Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 3, 2008, at 6:55 AM, Eric Smith wrote: Did some checkin emails get lost yesterday? I didn't see mail for a checkin of mine, r63895. Looking at http://mail.python.org/pipermail/python-checkins/2008-June/date.html, it looks like r63887-r63898 are missing from the archive, too. We should probably make an effort to review those checkins. mail.python.org had problems yesterday, so if the mail client doesn't resend, it's very possible that messages got lost. Everything is back to normal now. Thanks, Barry. Does anyone know if we can force svn to resend the checkin notifications for that range? It also looks like r63862 and r63915 are missing. I haven't done an exhaustive analysis of what is and isn't present (I also don't know if it's normal for revisions to be missing). Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] converting the stdlib to str.format
On Tue, Jun 3, 2008 at 2:03 AM, Eric Smith <[EMAIL PROTECTED]> wrote: > Georg Brandl wrote: >> >> Martin v. Löwis schrieb: In any case, I'm willing to give the TLC to convert the whole stdlib to str.format, so I just need your permission! >>> >>> Please don't - not before % is actually deprecated (which I hope won't >>> happen until Python 4, with removal of % in Python 5, in the year >>> when I retire, i.e. 2037). >> >> Now this is news to me -- was there a discussion that changed the >> lifetime expectancy of str.__mod__? I'd always supposed it being >> deprecated at some point in 3.x. I think Martin was attempting humor. :-) There's widespread disagreement on when we should retire %. >> Not that I'm opposed to keeping it... it *will* be a pain to migrate. > > Guido has previously said he wouldn't mind adding a > PendingDeprecationWarning to %-formatting in 3.0. I've attempted to do that > in http://bugs.python.org/issue2772. For a reason I don't understand, my > change broke test_doctest.py, so I've never applied it. For 3.0, it should be at best a SilentDeprecationWarning. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On Tue, Jun 3, 2008 at 3:48 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Antoine Pitrou schrieb: >> >> Guido van Rossum python.org> writes: >>> >>> I'd prefer the 2.6 code base to >>> stay true to 2.x, and the 3.0 code base start afresh where it makes >>> sense. We should reindent more of the 3.0 code base to use >>> 4-space-indents in C code too. >> >> Is there any reason reindenting shouldn't be done for 2.6 too? >> (apart from "staying true to 2.x" :-)) > > It would make svn blame useless, for a start. > > (SVN could really use a feature to exclude certain revisions from > showing up in svn blame.) What he said. And "staying true to 2.x" is not a bad rationale. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On 2008-06-03 01:09, Guido van Rossum wrote: I will freely admit that I haven't followed this thread in any detail, but if it were up to me, I'd have the 2.6 internal code use PyString (as both what the linker sees and what the human reads in the source code) and the 3.0 code use PyBytes for the same thing. Let the merges be damed -- most changes to 2.6 these days seem to be blocked explicitly from being merged anyway. I'd prefer the 2.6 code base to stay true to 2.x, and the 3.0 code base start afresh where it makes sense. We should reindent more of the 3.0 code base to use 4-space-indents in C code too. I would also add macros that map the PyBytes_* APIs to PyString_*, but I would not start using these internally except in code newly written for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString for 8-bit strings containing text, and PyBytes for 8-bit strings containing binary data. For 8-bit strings that could contain either text or data, I'd use PyString, in the spirit of 2.x. +1 Let's work on better merge tools that edit the trunk code base into shape for a 3.x checkin. Using automated tools for this is likely going to lower the probability of bugs introduced due to unnoticed merge conflicts and in the end is also going to be a benefit to everyone wanting to maintain a single code base for both targets. Perhaps we could revive the old Tools/scripts/fixcid.py that was used for the 1.4->1.5 renaming ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 03 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2008-07-07: EuroPython 2008, Vilnius, Lithuania33 days to go Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] converting the stdlib to str.format
>> Please don't - not before % is actually deprecated (which I hope won't >> happen until Python 4, with removal of % in Python 5, in the year >> when I retire, i.e. 2037). > > Now this is news to me -- was there a discussion that changed the > lifetime expectancy of str.__mod__? I'd always supposed it being > deprecated at some point in 3.x. The PEP doesn't specify anything, and I don't recall any discussion, either - the specific timing suggested above is merely my own hopes. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Missing checkin emails
> Does anyone know if we can force svn to resend the checkin notifications > for that range? It also looks like r63862 and r63915 are missing. I > haven't done an exhaustive analysis of what is and isn't present (I also > don't know if it's normal for revisions to be missing). I just resent the range that you indicated (r63887-r63898, inclusive). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Postponing the first betas
On 02/06/2008, Barry Warsaw <[EMAIL PROTECTED]> wrote: > meantime, Guido said: > > "I'd also like to see PEP 3138 (CJK-friendly repr()) and the > pyprocessing PEP implemented by then, and perhaps some other small > stuff." The pyprocessing unit tests crash with a fatal error when run on Linux with a debug version of the interpreter. This is because the GILState stuff is not fork aware. I submitted a patch some months ago: http://bugs.python.org/issue1683 Could somebody review it please. Cheers, Richard. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 371: Additional Discussion
Per feedback from Guido, the python-dev list and others, I have sent in an updated version of PEP 371 - the inclusion of the pyprocessing module into the standard library. URL: http://www.python.org/dev/peps/pep-0371/ New highlights: * The module will be renamed to "multiprocessing" * The API will become PEP 8 compliant * Additional Benchmark data added (thanks Alec!) * Additional grammar and terminology changes Please review the new more final draft of the PEP and send out suggestions and feedback. It looks like this is on the slate for 2.6b1 and 3.0b1 so the sooner we get feedback, the better. -Jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
2008/6/3 Jesse Noller <[EMAIL PROTECTED]>: > Per feedback from Guido, the python-dev list and others, I have sent > in an updated version of PEP 371 - the inclusion of the pyprocessing > module into the standard library. > > URL: http://www.python.org/dev/peps/pep-0371/ > > New highlights: > * The module will be renamed to "multiprocessing" > * The API will become PEP 8 compliant Doesn't that kill the intent that it's a drop-in replacement for threading? I'd say don't do this unless threading is made PEP 8 compliant as well. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
* The API will become PEP 8 compliant Doesn't that kill the intent that it's a drop-in replacement for threading? IMO, it is essential that the API match the theading module, PEP 8 be damned. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
What about also including a patch to fix the threading api to be pep 8 compliant? On Jun 3, 2008, at 5:43 PM, "Raymond Hettinger" <[EMAIL PROTECTED]> wrote: * The API will become PEP 8 compliant Doesn't that kill the intent that it's a drop-in replacement for threading? IMO, it is essential that the API match the theading module, PEP 8 be damned. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
On Tue, Jun 3, 2008 at 5:02 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: > What about also including a patch to fix the threading api to be pep 8 > compliant? I doubt that will be accepted because of the closeness threading has to Java's APIs. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
Also - we could leave in stubs to match the threading api - Guido, David Goodger and others really prefer not to continue the "broken" API of the threading API On Jun 3, 2008, at 5:43 PM, "Raymond Hettinger" <[EMAIL PROTECTED]> wrote: * The API will become PEP 8 compliant Doesn't that kill the intent that it's a drop-in replacement for threading? IMO, it is essential that the API match the theading module, PEP 8 be damned. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
Benjamin Peterson gmail.com> writes: > On Tue, Jun 3, 2008 at 5:02 PM, Jesse Noller gmail.com> wrote: > > What about also including a patch to fix the threading api to be pep 8 > > compliant? > > I doubt that will be accepted because of the closeness threading has > to Java's APIs. Is this really a serious concern for some people? If you come from the Java world and are learning Python, I suppose there are things more difficult to assimilate than the change in method naming style... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
On Tue, Jun 3, 2008 at 3:08 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: > Also - we could leave in stubs to match the threading api - Guido, David > Goodger and others really prefer not to continue the "broken" API of the > threading API > +1 from me. Gives a transition plan for people to move over to the new API. -Brett > On Jun 3, 2008, at 5:43 PM, "Raymond Hettinger" <[EMAIL PROTECTED]> wrote: > * The API will become PEP 8 compliant >>> >>> Doesn't that kill the intent that it's a drop-in replacement for >>> threading? >> >> IMO, it is essential that the API match the theading module, PEP 8 be >> damned. >> >> >> Raymond >> >> > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
On Tue, Jun 3, 2008 at 5:08 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: > Also - we could leave in stubs to match the threading api - Guido, David > Goodger and others really prefer not to continue the "broken" API of the > threading API I agree that the threading the the pyprocessing APIs should be PEP 8 compliant, but I think 2 APIs is almost worse than one wrong one. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
On Tue, Jun 3, 2008 at 3:53 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 5:08 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: >> Also - we could leave in stubs to match the threading api - Guido, David >> Goodger and others really prefer not to continue the "broken" API of the >> threading API > I agree that the threading the the pyprocessing APIs should be PEP 8 > compliant, but I think 2 APIs is almost worse than one wrong one. > I disagree. If you state upfront that one of them is only for backwards-compatibility/transitioning and will be going away in the future, then I think it is fine to have the extra API. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
On 3-Jun-08, at 3:53 PM, Benjamin Peterson wrote: On Tue, Jun 3, 2008 at 5:08 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: Also - we could leave in stubs to match the threading api - Guido, David Goodger and others really prefer not to continue the "broken" API of the threading API I agree that the threading the the pyprocessing APIs should be PEP 8 compliant, but I think 2 APIs is almost worse than one wrong one. A cleaner way to effectuate the transition would be to leave the camelCase API in 2.6 (for both modules), switch to PEP 8 in py3k (for both modules), and provide threading3k and multiprocessing3k modules in 2.6 that façade the 2.6 API with the PEP 8 API. 2to3 would rewrite 'import threading3k' to 'import threading' and everything would work (it would warn about 'import threading' in 2.6 code). -Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
On Tue, Jun 3, 2008 at 6:00 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 3:53 PM, Benjamin Peterson > <[EMAIL PROTECTED]> wrote: >> On Tue, Jun 3, 2008 at 5:08 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: >>> Also - we could leave in stubs to match the threading api - Guido, David >>> Goodger and others really prefer not to continue the "broken" API of the >>> threading API >> I agree that the threading the the pyprocessing APIs should be PEP 8 >> compliant, but I think 2 APIs is almost worse than one wrong one. >> > > I disagree. If you state upfront that one of them is only for > backwards-compatibility/transitioning and will be going away in the > future, then I think it is fine to have the extra API. In that case, I'm +1 as long as we implement a full DeprecationWarning on one. > > -Brett > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
I'm curious why people thing that strict API compatibility is important at all. In my view, having the APIs be similar is really helpful because it helps people quickly understand what you can do with the new module. But I honestly don't expect anyone to take an existing app using threading and turning it into one using multiprocessing by changing a single line. There are too many things that threads let you do that aren't supported by processes (e.g. shared mutable objects protected by locks). IMO the multiprocessing module should only provide a PEP-8-compliant API, and optionally we could start adding such an API to the threading module. Strict compatibility with the Java API really isn't important there either -- that's just how I got started with it, and I gladly admit I went overboard there. --Guido On Tue, Jun 3, 2008 at 4:01 PM, Mike Klaas <[EMAIL PROTECTED]> wrote: > > On 3-Jun-08, at 3:53 PM, Benjamin Peterson wrote: > >> On Tue, Jun 3, 2008 at 5:08 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: >>> >>> Also - we could leave in stubs to match the threading api - Guido, David >>> Goodger and others really prefer not to continue the "broken" API of the >>> threading API >> >> I agree that the threading the the pyprocessing APIs should be PEP 8 >> compliant, but I think 2 APIs is almost worse than one wrong one. > > A cleaner way to effectuate the transition would be to leave the camelCase > API in 2.6 (for both modules), switch to PEP 8 in py3k (for both modules), > and provide threading3k and multiprocessing3k modules in 2.6 that façade the > 2.6 API with the PEP 8 API. > > 2to3 would rewrite 'import threading3k' to 'import threading' and everything > would work (it would warn about 'import threading' in 2.6 code). > > -Mike > ___ > Python-Dev mailing list > Python-Dev@python.org > 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
I think its a small disaster to have the APIs be almost the same but with trivial differences in spelling. PEP 8 is a nice guideline but it seems to have become an end in an of itself. The point of the PEP is to use consistency as a memory cue, but having two sets of method names that are almost parallel but spelled differently is at odds with that goal. Moving both modules to PEP 8 compliance makes more sense, but I would hope that gets left for Py3.0. There's too much existing code, too many existing tutorials, and too many hardcopy books already in Py2.x. Raymond - Original Message - From: "Guido van Rossum" <[EMAIL PROTECTED]> To: "Mike Klaas" <[EMAIL PROTECTED]> Cc: Sent: Tuesday, June 03, 2008 4:21 PM Subject: Re: [Python-Dev] PEP 371: Additional Discussion I'm curious why people thing that strict API compatibility is important at all. In my view, having the APIs be similar is really helpful because it helps people quickly understand what you can do with the new module. But I honestly don't expect anyone to take an existing app using threading and turning it into one using multiprocessing by changing a single line. There are too many things that threads let you do that aren't supported by processes (e.g. shared mutable objects protected by locks). IMO the multiprocessing module should only provide a PEP-8-compliant API, and optionally we could start adding such an API to the threading module. Strict compatibility with the Java API really isn't important there either -- that's just how I got started with it, and I gladly admit I went overboard there. --Guido On Tue, Jun 3, 2008 at 4:01 PM, Mike Klaas <[EMAIL PROTECTED]> wrote: On 3-Jun-08, at 3:53 PM, Benjamin Peterson wrote: On Tue, Jun 3, 2008 at 5:08 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: Also - we could leave in stubs to match the threading api - Guido, David Goodger and others really prefer not to continue the "broken" API of the threading API I agree that the threading the the pyprocessing APIs should be PEP 8 compliant, but I think 2 APIs is almost worse than one wrong one. A cleaner way to effectuate the transition would be to leave the camelCase API in 2.6 (for both modules), switch to PEP 8 in py3k (for both modules), and provide threading3k and multiprocessing3k modules in 2.6 that façade the 2.6 API with the PEP 8 API. 2to3 would rewrite 'import threading3k' to 'import threading' and everything would work (it would warn about 'import threading' in 2.6 code). -Mike ___ Python-Dev mailing list Python-Dev@python.org 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python%40rcn.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
From: "Mike Klaas" <[EMAIL PROTECTED]> A cleaner way to effectuate the transition would be to leave the camelCase API in 2.6 (for both modules), switch to PEP 8 in py3k (for both modules) +1 That makes good sense. , and provide threading3k and multiprocessing3k modules in 2.6 that façade the 2.6 API with the PEP 8 API. +0 PEP 8 is nice but it's not that important. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
Benjamin Peterson wrote: I agree that the threading the the pyprocessing APIs should be PEP 8 compliant, but I think 2 APIs is almost worse than one wrong one. So change them both to be PEP 8 compliant, and leave aliases in both for existing code to use. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
On Tue, Jun 3, 2008 at 6:48 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I think its a small disaster to have the APIs be almost > the same but with trivial differences in spelling. Strong words -- and it now seems just your gut feelings against mine. I have come to trust mine quite a bit. > PEP 8 is a nice guideline but it seems to have become > an end in an of itself. The point of the PEP is to use > consistency as a memory cue, but having two sets of > method names that are almost parallel but spelled > differently is at odds with that goal. PEP 8 helps by making exact method spellings easier to remember. The recommendation against abbreviations also comes from this goal. It should be used for all new APIs. (Except of course when adding to a set of existing APIs that use a different convention.) I consider multiprocessing a new API -- while it bears a superficial resemblance with the threading API the similarities are just that, and it should not be constrained by mistakes in that API. > Moving both modules to PEP 8 compliance makes more > sense, but I would hope that gets left for Py3.0. There's > too much existing code, too many existing tutorials, and > too many hardcopy books already in Py2.x. It was decided not to "fix" APIs for Py3k beyond the module naming issue. We can add a new PEP-8-compliant API to the threading module in 3.0 but the old API should stay for another release or more. I'm neutral on whether it makes sense to backport the new threading.py APIs to 2.6. --Guido > Raymond > > > - Original Message - From: "Guido van Rossum" <[EMAIL PROTECTED]> > To: "Mike Klaas" <[EMAIL PROTECTED]> > Cc: > Sent: Tuesday, June 03, 2008 4:21 PM > Subject: Re: [Python-Dev] PEP 371: Additional Discussion > > > I'm curious why people thing that strict API compatibility is > important at all. In my view, having the APIs be similar is really > helpful because it helps people quickly understand what you can do > with the new module. But I honestly don't expect anyone to take an > existing app using threading and turning it into one using > multiprocessing by changing a single line. There are too many things > that threads let you do that aren't supported by processes (e.g. > shared mutable objects protected by locks). > > IMO the multiprocessing module should only provide a PEP-8-compliant > API, and optionally we could start adding such an API to the threading > module. Strict compatibility with the Java API really isn't important > there either -- that's just how I got started with it, and I gladly > admit I went overboard there. > > --Guido > > On Tue, Jun 3, 2008 at 4:01 PM, Mike Klaas <[EMAIL PROTECTED]> wrote: >> >> On 3-Jun-08, at 3:53 PM, Benjamin Peterson wrote: >> >>> On Tue, Jun 3, 2008 at 5:08 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: Also - we could leave in stubs to match the threading api - Guido, David Goodger and others really prefer not to continue the "broken" API of the threading API >>> >>> I agree that the threading the the pyprocessing APIs should be PEP 8 >>> compliant, but I think 2 APIs is almost worse than one wrong one. >> >> A cleaner way to effectuate the transition would be to leave the camelCase >> API in 2.6 (for both modules), switch to PEP 8 in py3k (for both modules), >> and provide threading3k and multiprocessing3k modules in 2.6 that façade >> the >> 2.6 API with the PEP 8 API. >> >> 2to3 would rewrite 'import threading3k' to 'import threading' and >> everything >> would work (it would warn about 'import threading' in 2.6 code). >> >> -Mike >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> 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 > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/python%40rcn.com > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 371: Additional Discussion
On Tue, Jun 3, 2008 at 6:56 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > From: "Mike Klaas" <[EMAIL PROTECTED]> >> >> A cleaner way to effectuate the transition would be to leave >> the camelCase API in 2.6 (for both modules), switch to PEP 8 >> in py3k (for both modules) > > +1 > That makes good sense. No. It makes *no* sense to introduce a new API in 2.6 and change it again in 3.0. That sounds like another foolish consistency. >> , and provide threading3k and multiprocessing3k modules in 2.6 that >> façade the 2.6 API with the PEP 8 API. > > +0 > PEP 8 is nice but it's not that important. > > > Raymond > ___ > Python-Dev mailing list > Python-Dev@python.org > 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
