I'm changing the subject line because I want to convince everyone that
the problem being discussed in the "unicode hell" thread has nothing
to do with unicode and strings. It's all about dicts.
I have not observed real breakage in my own code, but I will present
a sample of made-up-but-completely-
Michael Chermside <[EMAIL PROTECTED]> writes:
> I'm changing the subject line because I want to convince everyone that
> the problem being discussed in the "unicode hell" thread has nothing
> to do with unicode and strings. It's all about dicts.
I'd say it's more to do with __eq__. It's a strang
"Michael Hudson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Michael Chermside <[EMAIL PROTECTED]> writes:
>
>> I'm changing the subject line because I want to convince everyone that
>> the problem being discussed in the "unicode hell" thread has nothing
>> to do with unicode an
Terry Reedy wrote:
> "Michael Hudson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Michael Chermside <[EMAIL PROTECTED]> writes:
>>
>>> I'm changing the subject line because I want to convince everyone that
>>> the problem being discussed in the "unicode hell" thread has nothin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 4, 2006, at 11:43 AM, M.-A. Lemburg wrote:
> How about generating a warning instead and then go for the exception
> in 2.6 ?
From the perspective of wanting to avoid blog entries in 2007
railing against our gratuitous breakages in Python 2.
Marc-Andre Lemburg writes:
> How about generating a warning instead and then go for the exception
> in 2.6 ?
Agreed. Michael Hudson's explanation convinced me.
-- Michael Chermside
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
There's one problem with generating a warning for 2.5, and that is the
same problem as generating a warning for possible packages that lack an
__init__.py; users may start to get a bunch of warnings, and be unaware
of how to suppress them.
All in all though, I'm +0 on the warning, and +1 on it no
On Fri, 04 Aug 2006 11:23:10 -0700, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
>There's one problem with generating a warning for 2.5, and that is the
>same problem as generating a warning for possible packages that lack an
>__init__.py; users may start to get a bunch of warnings, and be unaware
>
Hi!
Terry Reedy wrote:
> The fundamental axiom of sets and hence of dict keys is that any
> object/value either is or is not a member (at any given time for 'mutable'
> set collections). This requires that testing an object for possible
> membership by equality give a clean True or False answe
Paul Colomiets <[EMAIL PROTECTED]> wrote:
> Well it's not recomended to mix strings and unicode in the
> dictionaries
> but if we mix for example integer and float we have the same thing. It
> doesn't raise exception but still it is not expected behavior for me:
> >>> d = { 1.0: 10, 2.0: 20 }
> t
On Aug 4, 2006, at 12:51 PM, Giovanni Bajo wrote:
> Paul Colomiets <[EMAIL PROTECTED]> wrote:
>
>> Well it's not recomended to mix strings and unicode in the
>> dictionaries
>> but if we mix for example integer and float we have the same
>> thing. It
>> doesn't raise exception but still it is n
Giovanni Bajo wrote:
> Paul Colomiets <[EMAIL PROTECTED]> wrote:
>
>
>> Well it's not recomended to mix strings and unicode in the
>> dictionaries
>> but if we mix for example integer and float we have the same thing. It
>> doesn't raise exception but still it is not expected behavior for me:
>>
M.-A. Lemburg wrote:
> Terry Reedy wrote:
>> "Michael Hudson" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> Michael Chermside <[EMAIL PROTECTED]> writes:
>>>
I'm changing the subject line because I want to convince everyone that
the problem being discussed in the "un
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Fri, 04 Aug 2006 11:23:10 -0700, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >There's one problem with generating a warning for 2.5, and that is the
> >same problem as generating a warning for possible packages that lack an
> >__init__.py; users
M.-A. Lemburg schrieb:
> Python just doesn't know the encoding of the 8-bit string, so can't
> make any assumptions on it. As result, it raises an exception to inform
> the programmer.
Oh, Python does make an assumption what the encoding is: it assumes
it is the system encoding (i.e. "ascii"). The
Martin v. Löwis wrote:
> M.-A. Lemburg schrieb:
>> Python just doesn't know the encoding of the 8-bit string, so can't
>> make any assumptions on it. As result, it raises an exception to inform
>> the programmer.
>
> Oh, Python does make an assumption what the encoding is: it assumes
> it is the s
M.-A. Lemburg schrieb:
> Hiding programmer errors is not making life easier in the
> long run, so I'm -1 on having the equality comparison return
> False.
There is no error to hide here. The objects are inequal, period.
> Instead we should generate a warning in Python 2.5 and introduce
> the exce
Martin v. Löwis wrote:
> M.-A. Lemburg schrieb:
>> Hiding programmer errors is not making life easier in the
>> long run, so I'm -1 on having the equality comparison return
>> False.
>
> There is no error to hide here. The objects are inequal, period.
And in the case of dicts it hides errors rand
Martin v. Löwis wrote:
> M.-A. Lemburg schrieb:
>> Failure to decode a string doesn't imply inequality.
>
> If the failure is "these bytes don't have a meaningful character
> interpretation", then the bytes are *clearly* not equal to
> some character string.
>
>> It implies
>> that the programmer
M.-A. Lemburg schrieb:
> If the programmer writes:
>
> x = 'äöü'
> y = u'äöü'
> ...
> if x == y:
> do_something()
>
> then he clearly has had the intention to compare two character
> strings.
Programmers make all kinds of mistakes when comparing objects,
assuming that things ought to be equa
Martin> Programmers make all kinds of mistakes when comparing objects,
Martin> assuming that things ought to be equal that actually aren't:
py> 1.6/math.pi*math.pi == 1.6
False
By extension, perhaps Computer Science departments should begin offering
Unicode Analysis as an advance
M.-A. Lemburg wrote:
> Hiding programmer errors is not making life easier in the
> long run, so I'm -1 on having the equality comparison return
> False.
I don't see how this is greatly different from, e.g.
[1, 2] == (1, 2)
returning False. Comparing things of different types
may or may not i
Martin v. Löwis wrote:
> M.-A. Lemburg schrieb:
>> Note that we are not discussing changing the behavior of the
>> __eq__ comparison between strings and Unicode, since this has
>> always been to raise exceptions in case the automatic propagation
>> fails.
>
> Not sure what you are discussing: This
Martin v. Löwis wrote:
> M.-A. Lemburg schrieb:
>> Python just doesn't know the encoding of the 8-bit string, so can't
>> make any assumptions on it. As result, it raises an exception to inform
>> the programmer.
>
> Oh, Python does make an assumption what the encoding is: it assumes
> it is the s
24 matches
Mail list logo
