Mailman 3 January 2008 - Python-Dev

math and numerical fixes (was: When is min(a, b) != min(b, a)?)
by Christian Heimes 23 Jan '08

23 Jan '08

Jason wrote: > Please note that NaN's are very funky and platform dependent. They > depend on their underlying platform's C library for creation and > display. On windows, "float('nan')" will cause an exception, as there > are no valid string representations of NAN that can be converted to > the special floating point value. Also, if you manage to create a nan > under Windows, it displays as "1.#QNAN". > > Infinite values are also problematic. In almost all cases, it is far > better to avoid infinite and NaN values. CC to Python Dev I've fixed that and enhanced the support for NaN and inf for 2.6 and 3.0. I'm working together with Mark on more NaN and inf related fixes and he has fixed some numerical issues in the cmath module. We both hope to get Python's math more sound and stable across platforms. So far I got float('nan'), float('inf') and float('-inf') working on all platforms. The math module got three new methods: isinf, isnan, copysign. Additionally the trunk-math branch contains code for inverse hyberbolic functions (acosh), log1p, Mark's fixes for complex math and more stuff. For example operations on NaNs now return a NaN on all platforms (except 1**NAN which is defined as 1 and 0**NAN which is defined as 0). In 2.5 it depends on the platform whether a function raises an exception or returns NaN. Mark had the nice idea to introduce a thread local or global flag for NaN support. Depending on a flag Python turns a NaN into an exception. The feature needs a proper PEP. Maybe Mark has time to write a PEP in time. Christian

1 0

rfc822_escape doing the right thing?
by stephen emslie 23 Jan '08

23 Jan '08

I've been working on a project that renders PKG-INFO metadata in a number of ways. I have noticed that fields with any indentation were flattened out, which is being done in distutils.util.rfc822_escape. This unfortunately means that you cant use reStructuredText formatting in your long description (suggested in PEP345), or are limited to a set that doesn't require indentation (no block quotes, etc.). It looks like this behavior was intentionally added in rev 20099, but that was about 7 years ago - before reStructuredText and eggs. I wonder if it makes sense to re-think that implementation with this sort of metadata in mind, assuming this behavior isn't required to be rfc822 compliant. I think it would certainly be a shame to miss out on a good thing like proper (renderable) reST in our metadata. A quick example of what I mean: >>> rest = """ ... a literal python block:: ... >>> import this ... """ >>> print distutils.util.rfc822_escape(rest) a literal python block:: >>> import this should look something like: a literal python block:: >>> import this Is distutils being over-cautious in flattening out all whitespace? A w3c discussion on multiple lines in rfc822 [1] seems to suggest that whitespace can be 'unfolded' safely, so it seems a shame to be throwing it away when it can have important meaning. [1] http://www.w3.org/Protocols/rfc822/3_Lexical.html Thanks for any comments Stephen Emslie

1 0

Re: [Python-Dev] misbehaving __contains__
by Raymond Hettinger 23 Jan '08

23 Jan '08

>> And, would we lose the nice relationship expressed by: >> >> for elem in container: >> assert elem in container [Steven Bethard] >We've already lost this if anyone really wants to break it:: > > >>> class C(object): > ... def __iter__(self): > ... return iter(xrange(3)) > ... def __contains__(self, item): > ... return False I think this is in the same category as writing a __hash__ that doens't match __eq__. It is explicitly shooting yourself in the foot. I'm more concerned about introducing an API where well-meaning attempts to code a __contains__ override will implicitly shoot the toes off of client code that innocently assumes a somewhat sensible invariant relation between looping over elements in a container and those elements being in the container. The code for sets and frozensets makes that assumption, for example. And, when the code does break, the errors will be darned hard to find. Raymond

2 1

PEP: per user site-packages directory
by Christian Heimes 23 Jan '08

23 Jan '08

