Mailman 3 April 2009 - Python-Dev

PyEval_Call* convenience functions
by Tim Lesher 24 Apr '09

24 Apr '09

Is there a reason that the PyEval_CallFunction() and PyEval_CallMethod() convenience functions remain undocumented? (i.e., would a doc-and-test patch to correct this be rejected?) I didn't see any mention of this coming up in python-dev before. Also, despite its name, PyEval_CallMethod() is quite useful for calling module-level functions or classes (given that it's just a PyObject_GetAttrString plus the implementation of PyEval_CallFunction). Is there any reason (beyond its undocumented status) to believe this use case would ever be deprecated? Thanks. -- Tim Lesher <tlesher(a)gmail.com>

2 1

version for blender Vista
by Yuma Scott 24 Apr '09

24 Apr '09

Can you tell me which installer of Python I need to work with Blender and Windows Vista Home Premium? Thanks! Yuma Scott

2 1

Re: [Python-Dev] Python3 and arm-linux
by Bugbee, Larry 24 Apr '09

24 Apr '09

> > Somebody knowns, is python3 works on arm-linux. Is it possible to build it? > > Where to find related discussions? Maybe some special patches already > > available? Should i try to get sources from svn or get known version > > snapshot? > > > > I haven't tried, but there's an interesting distro at http://www.vanille- > media.de/site/index.php/projects/python-for-arm-linux/ -- I don't know if > other such distros have better-updated Python versions (eg. current 2.6.* > vs that one's 2.4.*) but that one includes a lot of very useful add-ons. You may want to look at the Ångström distro. http://www.angstrom-distribution.org/ http://www.angstrom-distribution.org/repo/?pkgname=libpython2.6-1.0 That's where I'll be heading in a couple of weeks. (I have a new BeagleBoard with an ARM Cortex-A8.) Larry

1 0

Python3 and arm-linux
by cyberGn0m 23 Apr '09

23 Apr '09

Somebody knowns, is python3 works on arm-linux. Is it possible to build it? Where to find related discussions? Maybe some special patches already available? Should i try to get sources from svn or get known version snapshot? ----------------------------------------------------------------- <y6erGn0m.

2 2

Suggested doc patch for tarfile
by Ben North 23 Apr '09

23 Apr '09

