Raymond:
> Forgive me, but perhaps a Letterman style top ten list may be a better
> way to summarize what I've heard so far.
*grin*
Nice. And in case I wasn't clear before... you're right about what
to do with the code, I'm only wondering about how to cleanly and
clearly tell users when calls to their user-defined __eq__ might
not occur.
-- Michael Chermside
On May 22 I submitted a patch to fix this long-standing bug:
https://sourceforge.net/tracker/?func=detail&aid=728330&group_id=5470&ati...
My hope was that this fix will make it into Python 2.3.4 final
but so far nobody is paying attention. Could someone please have
a look and let me know if there are any concerns? As it stands
Python as distributed is near useless under SGI's IRIX because
the socket module doesn't compile. My patch fixes this problem.
The danger of introducing undesirable side effects is minimal
because all changed are surrounded by very specific #ifdef's.
I've tested the patch under three different OS levels with
three different compiler versions.
Thanks,
Ralf
Thomas is back on deck, so I'm aiming to do the 2.3.4 release
this Thursday (AU time).
Anthony
--
Anthony Baxter <anthony(a)interlink.com.au>
It's never too late to have a happy childhood.
In <http://www.python.org/peps/pep-0320.html>:
...
Planned features for 2.4
...
PEP 328: Imports: Multi-line and Absolute/Relative. (Possibly
the absolute/relative stuff is too controversial and will be
pushed off to 2.4.)
...
Pushed off to 2.4 is not the best possible description for a feature
list for 2.4 :-)
-Scott David Daniels
Scott.Daniels(a)Acm.Org
From: Richard Cooper <anon(a)spam-trap.richardcooper.net>
Date: Wed May 19, 2004 1:34:12 pm Europe/London
To: python-dev(a)python.org
Subject: Re: .pth files in current or script directory
Seems this message got lost somewhere. So subscribing and resending.
Greg Ewing wrote:
> Richard Cooper <anon at server15.ukservers.net>:
>
> > When a module is imported, its import search path includes
everything it
> > does now PLUS the directory that is the top of the module's
enclosing
> > package structure.
>
> I don't see how that changes anything, since in order to get
> imported in the first place, the module's top-level package has
> to already be on the module search path somehow.
Sorry, slip of the brain. I meant "When a module is executed ..."
Aahz wrote:
> What's wrong with PEP 328?
Nothing, I think it's great. However it talks about making import
statement
absolute by default (searching sys.path only) without worrying about
how a
package gets on sys.path in the first place.
Currently a module can't import (absolutely) from it's own package
unless:
1) Its package is in one of a few special places (like site-packages)
2) The package is in PYTHONPATH
3) The module does some sys.path tinkering before the import
None of these are great solutions. My initial problem was that I picked
the
PYTHONPATH solution which (as you all know) turns out to be a real pain
when working on cvs branches.
If the top of the containing package got added to sys.path when a module
is executed then importing (absolutely) from your own package would
(I think) just work. And given that PEP 328 is going to encourage
absolute
imports and is going to be changing import semantics anyway, I think
this
would be a nice feature to have.
Rich
Forgive me, but perhaps a Letterman style top ten list may be a better
way to summarize what I've heard so far.
Proposal: Remove 8 lines of code discussed and approved by Raymond,
Tim, Guido, and Armin at PyCon. Replicate those lines and push them
down in every object known to man.
Advantages:
10) Facilitating insane use cases
9) Increasing the size of code base
8) Avoiding that silly concept of code factoring
7) Reducing performance
6) Breaking foolish invariants like "[x]==[x] and x in [x]"
5) Tricking myself into thinking that some sort of consistency has been
achieved though some existing calls to Py_RichCompareBool() already have
their own identity checks slightly upstream of the call.
. . .
And the number one reason for reverting good code is:
It feels so groovy to call something a hack!
Hopefully you find this funny and use it help get things back on course.
With so many contrarians the mailing list, it's nearly impossible to get
agreement on the simplest things. It's amazing how much support there
is for something with no practical use cases.
Raymond
Michael Chermside:
[Where PyObject_RichCompareBool is called, and the is shortcut
might be a problem]
Most of these operations -- including the container comparison --
are not well-defined if "is" does not imply equality.
> I would intuitively expect that any contained objects
> with customized comparison methods would have those methods
> invoked.
Yes, but you couldn't reliably predict the order they would
be compared (I *choose* to start with the least significant!
Oh yeah? Well I timsort with much galloping!), so inconsistent
results are not guaranteed.
The real problem is that you won't get the expected side effects.
> I'm tending to think it's best to put the test for identity in
> PyObject_RichCompareBool, but then how do we explain (in simple
> terms) when user-defined comparison methods are invoked and when
> they're not necessarily?
Say that Python only promises to make the comparisons you explicitly
ask for. Implicit comparisons (including cmp, sort, and comparisons
between subobjects) may be optimized away. For
example:
a < b
will compare a and b, but:
[1, a] < [2, b]
or even:
[a] < [b]
might not.
-jJ
[Jim J Jewett]
>> CVS has previously restricted the shortcut to those two,
>> but I agree it should be all or nothing.
[Tim Peters]
> The rich comparison PEP explicitly promised that, for example,
> x <= y is not necessarily the same as "x < y or x == y":
> ...it's also not kosher to infer x != y is False from
> that x == y is True.
With consistent orderings, "x <= y" is strictly weaker than
"x < y or x == y"; they differ only when a pair of objects
don't know *which* of "<" and "==" is true.
If we do not assume consistency, then "is" does not even
imply "==", let alone "not !="
> Any shortcuts based on object identity are optimizations,
> and dubious ones
Agreed.
> because they violate promises made in that PEP.
PEP 207 http://www.python.org/peps/pep-0207.html said that
you can't (generally) reason from one rich compare to
another. It said nothing about reasoning from "is" to any
of the comparisons directly. So this optimization may
violate the spirit of __eq__, but it doesn't violate the
letter of the PEP.
> There's a strong pragmatic ("go fast") case for starting to
> infer "x == y" and "not x != y" from "x is y", but that
> doesn't extend to inferring others from "x is y"
For normal objects, consistency holds.
When consistency does not hold, even Py_EQ and Py_NE are wrong.
Doing (only) the other operations correctly won't fix the whole
program; it will just make the bugs less obvious (and therefore
harder to catch).
-jJ
> [Greg Ewing]
> >> What if the list contains a NaN?
>
> [Armin Rigo]
> > Uh, right. The whole issue with NaNs is muddy. Let's focus on Numeric as
> > a much saner example of why you need 'a==a' to return something else than
> > True.
>
> Yes. Please <wink>.
I belive that either my question was misinterpreted, or I'm
missing something.
I'm not suggesting to limit 'a==a' to return True/False only. I'm
suggesting to introduce a shortcut in the *list* comparison (more
specifically, in list_richcompare), since this is what is
currently being done, but with a more expensive logic.
Going through the function, in a case where v is w and op is
either Py_EQ or Py_NE, we have
1) Both objects are lists, go on.
2) Both objects have the same size, go on.
3) Searching for the first index where items are different, using
PyObject_RichCompareBool(), won't find anything. Go on.
4) No more items to compare. Check sizes.
5) Sizes match. Check comparison operator.
6) Return either Py_True or Py_False.
This whole logic might be replaced by simply:
if (v == w && (op == Py_EQ || op == Py_NE)) {
res = (op == Py_EQ ? Py_True : Py_False);
Py_INCREF(res);
return res;
}
--
Gustavo Niemeyer
http://niemeyer.net
