Zitat von Terry Reedy :
I was and am posting here in response to a certain French writer who
dislikes the fact that 3.3 unicode favors text written with the
first 256 code points, which do not include all the characters
needed for French, and do not include the euro symbol invented years
On 8/21/2012 9:04 AM, Victor Stinner wrote:
2012/8/18 Terry Reedy :
The issue came up in python-list about string operations being slower in
3.3. (The categorical claim is false as some things are actually faster.)
Yes, some operations are slower, but others are faster :-)
Yes, that is what
On 19.08.12 00:17, Terry Reedy wrote:
This is one of the 3.3 improvements. But since the results are equal:
('a'*1000).encode() == ('a'*1000).encode(encoding='utf-8')
and 3.3 should know that for an all-ascii string, I do not see why
adding the parameter should double the the time. Another issue
On Wed, 22 Aug 2012 03:25:21 +1000
Steven D'Aprano wrote:
> On 21/08/12 23:04, Victor Stinner wrote:
>
> > I don't like the timeit module for micro benchmarks, it is really
> > unstable (default settings are not written for micro benchmarks).
> [...]
> > I wrote my own benchmark tool, based on ti
On Tue, Aug 21, 2012 at 1:56 PM, Xavier Morel wrote:
> As a side-note, every time I use timeit programmatically, it annoys me that
> this behavior is not available and has to be implemented manually.
You are not alone:
http://bugs.python.org/issue6422
___
Xavier Morel, 21.08.2012 19:56:
> On 21 août 2012, at 19:25, Steven D'Aprano wrote:
>> On 21/08/12 23:04, Victor Stinner wrote:
>>> I don't like the timeit module for micro benchmarks, it is really
>>> unstable (default settings are not written for micro benchmarks).
>> [...]
>>> I wrote my own be
On 21 août 2012, at 19:25, Steven D'Aprano wrote:
> On 21/08/12 23:04, Victor Stinner wrote:
>
>> I don't like the timeit module for micro benchmarks, it is really
>> unstable (default settings are not written for micro benchmarks).
> [...]
>> I wrote my own benchmark tool, based on timeit, to ha
On 21/08/12 23:04, Victor Stinner wrote:
I don't like the timeit module for micro benchmarks, it is really
unstable (default settings are not written for micro benchmarks).
[...]
I wrote my own benchmark tool, based on timeit, to have more stable
results on micro benchmarks:
https://bitbucket.
On Tue, 21 Aug 2012 17:20:14 +0200
Andrea Griffini wrote:
> > My benchmark.py script calibrates automatically the number of loops to
> > take at least 100 ms, and then repeat the test during at least 1.0
> > second.
> >
> > Using time instead of a fixed number of loops is more reliable because
> >
print(timeit("c in a", "c = '…'; a = 'a'*1000+c")) # ord(c) = 8230
I'm not sure that I read your benchmark correctly: you write c='...'
Apparenly you didn't - or your MUA was not able to display it
correctly. He didn't say
'...' # U+002E U+002E U+002E, 3x FULL STOP
but
'…' # U+2026, HORIZ
> My benchmark.py script calibrates automatically the number of loops to
> take at least 100 ms, and then repeat the test during at least 1.0
> second.
>
> Using time instead of a fixed number of loops is more reliable because
> the test is less dependent on the system activity.
I've also been bit
2012/8/18 Terry Reedy :
> The issue came up in python-list about string operations being slower in
> 3.3. (The categorical claim is false as some things are actually faster.)
Yes, some operations are slower, but others are faster :-) There was
an important effort to limit the overhead of the PEP 3
Wiadomość napisana przez Antoine Pitrou w dniu 18 sie
2012, o godz. 23:27:
> On Sat, 18 Aug 2012 17:17:14 -0400
> Terry Reedy wrote:
>> The issue came up in python-list about string operations being slower in
>> 3.3. (The categorical claim is false as some things are actually
>> faster.) Some
On 8/18/2012 5:27 PM, Antoine Pitrou wrote:
On Sat, 18 Aug 2012 17:17:14 -0400
Terry Reedy wrote:
The issue came up in python-list about string operations being slower in
3.3. (The categorical claim is false as some things are actually
faster.) Some things I understand, this one I do not.
Win7
On Sat, 18 Aug 2012 17:17:14 -0400, Terry Reedy wrote:
> print(timeit("a.encode()", "a = 'a'*1000"))
> # 1.5 in 3.2, .26 in 3.3
>
> print(timeit("a.encode(encoding='utf-8')", "a = 'a'*1000"))
> # 1.7 in 3.2, .51 in 3.3
>
> This is one of the 3.3 improvements. But since the results are equal:
> (
Zitat von Terry Reedy :
Is this worth a tracker issue (I searched and could not find one) or
is there a known and un-fixable cause?
There is a third option: it's not known, but it's also unimportant.
I'd say posting it to python-dev is enough: either there is somebody
with sufficient time an
On Sat, 18 Aug 2012 17:17:14 -0400
Terry Reedy wrote:
> The issue came up in python-list about string operations being slower in
> 3.3. (The categorical claim is false as some things are actually
> faster.) Some things I understand, this one I do not.
>
> Win7-64, 3.3.0b2 versus 3.2.3
> print(t
The issue came up in python-list about string operations being slower in
3.3. (The categorical claim is false as some things are actually
faster.) Some things I understand, this one I do not.
Win7-64, 3.3.0b2 versus 3.2.3
print(timeit("c in a", "c = '…'; a = 'a'*1000+c")) # ord(c) = 8230
# .6
18 matches
Mail list logo