Hi, The current documentation for tarfile.TarFile.extractfile() does not mention that the returned 'file-like object' supports close() and also iteration. The attached patch (against svn trunk) fixes this. (Background: I was wondering whether I could write def process_and_close_file(f_in): with closing(f_in) as f: # Do stuff with f. and have it work whether f_in was a true file or the return value of extractfile(), and thought from the documentation that I couldn't. Of course, I could have just tried it, but I think fixing the documentation wouldn't hurt.) Alternative: enhance the tarfile.ExFileObject class to support use as a context manager? Thanks, Ben.

2 2

Proposed: add an environment variable, PYTHONPREFIXES
by Larry Hastings 23 Apr '09

23 Apr '09

I've submitted a patch to implement a new environment variable, PYTHONPREFIXES. The patch is here: http://bugs.python.org/issue5819 PYTHONPREFIXES is similar to PYTHONUSERBASE: it lets you add "prefix directories" to be culled for site packages. It differs from PYTHONUSERBASE in three ways: * PYTHONPREFIXES has an empty default value. PYTHONUSERBASE has a default, e.g. ~/.local on UNIX-like systems. * PYTHONPREFIXES supports multiple directories, separated by the site-specific directory separator character (os.pathsep). Earlier directories take precedence. PYTHONUSERBASE supports specifying at most one directory. * PYTHONPREFIXES adds its directories to site.PREFIXES, so it reuses the existing mechanisms for site package directories, exactly simulating a real prefix directory. PYTHONUSERBASE only adds a single directory, using its own custom code path. This last point bears further discussion. PYTHONUSERBASE's custom code to inspect only a single directory has resulted in at least one bug, if not more, as follows: * The bona-fide known bug: the Debian package mantainer for Python decided to change "site-packages" to "dist-packages" in 2.6, for reasons I still don't quite understand. He made this change in site.addsitepackages and distutils.sysconfig.get_python_lib, and similarly in setuptools, but he missed changing it in site.addusersitepackages. This meant that if you used setup.py to install a package to a private prefix directory, PYTHONUSERBASE had no hope of ever finding the package. (Happily this bug is fixed.) * I suspect there's a similar bug with PYTHONUSERBASE on the "os2emx" and "riscos" platforms. site.addsitepackages on those platforms looks in "{prefix}/Lib/site-packages", but site.addusersitepackages looks in "{prefix}/lib/python{version}/site-packages" as it does on any non-Windows platform. Presumably setup.py on those two platforms installs site packages to the directory site.addsitepackages inspects, which means that PYTHONUSERBASE doesn't work on those two platforms. PYTHONUSERBASE's custom code path to add site package directories seems unnecessary to me. I cannot fathom why its implementors chose this approach; in any case I think reusing site.addsitepackages is a clear win. I fear it's too late to change PYTHONUSERBASE so it simply called site.addsitepackages, as that would change its established semantics. Though if that idea found support I'd be happy to contribute a patch. A few more notes on PYTHONPREFIXES: * PYTHONPREFIXES is gated by the exact same mechanisms that shut off PYTHONUSERBASE. * Specifying "-s" on the Python command line shuts it off. * Setting the environment variable PYTHONNOUSERSITE to a non-empty string shuts it off. * If the effective uid / gid doesn't match the actual uid / gid it automatically shuts off. * I'm not enormously happy with the name. Until about an hour or two ago I was calling it "PYTHONUSERBASES". I'm open to other suggestions. * I'm not sure that PYTHONPREFIX should literally modify site.PREFIXES. If that's a bad idea I'd be happy to amend the patch so it didn't touch site.PREFIXES. * Reaction in python-ideas has been reasonably positive, though I gather Nick Coughlan and Scott David Daniels think it's unnecessary. (To read the discussion, search for the old name: "PYTHONUSERBASES".) * Ben Finney prefers a counter-proposal he made in the python-ideas discussion: change the existing PYTHONUSERBASE to support multiple directories. I don't like this approach, because: a) it means you have to explicitly add the local default if you want to use it, and b) PYTHONUSERBASE only inspects one directory, whereas PYTHONPREFIX inspects all the directories Python might use for site packages. I do admit this approach would be preferable to no change at all. The patch is thrillingly simple and works fine. However it's not ready to be merged because I haven't touched the documentation. I figured I'd hold off until I see which way the wind blows. I'd also be happy to convert this into a PEP if that's what's called for. /larry/

2 1

Reminder: Python Bug Day on Saturday
by Georg Brandl 23 Apr '09

23 Apr '09

Hi, I'd like to remind everyoone that there will be a Python Bug Day on April 25. As always, this is a perfect opportunity to get involved in Python development, or bring your own issues to attention, discuss them and (hopefully) resolve them together with the core developers. We will coordinate over IRC, in #python-dev on irc.freenode.net, and the Wiki page http://wiki.python.org/moin/PythonBugDay has all important information and a short list of steps how to get set up. Hope to see you there! Georg

1 0

Issue5434: datetime.monthdelta
by Jess Austin 22 Apr '09

22 Apr '09

hi, I'm new to python core development, and I've been advised to write to python-dev concerning a feature/patch I've placed at http://bugs.python.org/issue5434, with Rietveld at http://codereview.appspot.com/25079. This patch adds a "monthdelta" class and a "monthmod" function to the datetime module. The monthdelta class is much like the existing timedelta class, except that it represents months offset from a date, rather than an exact period offset from a date. This allows us to easily say, e.g. "3 months from now" without worrying about the number of days in the intervening months. >>> date(2008, 1, 30) + monthdelta(1) datetime.date(2008, 2, 29) >>> date(2008, 1, 30) + monthdelta(2) datetime.date(2008, 3, 30) The monthmod function, named in (imperfect) analogy to divmod, allows us to round-trip by returning the interim between two dates represented as a (monthdelta, timedelta) tuple: >>> monthmod(date(2008, 1, 14), date(2009, 4, 2)) (datetime.monthdelta(14), datetime.timedelta(19)) Invariant: dt + monthmod(dt, dt+td)[0] + monthmod(dt, dt+td)[1] == dt + td These also work with datetimes! There are more details in the documentation included in the patch. In addition to the C module file, I've updated the datetime CAPI, the documentation, and tests. I feel this would be a good addition to core python. In my work, I've often ended up writing annoying one-off "add-a-month" or similar functions. I think since months work differently than most other time periods, a new object is justified rather than trying to shoe-horn something like this into timedelta. I also think that the round-trip functionality provided by monthmod is important to ensure that monthdeltas are "first-class" objects. Please let me know what you think of the idea and/or its execution. thanks, Jess Austin

15 29

3.1 beta blockers
by Benjamin Peterson 21 Apr '09

21 Apr '09

The first (and only) beta of 3.1 is scheduled for less than 2 weeks away, May 2nd, and is creeping onto the horizon. There are currently 6 blockers: #5692: test_zipfile fails under Windows - This looks like a fairly easy fix. #5775: marshal.c needs to be checked for out of memory errors - Looks like Eric has this one. #5410: msvcrt bytes cleanup - It would be nice to have a Windows expert examine the patch on this issue for correctness. #5786: [This isn't applicable to 3.1] #5783: IDLE cannot find windows chm file - Awaiting a fix to the IDLE or the doc build system. -- Thanks for your work, Benjamin

5 9

Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable
by Benjamin Peterson 20 Apr '09

20 Apr '09

2009/4/18 Mitchell L Model <MLMLists(a)comcast.net>: > Some library files, such as pdb.py, begin with > #!/usr/bin/env python > In various discussions regarding some issues I submitted I was told that the > decision had been made to call Python 3.x release executables python3. (One > of the conflicts I ran into when I made 'python' a link to python3.1 was > that some tools used in making the HTML documentation haven't been upgraded > to run with 3.) > > Shouldn't all library files that begin with the above line be changed so > that they read 'python3' instead of python? Perhaps I should have just filed > this as an issue, but I'm not confident of the state of the plan to move to > python3 as the official executable name. That sounds correct. Please file a bug report. -- Regards, Benjamin

15 24