Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #41586 > unrolled thread

"monty" < "python"

Back to article view | Back to comp.lang.python

Contents

  "monty" < "python" franzferdinand <melo.dumoulin@hotmail.com> - 2013-03-20 06:33 -0700
    Re: "monty" < "python" Jan Oelze <jan@codein.is> - 2013-03-20 14:38 +0100
      Re: "monty" < "python" Roy Smith <roy@panix.com> - 2013-03-20 09:58 -0400
        Re: "monty" < "python" franzferdinand <melo.dumoulin@hotmail.com> - 2013-03-20 07:03 -0700
          Re: "monty" < "python" Terry Reedy <tjreedy@udel.edu> - 2013-03-21 04:08 -0400
            Re: "monty" < "python" Roy Smith <roy@panix.com> - 2013-03-21 08:45 -0400
              Re: "monty" < "python" Chris Angelico <rosuav@gmail.com> - 2013-03-21 23:55 +1100
              Re: "monty" < "python" Wayne Werner <wayne@waynewerner.com> - 2013-03-21 07:56 -0500
              Re: "monty" < "python" Dave Angel <davea@davea.name> - 2013-03-21 09:02 -0400
    Re: "monty" < "python" "R. Michael Weylandt" <michael.weylandt@gmail.com> - 2013-03-20 13:40 +0000
    Re: "monty" < "python" Ian Foote <ian@feete.org> - 2013-03-20 14:17 +0000
    Re: "monty" < "python" Jan Oelze <jan@codein.is> - 2013-03-20 15:23 +0100
    Re: "monty" < "python" Grant Edwards <invalid@invalid.invalid> - 2013-03-20 16:04 +0000
      Re: "monty" < "python" jmfauth <wxjmfauth@gmail.com> - 2013-03-20 12:40 -0700
        Re: "monty" < "python" Tim Delaney <tim.delaney@aptare.com> - 2013-03-21 08:02 +1100
          Re: "monty" < "python" jmfauth <wxjmfauth@gmail.com> - 2013-03-23 02:24 -0700
            Re: "monty" < "python" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-23 16:17 +0000
              Re: "monty" < "python" jmfauth <wxjmfauth@gmail.com> - 2013-03-24 06:31 -0700
                Re: "monty" < "python" Chris Angelico <rosuav@gmail.com> - 2013-03-25 00:44 +1100
                Re: "monty" < "python" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-24 14:08 +0000
        Re: "monty" < "python" Michael Torrie <torriem@gmail.com> - 2013-03-20 19:41 -0600
        Re: "monty" < "python" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-21 02:52 +0000
        Re: "monty" < "python" rusi <rustompmody@gmail.com> - 2013-03-20 20:12 -0700
          Vowels [was Re: "monty" < "python"] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-21 04:28 +0000
            Re: Vowels [was Re: "monty" < "python"] Larry Hudson <orgnut@yahoo.com> - 2013-03-20 23:26 -0700
              Re: Vowels [was Re: "monty" < "python"] David H Wild <dhwild@talktalk.net> - 2013-03-21 09:36 +0000
                Re: Vowels [was Re: "monty" < "python"] Chris Angelico <rosuav@gmail.com> - 2013-03-21 21:09 +1100
                  Re: Vowels [was Re: "monty" < "python"] Peter Pearson <ppearson@nowhere.invalid> - 2013-03-21 21:52 +0000
                    Re: Vowels [was Re: "monty" < "python"] Chris Angelico <rosuav@gmail.com> - 2013-03-22 08:59 +1100
                Re: Vowels [was Re: "monty" < "python"] istjanichtzufassen@gmail.com - 2013-03-21 06:26 -0700
                  Re: Vowels [was Re: "monty" < "python"] Chris Angelico <rosuav@gmail.com> - 2013-03-22 00:38 +1100
            Re: Vowels [was Re: "monty" < "python"] Grant Edwards <invalid@invalid.invalid> - 2013-03-21 17:31 +0000
              Re: Vowels [was Re: "monty" < "python"] Terry Reedy <tjreedy@udel.edu> - 2013-03-21 19:05 -0400
                Re: Vowels [was Re: "monty" < "python"] Roy Smith <roy@panix.com> - 2013-03-21 20:09 -0400
                Re: Vowels [was Re: "monty" < "python"] Grant Edwards <invalid@invalid.invalid> - 2013-03-22 14:14 +0000
              Re: Vowels [was Re: "monty" < "python"] Stefan Behnel <stefan_ml@behnel.de> - 2013-03-24 15:25 +0100
                Re: Vowels [was Re: "monty" < "python"] rusi <rustompmody@gmail.com> - 2013-03-24 08:04 -0700
              Re: Vowels [was Re: "monty" < "python"] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-24 16:12 +0000
          Re: "monty" < "python" jmfauth <wxjmfauth@gmail.com> - 2013-03-23 02:23 -0700
            Re: "monty" < "python" Chris Angelico <rosuav@gmail.com> - 2013-03-23 20:45 +1100
            Re: "monty" < "python" Chris Angelico <rosuav@gmail.com> - 2013-03-23 20:56 +1100
            Re: "monty" < "python" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-03-23 16:06 +0000

