On 07.04.13 00:24, Chris Angelico wrote:
On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka storch...@gmail.com wrote:
See also the discussion at
http://comments.gmane.org/gmane.comp.python.ideas/15640 . I agree with
rejection. This is an implementation detail and different Python
implementations
On Sat, 06 Apr 2013 19:58:02 -0600, Ian Kelly wrote:
On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
For some definition of easily.
if implementation == CPython:
if version 3.3:
if sys.maxunicode exists:
use it to decide
On 06/04/2013 22:24, Chris Angelico wrote:
On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka storch...@gmail.com wrote:
04.04.13 00:57, Chris Angelico написав(ла):
http://bugs.python.org/issue17629 opened.
See also the discussion at
http://comments.gmane.org/gmane.comp.python.ideas/15640 . I
04.04.13 00:57, Chris Angelico написав(ла):
On Thu, Apr 4, 2013 at 2:07 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Thu, 04 Apr 2013 01:17:28 +1100, Chris Angelico wrote:
Probably, but it still has to scan the body of the string. It'd not be
too bad if it's all astral,
On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka storch...@gmail.com wrote:
04.04.13 00:57, Chris Angelico написав(ла):
http://bugs.python.org/issue17629 opened.
See also the discussion at
http://comments.gmane.org/gmane.comp.python.ideas/15640 . I agree with
rejection. This is an
On 04/06/2013 02:24 PM, Chris Angelico wrote:
On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka storch...@gmail.com wrote:
04.04.13 00:57, Chris Angelico написав(ла):
http://bugs.python.org/issue17629 opened.
See also the discussion at
http://comments.gmane.org/gmane.comp.python.ideas/15640
On Sat, 06 Apr 2013 14:58:23 -0700, Ethan Furman wrote:
On 04/06/2013 02:24 PM, Chris Angelico wrote:
On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka storch...@gmail.com
wrote:
04.04.13 00:57, Chris Angelico написав(ла):
http://bugs.python.org/issue17629 opened.
See also the discussion
On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
For some definition of easily.
if implementation == CPython:
if version 3.3:
if sys.maxunicode exists:
use it to decide whether this is a wide or narrow build
if
On Sat, Apr 6, 2013 at 3:24 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka storch...@gmail.com wrote:
04.04.13 00:57, Chris Angelico написав(ла):
http://bugs.python.org/issue17629 opened.
See also the discussion at
In article mailman.222.1365299932.3114.python-l...@python.org,
Ian Kelly ian.g.ke...@gmail.com wrote:
On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
For some definition of easily.
if implementation == CPython:
if version 3.3:
On Sat, Apr 6, 2013 at 8:18 PM, Roy Smith r...@panix.com wrote:
In article mailman.222.1365299932.3114.python-l...@python.org,
Ian Kelly ian.g.ke...@gmail.com wrote:
On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
For some definition of easily.
On 4/3/2013 1:32 AM, Steven D'Aprano wrote:
On Wed, 03 Apr 2013 14:31:03 +1100, Neil Hodgson wrote:
Sorting a million string list (all the file paths on a particular
computer) went from 0.4 seconds with Python 3.2 to 0.78 with 3.3 so
we're out of the 'not noticeable by humans' range.
On Wed, Apr 3, 2013 at 3:03 PM, Neil Hodgson nhodg...@iinet.net.au wrote:
rusi wrote:
Every program attempts to expand until it can read mail. Those programs
which cannot so expand are replaced by ones which can.
In my personal experience, it's calculators. I put command-line
calculators
On Wed, Apr 3, 2013 at 4:32 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 03 Apr 2013 14:31:03 +1100, Neil Hodgson wrote:
Sorting a million string list (all the file paths on a particular
computer) went from 0.4 seconds with Python 3.2 to 0.78 with 3.3 so
we're
Chris Angelico:
I'd be curious to know the sorts of characters used. Given that it's
probably a narrow-vs-wide Python difference we're talking here, the
actual distribution of codepoints may well make a difference.
I was going to upload it but then I thought of potential client
Terry Jan Reedy:
What system *and* what compiler and compiler options. Unless 3.2 and 3.3
are both compiler with the same compiler and settings, we do not know
the source of the difference.
The version signatures are:
3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)]
On Wed, Apr 3, 2013 at 5:29 PM, Neil Hodgson nhodg...@iinet.net.au wrote:
Chris Angelico:
I'd be curious to know the sorts of characters used. Given that it's
probably a narrow-vs-wide Python difference we're talking here, the
actual distribution of codepoints may well make a difference.
On Wed, Apr 3, 2013 at 12:52 AM, Chris Angelico ros...@gmail.com wrote:
Hmm. I was about to say Can you just do a quick collections.Counter()
of the string widths in 3.3, as an easy way of seeing which ones use
BMP or higher characters, but I can't find a simple way to query a
string's width.
On Wed, Apr 3, 2013 at 6:06 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Wed, Apr 3, 2013 at 12:52 AM, Chris Angelico ros...@gmail.com wrote:
Hmm. I was about to say Can you just do a quick collections.Counter()
of the string widths in 3.3, as an easy way of seeing which ones use
BMP or
Reran the programs taking a bit more care with the encoding of the
file. This had no effect on the speeds. There are only a small amount of
paths that don't fit into ASCII:
ASCII 1076101
Latin1 218
BMP 113
Astral 0
# encoding:utf-8
import codecs, os, time
from os.path import join, getsize
On Wed, 03 Apr 2013 18:24:25 +1100, Chris Angelico wrote:
On Wed, Apr 3, 2013 at 6:06 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Wed, Apr 3, 2013 at 12:52 AM, Chris Angelico ros...@gmail.com
wrote:
Hmm. I was about to say Can you just do a quick collections.Counter()
of the string widths
On Wed, Apr 3, 2013 at 6:53 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Here's another way:
(sys.getsizeof(s) - sys.getsizeof(''))/len(s)
should work.
Hmm, I had been under the impression that there was a certain base
length below which strings all had the same size.
On Apr 3, 12:37 pm, Neil Hodgson nhodg...@iinet.net.au wrote:
Reran the programs taking a bit more care with the encoding of the
file. This had no effect on the speeds. There are only a small amount of
paths that don't fit into ASCII:
ASCII 1076101
Latin1 218
BMP 113
Astral 0
#
This FSR is wrong by design. A naive way to embrace Unicode.
jmf
--
http://mail.python.org/mailman/listinfo/python-list
Roy Smith:
On the other hand, how long did it take you to do the directory tree
walk required to find those million paths? I'll bet a long longer than
0.78 seconds, so this gets lost in the noise.
About 2 minutes. But that's just getting an example data set. Other
data sets may be loaded
rusi:
Can you please try one more experiment Neil?
Knock off all non-ASCII strings (paths) from your dataset and try
again.
Results are the same 0.40 (well, 0.001 less but I don't think the
timer is that accurate) for Python 3.2 and 0.78 for Python 3.3.
Neil
--
On 04/03/2013 04:22 AM, Neil Hodgson wrote:
rusi:
Can you please try one more experiment Neil?
Knock off all non-ASCII strings (paths) from your dataset and try
again.
Results are the same 0.40 (well, 0.001 less but I don't think the
timer is that accurate) for Python 3.2 and 0.78 for
Dave Angel:
That would seem to imply that the speed regression on your data is NOT
caused by the differing size encodings. Perhaps it is the difference in
MSC compiler version, or other changes made between 3.2 and 3.3
Its not caused by there actually being different size encodings but
On 03/04/2013 09:08, jmfauth wrote:
This FSR is wrong by design. A naive way to embrace Unicode.
jmf
The hole you're digging for yourself is getting bigger and bigger and
I'm loving it :)
--
If you're using GoogleCrap™ please read this
On 04/03/2013 07:05 AM, Neil Hodgson wrote:
Dave Angel:
That would seem to imply that the speed regression on your data is NOT
caused by the differing size encodings. Perhaps it is the difference in
MSC compiler version, or other changes made between 3.2 and 3.3
Its not caused by there
In article 1f2dnfpbhy54embmnz2dnuvz_osdn...@westnet.com.au,
Neil Hodgson nhodg...@iinet.net.au wrote:
Roy Smith:
On the other hand, how long did it take you to do the directory tree
walk required to find those million paths? I'll bet a long longer than
0.78 seconds, so this gets lost
In article mailman.37.1364970149.3114.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Wed, Apr 3, 2013 at 3:03 PM, Neil Hodgson nhodg...@iinet.net.au wrote:
rusi wrote:
Every program attempts to expand until it can read mail. Those programs
which cannot so expand are
On Thu, Apr 4, 2013 at 12:28 AM, Roy Smith r...@panix.com wrote:
In article mailman.37.1364970149.3114.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Wed, Apr 3, 2013 at 3:03 PM, Neil Hodgson nhodg...@iinet.net.au wrote:
rusi wrote:
Every program attempts to expand
On Thu, Apr 4, 2013 at 12:25 AM, Roy Smith r...@panix.com wrote:
Fair enough. In fact, given that reading the file from disk is O(n) and
sorting it is O(n log n), at some point, the sort will totally swamp the
input time.
But given the much larger fixed cost of disk access, that might take
In article 515be00e$0$29891$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 03 Apr 2013 18:24:25 +1100, Chris Angelico wrote:
On Wed, Apr 3, 2013 at 6:06 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Wed, Apr 3, 2013 at 12:52 AM,
On 02/04/2013 10:28, Neil Hodgson wrote:
jmfauth:
3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)]
[0.8343414906182101, 0.8336184057396241, 0.8330473419738562]
3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit
[1.3840254166697845, 1.3933888932429768,
On Thu, Apr 4, 2013 at 12:43 AM, Roy Smith r...@panix.com wrote:
This has to inspect the entire string, no? I posted (essentially) this
a few days ago:
if all(ord(c) = 0x for c in s):
return it's all bmp
else:
return it's got astral crap in it
On Wed, 03 Apr 2013 07:52:42 -0400, Dave Angel wrote:
I thought that the sort algorithm used a hash of all
the items to be sorted, and only reverted to a raw comparison of the
original values when the hash collided. Is that not the case? Or is
the code you post here only used when the hash
On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote:
[...]
n = max(map(ord, s))
4 if n 0x else 2 if n 0xff else 1
This has to inspect the entire string, no?
Correct. A more efficient implementation would be:
def char_size(s):
for n in map(ord, s):
if n 0x: return 4
In article 515c400e$0$29966$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
I seem to recall that sort relies only on operator is a language
promise, but I can't seem to find it documented anywhere official.
That's pretty typical for sort
On Thu, 04 Apr 2013 01:17:28 +1100, Chris Angelico wrote:
Probably, but it still has to scan the body of the string. It'd not be
too bad if it's all astral, but if it's all BMP, it has to scan the
whole string. In the max() case, it has to scan the whole string anyway,
as there's no other way
On Apr 3, 6:43 pm, Roy Smith r...@panix.com wrote:
This has to inspect the entire string, no? I posted (essentially) this
a few days ago:
if all(ord(c) = 0x for c in s):
return it's all bmp
else:
return it's got astral crap in it
Astral crap?
On Wed, Apr 3, 2013 at 5:52 AM, Dave Angel da...@davea.name wrote:
I'm also puzzled. I thought that the sort algorithm used a hash of all the
items to be sorted, and only reverted to a raw comparison of the original
values when the hash collided. Is that not the case? Or is the code you
On Wed, Apr 3, 2013 at 9:02 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote:
[...]
n = max(map(ord, s))
4 if n 0x else 2 if n 0xff else 1
This has to inspect the entire string, no?
Correct. A more efficient
On Wed, Apr 3, 2013 at 1:53 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
(sys.getsizeof(s) - sys.getsizeof(''))/len(s)
s = '\x80\x81\x82\x83\x84\x85'
len(s)
6
import sys
sys.getsizeof(s)
43
sys.getsizeof(s) - sys.getsizeof('')
18
(sys.getsizeof(s) - sys.getsizeof('')) /
On 04/03/2013 09:10 AM, rusi wrote:
On Apr 3, 6:43 pm, Roy Smith r...@panix.com wrote:
This has to inspect the entire string, no? I posted (essentially) this
a few days ago:
if all(ord(c) = 0x for c in s):
return it's all bmp
else:
return it's
On Wed, 03 Apr 2013 10:38:20 -0600, Ian Kelly wrote:
On Wed, Apr 3, 2013 at 9:02 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote:
[...]
n = max(map(ord, s))
4 if n 0x else 2 if n 0xff else 1
This has to inspect the
On 04/03/2013 12:30 PM, Ian Kelly wrote:
On Wed, Apr 3, 2013 at 5:52 AM, Dave Angel da...@davea.name wrote:
I'm also puzzled. I thought that the sort algorithm used a hash of all the
items to be sorted, and only reverted to a raw comparison of the original
values when the hash collided. Is
On Thu, Apr 4, 2013 at 4:43 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 03 Apr 2013 10:38:20 -0600, Ian Kelly wrote:
On Wed, Apr 3, 2013 at 9:02 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote:
On Thu, Apr 4, 2013 at 2:07 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Thu, 04 Apr 2013 01:17:28 +1100, Chris Angelico wrote:
Probably, but it still has to scan the body of the string. It'd not be
too bad if it's all astral, but if it's all BMP, it has to scan the
On 03/04/2013 22:55, Chris Angelico wrote:
On Thu, Apr 4, 2013 at 4:43 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 03 Apr 2013 10:38:20 -0600, Ian Kelly wrote:
On Wed, Apr 3, 2013 at 9:02 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 03
Neil Hodgson, replying to self:
The assembler (32-bit build) for each
PyUnicode_READ looks like
Don't have 64-bit MSVC 2010 set up but the code from 64-bit MSVC
2012 is better since there are an extra 8 registers in 64-bit mode:
; 10431: c1 = PyUnicode_READ(kind1, data1, i);
In article
aa3b500f-bebf-4d77-9855-3d90b07ea...@y7g2000pbu.googlegroups.com,
rusi rustompm...@gmail.com wrote:
On Apr 3, 6:43 pm, Roy Smith r...@panix.com wrote:
This has to inspect the entire string, no? I posted (essentially) this
a few days ago:
if all(ord(c) = 0x for c
In article 515c448c$0$29966$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote:
[...]
n = max(map(ord, s))
4 if n 0x else 2 if n 0xff else 1
This has to inspect the entire string,
On 2 avr, 01:43, Neil Hodgson nhodg...@iinet.net.au wrote:
Mark Lawrence:
You've given many examples of the same type of micro benchmark, not many
examples of different types of benchmark.
Trying to work out what jmfauth is on about I found what appears to
be a performance regression
On Tue, Apr 2, 2013 at 6:24 PM, jmfauth wxjmfa...@gmail.com wrote:
An editor may reflect very well the example a gave. You enter
thousand ascii chars, then - boum - as you enter a non ascii
char, your editor (assuming is uses a mechanism like the FSR),
has to internally reencode everything!
On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote:
On Tue, Apr 2, 2013 at 6:24 PM, jmfauth wxjmfa...@gmail.com wrote:
An editor may reflect very well the example a gave. You enter thousand
ascii chars, then - boum - as you enter a non ascii char, your editor
(assuming is uses a
On 2 avr, 10:03, Chris Angelico ros...@gmail.com wrote:
On Tue, Apr 2, 2013 at 6:24 PM, jmfauth wxjmfa...@gmail.com wrote:
An editor may reflect very well the example a gave. You enter
thousand ascii chars, then - boum - as you enter a non ascii
char, your editor (assuming is uses a
On 2 avr, 10:35, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote:
So what? Who cares if it takes 0.2 second to insert a character
instead of 0.1 second? That's still a hundred times faster than you
can type.
jmfauth:
3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)]
[0.8343414906182101, 0.8336184057396241, 0.8330473419738562]
3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit
[1.3840254166697845, 1.3933888932429768, 1.391664674507438]
That's a larger
On 02/04/2013 10:24, jmfauth wrote:
On 2 avr, 10:35, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote:
So what? Who cares if it takes 0.2 second to insert a character
instead of 0.1 second? That's still a hundred
On 02/04/2013 10:43, Mark Lawrence wrote:
On 02/04/2013 10:24, jmfauth wrote:
On 2 avr, 10:35, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote:
So what? Who cares if it takes 0.2 second to insert a character
instead of
On Apr 2, 3:58 pm, Steve Simmons square.st...@gmail.com wrote:
On 02/04/2013 10:43, Mark Lawrence wrote:
On 02/04/2013 10:24, jmfauth wrote:
On 2 avr, 10:35, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote:
So
On Tue, 02 Apr 2013 11:58:11 +0100, Steve Simmons wrote:
It seems to me that jmf *might* be moving towards a vindicated position.
There is some interest now in duplicating, understanding and
(hopefully!) extending his test results, which can only be a Good Thing
- whatever the outcome and
On 02/04/2013 11:58, Steve Simmons wrote:
On 02/04/2013 10:43, Mark Lawrence wrote:
On 02/04/2013 10:24, jmfauth wrote:
On 2 avr, 10:35, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote:
So what? Who cares if it takes
On 02/04/2013 15:03, Steven D'Aprano wrote:
On Tue, 02 Apr 2013 11:58:11 +0100, Steve Simmons wrote:
It seems to me that jmf *might* be moving towards a vindicated position.
There is some interest now in duplicating, understanding and
(hopefully!) extending his test results, which can only
On 02/04/2013 15:39, Steve Simmons wrote:
My post was primarily aimed at recognising the work that people like
Mark, Neil and others have done to move the problem forward and was
intended to help shift the focus to a more productive approach. Again,
my apologies if it was ill timed or
On 02/04/2013 15:12, Mark Lawrence wrote:
I've already raised an issue about performance and Neil Hodgson has
raised a new one.
Recognised in a separate post
To balance this out perhaps we should have counter issues asking for
the amount of memory being used to be increased to old levels and
On 2 avr, 16:03, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Tue, 02 Apr 2013 11:58:11 +0100, Steve Simmons wrote:
I'm sure you didn't intend to be insulting, but some of us *have* taken
JMF seriously, at least at first. His repeated overblown claims of how
Python is
On 04/02/2013 08:03 AM, Steve Simmons wrote:
On 02/04/2013 15:12, Mark Lawrence wrote:
I've already raised an issue about performance and Neil Hodgson has raised a
new one.
Recognised in a separate post
To balance this out perhaps we should have counter issues asking for the amount
of
On 02/04/2013 16:12, jmfauth wrote:
Sorrry I never claimed this, I'm just seeing on how Python is becoming
less Unicode friendly.
Please explain this. I see no justification for this comment. How can
an implementation that fixes bugs be less Unicode friendly than its
earlier, buggier
On 04/02/2013 07:39 AM, Steve Simmons wrote:
On 02/04/2013 15:03, Steven D'Aprano wrote:
On Tue, 02 Apr 2013 11:58:11 +0100, Steve Simmons wrote:
It seems to me that jmf *might* be moving towards a vindicated position.
There is some interest now in duplicating, understanding and
On Apr 2, 8:17 pm, Ethan Furman et...@stoneleaf.us wrote:
Simmons (too many Steves!), I know you're new so don't have all the history
with jmf that many
of us do, but consider that the original post was about numbers, had nothing
to do with
characters or unicode *in any way*, and yet jmf
On Apr 2, 8:12 pm, jmfauth wxjmfa...@gmail.com wrote:
Sorrry I never claimed this, I'm just seeing on how Python is becoming
less Unicode friendly.
jmf: I suggest you try to use less emotionally loaded and more precise
language if you want people to pay heed to your technical observations/
On 2 avr, 18:57, rusi rustompm...@gmail.com wrote:
On Apr 2, 8:17 pm, Ethan Furman et...@stoneleaf.us wrote:
Simmons (too many Steves!), I know you're new so don't have all the history
with jmf that many
of us do, but consider that the original post was about numbers, had
nothing to do
On Apr 2, 11:22 pm, jmfauth wxjmfa...@gmail.com wrote:
On 2 avr, 18:57, rusi rustompm...@gmail.com wrote:
On Apr 2, 8:17 pm, Ethan Furman et...@stoneleaf.us wrote:
Simmons (too many Steves!), I know you're new so don't have all the
history with jmf that many
of us do, but
On Tue, Apr 2, 2013 at 3:20 AM, jmfauth wxjmfa...@gmail.com wrote:
It is somehow funny to see, the FSR fails precisely
on problems Unicode will solve/handle, eg normalization or
sorting [3].
Neither of these problems have anything to do with the FSR. Can you
give us an example of
On 4/2/2013 11:12 AM, jmfauth wrote:
On 2 avr, 16:03, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
I'm sure you didn't intend to be insulting, but some of us *have* taken
JMF seriously, at least at first. His repeated overblown claims of how
Python is destroying Unicode ...
The initial post posited:
The Python 3 merge of int and long has effectively penalized
small-number arithmetic by removing an optimization. As we've seen
from PEP 393 strings (jmf aside), there can be huge benefits from
having a single type with multiple representations internally. Is
there value
jmfauth wxjmfa...@gmail.com writes:
Now replace i by a char, a representent of each subset
of the FSR, select a method where this FST behave badly
and take a look of what happen.
You insist in cherry-picking a single method where this FST behave
badly, even when it is so obviously a corner
Ian Kelly:
Micro-benchmarks like the ones you have been reporting are *useful*
when it comes to determining what operations can be better optimized,
but they are not *important* in and of themselves. What is important
is that actual, real-world programs are not significantly slowed by
these
On Apr 3, 8:31 am, Neil Hodgson nhodg...@iinet.net.au wrote:
Sorting a million string list (all the file paths on a particular
computer) went from 0.4 seconds with Python 3.2 to 0.78 with 3.3 so
we're out of the 'not noticeable by humans' range. Perhaps this is still
a 'micro-benchmark' -
rusi wrote:
...
a 'micro-benchmark' - I'd just like to avoid adding email access to get
this over the threshold.
What does that last statement mean?
Its a reference to a comment by Jamie Zawinski (relatively famous
developer of Netscape Navigator and other things):
Every program
In article
5f8ed721-7c89-4ffd-8f2b-21979cc33...@kk11g2000pbb.googlegroups.com,
rusi rustompm...@gmail.com wrote:
On Apr 3, 8:31 am, Neil Hodgson nhodg...@iinet.net.au wrote:
Sorting a million string list (all the file paths on a particular
computer) went from 0.4 seconds with Python
On Apr 3, 9:03 am, Neil Hodgson nhodg...@iinet.net.au wrote:
rusi wrote:
...
a 'micro-benchmark' - I'd just like to avoid adding email access to get
this over the threshold.
What does that last statement mean?
Its a reference to a comment by Jamie Zawinski (relatively famous
On Wed, 03 Apr 2013 14:31:03 +1100, Neil Hodgson wrote:
Sorting a million string list (all the file paths on a particular
computer) went from 0.4 seconds with Python 3.2 to 0.78 with 3.3 so
we're out of the 'not noticeable by humans' range. Perhaps this is still
a 'micro-benchmark' - I'd
On Mon, Apr 1, 2013 at 4:33 PM, rusi rustompm...@gmail.com wrote:
So I really wonder: Is python losing more by supporting SMP with
performance hit on BMP?
If your strings fit entirely within the BMP, then you should see no
penalty compared to previous versions of Python. If they happen to fit
On Sun, 31 Mar 2013 22:33:45 -0700, rusi wrote:
On Mar 31, 5:55 pm, Mark Lawrence breamore...@yahoo.co.uk wrote:
snipped jmf's broken-record whine
I'm feeling very sorry for this horse, it's been flogged so often it's
down to bare bones.
While I am now joining the camp of those fed up
In article 515941d8$0$29967$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
[...]
OK, that leads to the next question. Is there anyway I can (in Python
2.7) detect when a string is not entirely in the BMP? If I could find
all the non-BMP
On Apr 1, 5:15 pm, Roy Smith r...@panix.com wrote:
In article 515941d8$0$29967$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
[...]
OK, that leads to the next question. Is there anyway I can (in Python
2.7) detect when a string is not
On Mon, 01 Apr 2013 06:11:50 -0700, rusi wrote:
On Apr 1, 5:15 pm, Roy Smith r...@panix.com wrote:
The import job isn't done yet, but so far we've processed 116 million
records and had to clean up four of them. I can live with that.
Sometimes practicality trumps correctness.
That works
On Mon, 01 Apr 2013 08:15:53 -0400, Roy Smith wrote:
In article 515941d8$0$29967$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
[...]
OK, that leads to the next question. Is there anyway I can (in
Python 2.7) detect when a string is not
On Tue, Apr 2, 2013 at 4:07 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Mon, 01 Apr 2013 08:15:53 -0400, Roy Smith wrote:
It turns out, the problem is that the version of MySQL we're using
Well there you go. Why don't you use a real database?
On 01/04/2013 18:07, Steven D'Aprano wrote:
On Mon, 01 Apr 2013 08:15:53 -0400, Roy Smith wrote:
In article 515941d8$0$29967$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
[...]
OK, that leads to the next question. Is there anyway I can (in
-
I'm not whining or and I'm not complaining (and never did).
I always exposed facts.
I'm not especially interested in Python, I'm interested in
Unicode.
Usualy when I posted examples, there are confirmed.
What I see is this (std download-abled Python's on Windows 7 (and
other
On Tue, Apr 2, 2013 at 6:15 AM, jmfauth wxjmfa...@gmail.com wrote:
Py32
import timeit
timeit.repeat('a' * 1000 + 'ẞ')
[0.7005365263669056, 0.6810694766790423, 0.6811978680727229]
timeit.repeat('a' * 1000 + 'z')
[0.7105829560031083, 0.6904999426964764, 0.6938637184431968]
Py33
import
On 01/04/2013 20:15, jmfauth wrote:
-
I'm not whining or and I'm not complaining (and never did).
I always exposed facts.
The only fact I'm aware of is an edge case that is being addressed on
the Python bug tracker, sorry I'm too lazy to look up the number again.
I'm not
On 1 avr, 21:28, Chris Angelico ros...@gmail.com wrote:
On Tue, Apr 2, 2013 at 6:15 AM, jmfauth wxjmfa...@gmail.com wrote:
Py32
import timeit
timeit.repeat('a' * 1000 + 'ẞ')
[0.7005365263669056, 0.6810694766790423, 0.6811978680727229]
timeit.repeat('a' * 1000 + 'z')
In article 5159beb6$0$29967$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
The import job isn't done yet, but so far we've processed 116 million
records and had to clean up four of them. I can live with that.
Sometimes practicality trumps
On Tue, Apr 2, 2013 at 7:28 AM, jmfauth wxjmfa...@gmail.com wrote:
Of course this is an example, as many I gave. Examples you may find in
apps.
Show me an *entire app* that suffers.
Show me one.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
1 - 100 of 210 matches
Mail list logo
