Python-Dev May 2004

python-dev@python.org

86 participants
125 discussions

Start a nNew thread

Re: [Python-Dev] Patch for long-standing bug in socket module

by Ralf W. Grosse-Kunstleve

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.

16 years

RE: [Python-Dev] cmp(x,x)

by Michael Chermside

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

16 years

Patch for long-standing bug in socket module

by Ralf W. Grosse-Kunstleve

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

16 years

2.3.4 release this thursday

by Anthony Baxter

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.

16 years

PEP 320

by Scott David Daniels

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

16 years

Re: .pth files in current or script directory

by Richard Cooper

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

16 years

RE: [Python-Dev] cmp(x,x)

by Raymond Hettinger

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

16 years

RE: [Python-Dev] cmp(x,x)

by Jewett, Jim J

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

16 years

RE: [Python-Dev] cmp(x,x)

by Jewett, Jim J

[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

16 years

Re: [Python-Dev] cmp(x,x)

by Gustavo Niemeyer

> [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

16 years

← Newer
1
2
3
4
5
6
7
...
13
Older →

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev May 2004