Page 1 of 3  [1] 2 3  Next page →

#41586 — "monty" < "python"

>>> "Monty" < "Python"
True
>>> "Z" < "a"
True
>>> "Monty" < "Montague"

False
What's the rule about that? Is it the number of letters or what?
thanks

[toc] | [next] | [standalone]

#41587

[Multipart message — attachments visible in raw view] — view raw

From the docs[0]:

"Strings are compared lexicographically using the numeric equivalents (the result of the built-in function ord()) of their characters. Unicode and 8-bit strings are fully interoperable in this behavior."

[0] http://docs.python.org/2/reference/expressions.html#not-in

On 20.03.2013, at 14:33, franzferdinand <melo.dumoulin@hotmail.com> wrote:

>>>> "Monty" < "Python"
> True
>>>> "Z" < "a"
> True
>>>> "Monty" < "Montague"
> 
> False
> What's the rule about that? Is it the number of letters or what?
> thanks
> -- 
> http://mail.python.org/mailman/listinfo/python-list

[toc] | [prev] | [next] | [standalone]

#41590

In article <mailman.3561.1363786737.2939.python-list@python.org>,
 Jan Oelze <jan@codein.is> wrote:

> From the docs[0]:
> 
> "Strings are compared lexicographically using the numeric equivalents (the 
> result of the built-in function ord()) of their characters. Unicode and 8-bit 
> strings are fully interoperable in this behavior."

Note, however, that sorting order is a really complicated subject.  
Different languages have all sorts of rules for how to alphabetize 
entries in a directory or dictionary.  Does N sort the same as N?  Does 
E sort the same as E?  What about C and C?  Are these pairs all the same 
letter, one of which is decorated with some mark, or are they different 
letters?

If you're worried about these sorts of things, you need to be looking at 
the locale module.

[toc] | [prev] | [next] | [standalone]

#41591

Ok, thanks everybody!

[toc] | [prev] | [next] | [standalone]

#41637

On 3/20/2013 10:03 AM, franzferdinand wrote:
> Ok, thanks everybody!

Threads are like the Sorcerer's Apprentice. You can start 'em, but you 
cannot stop 'em ;-)

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#41648

In article <mailman.3582.1363853304.2939.python-list@python.org>,
 Terry Reedy <tjreedy@udel.edu> wrote:

> On 3/20/2013 10:03 AM, franzferdinand wrote:
> > Ok, thanks everybody!
> 
> Threads are like the Sorcerer's Apprentice. You can start 'em, but you 
> cannot stop 'em ;-)

Of course you can stop threads.  Just call _exit().  No more threads!

[toc] | [prev] | [next] | [standalone]

