On Sat, Nov 26, 2011 at 6:39 AM, Nick Coghlan wrote:
> On Sat, Nov 26, 2011 at 8:14 AM, Michael Foord
> wrote:
>>
>> On 24 Nov 2011, at 04:06, Nick Coghlan wrote:
>>
>>> On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote:
Mea culpa for not keeping track, but what's the status of PEP 3
On Sat, Nov 26, 2011 at 3:14 PM, Raymond Hettinger
wrote:
>
> On Nov 25, 2011, at 6:18 PM, Jesus Cea wrote:
>
> On 12/11/11 16:56, Éric Araujo wrote:
>
> Ezio and I chatted a bit about his on IRC and he may try to write
>
> a Python parser for Misc/NEWS in order to write a fully automated
>
> merg
On Nov 25, 2011, at 6:18 PM, Jesus Cea wrote:
> On 12/11/11 16:56, Éric Araujo wrote:
>> Ezio and I chatted a bit about his on IRC and he may try to write
>> a Python parser for Misc/NEWS in order to write a fully automated
>> merge tool.
>
> Anything new in this front? :-)
To me, it would make
On Sat, Nov 26, 2011 at 8:14 AM, Michael Foord
wrote:
>
> On 24 Nov 2011, at 04:06, Nick Coghlan wrote:
>
>> On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote:
>>> Mea culpa for not keeping track, but what's the status of PEP 380? I
>>> really want this in Python 3.3!
>>
>> There are two r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/11/11 16:56, Éric Araujo wrote:
> Ezio and I chatted a bit about his on IRC and he may try to write
> a Python parser for Misc/NEWS in order to write a fully automated
> merge tool.
Anything new in this front? :-)
- --
Jesus Cea Avion
On 24 Nov 2011, at 04:06, Nick Coghlan wrote:
> On Thu, Nov 24, 2011 at 10:28 AM, Guido van Rossum wrote:
>> Mea culpa for not keeping track, but what's the status of PEP 380? I
>> really want this in Python 3.3!
>
> There are two relevant tracker issues (both with me for the moment).
>
> The
2011/11/25 Brett Cannon
>
>
> On Thu, Nov 24, 2011 at 07:46, Nick Coghlan wrote:
>
>> On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski
>> wrote:
>> > The problem is not with maintaining the modified directory. The
>> > problem was always things like changing interface between the C
>> > ver
On Fri, 25 Nov 2011 12:37:59 -0500
Brett Cannon wrote:
> On Thu, Nov 24, 2011 at 07:46, Nick Coghlan wrote:
>
> > On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski
> > wrote:
> > > The problem is not with maintaining the modified directory. The
> > > problem was always things like changing i
On Thu, Nov 24, 2011 at 07:46, Nick Coghlan wrote:
> On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski
> wrote:
> > The problem is not with maintaining the modified directory. The
> > problem was always things like changing interface between the C
> > version and the Python version or introdu
ACTIVITY SUMMARY (2011-11-18 - 2011-11-25)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3134 (+19)
closed 22128 (+31)
total 25262 (+50)
Open issues wit
On 25/11/2011 15:48, Paul Moore wrote:
On 25 November 2011 15:07, Amaury Forgeot d'Arc wrote:
2011/11/25 Paul Moore
It would be nice to have the optimisation back if it's easy enough to
do so, for quick-and-dirty code, but it is not a good idea to rely on
it (and it's especially unwise to base
On 25 November 2011 15:07, Amaury Forgeot d'Arc wrote:
> 2011/11/25 Paul Moore
>> It would be nice to have the optimisation back if it's easy enough to
>> do so, for quick-and-dirty code, but it is not a good idea to rely on
>> it (and it's especially unwise to base benchmarks on it working :-))
On Fri, Nov 25, 2011, Jesus Cea wrote:
>
> When mailing there, I get this error. Not sure where to report.
>
> """
> Final-Recipient: rfc822; sdr...@sdrees.de
> Original-Recipient: rfc822;webmas...@python.org
> Action: failed
> Status: 5.1.1
> Remote-MTA: dns; stefan.zinzdrees.de
> Diagnostic-Code
2011/11/25 Paul Moore
> The optimisation mentioned was an attempt (by mutating an existing
> string when the runtime determined that it was safe to do so) to hide
> the consequences of this fact from end-users who didn't fully
> understand the issues. It was relatively effective, but like any suc
On 25 November 2011 11:37, Matt Joiner wrote:
>> No "wtf" here, the read() loop is quadratic since you're building a
>> new, larger, bytes object every iteration. Python 2 has a fragile
>> optimization for concatenation of strings, which can avoid the
>> quadratic behaviour on some systems (depen
On Fri, 25 Nov 2011 22:37:49 +1100
Matt Joiner wrote:
> On Fri, Nov 25, 2011 at 10:04 PM, Antoine Pitrou wrote:
> > On Fri, 25 Nov 2011 20:34:21 +1100
> > Matt Joiner wrote:
> >>
> >> It's Python 3.2. I tried it for larger files and got some interesting
> >> results.
> >>
> >> readinto() for 10
On Fri, Nov 25, 2011 at 14:02, Matt Joiner wrote:
> I was under the impression this is already in 3.3?
>
Sure, but 3.3 wasn't released yet.
Eli
P.S. Top-posting again ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
I was under the impression this is already in 3.3?
On Nov 25, 2011 10:58 PM, "Eli Bendersky" wrote:
>
>
>> > However, the original question remains - on the 100MB file also,
although
>> > in 2.7 readinto is 35% faster than readandcopy(), on 3.2 it's about the
>> > same speed (even a few % slower)
> > However, the original question remains - on the 100MB file also, although
> > in 2.7 readinto is 35% faster than readandcopy(), on 3.2 it's about the
> > same speed (even a few % slower). That said, I now observe with Python
> 3.3
> > the same speed as with 2.7, including the readinto() speedup
On Fri, Nov 25, 2011 at 10:04 PM, Antoine Pitrou wrote:
> On Fri, 25 Nov 2011 20:34:21 +1100
> Matt Joiner wrote:
>>
>> It's Python 3.2. I tried it for larger files and got some interesting
>> results.
>>
>> readinto() for 10MB files, reading 10MB all at once:
>>
>> readinto/2.7 100 loops, best
You can see in the tests on the largest buffer size tested, 8192, that
the naive "read" actually outperforms readinto(). It's possibly by
extrapolating into significantly larger buffer sizes that readinto()
gets left behind. It's also reasonable to assume that this wasn't
tested thoroughly.
On Fri
On Fri, 25 Nov 2011 20:34:21 +1100
Matt Joiner wrote:
>
> It's Python 3.2. I tried it for larger files and got some interesting results.
>
> readinto() for 10MB files, reading 10MB all at once:
>
> readinto/2.7 100 loops, best of 3: 8.6 msec per loop
> readinto/3.2 10 loops, best of 3: 29.6 mse
On Fri, 25 Nov 2011 08:38:48 +0200
Eli Bendersky wrote:
>
> Just to be clear, there were two separate issues raised here. One is the
> speed regression of readinto() from 2.7 to 3.2, and the other is the
> relative slowness of justread() in 3.3
>
> Regarding the second, I'm not sure it's an issu
On Fri, Nov 25, 2011 at 5:41 PM, Eli Bendersky wrote:
>> Eli, the use pattern I was referring to is when you read in chunks,
>> and and append to a running buffer. Presumably if you know in advance
>> the size of the data, you can readinto directly to a region of a
>> bytearray. There by avoiding
Dnia 25-11-2011 o godz. 1:01 Jesus Cea napisał(a):
>
> PS: The devguide doesn't say anything (AFAIK) about the contributor
> agreement.
There is info in the Contributing part of the devguide,
follow How to Become a Core Developer link which points to
http://docs.python.org/devguide/coredev.html
25 matches
Mail list logo