MA Lemburg has suggested a per user site-packages directory in the "pkgutil, pkg_resource and Python 3.0 name space packages" thread. I've written a short PEP about it for Python 2.6 and 3.0. PEP: XXX Title: Per user site-packages directory Version: $Revision$ Last-Modified: $Date$ Author: Christian Heimes <christian(at)cheimes(dot)de> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 11-Jan-2008 Python-Version: 2.6, 3.0 Post-History: Abstract ======== This PEP proposes a new a per user site-packages directory to allow users the local installation of Python packages in their home directory. Rationale ========= Current Python versions don't have an unified way to install packages into the home directory of an user (except for Mac Framework builds). Users are either forced to ask the system administrator to install or update a package for them or to use one of the many workaround like Virtual Python [1]_, Working Env [2]_ or Virtual Env [3]_. It's not the goal of the PEP to replace the tools or to implement isolated installations of Python. It only implements the most common use case of an additional site-packages directory for each user. The feature can't be implemented using the environment variable *PYTHONPATH*. The env var just inserts a new directory to the beginning of *sys.path* but it doesn't parse the pth files in the directory. A full blown site-packages path is required for several applications and Python eggs. Specification ============= site directory (site-packages) A directory in sys.path. In contrast to ordinary directories the pth files in the directory are processed, too. user site directory A site directory inside the users' home directory. An user site directory is specific to a Python version. The path contains the version number (major and minor only). Windows: %APPDATA%/Python/Python26/site-packages Mac: ~/Library/Python/2.6/site-packages Unix: ~/.local/lib/python2.6/site-packages user configuration directory Usually the parent directory of the user site directory. It's meant for Python version specific data like config files. Windows: %APPDATA%/Python/Python26 Mac: ~/Library/Python/2.6 Unix: ~/.local/lib/python2.6 user base directory It's located inside the user's home directory. The user site and use config directory are inside the base directory. On some systems the directory may be shared with 3rd party apps. Windows: %APPDATA%/Python Mac: ~/Library/Python Unix: ~/.local On Windows APPDATA was chosen because it is the most logical place for application data. Microsoft recommands that software doesn't write to USERPROFILE [5]_ and My Documents is not suited for application data, too. [8]_ On Linux ~/.local/ was chosen in favor over ./~python/ because the directory is already used by several other programs in analogy to /usr/local. [7]_ Implementation ============== The site module gets a new method adduserpackage() which adds the appropriate directory to the search path. The directory is not added if it doesn't exist when Python is started. However the location of the user site directory and user base directory is stored in an internal variable for distutils. The user site directory is added before the system site directories but after Python's search paths and PYTHONPATH. This setup allows the user to install a different version of a package than the system administrator but it prevents the user from accidently overwriting a stdlib module. Stdlib modules can still be overwritten with PYTHONPATH. distutils.command.install (setup.py install) gets a new argument --user to install packages in the user site directory. The required directories are created by install. distutils.sysconfig will get methods to access the private variables of site. (not yet implemented) The Windows updater needs to be updated, too. It should create an menu item which opens the user site directory in a new explorer windows. Backwards Compatibility ======================= TBD Open Questions ============== * Are the directories for Windows, Mac and Unix fine? * Mac: Should framework and non-framework builds of Python use the same directories? * The patch also adds a usecustomize hook to site. Is it useful and should it stay? Reference Implementation ======================== A reference implementation is available in the bug tracker. [4]_ Acknowledgments =============== The implementation of this PEP, if accepted, is sponsored by Google through the Google Summer of Code program. Copyright ========= This document has been placed in the public domain. References ========== .. [1] Virtual Python http://peak.telecommunity.com/DevCenter/EasyInstall#creating-a-virtual-pyth… .. [2] Working Env http://pypi.python.org/pypi/workingenv.py http://blog.ianbicking.org/workingenv-revisited.html .. [3] Virtual Env http://pypi.python.org/pypi/virtualenv .. [4] reference implementation http://bugs.python.org/issue1799 .. [5] MSDN: CSIDL http://msdn2.microsoft.com/en-us/library/bb762494.aspx .. [6] Initial suggestion for a per user site-packages directory http://permalink.gmane.org/gmane.comp.python.devel/90902 .. [7] Suggestion of ~/.local/ http://permalink.gmane.org/gmane.comp.python.devel/90925 .. [8] APPDATA discussion http://permalink.gmane.org/gmane.comp.python.devel/90932 .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