#41649

On Thu, Mar 21, 2013 at 11:45 PM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.3582.1363853304.2939.python-list@python.org>,
>  Terry Reedy <tjreedy@udel.edu> wrote:
>
>> On 3/20/2013 10:03 AM, franzferdinand wrote:
>> > Ok, thanks everybody!
>>
>> Threads are like the Sorcerer's Apprentice. You can start 'em, but you
>> cannot stop 'em ;-)
>
> Of course you can stop threads.  Just call _exit().  No more threads!

I don't think Mickey Mouse knew about that call, otherwise he'd have
used it. Either that, or he had a completely saturated system and
couldn't type anything at the console, so it took the wizard's SSH
session to deal with the problem using "kill -9".

ChrisA

[toc] | [prev] | [next] | [standalone]

#41650

On Thu, 21 Mar 2013, Roy Smith wrote:

> In article <mailman.3582.1363853304.2939.python-list@python.org>,
> Terry Reedy <tjreedy@udel.edu> wrote:
>
>> On 3/20/2013 10:03 AM, franzferdinand wrote:
>>> Ok, thanks everybody!
>>
>> Threads are like the Sorcerer's Apprentice. You can start 'em, but you
>> cannot stop 'em ;-)
>
> Of course you can stop threads.  Just call _exit().  No more threads!

Thank you for making me laugh this morning - I found that extremely 
amusing.

-W

[toc] | [prev] | [next] | [standalone]

#41651

On 03/21/2013 08:55 AM, Chris Angelico wrote:
> On Thu, Mar 21, 2013 at 11:45 PM, Roy Smith <roy@panix.com> wrote:
>> In article <mailman.3582.1363853304.2939.python-list@python.org>,
>>   Terry Reedy <tjreedy@udel.edu> wrote:
>>
>>> On 3/20/2013 10:03 AM, franzferdinand wrote:
>>>> Ok, thanks everybody!
>>>
>>> Threads are like the Sorcerer's Apprentice. You can start 'em, but you
>>> cannot stop 'em ;-)
>>
>> Of course you can stop threads.  Just call _exit().  No more threads!
>
> I don't think Mickey Mouse knew about that call, otherwise he'd have
> used it. Either that, or he had a completely saturated system and
> couldn't type anything at the console, so it took the wizard's SSH
> session to deal with the problem using "kill -9".
>

Denial-of-service, the traditional way.

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#41588

It's lexigraphic (order by first letter, but if those are the same,
compare the second, but if those are same compare the third, ... if
one ends while the other continues, it's considered 'lower') on the
character's ASCII (binary encoding values):

http://www.asciitable.com/

