M.-A. Lemburg wrote:
> M.-A. Lemburg wrote:
>> Guido van Rossum wrote:
>>> Marc-Andre, how's the patch coming along?
>> I'm working on it.
>>
>> Since we only want equal compares to generate the warning,
>> I have to add a rich compare function to Unicode objects.
>
> Here's an initial version:
>
Jim Jewett schrieb:
> hash was just changed to support the common use of id, even though
> some people argued it was *really* a bug in the classes themselves.
> This is a similar situation.
Similar still different. In the case of __hash__ returning id(),
it is very clear what the intention of the
Guido van Rossum schrieb:
>> >__eq__ methods should always return True or False. They should
>> >only raise an exception if there is some internal error within
>> >one of the objects being compared -- they should never raise
>> >an exception because the other object is of an unexpe
On 8/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Michael Chermside schrieb:
> > I propose that we institute a new policy. The policy should state:
> >
> >__eq__ methods should always return True or False. They should
> >only raise an exception if there is some internal error withi
On 8/11/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis writes:
> > Now I looked at it, and think that the recipe is broken.
>
> Not broken, but perhaps wrongheaded. The recipe went out of its way
> to ensure that it would raise an exception of enum values from different
> enumer
Michael Chermside schrieb:
> Not broken, but perhaps wrongheaded. The recipe went out of its way
> to ensure that it would raise an exception of enum values from different
> enumerations were compared. There's nothing out there saying that this
> is a bad thing to do.
And it's actually fine for th
M.-A. Lemburg wrote:
> Guido van Rossum wrote:
>> Marc-Andre, how's the patch coming along?
>
> I'm working on it.
>
> Since we only want equal compares to generate the warning,
> I have to add a rich compare function to Unicode objects.
Here's an initial version:
http://sourceforge.net/tracker
Martin v. Löwis writes:
> Now I looked at it, and think that the recipe is broken.
Not broken, but perhaps wrongheaded. The recipe went out of its way
to ensure that it would raise an exception of enum values from different
enumerations were compared. There's nothing out there saying that this
is
Michael Chermside schrieb:
> I don't *strongly* object to this consensus, but if you haven't
> glanced at my original example, take a look - it might convince you.
> The proposed solution will not help with my example.
I ignored your example the first time because it was too complicated
to underst
Guido van Rossum schrieb:
> Me too, and that's what we'll do in py3k. But in 2.5, we're bound by
> the decisions we made in 1999-2000 about unicode. (Unless Martin has a
> convincing reason not to have a warning?)
Only the general anti-warning argument: it's not the developer which
will see the wa
Guido van Rossum wrote:
> Marc-Andre, how's the patch coming along?
I'm working on it.
Since we only want equal compares to generate the warning,
I have to add a rich compare function to Unicode objects.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#
On 8/11/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Thu, Aug 10, 2006 at 02:36:16PM -0700, Guido van Rossum wrote:
> > > On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
> > > > I'm in favour of having this __eq__ just return False. I don't think
> > > > the warning is
Guido writes:
> Alas, I have no idea what it does. Can you come up with an example
> that doesn't require enums and localization?
Sorry. Here's the short version:
Fact 1: Sometimes people create objects that raise exceptions when
compared for equality. Maybe it's a bad idea to do this, and object
Armin Rigo wrote:
> Hi,
>
> On Thu, Aug 10, 2006 at 02:36:16PM -0700, Guido van Rossum wrote:
>>> On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
I'm in favour of having this __eq__ just return False. I don't think
the warning is necessary, (...)
>>> +1
>> Can you expl
Hi,
On Thu, Aug 10, 2006 at 02:36:16PM -0700, Guido van Rossum wrote:
> > On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
> > > I'm in favour of having this __eq__ just return False. I don't think
> > > the warning is necessary, (...)
> >
> > +1
>
> Can you explain why you beli
M.-A. Lemburg wrote:
> Michael Chermside wrote:
>>> How about we change unicode-vs-str __eq__ to
>>> issue a warning (and return False) instead of raising
>>> UnicodeException?
>> [... Marc-Andre Lemburg agrees ...]
>>> Great! Now we need someone to volunteer to write a patch (which should
>>
On 8/10/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
> > I'm in favour of having this __eq__ just return False. I don't think
> > the warning is necessary, (...)
>
> +1
Can you explain why you believe that no warning is nece
On 8/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to
> > issue a warning (and return False) instead of raising
> > UnicodeException?
>
> I'm in favour of having this __eq__ just return False. I
Guido van Rossum wrote:
> On 8/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to
>>> issue a warning (and return False) instead of raising
>>> UnicodeException? That won't break much code (it's unlike
Michael Chermside wrote:
>> How about we change unicode-vs-str __eq__ to
>> issue a warning (and return False) instead of raising
>> UnicodeException?
> [... Marc-Andre Lemburg agrees ...]
>> Great! Now we need someone to volunteer to write a patch (which should
>> include doc and NEWS update
On 8/10/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> See also my example from the beginning of this thread
> (http://mail.python.org/pipermail/python-dev/2006-August/067978.html).
> The example wasn't from real code, but it WAS quite plausible --
> straightforward use of a popular Python Cook
Hi,
On Thu, Aug 10, 2006 at 09:11:42PM +0200, "Martin v. L?wis" wrote:
> I'm in favour of having this __eq__ just return False. I don't think
> the warning is necessary, (...)
+1
Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
Michael Urman writes:
> I strongly believe that unicode vs str here is the symptom and not the
> actual problem. The comparison between two non-us-ascii str/unicode
> instances is but one of many ways to raise an exception during
> comparison.
[... example ...]
> Yes this is made up code. Bu
Guido van Rossum schrieb:
> Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to
> issue a warning (and return False) instead of raising
> UnicodeException?
I'm in favour of having this __eq__ just return False. I don't think
the warning is necessary, and believe that people will
On 8/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to
> > issue a warning (and return False) instead of raising
> > UnicodeException? That won't break much code (it's unlikely that
> > people *depend*
Guido van Rossum wrote:
> On 8/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> I'd suggest that we still inform the programmers of the problem
>> by issuing a warning (which they can then silence at will),
>> maybe a new PyExc_UnicodeWarning.
>
> Hmm... Here's an idea... How about we change uni
On 8/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> I'd suggest that we still inform the programmers of the problem
> by issuing a warning (which they can then silence at will),
> maybe a new PyExc_UnicodeWarning.
Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to
issue a war
On 8/10/06, Michael Urman <[EMAIL PROTECTED]> wrote:
> I strongly believe that unicode vs str here is the symptom and not the
> actual problem.
No. Everywhere when __eq__ fails, we can safely tell the user that
it's a bug in their __eq__ that they should fix (maybe by making it
return False when t
On 8/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > But since people are adamant that they want this in sooner, I suggest
> > that to minimize breakage we could make an exception for str-unicode
> > comparisons.
> > What do people think?
>
> I'd suggest that we still
Guido van Rossum wrote:
>
> - the exception could be narrowed even further by only suppressing the
> exception when startkey and key are both either str or unicode
> instances.
>
I always assumed dictionaries would work exactly like this. So, at least
it would now work as I had always expected
Guido van Rossum wrote:
> I've been happily ignoring python-dev for the last three weeks or so,
> and Neal just pointed me to some thorny issues that are close to
> resolution but not quite yet resolved, yet need to be before beta 3 on
> August 18 (Friday next week).
>
> Here's my take on the dict
"Jim Jewett" <[EMAIL PROTECTED]> writes:
>> It wasn't my idea to stop ignoring exceptions in dict lookups; I would
>> gladly have put this off until Py3k, where the main problem
>> (str-unicode __eq__ raising UnicodeError) will go away.
>
>> But since people are adamant that they want this in soon
32 matches
Mail list logo
