We're working at the sprint on tracking this down. I want to provide some
history first and then what we're looking for feedback on.
Steve Holden found this on Sunday, the pybench try/except test shows a ~60%
slowdown from 2.4.3 to 2.5a2. The original test is, roughly:
for i in range(N):
Sean Reifschneider [EMAIL PROTECTED] writes:
We're working at the sprint on tracking this down. I want to provide some
history first and then what we're looking for feedback on.
Steve Holden found this on Sunday, the pybench try/except test shows a ~60%
slowdown from 2.4.3 to 2.5a2. The
Michael Hudson wrote:
Could it just be that instantiating instances of new-style classes is
slower than instantiating instances of old-style classes? There's not
anything in what you've posted to suggest that exceptions are involved
directly.
python -mtimeit -s class Exception(object): pass
Fredrik Lundh wrote:
Could it just be that instantiating instances of new-style classes is
slower than instantiating instances of old-style classes? There's not
anything in what you've posted to suggest that exceptions are involved
directly.
for completeness, here's the corresponding
On Wed, May 24, 2006 at 11:36:52AM +0100, Michael Hudson wrote:
Could it just be that instantiating instances of new-style classes is
slower than instantiating instances of old-style classes? There's not
anything in what you've posted to suggest that exceptions are involved
directly.
Sorry, I
On 5/23/06, Andrew Dalke [EMAIL PROTECTED] wrote:
Me [Andrew Dalke] said:
The relevant code in stringobject uses PySequence_Fast_GET_ITEM(seq,
i),
which likely doesn't know about my derived __getitem__.
Oops, I didn't know what the code was doing well enough. The
relevant problem is
so, which one is correct ?
Python 2.4.3
.replace(, a)
''
u.replace(u, ua)
u'a'
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
We've done some more research on it, and Richard Jones is working on it
right now. We'll see how it works, probably tomorrow.
Thanks,
Sean
--
If you don't have time to do it right, when will you ever find time to do
it over?
Sean Reifschneider, Member of Technical Staff [EMAIL PROTECTED]
On 5/24/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
so, which one is correct ?
Python 2.4.3
.replace(, a)
''
u.replace(u, ua)
u'a'
Since 'x'.replace('', 'a') and u'x'.replace('', u'a') return 'axa' and
u'axa', respectively, I conclude that the unicode version is correct
and the 8-bit
Ian Bicking wrote:
Phillip J. Eby wrote:
At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote:
I'd like to include paste.lint with that as well (as wsgiref.lint or
whatever). Since the last discussion I enumerated in the docstring all
the checks it does. There's still some outstanding issues,
[/F]
so, which one is correct ?
Python 2.4.3
.replace(, a)
''
u.replace(u, ua)
u'a'
[Greg Ewing]
Probably there shouldn't be any correct in this case,
i.e. the result of replacing an empty string should be
undefined (because any string contains infinitely many
empty substrings).
On 5/24/06, Greg Ewing [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
so, which one is correct ?
Python 2.4.3
.replace(, a)
''
u.replace(u, ua)
u'a'
Probably there shouldn't be any correct in this case,
i.e. the result of replacing an empty string should be
undefined (because
I'd like to point out sf bug #1494314 (
http://sourceforge.net/tracker/index.php?func=detailaid=1494314group_id=5470atid=105470
) as an important one to fix before 2.5. It's clearly a regression and the
fix should be simple (there's a patch on the ticket).
Jean-Paul
13 matches
Mail list logo
