Mailman 3 May 2004 - Python-Dev

Forum notify
by Bwarsaw 27 May '04

27 May '04

2 1

Re: [Python-Dev] Patch for long-standing bug in socket module
by Ralf W. Grosse-Kunstleve 26 May '04

26 May '04

In my opinion this is a critical bug. For people in science it is very sad that Python 2.3 has this problem under IRIX.

2 1

RE: [Python-Dev] cmp(x,x)
by Michael Chermside 26 May '04

26 May '04

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

1 0

Patch for long-standing bug in socket module
by Ralf W. Grosse-Kunstleve 26 May '04

26 May '04

On May 22 I submitted a patch to fix this long-standing bug: https://sourceforge.net/tracker/?func=detail&aid=728330&group_id=5470&atid=… 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

3 2

2.3.4 release this thursday
by Anthony Baxter 25 May '04

25 May '04

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.

3 3

PEP 320
by Scott David Daniels 25 May '04

25 May '04

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

2 1

Re: .pth files in current or script directory
by Richard Cooper 25 May '04

25 May '04

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

1 0

RE: [Python-Dev] cmp(x,x)
by Raymond Hettinger 25 May '04

25 May '04

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

1 0

RE: [Python-Dev] cmp(x,x)
by Jewett, Jim J 25 May '04

25 May '04

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

1 0

RE: [Python-Dev] cmp(x,x)
by Jewett, Jim J 25 May '04

25 May '04

[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

1 0