22 66

Rational approximation methods
by Jeffrey Yasskin 23 Jan '08

23 Jan '08

In the Rational class that I've recently checked into Python 2.6 (http://bugs.python.org/issue1682), it might be nice to provide a method that, given a particular rational number, returns a nearby number that's nicer in some way. I know of two reasonable behaviors for this operation. Since I don't know which is likely to be more useful, or even if either is useful enough to include in the first version of the module, I'm coming to you guys for advice. Both were implemented a while ago in http://svn.python.org/view/sandbox/trunk/rational/Rational.py?rev=40988&vie… and are based on the continued fraction representation of the number (http://en.wikipedia.org/wiki/Continued_fraction#Best_rational_approximations). The first returns the closest rational whose denominator is less than a given integer. For discussion, we might call it .limit_denominator(), although I'm also looking for good names. This seems useful for computations in which you want to sacrifice some accuracy for speed. On the other hand, Decimal may fill the niche for fast-ish computation that surprises people less than float. The second returns the simplest rational within some distance. For instance, it'll prefer 22/7 over 333/106 if both are close enough. We might call it .simplest_within() for now. This seems useful for converting from float and displaying results to users, where we prefer readability over accuracy or have reason to believe that a simpler fraction might be more correct. What does the list think? Jeffrey

6 8

Re: [Python-Dev] misbehaving __contains__
by Raymond Hettinger 23 Jan '08

23 Jan '08

[Daniel Stutzbach] > There are many places in the C implementation where a slot > returns an int rather than a PyObject. There other replies > in this thread seem to support altering the signature of the > slot to return a PyObject. Is this setting a precedent that > _all_ slots should return a PyObject? I hope not. One cost of these hypergeneralizations is that it makes Python slower. Also, it makes it harder to write code when you can no longer count on simple predicates to return either True or False. [tomer filiba] > i see no reason it should behave differently than > __eq__ and the rest of comparison operators The rest of the equality operators were a special case to allow rich comparisons which were needed to implement some vector arithmetic idioms. It was thought that those use case had enough benefit to pay for the negative impacts: * making the language more complex * slowing everything down a bit. * complicating the underlying implementation * making the language more difficult to learn (rich operators are harder than cmp) Does making __contains__ return a PyObject have use cases that are worth those costs? It is reminiscent of the ill-fated proposals to overrride 'and', 'or', 'is', and 'is not'. A couple more questions about the proposal: If __contains__ returns 17 in Tomer's example, what would "8 not in f" return? And, would we lose the nice relationship expressed by: for elem in container: assert elem in container It looks like changing the semantics would introduce some weirdness. Raymond

2 1

misbehaving __contains__
by tomer filiba 22 Jan '08

22 Jan '08

i'm using python to create expression objects, for more intuitive usage as predicates, for instance: x = (Arg(0) > 17) & (Arg(1).foo == "bar") instead of x = And(Gt(Arg(0), 17), Eq(GetAttr(Arg(1), "foo"), "bar")) so now i can use x.eval(18, "spam") and get the result of the expression. i'm doing it by overriding all the operators to return expression objects, instead of evaluating the result immediately. it works fine, but i encountered a problem with making __contains__ behave so. it turns out __contains__ coerces the return value into a bool. this might seem logical at first, but is not consistent with the result of the language. consider the following code: >>> class Foo(object): ... def __contains__(self, key): ... return 17 ... def __eq__(self, other): ... return 19 ... >>> >>> f=Foo() >>> f == 8 19 >>> 8 in f True as you can see, __eq__ does not coerces the result to bool, so why should __contains__ do that? i've looked at PySequence_Contains in objects/abstract.c, but i can't quite understand where the coercion is made. is because the function is typed as int? if so, i believe it should either be changed to PyObject, or have cmp_outcome (in ceval.c) not use this API directly, and rather return the result as it is returned from __contains__. i see no reason it should behave differently than __eq__ and the rest of comparison operators. -tomer

