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
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
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> 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 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 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
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
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:
>> 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:
> 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
Bob Ippolito <[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,
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 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
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:
>>
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
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
Michael Hudson <[EMAIL PROTECTED]> wrote:
>
> I'd say it's more to do with __eq__. It's a strange __eq__ method
> that raises an Exception, IMHO.
Not entirely. Any type that supports invalid values (e.g. IEEE 754)
and is safe against losing the invalid state by accident needs to
raise an except
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
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
>
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
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
-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.
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
"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
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
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-
26 matches
Mail list logo
