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! wink
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
In any case, I'm willing to give the TLC to convert the whole stdlib
to str.format, so I just need your permission! wink
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,
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
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! wink
Please don't - not before % is actually deprecated
On Tue, Jun 3, 2008 at 3:48 AM, Georg Brandl [EMAIL PROTECTED] wrote:
Antoine Pitrou schrieb:
Guido van Rossum guido at 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
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
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
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
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
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
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
* 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
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
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
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
Benjamin Peterson musiccomposition at gmail.com writes:
On Tue, Jun 3, 2008 at 5:02 PM, Jesse Noller jnoller at 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
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
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
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
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
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
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
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
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
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
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.
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.
27 matches
Mail list logo
