Le lundi 29 juillet 2013 16:49:34 UTC+2, Chris Angelico a écrit :
> On Mon, Jul 29, 2013 at 3:20 PM, wrote:
>
> >>c:\python32\pythonw -u "timitmod.py"
>
> > 15.258061416225663
>
> >>Exit code: 0
>
> >>c:\Python33\pythonw -u "timitmod.py"
>
> > 17.052203122286194
>
> >>Exit code: 0
>
>
>
On Mon, Jul 29, 2013 at 3:20 PM, wrote:
>>c:\python32\pythonw -u "timitmod.py"
> 15.258061416225663
>>Exit code: 0
>>c:\Python33\pythonw -u "timitmod.py"
> 17.052203122286194
>>Exit code: 0
>>> len(dir(C))
Did you even think to check that before you posted timings?
ChrisA
--
http://mail.pytho
Le lundi 29 juillet 2013 13:57:47 UTC+2, Chris Angelico a écrit :
> On Mon, Jul 29, 2013 at 12:43 PM, wrote:
>
> > Le dimanche 28 juillet 2013 22:52:16 UTC+2, Steven D'Aprano a écrit :
>
> > 3.2
>
> timeit.timeit("r = dir(list)")
>
> > 22.300465007102908
>
> >
>
> > 3.3
>
> timei
Le dimanche 28 juillet 2013 19:36:00 UTC+2, Terry Reedy a écrit :
> On 7/28/2013 11:52 AM, Michael Torrie wrote:
>
> >
>
> > 3. UTF-8 and UTF-16 encodings, being variable width encodings, mean that
>
> > slicing a string would be very very slow,
>
>
>
> Not necessarily so. See below.
>
>
>
Le lundi 29 juillet 2013 13:57:47 UTC+2, Chris Angelico a écrit :
> On Mon, Jul 29, 2013 at 12:43 PM, wrote:
>
> > Le dimanche 28 juillet 2013 22:52:16 UTC+2, Steven D'Aprano a écrit :
>
> > 3.2
>
> timeit.timeit("r = dir(list)")
>
> > 22.300465007102908
>
> >
>
> > 3.3
>
> timei
On 07/29/2013 08:06 AM, Heiko Wundram wrote:
Am 29.07.2013 13:43, schrieb wxjmfa...@gmail.com:
3.2
timeit.timeit("r = dir(list)")
22.300465007102908
3.3
timeit.timeit("r = dir(list)")
27.13981129541519
For the record, I do not put your example to contradict
you. I was expecting such a res
Am 29.07.2013 13:43, schrieb wxjmfa...@gmail.com:
3.2
timeit.timeit("r = dir(list)")
22.300465007102908
3.3
timeit.timeit("r = dir(list)")
27.13981129541519
For the record, I do not put your example to contradict
you. I was expecting such a result even before testing.
Now, if you do not un
On Mon, Jul 29, 2013 at 12:43 PM, wrote:
> Le dimanche 28 juillet 2013 22:52:16 UTC+2, Steven D'Aprano a écrit :
> 3.2
timeit.timeit("r = dir(list)")
> 22.300465007102908
>
> 3.3
timeit.timeit("r = dir(list)")
> 27.13981129541519
3.2:
>>> len(dir(list))
42
3.3:
>>> len(dir(list))
45
Le dimanche 28 juillet 2013 22:52:16 UTC+2, Steven D'Aprano a écrit :
> On Sun, 28 Jul 2013 12:23:04 -0700, wxjmfauth wrote:
>
>
>
> > Do not forget that à la "FSR" mechanism for a non-ascii user is
>
> > *irrelevant*.
>
>
>
> You have been told repeatedly, Python's internals are *full* of A
On Sun, 28 Jul 2013 12:23:04 -0700, wxjmfauth wrote:
> Do not forget that à la "FSR" mechanism for a non-ascii user is
> *irrelevant*.
You have been told repeatedly, Python's internals are *full* of ASCII-
only strings.
py> dir(list)
['__add__', '__class__', '__contains__', '__delattr__', '__del
Op 28-07-13 21:23, wxjmfa...@gmail.com schreef:
Le dimanche 28 juillet 2013 17:52:47 UTC+2, Michael Torrie a écrit :
On 07/27/2013 12:21 PM, wxjmfa...@gmail.com wrote:
Good point. FSR, nice tool for those who wish to teach
Unicode. It is not every day, one has such an opportunity.
I had
On 28/07/2013 20:23, wxjmfa...@gmail.com wrote:
[snip]
Compare these (a BDFL exemple, where I'using a non-ascii char)
Py 3.2 (narrow build)
Why are you using a narrow build of Python 3.2? It doesn't treat all
codepoints equally (those outside the BMP can't be stored in one code
unit) and, the
Le dimanche 28 juillet 2013 17:52:47 UTC+2, Michael Torrie a écrit :
> On 07/27/2013 12:21 PM, wxjmfa...@gmail.com wrote:
>
> > Good point. FSR, nice tool for those who wish to teach
>
> > Unicode. It is not every day, one has such an opportunity.
>
>
>
> I had a long e-mail composed, but deci
On Sun, Jul 28, 2013 at 6:36 PM, Terry Reedy wrote:
> I posted about a week ago, in response to Chris A., a method by which lookup
> for UTF-16 can be made O(log2 k), or perhaps more accurately,
> O(1+log2(k+1)), where k is the number of non-BMP chars in the string.
>
Which is an optimization cho
On 7/28/2013 11:52 AM, Michael Torrie wrote:
3. UTF-8 and UTF-16 encodings, being variable width encodings, mean that
slicing a string would be very very slow,
Not necessarily so. See below.
and that's unacceptable for
the use cases of python strings. I'm assuming you understand big O
notat
On Sun, Jul 28, 2013 at 4:52 PM, Michael Torrie wrote:
> Is my understanding of these things wrong?
No, your understanding of those matters is fine. There's just one area
you seem to be misunderstanding; you appear to think that jmf actually
cares about logical argument. I gave up on that theory
On 07/27/2013 12:21 PM, wxjmfa...@gmail.com wrote:
> Good point. FSR, nice tool for those who wish to teach
> Unicode. It is not every day, one has such an opportunity.
I had a long e-mail composed, but decided to chop it down, but still too
long. so I ditched a lot of the context, which jmf also
17 matches
Mail list logo
