Mailman 3 May 2004 - Python-Dev

hash comments in interactive interpreter
by John Belmonte 21 May '04

21 May '04

Hello, I'm wondering what the rationale is for hash comments yielding a continuation prompt (PS2) in the interactive interpreter. I'd like to put such comments in interactive examples, but the output is hard to follow: >>> a = 5 >>> # and now for some multiplication ... >>> a * 10 50 What I would prefer can, ironically, be shown by the interactive interpreter emulator: >>> import code >>> code.interact() Python 2.3.3 (#2, May 1 2004, 06:12:12) [GCC 3.3.3 (Debian 20040401)] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> a = 5 >>> # and now for some multiplication >>> a * 10 50 Another apparent inconsistency is that end of line comments don't behave this way: >>> a = 5 >>> a * 10 # end of line comment 50 Is there something preventing this anomaly in the interactive interpreter from being corrected? -John -- http:// ift ile.org/

3 2

sets, scanf
by Mark.Lake＠aigfpc.com 21 May '04

21 May '04

Just a couple of modest suggestions for new features. Nothing earth-shattering here but I think these would give a lot of bang for the buck. 1. sscanf functionality: I know this has been discussed for years, but it's time to bite the bullet and do it. 2. Sets are a useful addition to the language, but sorted sets (and dictionaries) would be more useful. C++/Java/C# all provide these types. In particular I'd like to see: A. Dictionaries support union, intersection, and symmetric difference operations as sets do. B. (Sorted) Dictionaries and sets support slicing operations: E.g. dict['a':'z'] should return a sub-dictionary with all the keys between 'a' and 'z'. C. Binary searching for items in sorted sequence and mapping types. D. Ability to handle multiple getitems at once in sequence and mapping types (Akin to what can be done in numarray). Certainly there is no good reason why lists/tuples shouldn't support list[iterable] (not to be confused with list(iterable)) which returns or dictionaries support something like dict.getm(iterable). Mark Lake

2 1

Relative vs. absolute imports
by M.-A. Lemburg 20 May '04

20 May '04

I have a few questions about the PEP 328 which I'd like discussed: * Why do we absolutely need to change the current scheme of 'local, then absolute' for name resolution ? In the past I have often had the case where I wanted to move Python software written as top-level modules into their own package. The current logic makes this painless; the proposed move to 'absolute only' introduces serious editing which is bound to be error-prone. I don't object absolute imports at all, but I like the possibilitiy to package'ify existing Python module/module sets by simply copying them into a newly created package directory. Note that Python's own name lookup behaviour is very similar to the existing import scheme (nested scopes left aside). * How will the proposed 'absolute only' strategy affect the __import__() API ? This is of special concern since quite a few applications out there rely on __import__() having the existing semantics and a change would cause these applications to fail. One such instance is the encodings package search function, which relies on first looking in the package for a suitable codec and then scans for a top-level installation. * Will the DeprecationWarning only be raised for uses of 'import xyz' and 'from xyz import a' or also for __import__() ? * How do these semantics changes affect importers that hook into __import__ ? (imputil.py, ihooks.py, etc.) * What's the affect on zip imports or tools like py2exe, McMillan's installer, etc. ? BTW, is any of this already implemented to play with ? Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 17 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, Göteborg, Sweden 20 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

8 22

RE: [Python-Dev] Relative vs. absolute imports
by Michael Chermside 20 May '04

20 May '04

Phillip Eby: > Yes it is, actually. You can answer the "print foo" question simply by > inspecting the code of the function that contains it. (And if it's not > in a function, you know it's a global, unless it's never assigned, in > which case it's a builtin.) > > But the "import foo" question cannot be answered by referring to the > source of the module in which it occurs. Bernhard Herzog: > Of course it's different, but it's not all that much different. To > determine whether an import is relative or not you look into the > directory containing the module with the import statement. Shouldn't be > more than a few keystrokes in a decent editor. On the contrary, I find a big difference between something which can be learned by inspecting the source and something which requires access to the filesystem the source is running on. Many times that filesystem isn't even available: "Susan emailed me this module she uses to fnob large datasets, and I can't understand why it isn't working for me!" -- Michael Chermside

2 1

Re: [Python-Dev] Access to generator type
by James William Pye 20 May '04

20 May '04

