Mailman 3 February 2007 - Python-Dev

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 04 Feb '07

04 Feb '07

Patch / Bug Summary ___________________ Patches : 423 open ( +2) / 3553 closed ( +4) / 3976 total ( +6) Bugs : 963 open (+20) / 6479 closed ( +8) / 7442 total (+28) RFE : 260 open ( +0) / 250 closed ( +0) / 510 total ( +0) New / Reopened Patches ______________________ ConfigParser getboolean() consistency (2007-01-28) http://python.org/sf/1646432 opened by Tal Einat gzip.GzipFile has no name attribute (2007-01-29) http://python.org/sf/1647484 opened by Lars Gustäbel proxy_bypass in urllib handling of <local> macro (2007-01-30) http://python.org/sf/1648102 opened by Anthony Tuininga pty.fork() python implementation leaks the slave fd (2007-01-31) CLOSED http://python.org/sf/1648435 opened by John Levon Adding support for _Bool to ctypes as c_bool (2007-01-31) http://python.org/sf/1649190 opened by David Remahl configHandler support for raw data (2007-02-01) http://python.org/sf/1650174 opened by Tal Einat Patches Closed ______________ file -> open in stdlib (2007-01-25) http://python.org/sf/1644218 closed by gbrandl compiler.pycodegen causes crashes when compiling 'with' (2007-01-18) http://python.org/sf/1638243 closed by gbrandl Add aliases for latin7/9/10 charsets (2007-01-13) http://python.org/sf/1634778 closed by gbrandl pty.fork() python implementation leaks the slave fd (2007-01-31) http://python.org/sf/1648435 closed by gbrandl New / Reopened Bugs ___________________ os.access now returns bool but docstring is not updated (2007-01-27) CLOSED http://python.org/sf/1645944 opened by Seo Sanghyeon Dict lookups fail if sizeof(Py_ssize_t) < sizeof(long) (2007-01-27) http://python.org/sf/1646068 opened by ked-tao ctypes.string_at(buf, 0) is seen as zero-terminated-string (2007-01-28) http://python.org/sf/1646630 opened by Johannes Hölzl datetime.fromtimestamp fails with negative fractional times (2007-01-29) http://python.org/sf/1646728 opened by James Henstridge os.path, %HOME% set: realpath contradicts expanduser on '~' (2007-01-29) http://python.org/sf/1646838 opened by wrstl prmpft cookielib.CookieJar does not handle cookies when port in url (2007-01-29) CLOSED http://python.org/sf/1647037 opened by STS zero-length match confuses re.finditer() (2007-01-29) http://python.org/sf/1647489 opened by Jacques Frechet SystemError with re.match(array) (2007-01-30) http://python.org/sf/1647541 opened by Armin Rigo No obvious and correct way to get the time zone offset (2007-01-30) http://python.org/sf/1647654 opened by James Henstridge set update problem with class derived from dict (2007-01-30) CLOSED http://python.org/sf/1648179 opened by duncan Grammatical error (2007-01-30) CLOSED http://python.org/sf/1648191 opened by Chris Beelby Parameter list mismatches (portation problem) (2007-01-30) http://python.org/sf/1648268 opened by ked-tao HP-UX: ld -Wl,+b... (2007-01-31) http://python.org/sf/1648890 opened by Johannes Abt HP-UX: -lcurses missing for readline.so (2007-01-31) http://python.org/sf/1648923 opened by Johannes Abt HP-UX: _ctypes/libffi/src/ia64/ffi/__attribute__/native cc (2007-01-31) http://python.org/sf/1648957 opened by Johannes Abt HP-UX11.23: module zlib missing (2007-01-31) http://python.org/sf/1648960 opened by Johannes Abt HP-UX: compiler warnings: alignment (2007-01-31) http://python.org/sf/1649011 opened by Johannes Abt non-standard: array[0] (2007-01-31) http://python.org/sf/1649098 opened by Johannes Abt Arithmetics behaving strange (2007-01-31) CLOSED http://python.org/sf/1649100 opened by Sascha Peilicke potential class with C++ in ceval.h (2007-01-31) http://python.org/sf/1649238 opened by thechao gettext.py incompatible with eggs (2007-01-31) http://python.org/sf/1649329 opened by Shannon -jj Behrens decimals compare badly to floats (2007-02-01) http://python.org/sf/1650053 opened by Brian Sutherland doctest doesn't find nested functions (2007-02-01) http://python.org/sf/1650090 opened by Daniel Brown sys.excepthook does not work with -m command line switch (2007-02-02) CLOSED http://python.org/sf/1650899 opened by Miki Tebeka PyFloat_FromString deprecated form (2007-02-02) http://python.org/sf/1650903 opened by Jim Jewett ctypes.Structure formal parameter dies given tuple (2007-02-03) http://python.org/sf/1651235 opened by Gary Bishop readline needs termcap on my FC6 (2007-02-03) http://python.org/sf/1651427 opened by guichaz sgmllib _convert_ref UnicodeDecodeError exception, new in 2. (2007-02-04) http://python.org/sf/1651995 opened by John Nagle Bugs Closed ___________ os.access now returns bool but docstring is not updated (2007-01-27) http://python.org/sf/1645944 closed by gbrandl cookielib.CookieJar does not handle cookies when port in url (2007-01-29) http://python.org/sf/1647037 closed by tools-sts set update problem with class derived from dict (2007-01-30) http://python.org/sf/1648179 closed by rhettinger Grammatical error (2007-01-30) http://python.org/sf/1648191 closed by gbrandl GUI scripts always return to an interpreter (2006-09-29) http://python.org/sf/1568075 closed by jejackson Arithmetics behaving strange and magic underscore (2007-01-31) http://python.org/sf/1649100 closed by gbrandl pty.fork() leaves slave fd's open on Solaris (2004-04-12) http://python.org/sf/933670 closed by gbrandl Idle 1.2 - Calltips Hotkey does not work (2006-09-27) http://python.org/sf/1566611 closed by sf-robot sys.excepthook does not work with -m command line switch (2007-02-02) http://python.org/sf/1650899 closed by tebeka

