Mailman 3 July 2007 - Python-checkins

r56637 - peps/trunk/pep-3141.txt
by guido.van.rossum 31 Jul '07

31 Jul '07

Author: guido.van.rossum Date: Tue Jul 31 23:14:18 2007 New Revision: 56637 Modified: peps/trunk/pep-3141.txt Log: Insert some blank lines between methods (and remove a few between chapters). Modified: peps/trunk/pep-3141.txt ============================================================================== --- peps/trunk/pep-3141.txt (original) +++ peps/trunk/pep-3141.txt Tue Jul 31 23:14:18 2007 @@ -83,6 +83,7 @@ special knowledge about them, it should fall back to the builtin complex type as described below. """ + @abstractmethod def __complex__(self): """Return a builtin complex instance.""" @@ -92,6 +93,7 @@ def real(self): """Retrieve the real component of this number, which should subclass Real.""" raise NotImplementedError + @abstractmethod @property def imag(self): @@ -101,15 +103,19 @@ @abstractmethod def __add__(self, other): raise NotImplementedError + @abstractmethod def __sub__(self, other): raise NotImplementedError + @abstractmethod def __neg__(self): raise NotImplementedError + @abstractmethod def __mul__(self, other): raise NotImplementedError + @abstractmethod def __div__(self, other): raise NotImplementedError @@ -127,6 +133,7 @@ @abstractmethod def __eq__(self, other): raise NotImplementedError + def __ne__(self, other): return not (self == other) @@ -143,6 +150,7 @@ Real also provides defaults for the derived operations. """ + @abstractmethod def __float__(self): """Any Real can be converted to a native float object.""" @@ -156,10 +164,12 @@ def __divmod__(self, other): """The pair (self // other, self % other).""" return (self // other, self % other) + @abstractmethod def __floordiv__(self, other): """The floor() of self/other.""" raise NotImplementedError + @abstractmethod def __mod__(self, other): """.""" @@ -168,6 +178,7 @@ @abstractmethod def __lt__(self, other): raise NotImplementedError + def __le__(self, other): # Assume that if other is Real, it defines an ordering # consistent with this class, or returns NotImplemented. @@ -175,11 +186,14 @@ return not (other < self) # Concrete implementations of Complex abstract methods. + def __complex__(self): return complex(float(self)) + @property def real(self): return self + @property def imag(self): return 0 @@ -191,10 +205,12 @@ class Rational(Real, Exact): """.numerator and .denominator should be in lowest terms.""" + @abstractmethod @property def numerator(self): raise NotImplementedError + @abstractmethod @property def denominator(self): @@ -209,6 +225,7 @@ class Integral(Rational): """Integral adds a conversion to int and the bit-string operations.""" + @abstractmethod def __int__(self): raise NotImplementedError @@ -216,32 +233,37 @@ @abstractmethod def __lshift__(self, other): raise NotImplementedError + @abstractmethod def __rshift__(self, other): raise NotImplementedError + @abstractmethod def __and__(self, other): raise NotImplementedError + @abstractmethod def __xor__(self, other): raise NotImplementedError + @abstractmethod def __or__(self, other): raise NotImplementedError # Concrete implementations of Rational and Real abstract methods. + def __float__(self): return float(int(self)) + @property def numerator(self): return self + @property def denominator(self): return 1 - - Exact vs. Inexact Classes ------------------------- @@ -295,6 +317,7 @@ __add__ and __radd__ should be defined as:: class MyIntegral(Integral): + def __add__(self, other): if isinstance(other, MyIntegral): return do_my_adding_stuff(self, other) @@ -302,6 +325,7 @@ return do_my_other_adding_stuff(self, other) else: return NotImplemented + def __radd__(self, other): if isinstance(other, MyIntegral): return do_my_adding_stuff(other, self)

1 0

buildbot warnings in x86 mvlgcc trunk
by buildbot＠python.org 31 Jul '07

31 Jul '07

The Buildbot has detected a new failure of x86 mvlgcc trunk. Full details are available at: http://www.python.org/dev/buildbot/all/x86%2520mvlgcc%2520trunk/builds/683 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: martin.v.loewis Build had warnings: warnings test Excerpt from the test logfile: Traceback (most recent call last): File "/home2/buildbot/slave/trunk.loewis-linux/build/Lib/threading.py", line 466, in __bootstrap self.run() File "/home2/buildbot/slave/trunk.loewis-linux/build/Lib/test/test_socketserver.py", line 93, in run svr.serve_a_few() File "/home2/buildbot/slave/trunk.loewis-linux/build/Lib/test/test_socketserver.py", line 35, in serve_a_few self.handle_request() File "/home2/buildbot/slave/trunk.loewis-linux/build/Lib/SocketServer.py", line 224, in handle_request self.handle_error(request, client_address) File "/home2/buildbot/slave/trunk.loewis-linux/build/Lib/SocketServer.py", line 222, in handle_request self.process_request(request, client_address) File "/home2/buildbot/slave/trunk.loewis-linux/build/Lib/SocketServer.py", line 429, in process_request self.collect_children() File "/home2/buildbot/slave/trunk.loewis-linux/build/Lib/SocketServer.py", line 425, in collect_children self.active_children.remove(pid) ValueError: list.remove(x): x not in list 1 test failed: test_socketserver make: *** [buildbottest] Error 1 sincerely, -The Buildbot

1 0

buildbot warnings in ia64 Ubuntu trunk 2.5
by buildbot＠python.org 31 Jul '07

31 Jul '07

The Buildbot has detected a new failure of ia64 Ubuntu trunk 2.5. Full details are available at: http://www.python.org/dev/buildbot/all/ia64%2520Ubuntu%2520trunk%25202.5/bu… Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch branches/release25-maint] HEAD Blamelist: martin.v.loewis Build had warnings: warnings test Excerpt from the test logfile: 1 test failed: test_urllib2net make: *** [buildbottest] Error 1 sincerely, -The Buildbot

1 0

buildbot failure in amd64 XP trunk
by buildbot＠python.org 31 Jul '07

31 Jul '07

The Buildbot has detected a new failure of amd64 XP trunk. Full details are available at: http://www.python.org/dev/buildbot/all/amd64%2520XP%2520trunk/builds/80 Buildbot URL: http://www.python.org/dev/buildbot/all/ Build Reason: Build Source Stamp: [branch trunk] HEAD Blamelist: martin.v.loewis BUILD FAILED: failed failed slave lost sincerely, -The Buildbot

1 0

r56636 - in python/trunk: Misc/NEWS configure configure.in pyconfig.h.in
by martin.v.loewis 31 Jul '07

31 Jul '07

Author: martin.v.loewis Date: Tue Jul 31 21:57:56 2007 New Revision: 56636 Modified: python/trunk/Misc/NEWS python/trunk/configure python/trunk/configure.in python/trunk/pyconfig.h.in Log: Define _BSD_SOURCE, to get access to POSIX extensions on OpenBSD 4.1+. Modified: python/trunk/Misc/NEWS ============================================================================== --- python/trunk/Misc/NEWS (original) +++ python/trunk/Misc/NEWS Tue Jul 31 21:57:56 2007 @@ -926,6 +926,8 @@ Build ----- +- Define _BSD_SOURCE, to get access to POSIX extensions on OpenBSD 4.1+. + - Stop supporting AtheOS and cause a build error in configure for the platform. - Bug #1655392: don't add -L/usr/lib/pythonX.Y/config to the LDFLAGS Modified: python/trunk/configure ============================================================================== --- python/trunk/configure (original) +++ python/trunk/configure Tue Jul 31 21:57:56 2007 @@ -1,5 +1,5 @@ #! /bin/sh -# From configure.in Revision: 54283 . +# From configure.in Revision: 55739 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.61 for python 2.6. # @@ -1838,6 +1838,14 @@ _ACEOF +# OpenBSD undoes our definition of __BSD_VISIBLE if _XOPEN_SOURCE is +# also defined. This can be overridden by defining _BSD_SOURCE + +cat >>confdefs.h <<\_ACEOF +#define _BSD_SOURCE 1 +_ACEOF + + # The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables # u_int on Irix 5.3. Defining _BSD_TYPES brings it back. Modified: python/trunk/configure.in ============================================================================== --- python/trunk/configure.in (original) +++ python/trunk/configure.in Tue Jul 31 21:57:56 2007 @@ -50,6 +50,10 @@ # them. AC_DEFINE(__BSD_VISIBLE, 1, [Define on FreeBSD to activate all library features]) +# OpenBSD undoes our definition of __BSD_VISIBLE if _XOPEN_SOURCE is +# also defined. This can be overridden by defining _BSD_SOURCE +AC_DEFINE(_BSD_SOURCE, 1, [Define on OpenBSD to activate all library features]) + # The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables # u_int on Irix 5.3. Defining _BSD_TYPES brings it back. AC_DEFINE(_BSD_TYPES, 1, [Define on Irix to enable u_int]) Modified: python/trunk/pyconfig.h.in ============================================================================== --- python/trunk/pyconfig.h.in (original) +++ python/trunk/pyconfig.h.in Tue Jul 31 21:57:56 2007 @@ -103,6 +103,10 @@ /* Define if you have the 'resize_term' function. */ #undef HAVE_CURSES_RESIZE_TERM +/* Define to 1 if you have the declaration of `tzname', and to 0 if you don't. + */ +#undef HAVE_DECL_TZNAME + /* Define to 1 if you have the device macros. */ #undef HAVE_DEVICE_MACROS @@ -802,22 +806,22 @@ /* Define if i>>j for signed int i does not extend the sign bit when i < 0 */ #undef SIGNED_RIGHT_SHIFT_ZERO_FILLS -/* The size of a `double', as computed by sizeof. */ +/* The size of `double', as computed by sizeof. */ #undef SIZEOF_DOUBLE -/* The size of a `float', as computed by sizeof. */ +/* The size of `float', as computed by sizeof. */ #undef SIZEOF_FLOAT -/* The size of a `fpos_t', as computed by sizeof. */ +/* The size of `fpos_t', as computed by sizeof. */ #undef SIZEOF_FPOS_T -/* The size of a `int', as computed by sizeof. */ +/* The size of `int', as computed by sizeof. */ #undef SIZEOF_INT -/* The size of a `long', as computed by sizeof. */ +/* The size of `long', as computed by sizeof. */ #undef SIZEOF_LONG -/* The size of a `long long', as computed by sizeof. */ +/* The size of `long long', as computed by sizeof. */ #undef SIZEOF_LONG_LONG /* The number of bytes in an off_t. */ @@ -826,25 +830,25 @@ /* The number of bytes in a pthread_t. */ #undef SIZEOF_PTHREAD_T -/* The size of a `short', as computed by sizeof. */ +/* The size of `short', as computed by sizeof. */ #undef SIZEOF_SHORT -/* The size of a `size_t', as computed by sizeof. */ +/* The size of `size_t', as computed by sizeof. */ #undef SIZEOF_SIZE_T /* The number of bytes in a time_t. */ #undef SIZEOF_TIME_T -/* The size of a `uintptr_t', as computed by sizeof. */ +/* The size of `uintptr_t', as computed by sizeof. */ #undef SIZEOF_UINTPTR_T -/* The size of a `void *', as computed by sizeof. */ +/* The size of `void *', as computed by sizeof. */ #undef SIZEOF_VOID_P -/* The size of a `wchar_t', as computed by sizeof. */ +/* The size of `wchar_t', as computed by sizeof. */ #undef SIZEOF_WCHAR_T -/* The size of a `_Bool', as computed by sizeof. */ +/* The size of `_Bool', as computed by sizeof. */ #undef SIZEOF__BOOL /* Define to 1 if you have the ANSI C header files. */ @@ -924,6 +928,9 @@ # undef _ALL_SOURCE #endif +/* Define on OpenBSD to activate all library features */ +#undef _BSD_SOURCE + /* Define on Irix to enable u_int */ #undef _BSD_TYPES @@ -980,7 +987,7 @@ /* Define to `int' if <sys/types.h> does not define. */ #undef mode_t -/* Define to `long' if <sys/types.h> does not define. */ +/* Define to `long int' if <sys/types.h> does not define. */ #undef off_t /* Define to `int' if <sys/types.h> does not define. */ @@ -989,7 +996,7 @@ /* Define to empty if the keyword does not work. */ #undef signed -/* Define to `unsigned' if <sys/types.h> does not define. */ +/* Define to `unsigned int' if <sys/types.h> does not define. */ #undef size_t /* Define to `int' if <sys/socket.h> does not define. */

1 0

r56635 - in python/branches/release25-maint: Misc/NEWS configure configure.in pyconfig.h.in
by martin.v.loewis 31 Jul '07

31 Jul '07

Author: martin.v.loewis Date: Tue Jul 31 21:54:20 2007 New Revision: 56635 Modified: python/branches/release25-maint/Misc/NEWS python/branches/release25-maint/configure python/branches/release25-maint/configure.in python/branches/release25-maint/pyconfig.h.in Log: Define _BSD_SOURCE, to get access to POSIX extensions on OpenBSD 4.1+. Modified: python/branches/release25-maint/Misc/NEWS ============================================================================== --- python/branches/release25-maint/Misc/NEWS (original) +++ python/branches/release25-maint/Misc/NEWS Tue Jul 31 21:54:20 2007 @@ -101,6 +101,8 @@ Build ----- +- Define _BSD_SOURCE, to get access to POSIX extensions on OpenBSD 4.1+. + - Patch #1673122: Use an explicit path to libtool when building a framework. This avoids picking up GNU libtool from a users PATH. Modified: python/branches/release25-maint/configure ============================================================================== --- python/branches/release25-maint/configure (original) +++ python/branches/release25-maint/configure Tue Jul 31 21:54:20 2007 @@ -1,5 +1,5 @@ #! /bin/sh -# From configure.in Revision: 52844 . +# From configure.in Revision: 54284 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.59 for python 2.5. # @@ -1388,6 +1388,14 @@ _ACEOF +# OpenBSD undoes our definition of __BSD_VISIBLE if _XOPEN_SOURCE is +# also defined. This can be overridden by defining _BSD_SOURCE + +cat >>confdefs.h <<\_ACEOF +#define _BSD_SOURCE 1 +_ACEOF + + # The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables # u_int on Irix 5.3. Defining _BSD_TYPES brings it back. Modified: python/branches/release25-maint/configure.in ============================================================================== --- python/branches/release25-maint/configure.in (original) +++ python/branches/release25-maint/configure.in Tue Jul 31 21:54:20 2007 @@ -50,6 +50,10 @@ # them. AC_DEFINE(__BSD_VISIBLE, 1, [Define on FreeBSD to activate all library features]) +# OpenBSD undoes our definition of __BSD_VISIBLE if _XOPEN_SOURCE is +# also defined. This can be overridden by defining _BSD_SOURCE +AC_DEFINE(_BSD_SOURCE, 1, [Define on OpenBSD to activate all library features]) + # The later defininition of _XOPEN_SOURCE and _POSIX_C_SOURCE disables # u_int on Irix 5.3. Defining _BSD_TYPES brings it back. AC_DEFINE(_BSD_TYPES, 1, [Define on Irix to enable u_int]) Modified: python/branches/release25-maint/pyconfig.h.in ============================================================================== --- python/branches/release25-maint/pyconfig.h.in (original) +++ python/branches/release25-maint/pyconfig.h.in Tue Jul 31 21:54:20 2007 @@ -909,6 +909,9 @@ # undef _ALL_SOURCE #endif +/* Define on OpenBSD to activate all library features */ +#undef _BSD_SOURCE + /* Define on Irix to enable u_int */ #undef _BSD_TYPES

1 0

r56634 - peps/trunk/pep-3141.txt
by guido.van.rossum 31 Jul '07

31 Jul '07

Author: guido.van.rossum Date: Tue Jul 31 21:19:57 2007 New Revision: 56634 Modified: peps/trunk/pep-3141.txt Log: New version by Jeffrey Yasskin. Modified: peps/trunk/pep-3141.txt ============================================================================== --- peps/trunk/pep-3141.txt (original) +++ peps/trunk/pep-3141.txt Tue Jul 31 21:19:57 2007 @@ -7,7 +7,7 @@ Type: Standards Track Content-Type: text/x-rst Created: 23-Apr-2007 -Post-History: 25-Apr-2007, 16-May-2007 +Post-History: 25-Apr-2007, 16-May-2007, xx-Aug-2007 Abstract @@ -15,7 +15,7 @@ This proposal defines a hierarchy of Abstract Base Classes (ABCs) (PEP 3119) to represent number-like classes. It proposes a hierarchy of -``Number :> Complex :> Real :> Rational :> Integer`` where ``A :> B`` +``Number :> Complex :> Real :> Rational :> Integral`` where ``A :> B`` means "A is a supertype of B", and a pair of ``Exact``/``Inexact`` classes to capture the difference between ``floats`` and ``ints``. These types are significantly inspired by Scheme's numeric @@ -28,41 +28,16 @@ the properties of those numbers, and if and when overloading based on types is added to the language, should be overloadable based on the types of the arguments. For example, slicing requires its arguments to -be ``Integers``, and the functions in the ``math`` module require +be ``Integrals``, and the functions in the ``math`` module require their arguments to be ``Real``. Specification ============= -This PEP specifies a set of Abstract Base Classes with default -implementations. If the reader prefers to think in terms of Roles (PEP -3133), the default implementations for (for example) the Real ABC -would be moved to a RealDefault class, with Real keeping just the -method declarations. - -Although this PEP uses terminology from PEP 3119, the hierarchy is -intended to be meaningful for any systematic method of defining sets -of classes, including Interfaces. I'm also using the extra notation -from PEP 3107 (Function Annotations) to specify some types. - - -Exact vs. Inexact Classes -------------------------- - -Floating point values may not exactly obey several of the properties -you would expect. For example, it is possible for ``(X + -X) + 3 == -3``, but ``X + (-X + 3) == 0``. On the range of values that most -functions deal with this isn't a problem, but it is something to be -aware of. - -Therefore, I define ``Exact`` and ``Inexact`` ABCs to mark whether -types have this problem. Every instance of ``Integer`` and -``Rational`` should be Exact, but ``Reals`` and ``Complexes`` may or -may not be. (Do we really only need one of these, and the other is -defined as ``not`` the first?):: - - class Exact(metaclass=MetaABC): pass - class Inexact(metaclass=MetaABC): pass +This PEP specifies a set of Abstract Base Classes, and suggests a +general strategy for implementing some of the methods. It uses +terminology from PEP 3119, but the hierarchy is intended to be +meaningful for any systematic method of defining sets of classes. Numeric Classes @@ -70,23 +45,21 @@ We begin with a Number class to make it easy for people to be fuzzy about what kind of number they expect. This class only helps with -overloading; it doesn't provide any operations. **Open question:** -Should it specify ``__add__``, ``__sub__``, ``__neg__``, ``__mul__``, -and ``__abs__`` like Haskell's ``Num`` class?:: +overloading; it doesn't provide any operations. class Number(metaclass=MetaABC): pass Some types (primarily ``float``) define "Not a Number" (NaN) values that return false for any comparison, including equality with -themselves, and are maintained through operations. Because this -doesn't work well with the Reals (which are otherwise totally ordered -by ``<``), Guido suggested we might put NaN in its own type. It is -conceivable that this can still be represented by C doubles but be -included in a different ABC at runtime. **Open issue:** Is this a good -idea?:: +themselves, and are maintained through operations. That is, ``nan + x +-> nan`` and ``nan == nan -> False`` Because this doesn't work well +with the Reals (which are otherwise totally ordered by ``<``), Guido +suggested we might put NaN in its own type. It is conceivable that +this can still be represented by C doubles but be included in a +different ABC at runtime. **Open issue:** Is this a good idea?:: - class NotANumber(Number): + class UndefinedNumber(Number): """Implement IEEE 754 semantics.""" def __lt__(self, other): return false def __eq__(self, other): return false @@ -94,162 +67,130 @@ def __add__(self, other): return self def __radd__(self, other): return self ... + # Should we demand a conversion to float? + +Most implementations of complex numbers will be hashable, but if you +need to rely on that, you'll have to check it explicitly: mutable +numbers are supported by this hierarchy. :: + + class Complex(Number): + """Complex defines the operations that work on the builtin complex type. -Complex numbers are immutable and hashable. Implementors should be -careful that they make equal numbers equal and hash them to the same -values. This may be subtle if there are two different extensions of -the real numbers:: - - class Complex(Hashable, Number): - """A ``Complex`` should define the operations that work on the - Python ``complex`` type. If it is given heterogenous - arguments, it may fall back on this class's definition of the - operations.addition, subtraction, negation, and - multiplication. These operators should never return a - TypeError as long as both arguments are instances of Complex - (or even just implement __complex__). + In short, those are: a conversion to complex, .real, .imag, +, + -, *, /, abs(), .conjugate, ==, and !=. + + If it is given heterogenous arguments, and doesn't have + special knowledge about them, it should fall back to the + builtin complex type as described below. """ @abstractmethod def __complex__(self): - """This operation gives the arithmetic operations a fallback. - """ - return complex(self.real, self.imag) + """Return a builtin complex instance.""" + + @abstractmethod @property def real(self): - return complex(self).real + """Retrieve the real component of this number, which should subclass Real.""" + raise NotImplementedError + @abstractmethod @property def imag(self): - return complex(self).imag - -I define the reversed operations here so that they serve as the final -fallback for operations involving instances of Complex. **Open -issue:** Should Complex's operations check for ``isinstance(other, -Complex)``? Duck typing seems to imply that we should just try -__complex__ and succeed if it works, but stronger typing might be -justified for the operators. TODO: analyze the combinations of normal -and reversed operations with real and virtual subclasses of Complex:: + """Retrieve the real component of this number, which should subclass Real.""" + raise NotImplementedError - def __radd__(self, other): - """Should this catch any type errors and return - NotImplemented instead?""" - return complex(other) + complex(self) - def __rsub__(self, other): - return complex(other) - complex(self) + @abstractmethod + def __add__(self, other): + raise NotImplementedError + @abstractmethod + def __sub__(self, other): + raise NotImplementedError + @abstractmethod def __neg__(self): - return -complex(self) - def __rmul__(self, other): - return complex(other) * complex(self) - def __rdiv__(self, other): - return complex(other) / complex(self) + raise NotImplementedError + @abstractmethod + def __mul__(self, other): + raise NotImplementedError + @abstractmethod + def __div__(self, other): + raise NotImplementedError + @abstractmethod def __abs__(self): - return abs(complex(self)) + """Returns the Real distance from 0.""" + raise NotImplementedError + @abstractmethod def conjugate(self): - return complex(self).conjugate() + """(x+y*i).conjugate() returns (x-y*i).""" + raise NotImplementedError - def __hash__(self): - """Two "equal" values of different complex types should - hash in the same way.""" - return hash(complex(self)) + @abstractmethod + def __eq__(self, other): + raise NotImplementedError + def __ne__(self, other): + return not (self == other) The ``Real`` ABC indicates that the value is on the real line, and supports the operations of the ``float`` builtin. Real numbers are -totally ordered. (NaNs were handled above.):: +totally ordered. (NaNs were handled above).:: + + class Real(Complex): + """To Complex, Real adds the operations that work on real numbers. + + In short, those are: a conversion to float, trunc(), divmod, + %, <, <=, >, and >=. - class Real(Complex, metaclass=TotallyOrderedABC): + Real also provides defaults for the derived operations. + """ @abstractmethod def __float__(self): """Any Real can be converted to a native float object.""" - raise NotImplementedError - def __complex__(self): - """Which gives us an easy way to define the conversion to - complex.""" - return complex(float(self)) - @property - def real(self): return self - @property - def imag(self): return 0 - - def __radd__(self, other): - if isinstance(other, Real): - return float(other) + float(self) - else: - return super(Real, self).__radd__(other) - def __rsub__(self, other): - if isinstance(other, Real): - return float(other) - float(self) - else: - return super(Real, self).__rsub__(other) - def __neg__(self): - return -float(self) - def __rmul__(self, other): - if isinstance(other, Real): - return float(other) * float(self) - else: - return super(Real, self).__rmul__(other) - def __rdiv__(self, other): - if isinstance(other, Real): - return float(other) / float(self) - else: - return super(Real, self).__rdiv__(other) - def __rdivmod__(self, other): - """Implementing divmod() for your type is sufficient to - get floordiv and mod too. - """ - if isinstance(other, Real): - return divmod(float(other), float(self)) - else: - return super(Real, self).__rdivmod__(other) - def __rfloordiv__(self, other): - return divmod(other, self)[0] - def __rmod__(self, other): - return divmod(other, self)[1] - + raise NotImplementedError + + @abstractmethod def __trunc__(self): - """Do we want properfraction, floor, ceiling, and round?""" - return trunc(float(self)) - - def __abs__(self): - return abs(float(self)) + """Returns an Integral of the same sign as self whose abs is <= self's abs.""" + raise NotImplementedError -There is no way to define only the reversed comparison operators, so -these operations take precedence over any defined in the other -type. :( :: + def __divmod__(self, other): + """The pair (self // other, self % other).""" + return (self // other, self % other) + @abstractmethod + def __floordiv__(self, other): + """The floor() of self/other.""" + raise NotImplementedError + @abstractmethod + def __mod__(self, other): + """.""" + raise NotImplementedError + @abstractmethod def __lt__(self, other): - """The comparison operators in Python seem to be more - strict about their input types than other functions. I'm - guessing here that we want types to be incompatible even - if they define a __float__ operation, unless they also - declare themselves to be Real numbers. - """ - if isinstance(other, Real): - return float(self) < float(other) - else: - return NotImplemented - - def __le__(self, other): + raise NotImplementedError + def __le__(self, other): + # Assume that if other is Real, it defines an ordering + # consistent with this class, or returns NotImplemented. if isinstance(other, Real): - return float(self) <= float(other) - else: - return NotImplemented + return not (other < self) + + # Concrete implementations of Complex abstract methods. + def __complex__(self): + return complex(float(self)) + @property + def real(self): + return self + @property + def imag(self): + return 0 - def __eq__(self, other): - if isinstance(other, Real): - return float(self) == float(other) - else: - return NotImplemented - There is no built-in rational type, but it's straightforward to write, -so we provide an ABC for it:: +so we provide an ABC for it. *Open issue*: Add Demo/classes/Rat.py to +the stdlib?:: class Rational(Real, Exact): - """rational.numerator and rational.denominator should be in - lowest terms. - """ + """.numerator and .denominator should be in lowest terms.""" @abstractmethod @property def numerator(self): @@ -259,49 +200,80 @@ def denominator(self): raise NotImplementedError + # Concrete implementation of Real's conversion to float. def __float__(self): return self.numerator / self.denominator - class Integer(Rational): - @abstractmethod - def __int__(self): - raise NotImplementedError - def __float__(self): - return float(int(self)) +And finally integers:: + + class Integral(Rational): + """Integral adds a conversion to int and the bit-string operations.""" + @abstractmethod + def __int__(self): + raise NotImplementedError + + @abstractmethod + def __lshift__(self, other): + raise NotImplementedError + @abstractmethod + def __rshift__(self, other): + raise NotImplementedError + @abstractmethod + def __and__(self, other): + raise NotImplementedError + @abstractmethod + def __xor__(self, other): + raise NotImplementedError + @abstractmethod + def __or__(self, other): + raise NotImplementedError + + # Concrete implementations of Rational and Real abstract methods. + def __float__(self): + return float(int(self)) @property - def numerator(self): return self + def numerator(self): + return self @property - def denominator(self): return 1 + def denominator(self): + return 1 - def __ror__(self, other): - return int(other) | int(self) - def __rxor__(self, other): - return int(other) ^ int(self) - def __rand__(self, other): - return int(other) & int(self) - def __rlshift__(self, other): - return int(other) << int(self) - def __rrshift__(self, other): - return int(other) >> int(self) - def __invert__(self): - return ~int(self) - def __radd__(self, other): - """All of the Real methods need to be overridden here too - in order to get a more exact type for their results. - """ - if isinstance(other, Integer): - return int(other) + int(self) - else: - return super(Integer, self).__radd__(other) - ... + + +Exact vs. Inexact Classes +------------------------- + +Floating point values may not exactly obey several of the properties +you would expect. For example, it is possible for ``(X + -X) + 3 == +3``, but ``X + (-X + 3) == 0``. On the range of values that most +functions deal with this isn't a problem, but it is something to be +aware of. + +Therefore, I define ``Exact`` and ``Inexact`` ABCs to mark whether +types have this problem. Every instance of ``Integral`` and +``Rational`` should be Exact, but ``Reals`` and ``Complexes`` may or +may not be. (Do we really only need one of these, and the other is +defined as ``not`` the first?):: + + class Exact(Number): pass + class Inexact(Number): pass + + +Notes for type implementors +--------------------------- + +Implementors should be careful to make equal numbers equal and +hash them to the same values. This may be subtle if there are two +different extensions of the real numbers. For example, a complex type +could reasonably implement hash() as follows:: def __hash__(self): - """Surprisingly, hash() needs to be overridden too, since - there are integers that float can't represent.""" - return hash(int(self)) + return hash(complex(self)) +but should be careful of any values that fall outside of the built in +complex's range or precision. Adding More Numeric ABCs ------------------------ @@ -313,7 +285,61 @@ class MyFoo(Complex): ... MyFoo.register(Real) -TODO(jyasskin): Check this. +Implementing the arithmetic operations +-------------------------------------- + +We want to implement the arithmetic operations so that mixed-mode +operations either call an implementation whose author knew about the +types of both arguments, or convert both to the nearest built in type +and do the operation there. For subtypes of Integral, this means that +__add__ and __radd__ should be defined as:: + + class MyIntegral(Integral): + def __add__(self, other): + if isinstance(other, MyIntegral): + return do_my_adding_stuff(self, other) + elif isinstance(other, OtherTypeIKnowAbout): + return do_my_other_adding_stuff(self, other) + else: + return NotImplemented + def __radd__(self, other): + if isinstance(other, MyIntegral): + return do_my_adding_stuff(other, self) + elif isinstance(other, OtherTypeIKnowAbout): + return do_my_other_adding_stuff(other, self) + elif isinstance(other, Integral): + return int(other) + int(self) + elif isinstance(other, Real): + return float(other) + float(self) + elif isinstance(other, Complex): + return complex(other) + complex(self) + else: + return NotImplemented + + +There are 5 different cases for a mixed-type operation on subclasses +of Complex. I'll refer to all of the above code that doesn't refer to +MyIntegral and OtherTypeIKnowAbout as "boilerplate". ``a`` will be an +instance of ``A``, which is a subtype of ``Complex`` (``a : A <: +Complex``), and ``b : B <: Complex``. I'll consider ``a + b``: + + 1. If A defines an __add__ which accepts b, all is well. + 2. If A falls back to the boilerplate code, and it were to return + a value from __add__, we'd miss the possibility that B defines + a more intelligent __radd__, so the boilerplate should return + NotImplemented from __add__. (Or A may not implement __add__ at + all.) + 3. Then B's __radd__ gets a chance. If it accepts a, all is well. + 4. If it falls back to the boilerplate, there are no more possible + methods to try, so this is where the default implementation + should live. + 5. If B <: A, Python tries B.__radd__ before A.__add__. This is + ok, because it was implemented with knowledge of A, so it can + handle those instances before delegating to Complex. + +If ``A<:Complex`` and ``B<:Real`` without sharing any other knowledge, +then the appropriate shared operation is the one involving the built +in complex, and both __radd__s land there, so ``a+b == b+a``. Rejected Alternatives @@ -324,12 +350,18 @@ MonoidUnderPlus, AdditiveGroup, Ring, and Field, and mentioned several other possible algebraic types before getting to the numbers. I had expected this to be useful to people using vectors and matrices, but -the NumPy community really wasn't interested. The numbers then had a -much more branching structure to include things like the Gaussian -Integers and Z/nZ, which could be Complex but wouldn't necessarily -support things like division. The community decided that this was too -much complication for Python, so the proposal has been scaled back to -resemble the Scheme numeric tower much more closely. +the NumPy community really wasn't interested, and we ran into the +issue that even if ``x`` is an instance of ``X <: MonoidUnderPlus`` +and ``y`` is an instance of ``Y <: MonoidUnderPlus``, ``x + y`` may +still not make sense. + +Then I gave the numbers a much more branching structure to include +things like the Gaussian Integers and Z/nZ, which could be Complex but +wouldn't necessarily support things like division. The community +decided that this was too much complication for Python, so I've now +scaled back the proposal to resemble the Scheme numeric tower much +more closely. + References ========== @@ -337,10 +369,7 @@ .. [#pep3119] Introducing Abstract Base Classes (http://www.python.org/dev/peps/pep-3119/) -.. [#pep3107] Function Annotations - (http://www.python.org/dev/peps/pep-3107/) - -.. [3] Possible Python 3K Class Tree?, wiki page created by Bill Janssen +.. [#classtree] Possible Python 3K Class Tree?, wiki page created by Bill Janssen (http://wiki.python.org/moin/AbstractBaseClasses) .. [#numericprelude] NumericPrelude: An experimental alternative hierarchy of numeric type classes @@ -355,9 +384,10 @@ Thanks to Neil Norwitz for encouraging me to write this PEP in the first place, to Travis Oliphant for pointing out that the numpy people -didn't really care about the algebraic concepts, and to Guido van -Rossum, Collin Winter, and lots of other people on the mailing list -for refining the concept. +didn't really care about the algebraic concepts, to Alan Isaac for +reminding me that Scheme had already done this, and to Guido van +Rossum and lots of other people on the mailing list for refining the +concept. Copyright =========

1 0

r56633 - python/trunk/Lib/threading.py
by nick.coghlan 31 Jul '07

31 Jul '07

Author: nick.coghlan Date: Tue Jul 31 15:38:01 2007 New Revision: 56633 Modified: python/trunk/Lib/threading.py Log: Eliminate RLock race condition reported in SF bug #1764059 Modified: python/trunk/Lib/threading.py ============================================================================== --- python/trunk/Lib/threading.py (original) +++ python/trunk/Lib/threading.py Tue Jul 31 15:38:01 2007 @@ -85,9 +85,10 @@ self.__count = 0 def __repr__(self): + owner = self.__owner return "<%s(%s, %d)>" % ( self.__class__.__name__, - self.__owner and self.__owner.getName(), + owner and owner.getName(), self.__count) def acquire(self, blocking=1):

1 0

r56632 - python/trunk/Lib/test/test_asynchat.py
by facundo.batista 31 Jul '07

31 Jul '07

Author: facundo.batista Date: Tue Jul 31 05:03:34 2007 New Revision: 56632 Modified: python/trunk/Lib/test/test_asynchat.py Log: When running asynchat tests on OS X (darwin), the test client now overrides asyncore.dispatcher.handle_expt to do nothing, since select.poll gives a POLLHUP error at the completion of these tests. Added timeout & count arguments to several asyncore.loop calls to avoid the possibility of a test hanging up a build. [GSoC - Alan McIntyre] Modified: python/trunk/Lib/test/test_asynchat.py ============================================================================== --- python/trunk/Lib/test/test_asynchat.py (original) +++ python/trunk/Lib/test/test_asynchat.py Tue Jul 31 05:03:34 2007 @@ -3,6 +3,7 @@ import thread # If this fails, we can't test this module import asyncore, asynchat, socket, threading, time import unittest +import sys from test import test_support HOST = "127.0.0.1" @@ -58,7 +59,12 @@ def handle_connect(self): pass - ##print "Connected" + + if sys.platform == 'darwin': + # select.poll returns a select.POLLHUP at the end of the tests + # on darwin, so just ignore it + def handle_expt(self): + pass def collect_incoming_data(self, data): self.buffer += data @@ -87,7 +93,7 @@ c.push("world%s" % term) c.push("I'm not dead yet!%s" % term) c.push(SERVER_QUIT) - asyncore.loop(use_poll=self.usepoll)#, count=5, timeout=5) + asyncore.loop(use_poll=self.usepoll, count=300, timeout=.01) s.join() self.assertEqual(c.contents, ["hello world", "I'm not dead yet!"]) @@ -120,7 +126,7 @@ data = "hello world, I'm not dead yet!\n" c.push(data) c.push(SERVER_QUIT) - asyncore.loop(use_poll=self.usepoll)#, count=5, timeout=5) + asyncore.loop(use_poll=self.usepoll, count=300, timeout=.01) s.join() self.assertEqual(c.contents, [data[:termlen]]) @@ -143,7 +149,7 @@ data = "hello world, I'm not dead yet!\n" c.push(data) c.push(SERVER_QUIT) - asyncore.loop(use_poll=self.usepoll)#, count=5, timeout=5) + asyncore.loop(use_poll=self.usepoll, count=300, timeout=.01) s.join() self.assertEqual(c.contents, []) @@ -157,7 +163,7 @@ data = "hello world\nI'm not dead yet!\n" p = asynchat.simple_producer(data+SERVER_QUIT, buffer_size=8) c.push_with_producer(p) - asyncore.loop(use_poll=self.usepoll)#, count=5, timeout=5) + asyncore.loop(use_poll=self.usepoll, count=300, timeout=.01) s.join() self.assertEqual(c.contents, ["hello world", "I'm not dead yet!"]) @@ -169,7 +175,7 @@ c = echo_client('\n') data = "hello world\nI'm not dead yet!\n" c.push_with_producer(data+SERVER_QUIT) - asyncore.loop(use_poll=self.usepoll)#, count=5, timeout=5) + asyncore.loop(use_poll=self.usepoll, count=300, timeout=.01) s.join() self.assertEqual(c.contents, ["hello world", "I'm not dead yet!"]) @@ -182,7 +188,7 @@ c = echo_client('\n') c.push("hello world\n\nI'm not dead yet!\n") c.push(SERVER_QUIT) - asyncore.loop(use_poll=self.usepoll) + asyncore.loop(use_poll=self.usepoll, count=300, timeout=.01) s.join() self.assertEqual(c.contents, ["hello world", "", "I'm not dead yet!"]) @@ -195,7 +201,7 @@ c.push("hello world\nI'm not dead yet!\n") c.push(SERVER_QUIT) c.close_when_done() - asyncore.loop(use_poll=self.usepoll)#, count=5, timeout=5) + asyncore.loop(use_poll=self.usepoll, count=300, timeout=.01) s.join() self.assertEqual(c.contents, [])

1 0

r56631 - doctools/trunk/sphinx/web/application.py
by georg.brandl 30 Jul '07

30 Jul '07

Author: georg.brandl Date: Mon Jul 30 21:47:15 2007 New Revision: 56631 Modified: doctools/trunk/sphinx/web/application.py Log: Make module cloud sizes relative to the smallest number that's present, not 0. Modified: doctools/trunk/sphinx/web/application.py ============================================================================== --- doctools/trunk/sphinx/web/application.py (original) +++ doctools/trunk/sphinx/web/application.py Mon Jul 30 21:47:15 2007 @@ -339,11 +339,13 @@ """ most_frequent = heapq.nlargest(30, self.freqmodules.iteritems(), lambda x: x[1]) - most_frequent = [{ - 'name': x[0], - 'size': 100 + math.log(x[1] or 1) * 20, - 'count': x[1] - } for x in sorted(most_frequent)] + if most_frequent: + base_count = most_frequent[0][1] + most_frequent = [{ + 'name': x[0], + 'size': 100 + math.log((x[1] - base_count) + 1) * 20, + 'count': x[1] + } for x in sorted(most_frequent)] showpf = None newpf = req.args.get('pf')

1 0