On 06/04/2013 22:24, Chris Angelico wrote:
On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka 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
rejectio
On Sat, 06 Apr 2013 19:58:02 -0600, Ian Kelly wrote:
> On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano
> wrote:
>> For some definition of "easily".
>>
>> if implementation == "CPython":
>> if version < "3.3":
>> if sys.maxunicode exists:
>> use it to decide whether this is
On 07.04.13 00:24, Chris Angelico wrote:
On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka 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 (including future C
On Sat, Apr 6, 2013 at 8:18 PM, Roy Smith wrote:
> In article ,
> Ian Kelly wrote:
>
>> On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano
>> wrote:
>> > For some definition of "easily".
>> >
>> > if implementation == "CPython":
>> > if version < "3.3":
>> > if sys.maxunicode exists:
>
In article ,
Ian Kelly wrote:
> On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano
> 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 narr
On Sat, Apr 6, 2013 at 3:24 PM, Chris Angelico wrote:
> On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka 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/156
On Sat, Apr 6, 2013 at 7:29 PM, Steven D'Aprano
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 a wide build: return 4
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
>> wrote:
>>> 04.04.13 00:57, Chris Angelico написав(ла):
http://bugs.python.org/issue17629 opened.
>>>
>>>
>>> See also the discussion
On 04/06/2013 02:24 PM, Chris Angelico wrote:
On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka 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
rejec
On Sat, Apr 6, 2013 at 8:09 PM, Serhiy Storchaka 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 implementation detail
04.04.13 00:57, Chris Angelico написав(ла):
On Thu, Apr 4, 2013 at 2:07 AM, Steven D'Aprano
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 t
In article <515c448c$0$29966$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano 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
In article
,
rusi wrote:
> On Apr 3, 6:43 pm, Roy Smith 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'
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);
On 03/04/2013 22:55, Chris Angelico wrote:
On Thu, Apr 4, 2013 at 4:43 AM, Steven D'Aprano
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
wrote:
On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote:
[...]
n = max(map(ord, s))
4 i
On Thu, Apr 4, 2013 at 2:07 AM, Steven D'Aprano
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
>> whole string. In the max() case,
On Thu, Apr 4, 2013 at 4:43 AM, Steven D'Aprano
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
>> wrote:
>>> On Wed, 03 Apr 2013 09:43:06 -0400, Roy Smith wrote:
>>>
>>> [...]
> n = max(map(ord, s))
> 4 if n > 0x else
On 04/03/2013 12:30 PM, Ian Kelly wrote:
On Wed, Apr 3, 2013 at 5:52 AM, Dave Angel 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?
On Wed, 03 Apr 2013 10:38:20 -0600, Ian Kelly wrote:
> On Wed, Apr 3, 2013 at 9:02 AM, Steven D'Aprano
> 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 strin
On 04/03/2013 09:10 AM, rusi wrote:
On Apr 3, 6:43 pm, Roy Smith 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 cr
On Wed, Apr 3, 2013 at 1:53 AM, Steven D'Aprano
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('')) / len(s)
3.0
I didn
On Wed, Apr 3, 2013 at 9:02 AM, Steven D'Aprano
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 implementation would be:
>
>
On Wed, Apr 3, 2013 at 5:52 AM, Dave Angel 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
> post here only u
On Apr 3, 6:43 pm, Roy Smith 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? CRAP?
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
In article <515c400e$0$29966$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano 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 implementations in all languages.
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: re
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 ha
On Thu, Apr 4, 2013 at 12:43 AM, Roy Smith 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"
>
> I'
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, 1.3916
In article <515be00e$0$29891$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Wed, 03 Apr 2013 18:24:25 +1100, Chris Angelico wrote:
>
> > On Wed, Apr 3, 2013 at 6:06 PM, Ian Kelly wrote:
> >> On Wed, Apr 3, 2013 at 12:52 AM, Chris Angelico
> >> wrote:
> >>> Hmm. I was about t
On Thu, Apr 4, 2013 at 12:25 AM, Roy Smith 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
an awful lot
On Thu, Apr 4, 2013 at 12:28 AM, Roy Smith wrote:
> In article ,
> Chris Angelico wrote:
>
>> On Wed, Apr 3, 2013 at 3:03 PM, Neil Hodgson wrote:
>> > rusi wrote:
>> >"Every program attempts to expand until it can read mail. Those programs
>> > which cannot so expand are replaced by ones wh
In article ,
Chris Angelico wrote:
> On Wed, Apr 3, 2013 at 3:03 PM, Neil Hodgson 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.
In article <1f2dnfpbhy54embmnz2dnuvz_osdn...@westnet.com.au>,
Neil Hodgson 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 the noise.
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 ac
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
http://wiki.python.org/moin/GoogleGroupsPyt
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
tha
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 Pyt
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
--
http://mail.python.org/
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
This FSR is wrong by design. A naive way to embrace Unicode.
jmf
--
http://mail.python.org/mailman/listinfo/python-list
On Apr 3, 12:37 pm, Neil Hodgson 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
>
> # encoding:utf-8
>
On Wed, Apr 3, 2013 at 6:53 PM, Steven D'Aprano
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. Yes, that also
works; though aga
On Wed, 03 Apr 2013 18:24:25 +1100, Chris Angelico wrote:
> On Wed, Apr 3, 2013 at 6:06 PM, Ian Kelly wrote:
>> On Wed, Apr 3, 2013 at 12:52 AM, Chris Angelico
>> 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
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
w
On Wed, Apr 3, 2013 at 6:06 PM, Ian Kelly wrote:
> On Wed, Apr 3, 2013 at 12:52 AM, Chris Angelico 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 fin
On Wed, Apr 3, 2013 at 12:52 AM, Chris Angelico 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. Can't see i
On Wed, Apr 3, 2013 at 5:29 PM, Neil Hodgson 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.
>
>
>I was g
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
-confidenti
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)]
3.3.
On Wed, Apr 3, 2013 at 4:32 PM, 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
On Wed, Apr 3, 2013 at 3:03 PM, Neil Hodgson 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 into *everything*..
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. Perha
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
On Apr 3, 9:03 am, Neil Hodgson 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
> developer of
In article
<5f8ed721-7c89-4ffd-8f2b-21979cc33...@kk11g2000pbb.googlegroups.com>,
rusi wrote:
> On Apr 3, 8:31 am, 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 o
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 at
On Apr 3, 8:31 am, 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 just like to
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 kin
jmfauth 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 case (IMHO it i
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
On 4/2/2013 11:12 AM, jmfauth wrote:
On 2 avr, 16:03, Steven D'Aprano 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 ...
... = 'usability in Python" or some va
On Tue, Apr 2, 2013 at 3:20 AM, jmfauth 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 normalization or sorting wh
On Apr 2, 11:22 pm, jmfauth wrote:
> On 2 avr, 18:57, rusi wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 2, 8:17 pm, Ethan Furman 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 abo
On 2 avr, 18:57, rusi wrote:
> On Apr 2, 8:17 pm, Ethan Furman 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 unicod
On Apr 2, 8:12 pm, jmfauth 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/
contributions.
In pa
On Apr 2, 8:17 pm, Ethan Furman 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 still felt the
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
(hopefully!
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 equiv
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 memor
On 2 avr, 16:03, Steven D'Aprano 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 destroying Unicode ...
Sorrry I neve
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 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 ill-direct
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 b
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 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
inste
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 Apr 2, 3:58 pm, 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 >> +comp.lang.pyt...@pearwood.info> wrote:
> >>> On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote:
>
> >>> So wha
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 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 hundre
On 02/04/2013 10:24, jmfauth wrote:
On 2 avr, 10:35, Steven D'Aprano 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 performa
On 2 avr, 10:03, Chris Angelico wrote:
> On Tue, Apr 2, 2013 at 6:24 PM, jmfauth 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
On 2 avr, 10:35, Steven D'Aprano 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.
>
-
This not the problem. The i
On Tue, 02 Apr 2013 19:03:17 +1100, Chris Angelico wrote:
> On Tue, Apr 2, 2013 at 6:24 PM, jmfauth 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 F
On Tue, Apr 2, 2013 at 6:24 PM, jmfauth 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!
That assumes that
On 2 avr, 01:43, Neil Hodgson 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 with '<' stri
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 with '<' string comparisons on Windows
64-bit. Its around 30% s
On 01/04/2013 21:28, jmfauth wrote:
On 1 avr, 21:28, Chris Angelico wrote:
On Tue, Apr 2, 2013 at 6:15 AM, jmfauth wrote:
Py32
import timeit
timeit.repeat("'a' * 1000 + 'ẞ'")
[0.7005365263669056, 0.6810694766790423, 0.6811978680727229]
timeit.repeat("'a' * 1000 + 'z'")
[0.7105829560031083
On 01/04/2013 21:35, Chris Angelico wrote:
On Tue, Apr 2, 2013 at 7:28 AM, jmfauth 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
Please don't hold your breath.
--
If you're using GoogleCrap™
On Tue, Apr 2, 2013 at 7:28 AM, jmfauth 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
In article <5159beb6$0$29967$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano 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.
>
>Well, true. It has
On 1 avr, 21:28, Chris Angelico wrote:
> On Tue, Apr 2, 2013 at 6:15 AM, jmfauth wrote:
> > Py32
> import timeit
> timeit.repeat("'a' * 1000 + 'ẞ'")
> > [0.7005365263669056, 0.6810694766790423, 0.6811978680727229]
> timeit.repeat("'a' * 1000 + 'z'")
> > [0.7105829560031083, 0.69049
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 especial
On Tue, Apr 2, 2013 at 6:15 AM, jmfauth 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 tim
-
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
Windo
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 wrote:
[...]
>> OK, that leads to the next question. Is there anyway I can (in
>> Python 2.7) detect when a str
On Tue, Apr 2, 2013 at 4:07 AM, Steven D'Aprano
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?
>
> http://www.postgresql.org/docs/9.2/static/multibyte.html
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 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?
On Mon, 01 Apr 2013 06:11:50 -0700, rusi wrote:
> On Apr 1, 5:15 pm, Roy Smith 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 out to
On Apr 1, 5:15 pm, Roy Smith wrote:
> In article <515941d8$0$29967$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano 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
1 - 100 of 209 matches
Mail list logo
