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
> 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,
Mar
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
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
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 _
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?
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
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 check
-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-r63
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 l
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 actua
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
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 suppos
> 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
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 w
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
* 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
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 essentia
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
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 real
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 ove
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 b
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
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 agre
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,
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 tur
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
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 t
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
34 matches
Mail list logo