Note that all the upper case values appear before the lower case
values. (And there are some other 'characters' like newline before
that but you won't see them)

Cheers,
Michael

On Wed, Mar 20, 2013 at 1:33 PM, franzferdinand
<melo.dumoulin@hotmail.com> wrote:
>>>> "Monty" < "Python"
> True
>>>> "Z" < "a"
> True
>>>> "Monty" < "Montague"
>
> False
> What's the rule about that? Is it the number of letters or what?
> thanks
> --
> http://mail.python.org/mailman/listinfo/python-list

[toc] | [prev] | [next] | [standalone]

#41595

On 20/03/13 13:38, Jan Oelze wrote:

> "Strings are compared lexicographically using the numeric equivalents
> (the result of the built-in function ord()) of their characters. Unicode
> and 8-bit strings are fully interoperable in this behavior."

This isn't true in python 3:

Python 3.2.3 (default, Oct 19 2012, 19:53:57)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> b'bytes' < 'unicode'
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: unorderable types: bytes() < str()

Ian F

[toc] | [prev] | [next] | [standalone]

#41596

Interesting. Thanks!

On 20.03.2013, at 15:17, Ian Foote <ian@feete.org> wrote:

> On 20/03/13 13:38, Jan Oelze wrote:
> 
>> "Strings are compared lexicographically using the numeric equivalents
>> (the result of the built-in function ord()) of their characters. Unicode
>> and 8-bit strings are fully interoperable in this behavior."
> 
> This isn't true in python 3:
> 
> Python 3.2.3 (default, Oct 19 2012, 19:53:57)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> b'bytes' < 'unicode'
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> TypeError: unorderable types: bytes() < str()
> 
> Ian F
> -- 
> http://mail.python.org/mailman/listinfo/python-list

[toc] | [prev] | [next] | [standalone]

#41608

On 2013-03-20, franzferdinand <melo.dumoulin@hotmail.com> wrote:
>>>> "Monty" < "Python"
> True
>>>> "Z" < "a"
> True
>>>> "Monty" < "Montague"
>
> False
> What's the rule about that?

I don't know what "that" refers to in your question, but 'a' comes
before 'y' if that's what you're asking.

> Is it the number of letters or what?

Individual letters are compared until a mismatch is found.

-- 
Grant Edwards               grant.b.edwards        Yow! You were s'posed
                                  at               to laugh!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#41618

----

Courageous people can try to do something with the unicode
collation algorithm (see unicode.org). Some time ago, for the fun,
I wrote something (not perfect) with a reduced keys table (see
unicode.org), only a keys subset for some scripts hold in memory.

It works with Py32 and Py33. In an attempt to just see the
performance and how it "can react", I did an horrible mistake,
I forgot Py33 is now optimized for ascii user, it is no more
unicode compliant and I stupidely tested/sorted lists of French
words...

jmf

[toc] | [prev] | [next] | [standalone]

#41623

[Multipart message — attachments visible in raw view] — view raw

On 21 March 2013 06:40, jmfauth <wxjmfauth@gmail.com> wrote:

> ----
> [snip usual rant from jmf]


Franz, please pay no attention to jmf. He has become obsessed with a single
small regression in Python 3.3 in performance with how strings perform in a
very small domain that rarely shows up in practice (although as he has
demonstrated, it is easy to create a microbenchmark that makes it appear to
be much worse than it is).

The regression is a consequence of the decision in Python 3.3 to
*correctly* support the full range of Unicode characters whilst also
reducing the required memory where possible. In the vast majority of cases
this is a performance *improvement*. It is only "optimised for the ascii
user" in the sense that in the Unicode standard the pre-existing ASCII
characters only require 1 byte per code point and hence can be stored in
less memory than most other Unicode code points. The possible character
widths are 1, 2 and 4 bytes.

The actual regression occurs when concatentating/replacing/etc a character
to a string that is wider than any other character currently in the string.
In this situation the new string needs to be widened (increase the number
of bytes used by every character) which is a much more expensive operation
than simply creating a new string (which is what would happen if the
character was the same size or smaller).

It has been acknowledged as a real regression, but he keeps hijacking every
thread where strings are mentioned to harp on about it. He has shown no
inclination to attempt to *fix* the regression and is rapidly coming to be
regarded as a troll by most participants in this list.

Tim Delaney

[toc] | [prev] | [next] | [standalone]

#41720

On 20 mar, 22:02, Tim Delaney <tim.dela...@aptare.com> wrote:
> On 21 March 2013 06:40, jmfauth <wxjmfa...@gmail.com> wrote:
>
> > ----
> > [snip usual rant from jmf]
>


>
> It has been acknowledged as a real regression, but he keeps hijacking every
> thread where strings are mentioned to harp on about it. He has shown no
> inclination to attempt to *fix* the regression and is rapidly coming to be
> regarded as a troll by most participants in this list.
>

---------

I can not help to fix it, because it is "unfixable". It
is "unfixable", because this flexible string representation
is wrong by design.

jmf

[toc] | [prev] | [next] | [standalone]

#41745

On 23/03/2013 09:24, jmfauth wrote:
> On 20 mar, 22:02, Tim Delaney <tim.dela...@aptare.com> wrote:
>> On 21 March 2013 06:40, jmfauth <wxjmfa...@gmail.com> wrote:
>>
>>> ----
>>> [snip usual rant from jmf]
>>
>
>
>>
>> It has been acknowledged as a real regression, but he keeps hijacking every
>> thread where strings are mentioned to harp on about it. He has shown no
>> inclination to attempt to *fix* the regression and is rapidly coming to be
>> regarded as a troll by most participants in this list.
>>
>
> ---------
>
> I can not help to fix it, because it is "unfixable". It
> is "unfixable", because this flexible string representation
> is wrong by design.
>
> jmf
>

Of course it's fixable.  All you need do is write a PEP clearing stating 
what is wrong with the implementation detailed in PEP393 and your own 
proposed design.  I'm looking forward to reading this PEP.

Note that going backwards to buggier unicode implementations that 
existed in Python prior to version 3.3 is simply not an option.

-- 
Cheers.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#41780

On 23 mar, 17:17, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
> On 23/03/2013 09:24, jmfauth wrote:
>
>
>
>
>
>
>
>
>
> > On 20 mar, 22:02, Tim Delaney <tim.dela...@aptare.com> wrote:
> >> On 21 March 2013 06:40, jmfauth <wxjmfa...@gmail.com> wrote:
>
> >>> ----
> >>> [snip usual rant from jmf]
>
> >> It has been acknowledged as a real regression, but he keeps hijacking every
> >> thread where strings are mentioned to harp on about it. He has shown no
> >> inclination to attempt to *fix* the regression and is rapidly coming to be
> >> regarded as a troll by most participants in this list.
>
> > ---------
>
> > I can not help to fix it, because it is "unfixable". It
> > is "unfixable", because this flexible string representation
> > is wrong by design.
>
> > jmf
>
> Of course it's fixable.  All you need do is write a PEP clearing stating
> what is wrong with the implementation detailed in PEP393 and your own
> proposed design.  I'm looking forward to reading this PEP.
>
> Note that going backwards to buggier unicode implementations that
> existed in Python prior to version 3.3 is simply not an option.
>
> --
> Cheers.
>
> Mark Lawrence

------

The problem here is that this PEP 393 should not have been
created.
The first time I read it, I quickly understood, it can
not work!

This is illustrated by all the examples I give on this list.
In all the cases, I can explain why.

I never saw somebody beeing able to argue these examples are
wrong and/or explaining why they are wrong, except arguing
the flexible string representation exists!

jmf

[toc] | [prev] | [next] | [standalone]

#41781

On Mon, Mar 25, 2013 at 12:31 AM, jmfauth <wxjmfauth@gmail.com> wrote:
> The problem here is that this PEP 393 should not have been
> created.
> The first time I read it, I quickly understood, it can
> not work!

I fail to understand how something can "not work" when it is clearly
working, and very successfully too, in two different languages. All of
your complaints have been on the basis of *timings*, which really
means you're complaining about performance, not correctness. If you
can show any evidence that something actually is not *working*, please
do so (in a fresh thread, not in a hijacked one).

ChrisA

[toc] | [prev] | [next] | [standalone]

#41783

On 24/03/2013 13:31, jmfauth wrote:
>
> The problem here is that this PEP 393 should not have been
> created.
> The first time I read it, I quickly understood, it can
> not work!

How come you couldn't pursuade the Python devs that PEP393 was so flawed?

>
> This is illustrated by all the examples I give on this list.
> In all the cases, I can explain why.

IIRC you've never said that the implementation doesn't work.   You've 
repeatedly given micro benchmarks regarding performance and nothing else.

>
> I never saw somebody beeing able to argue these examples are
> wrong and/or explaining why they are wrong, except arguing
> the flexible string representation exists!

Sheer unadultered crap.  Was your education at the Dr Goebbels Institute?

>
> jmf
>


-- 
Cheers.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web