On 05/10/04:19/1, Tim Peters wrote: > Possibly, if someone wants it enough to make a patch (including doc > changes). There are many types that aren't exposed at the C level, BTW. > Advertising their internals has an inhibiting effect on evolution. The > generator type has been around long enough w/o change that the value in > keeping it private has diminished. Okay, here's a preliminary patch with genobject.[ch]: http://sourceforge.net/tracker/index.php?func=detail&aid=957398&group_id=54… I assumed(yay) that py-dev would want it inline with how other core objects are managed(*object.[ch]), so I spun it out into its own files in /Object/genobject.c and /Include/genobject.h.. Of course, genobject.c references eval_frame(in ceval.c), which raises a problem; currently it is resolved in my tree by making a wrapper in ceval.c(PyEval_EvaluateFrame(){eval_frame()}). This is unlikely to be an acceptable solution, and I'm not sure how py-dev wants this to be handled. Keep it in its own genobject.[ch] and get eval_frame how? Or keep it in ceval.[ch]? The latter seems to be the right choice to me, but less pertty. Regards, James William Pye

1 0

python 2.3.4 delayed for a week
by Anthony Baxter 20 May '04

20 May '04

Due to circumstances beyond our control, Thomas is unable to cut the windows installer for 2.3.4 for a week - we'll delay the release until he's back on deck. -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

__str__ does not default to __repr__ if a base class has __str__
by Edward C. Jones 20 May '04

20 May '04

# In the code below, "a.__str__()" does not default to "a.__repr__() as # might be expected. It finds the "__str__" in the base class X. The # Reference Manual, section 3.3.1, says: # If a class defines __repr__() but not __str__(), then __repr__() is # also used when an 'informal' string representation of instances of # that class is required. # If the reader is in lawyer mode, the documentation is correct. # Is the current behavior what was intended? What should the behavior be? class X(object): def __str__(self): return 'str for X' def __repr__(self): return 'repr for X' class A(X): def __repr__(self): return 'repr for A' # __str__ = __repr__ x = X() a = A() print x.__str__() print x.__repr__() print a.__str__() print a.__repr__()

4 4

Re: [Python-Dev] cmp(x,x)
by Robert Ledwith 19 May '04

19 May '04

> Armin Rigo wrote: > ... > Unless there are serious objections I suggest to (i.e. I plan to) remove the > short-cut in PyObject_RichCompareBool() -- performance is probably not an > issue here -- and then review all built-in comparison methods and make sure > that they return "equal" for identical objects. I have a serious objection to this because it is a major performance problem. In my Python-2.3.3 code I had implemented an equivalent comparison test because of a performance bottleneck. The bottleneck involved looking up tuples in huge dictionaries of tuples (millions of tuples per dictionary). Putting in a simple equality test reduced the run time of programs by as much as 50%; since each program took days to run, this was a substantial improvement for me. I was considering posting this as a bugfix when I discovered that it had already been incorporated into the CVS. For the sake of people such as myself who use Python to perform large-scale symbolic processing, please consider other approaches to solving the NaN situation before removing this code. :s Robert H. Ledwith INET: rledwith(a)cas.org :s Unless explicitly stated to the contrary, nothing in this posting should :s be construed as representing my employer's opinions.

1 0

cmp(x,x)
by Armin Rigo 19 May '04

19 May '04

