Is 0 > None?? (fwd)

[Alex Martelli]

<gbreed at cix.compulink.co.uk> wrote in message
news:9mvth3$h1m$1 at thorium.cix.co.uk...
> In article <9mvpo606f7 at enews2.newsguy.com>, aleax at aleax.it (Alex Martelli)
> wrote:
>
> > It seems to me that nothing bad is happening (even with the
> > debatable choice of 'ascii' as the default encoding, which
> > I've restored for the purpose of this test from the latin-1
> > I normally use in my sitecustomize.py -- I thought your
> > observation might stem from such issues).  I must be
> > missing something here.
>
> PythonWin 2.0 (#8, Oct 19 2000, 11:30:05) [MSC 32 bit (Intel)] on win32.
> Portions Copyright 1994-2000 Mark Hammond (MarkH at ActiveState.com) - see
> 'Help/About PythonWin' for further copyright information.
> >>> 'ciao'<'ciaó'
> 1
> >>> u'ciaó'<'ciaó'
> Traceback (innermost last):
>   File "<interactive input>", line 1, in ?
> UnicodeError: ASCII decoding error: ordinal not in range(128)

Well, yes -- though the problem is not with the Unicode strings
(as I've shown, you can perfectly well compare them to anything:-)
but with the _widening_ of a plain string into a Unicode one (for
whatever operation may be required -- comparison or otherwise),
when the default encoding is set for strict checking AND the
plain string in question violates the chosen default encoding.

If you handle plain strings that encode Unicode ones by an
encoding different than ascii, you're probably better off
setting your default-encoding to other-than-ascii in your
sitecustomize.py, as I mentioned -- whenever you could find
yourself widening one of your plain string into a Unicode
one (be it for comparison, or for any other purpose).

The issue, it seems to me, is quite different wrt complex
numbers -- in that case, there is _no_ setting that lets you
default-sort an heterogeneous list that may contain a complex
number somewhere.  The Unicode issue might be finessed in
several ways.  The complex-number one is starker IMHO.


Alex