1 0

__dir__ and __all__
by Giovanni Bajo 04 Feb '07

04 Feb '07

Hello, I could not find a PEP for __dir__. I was thinking today that if __dir__ was added, I would find it useful if modules implemented it by returning __all__ (when __all__ is defined). Or even better, to return the same names that would be imported by a star-import (so, if __all__ is not defined, all names which do not start with '_'). This wouldn't prevent introspection tools to use mod.__dict__ to still access the module's global dictionary, of course. But it would allow module's authors to more clearly document the module's public API. -- Giovanni Bajo

2 1

Python's C interface for types
by Nick Maclaren 02 Feb '07

02 Feb '07

"Jim Jewett" <jimjjewett(a)gmail.com> wrote: > > > Fine. A very valid viewpoint. Would you like to explain that to > > the IEEE 754 people? > > When Decimal was being argued, Tim pointed out that the standard > requires certain operations, but doesn't require specific spelling > shortcuts. If you managed to do (and document) it right, people would > be grateful for methods like > > a.exactly(b) > a.close_enough(b) > a.same_expected_value(b) > > but that doesn't mean any of them should be used when testing a==b Hmm. That is misleading, as you state it. IEEE 754R doesn't include specific spellings, but IEEE 754 assuredly does. For example, it states that the equality operator that delivers False for NaN = NaN is spelled .EQ. in Fortran. There was no C standard at the time, but the "ad hoc' spellings are clearly intended for C-like languages, and C99 is very clear that the above equality operator is spelled '=='. However, there is no requirement that Python uses those names. What IS important is (a) that the comparisons are consistent, (b) that IEEE 754 (and IEEE 754R) define no reflexivity-preserving equality operator and (c) that the current float type derives its comparisons from C. > (In Lisp, you typically can specify which equality predicate a > hashtable should use on pairs of keys; in python, you only specify > which it should use on objects of your class, and if the other object > in the comparison disagrees, you're out of luck.) Yup. > > Strictly, it is only the reflexive property that IEEE 754 and the > > Decimal module lack. Yes, A == A is False, if A is a NaN. > > Therefore NaNs should never be used (in python) as dictionary keys. > Therefore, they should be unhashable. Again, a very valid point. Are you suggesting a change? :-) Currently, on my Linux system, Decimal raises an exception when trying to hash a NaN value but float doesn't. Is that a bug? > Also note that PyObject_RichCompareBool (from Objects/object.c) > assumes the reflexive property, and if you try to violate it, you will > get occasional surprises. Oh, yes, indeed! > > We already have the situation where A == B == 0, but where > > 'C op A' != 'C op B' != 'C op 0'. Both where op is a built-in > > operator and where 'C op' is a standard library function. > > That's fine; it just means that numeric equality may not be the > strongest possible equivalence. hash in particular just happens to be > defined in terms of ==, however == is determined. NO!!! What it means is that the equality operator may not be the strongest numeric equivalence! A much stronger statement. As I said, I am not grinding an axe, and have no answers. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

Python's C interface for types
by Jim Jewett 01 Feb '07

01 Feb '07

Nick Maclaren wrote: >>> I really do mean that quite a lot of floating-point bells and whistles >>> are non-transitive. Martin v. Löwis wrote: >> If so, they just shouldn't use the equal operator (==). == ought to >> be transitive. It should be consistent with has(). Nick Maclaren wrote: > Fine. A very valid viewpoint. Would you like to explain that to > the IEEE 754 people? When Decimal was being argued, Tim pointed out that the standard requires certain operations, but doesn't require specific spelling shortcuts. If you managed to do (and document) it right, people would be grateful for methods like a.exactly(b) a.close_enough(b) a.same_expected_value(b) but that doesn't mean any of them should be used when testing a==b (In Lisp, you typically can specify which equality predicate a hashtable should use on pairs of keys; in python, you only specify which it should use on objects of your class, and if the other object in the comparison disagrees, you're out of luck.) > Strictly, it is only the reflexive property that IEEE 754 and the > Decimal module lack. Yes, A == A is False, if A is a NaN. Therefore NaNs should never be used (in python) as dictionary keys. Therefore, they should be unhashable. Also note that PyObject_RichCompareBool (from Objects/object.c) assumes the reflexive property, and if you try to violate it, you will get occasional surprises. > We already have the situation where A == B == 0, but where > 'C op A' != 'C op B' != 'C op 0'. Both where op is a built-in > operator and where 'C op' is a standard library function. That's fine; it just means that numeric equality may not be the strongest possible equivalence. hash in particular just happens to be defined in terms of ==, however == is determined. -jJ