4 4

Bug Day outcome
by A.M. Kuchling 21 Jan '08

21 Jan '08

Today's bug day was a great success. Experienced people like Georg, Facundo, and Gregory P. Smith participated, and we also had people who submitted their first patches, some of which got applied today, too. Hopefully we'll see those people again. As of this writing, 37 issues were closed today, leaving 1300 open. (I saved a search in Roundup to list the bugs closed today.) --amk

6 9

Monkeypatching idioms -- elegant or ugly?
by Guido van Rossum 21 Jan '08

21 Jan '08

I ran into the need of monkeypatching a large number of classes (for what I think are very good reasons :-) and invented two new recipes. These don't depend on Py3k, and the second one actually works all the way back to Python 2.2. Neither of these allows monkeypatching built-in types like list. If you don't know what monkeypatching is, see see http://en.wikipedia.org/wiki/Monkey_patch. I think it's useful to share these recipes, if only to to establish whether they have been discovered before, or to decide whether they are worthy of a place in the standard library. I didn't find any relevant hits on the ASPN Python cookbook. First, a decorator to add a single method to an existing class: def monkeypatch_method(cls): def decorator(func): setattr(cls, func.__name__, func) return func return decorator To use: from <somewhere> import <someclass> @monkeypatch_method(<someclass>) def <newmethod>(self, args): return <whatever> This adds <newmethod> to <someclass> Second, a "metaclass" to add a number of methods (or other attributes) to an existing class, using a convenient class notation: def monkeypatch_class(name, bases, namespace): assert len(bases) == 1, "Exactly one base class required" base = bases[0] for name, value in namespace.iteritems(): if name != "__metaclass__": setattr(base, name, value) return base To use: from <somewhere> import <someclass> class <newclass>(<someclass>): __metaclass__ = monkeypatch_class def <method1>(...): ... def <method2>(...): ... ... This adds <method1>, <method2>, etc. to <someclass>, and makes <newclass> a local alias for <someclass>. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

9 11

PyCon 2008 Registration Open!
by David Goodger 21 Jan '08

21 Jan '08

I am pleased to announce that PyCon 2008 registration is now open! http://us.pycon.org/2008/registration/ Early-bird registration is open until February 20, so there's one month to register at the low rates. Regular on-line registration will be available from February 21 through March 7. PyCon 2008 will be held from March 13 through 20 in Chicago: * Tutorials: Thursday, March 13 * Conference: Friday, March 14, through Sunday, March 16 * Sprints: Monday, March 17 through Thursday, March 20 Register early, especially if you'd like to attend a tutorial or three, as tutorials fill up early. And yes, you heard that correctly -- this year, we have three tutorial sessions: morning, afternoon, and evening. There are 29 great tutorials to choose from. More about the tutorials soon, but for now, you can check out the descriptions yourself here: http://us.pycon.org/2008/tutorials/schedule/ The talk schedule is also up (in a preliminary form), although some changes are expected: http://us.pycon.org/2008/conference/schedule/ Hotel reservations are also open: https://www.cteusa.com/pycon1/ The rate is $99/night plus tax ($112/night net), also until February 20. More hotel information is here: http://us.pycon.org/2008/registration/hotel/ See the PyCon web site for complete details: http://us.pycon.org/2008/ Thanks to the PyCon organizers for developing the software, providing the website content, testing & debugging. PyCon is a community conference, of, by, and for the Python community. There is still much to do, and you can help! http://us.pycon.org/2008/helping/ See you in Chicago! David Goodger PyCon 2008 Chair

1 0