Hello, A minor semantic change that creeped in some time ago was an implicit assumption that any object x should "reasonably" be expected to compare equal to itself. The arguments are summarized below (should this be documented, inserted in NEWS, turned in a mini-PEP a posteriori ... ?). The point is that comparisons now behave differently if they are issued by C or Python code. The expression 'x == y' will always call x.__eq__(y), because in some settings (e.g. Numeric) the result is not just True or False but an arbitrary object (e.g. a Numeric array of zeroes and ones). You cannot just say that 'x == x' should return True, because of that. So the behavior of PyObject_RichCompare() didn't change. On the other hand, when C code does a comparison it uses PyObject_RichCompareBool(), meaning it is only interested in a 1 or 0 answer. So PyObject_RichCompareBool() is where the shortcut about comparing an object with itself has been inserted. The result is the following: say x has a method __cmp__() that always returns -1. >>> x == x # x.__cmp__() is called False >>> x < x # x.__cmp__() is called True >>> cmp(x,x) # x.__cmp__() is NOT called 0 >>> [x] == [x] # x.__cmp__() is NOT called True The only way to explain the semantic is that the expression 'x == x' always call the special methods, but built-in functions are allowed to assume that any object compares equal to itself. In other words, C code usually checks that objects are "identical or equal", which is equalivalent to the Python expression 'x is y or x == y'. For example, the equality of lists now works as follows: def __eq__(lst1, lst2): if len(lst1) != len(lst2): return False for x, y in zip(lst1, lst2): if not (x is y or x == y): return False else: return True Should any of this be documented? An alternative behavior would have been to leave PyObject_RichCompareBool() alone and only insert the short-cut on specific object types' comparison methods on a case-by-case basis. For example, identical lists would just compare equal, without going through the loop comparing each element. This would remove the surprize of x.__cmp__(x) being not always called. The semantics would be easier to explain too: two lists are equal if they are the same list or if elements compare pairwise equal. We would have (with x as above): >>> cmp(x,x) # x.__cmp__(x) is called -1 >>> [x] == [x] False # because the lists contain a non-equal element >>> lst = [x]; lst == lst True # because it is the same list Finally, whatever the final semantic is, we should make sure that existing built-in objects behave in a consistent way. Of course I'm thinking about floats: on my Linux box, >>> f = float('nan') >>> cmp(f,f) 0 # because f is f >>> f == f False # because float.__eq__() is called Note that as discussed below the following behavior is *expected* and in accordance with standards: >>> float('nan') is float('nan') False >>> float('nan') == float('nan') False # not the same object Unless there are serious objections I suggest to (i.e. I plan to) remove the short-cut in PyObject_RichCompareBool() -- performance is probably not an issue here -- and then review all built-in comparison methods and make sure that they return "equal" for identical objects. -+- summary of arguments that lead to the original change (in cvs head). The argument in favor of the change is to remove the complex and not useful code trying to compare self-recursive structures: for example, in some setting comparing __builtin__.__dict__ with itself would trigger recursive comparison of __builtin__.__dict__ with itself in an endless loop. The complex algorithm was able to spot that. The new semantics immediately assume __builtin__.__dict__ to be equal to itself. Removing the complex algorithm means that you will now get an endless loop when comparing two *non-identical* self-recursive structures with the same shape, which is most probably not a problem in practice (on the contrary this implicit algorithm did hide a bug in one of my program). The argument _against_ used to be that e.g. it makes sense that the float value 'nan' should be different from itself, as various standards require. This argument does not apply in Python: these standards are about comparing *values*, not objects, so it makes perfect sense to say that even if x is the result of a computation that yielded an unknown answer 'nan', this answer is still equal to itself; what it is probably not equal to is *another* 'nan' which was obtained differently. In other words *two* float objects both containing 'nan' should be different, but *one* 'nan' object is still equal to itself. This is sane as long as no code considers 'nan' as a singleton, or tries to reuse 'nan' objects for different 'nan' values. -+- Armin

5 12

Re: [Python-Dev] cmp(x,x)
by Armin Rigo 19 May '04

19 May '04

Hello Tim, On Tue, May 18, 2004 at 11:24:50PM -0400, Tim Peters wrote: > > >>> float('nan') is float('nan') > > False > > That result simply isn't defined, even on platforms where float('nan') > doesn't blow up: floats are immutable objects, and outside of interning > strings, Python doesn't define anything about the identity of immutable > objects returned from computation. Ok, I won't go into that argument again then. Raymond told me that the PyObject_RichCompareBool() short-cut is essential for performance, as a very large number of internal comparisons end up comparing identical objects (e.g. with dicts). I don't really care about what occurs with float('nan'), but it seems marginally strange that the outcome could, with some compilers, depend on the way you compare them: even though x == x and cmp(x,x) are known to do different things, as rich comparison goes, you wouldn't expect this to show up with floats. But anyway that's fine by me (and could be easily fixed by patching float_compare and float_richcompare to check for identity). A slightly stranger irregularity (though not a problem in general) is that comparing two objects of user-defined classes may invoke neither the __cmp__ nor the __eq__ special method at all. It should at least be documented somewhere, in my opinion. The language reference currently explicitely states that x==y calls x.__eq__(y) and falls back to y.__eq__(x). Armin

1 0