1 0

Re: [Python-Dev] Python's C interface for types
by Nick Maclaren 01 Feb '07

01 Feb '07

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin(a)v.loewis.de> wrote: > > >> If so, they just shouldn't use the equal operator (==). == ought to > >> be transitive. It should be consistent with has(). > > > > Fine. A very valid viewpoint. Would you like to explain that to > > the IEEE 754 people? > > Why should I? I don't talk about IEEE 754, I talk about Python. The problem is that Python is increasingly assuming IEEE 754 by implication, and you were stating something as a requirement that isn't true in IEEE 754. > > Strictly, it is only the reflexive property that IEEE 754 and the > > Decimal module lack. Yes, A == A is False, if A is a NaN. But > > the definition of 'transitive' often requires 'reflexive'. > > I deliberately stated 'transitive', not 'reflexive'. The standard > definition of 'transitive' is "if a==b and b==c then a==c". When I was taught mathematics, the lecturer said that a transitive relation is a reflexive one that has that extra property. It was then (and may still be) a fairly common usage. I apologise for being confusing! > > The most common form was where comparison was equivalent to subtraction, > > and there were numbers such that A-B == 0, B-C == 0 but A-C != 0. That > > could occur even for integers on some systems. I don't THINK that the > > Decimal specification has reintroduced this, but am not quite sure. > > I'm not talking about subtraction, either. I'm talking about == and > hash. Grrk. Look again. So am I. But let this one pass, as I don't think that mistake will return - and I sincerely hope not! > > Fine. Again, a very valid viewpoint. Would you like to explain it > > to the IEEE 754, Decimal and C99 people, and the Python people who > > think that tracking C is a good idea? > > I'm not explaining anything. I'm stating an opinion. You are, however, stating an opinion that conflicts with the direction that Python is currently taking. > It doesn't look like you *need* to give an answer now. I thought > you were proposing some change to Python (although I'm uncertain > what that change could have been). If you are merely explaining > things (to whom?), just keep going. Thanks. I hope the above clarifies things a bit. My purpose in posting is to point out that some changes are already happening, by inclusion from other standards, that are introducing problems to Python. And to many other languages, incidentally, including Fortran and C. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

dict(keys, values)
by Jim Jewett 01 Feb '07

01 Feb '07

George Sakkis wrote: > far too often I use the idiom dict(zip(keys,values)), or > the same with izip. How does letting dict take two positional > arguments sound ? I think the dict constructor is already a bit too complicated, and would prefer that it be a separate classmethod, such as dict.zip(keys, values=itertools.repeat(None)) The default argument on values should finish the replacement of dict.fromkeys functionality that sets and defaultdicts began. > At least as efficient as the current alternatives. I think it has to do better (at least by eliminating the temporary zip object) to be worthwhile; the do-it-yourself alternative is pretty short. >>> # from itertools import izip as zip >>> def dictz(keys, values): return dict(zip(keys,values)) -jJ

1 0

Re: [Python-Dev] Python's C interface for types
by Nick Maclaren 01 Feb '07

01 Feb '07

=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin(a)v.loewis.de> wrote: > > > I really do mean that quite a lot of floating-point bells and whistles > > are non-transitive. > > If so, they just shouldn't use the equal operator (==). == ought to > be transitive. It should be consistent with has(). Fine. A very valid viewpoint. Would you like to explain that to the IEEE 754 people? Strictly, it is only the reflexive property that IEEE 754 and the Decimal module lack. Yes, A == A is False, if A is a NaN. But the definition of 'transitive' often requires 'reflexive'. >>> from decimal import * >>> x = Decimal("NaN") >>> x == x False I don't know any CURRENT systems where basic floating-point doesn't have the strict transitive relation, but I wouldn't bet that there aren't any. You don't need to extend floating-point to have trouble; even the basic forms often had it. I sincerely hope that one is dead, but people keep reinventing old mistakes :-( The most common form was where comparison was equivalent to subtraction, and there were numbers such that A-B == 0, B-C == 0 but A-C != 0. That could occur even for integers on some systems. I don't THINK that the Decimal specification has reintroduced this, but am not quite sure. > > You have missed my point, which is extended floating-points effectively > > downgrade the status of the purely numeric comparisons, and therefore > > introduce a reasonable requirement for using a tighter match. Note > > that I am merely commenting that this needs bearing in mind, and NOT > > that anything should be changed. > > If introducing extended floating-points would cause trouble to existing > operations, I think extended floating-points should not be introduced > to Python. If all three of you really need them, come up with method > names to express "almost equal" or "equal only after sunset". Fine. Again, a very valid viewpoint. Would you like to explain it to the IEEE 754, Decimal and C99 people, and the Python people who think that tracking C is a good idea? We already have the situation where A == B == 0, but where 'C op A' != 'C op B' != 'C op 0'. Both where op is a built-in operator and where 'C op' is a standard library function. This one is NOT going to go away, and is going to get more serious, especially if extended floating-point formats like Decimal take off. Note that it is not a fault in Decimal, but a feature of almost all extended floating-points. As I said, I have no answer to it. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

2 1

Python's C interface for types
by Nick Maclaren 01 Feb '07

01 Feb '07

"Jim Jewett" <jimjjewett(a)gmail.com> wrote: > > >> For 0: hash(+0.0)==hash(-0.0)==hash(0)=hash(0L)=0 > > > Unfortunately, that assumes that equality is transitive. > > No, but the (transitively closed set of equivalent objects) must have > the same hash. ... Er, how do you have a transitive closure for a non-transitive operation? I really do mean that quite a lot of floating-point bells and whistles are non-transitive. The only one most people will have come across is IEEE NaNs, where 'a is b' does not imply 'a == b', but there are a lot of others (and have been since time immemorial). I don't THINK that IEEE 754R decimal introduces any, though I am not prepared to bet on it. > > let us say that I am implementing a special function and want to > > distinguish -0.0 and +0.0. Why can't I use a dictionary? > > Because they are equal. They aren't identical, but they are equal. You have missed my point, which is extended floating-points effectively downgrade the status of the purely numeric comparisons, and therefore introduce a reasonable requirement for using a tighter match. Note that I am merely commenting that this needs bearing in mind, and NOT that anything should be changed. > > >>> a = float("+0.0") > > >>> b = float("-0.0") > > >>> print a, b > > 0.0 -0.0 > > With the standard windows distribution, I get just > > 0.0 0.0 Watch that space :-) Expect it to change. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

2 1

dict(keys, values)
by George Sakkis 01 Feb '07

01 Feb '07

Perhaps this has been brought up in the past but I couldn't find it in the archives: far too often I use the idiom dict(zip(keys,values)), or the same with izip. How does letting dict take two positional arguments sound ? Pros: - Pretty obvious semantics, no mental overhead to learn and remember it. - More concise (especially if one imports itertools just to use izip). - At least as efficient as the current alternatives. - Backwards compatible. Cons: - ?? George

4 6