Mailman 3 September 2009 - Python-Dev

Python 2.7 Mac universal builds seem broken on trunk
by Barry Scott Sept. 29, 2009

Sept. 29, 2009

I'm working with http://svn.python.org/projects/python/trunk on Mac OS X 10.6.1 using Apples xcode gcc 4.2.1. When I run the following commands: ./configure --enable-framework --with-universal-archs=32-bit | tee build.config.log make clean all | tee build.make.log I end up with a x86_64 Python image. No matter what I use for archs its always the same. I would expect to see -arch arg to GCC but it is not there. export CFLAG="-arch i386" did not work either. Am I doing something wrong or is this broken on trunk? Barry

5 9

bug 3890
by Barry Warsaw Sept. 29, 2009

Sept. 29, 2009

I'd like to include the patch for bug 3890 in Python 2.6.3. There is a patch by Amaury that has gotten the blessing of Bill Janssen, however the patch has no test. Is there anybody who can come up with a test in the next few hours so we can get this into 2.6.3rc1? If not, is the fix important enough to include without the test? -Barry

1 0

Fuzziness in io module specs
by Pascal Chambon Sept. 29, 2009

Sept. 29, 2009

Hello everyone I'm currently working on a reimplementation of io.FileIO, which would allow cross-platform file range locking and all kinds of other safety features ; however I'm slightly stuck due to some specification fuzziness in the IO docs. CF http://bugs.python.org/issue6939 The main points that annoy me at the moment : - it is unclear what truncate() methods do with the file pointer, and even if the current implementation simply moves it to the truncation point, it's very contrary to the standard way of doing under unix, where the file pointer is normally left unchanged. Shouldn't we specify that the file pointer remains unmoved, and fix the _fileio module accordingly ? - exceptions are not always specified, and even if most of them are IOErrors, weirdly, in some cases, an OSError is raised instead (ie, if we try to wrap a wrong file descriptor when instanciating a new FileIO). This might lead to bad program crashes if some people don't "refuse the temptation to guess" and only get prepared to catch IOErrors - the doc sometimes says that when we receive an empty string from a read() operation, without exceptions, it means the file is empty. However, with the current implementation, if we call file.read(0), we simply receive "", even though it doesn't mean that we're at EOF. Shouldn't we avoid this (rare, I admit) ambiguity on the return value, by preventing read(0) ? Or at least, note in the doc that (we receive an empty string) <-> (the file is at EOF OR we called read with 0 as parameter) ? Are there some arguments that I don't know, which lead to this or that particular implementation choice ? I'd strongly advocate very detailled specifications, letting no room for cross-platform subtilities (that's also a strong goal of my reimplemntation), since that new IO system (which saved me a lot of coding time, by the way) should become the base of many programs. So wouldn't it be a godo idea to write some kind of mini-pep, just to fix the corner cases of the current IO documentation ? I might handle it, if no more-knowledgeable people feels like it. Regards, Pascal

14 45

IO module precisions and exception hierarchy
by Pascal Chambon Sept. 29, 2009

Sept. 29, 2009

Found in current io PEP : Q: Do we want to mandate in the specification that switching between reading and writing on a read-write object implies a .flush()? Or is that an implementation convenience that users should not rely on? -> it seems that the only important matter is : file pointer positions and bytes/characters read should always be the ones that the user expects, as if there were no buffering. So flushing or not may stay a non-mandatory behaviour, as long as the buffered streams ensures this data integrity. Eg. If a user opens a file in r/w mode, writes two bytes in it (which stay buffered), and then reads 2 bytes, the two bytes read should be those on range [2:4] of course, even though the file pointer would, due to python buffering, still be at index 0. Q from me : What happens in read/write text files, when overwriting a three-bytes character with a single-byte character ? Or at the contrary, when a single chinese character overrides 3 ASCII characters in an UTF8 file ? Is there any system designed to avoid this data corruption ? Or should TextIO classes forbid read+write streams ? IO Exceptions : Currently, the situation is kind of fuzzy around EnvironmentError subclasses. * OSError represents errors notified by the OS via errno.h error codes (as mirrored in the python "errno" module). errno.h errors (less than 125 error codes) seem to represent the whole of *nix system errors. However, Windows has many more system errors (15000+). So windows errors, when they can't be mapped to one of the errno errors are raises as "WindowsError" instances (a subclass of OSError), with the special attribute "winerror" indicating that win32 error code. * IOError are "errors raised because of I/O problems", but they use errno codes, like OSError. Thus, at the moment IOErrors rather have the semantic of "particular case of OSError", and it's kind of confusing to have them remain in their own separate tree... Furthermore, OSErrors are often used where IOErrors would perfectly fit, eg. in low level I/O functions of the OS module. Since OSErrors and IOErrors are slightly mixed up when we deal with IO operations, maybe the easiest way to make it clearer would be to push to their limits already existing designs. - the os module should only raise OSErrors, whatever the os operation involved (maybe it's already the case in CPython, isn't it ?) - the io module should only raise IOErrors and its subclasses, so that davs can easily take measures depending on the cause of the io failure (except 1 OSError exception, it's already the case in _fileio) - other modules refering to i/o might maybe keep their current (fuzzy) behaviour, since they're more platform specific, and should in the end be replaced by a crossplatform solution (at least I'd love it to happen) Until there, there would be no real benefits for the user, compared to catching EnvironmentErrors as most probably do. But the sweet thing would be to offer a concise but meaningfull IOError hierarchy, so that we can easily handle most specific errors gracefully (having a disk full is not the same level of gravity as simply having another process locking your target file). Here is a very rough beginning of IOError hierarchy. I'd liek to have people's opinion on the relevance of these, as well as on what other exceptions should be distinguished from basic IOErrors. IOError +-InvalidStreamError (eg. we try to write on a stream opened in readonly mode) +-LockingError +-PermissionError (mostly *nix chmod stuffs) +-FileNotFoundError +-DiskFullError +-MaxFileSizeError (maybe hard to implement, happens when we exceed 4Gb on fat32 and stuffs...) +-InvalidFileNameError (filepath max lengths, or "? / : " characters in a windows file name...) Regards, Pascal

7 16

Re: [Python-Dev] PEP 389: argparse - new command line parsing module
by Steven Bethard Sept. 28, 2009

Sept. 28, 2009

On Sun, Sep 27, 2009 at 8:49 PM, Benjamin Peterson <benjamin(a)python.org> wrote: > 2009/9/27 Steven Bethard <steven.bethard(a)gmail.com>: >> On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson <benjamin(a)python.org> wrote: >>> 2009/9/27 Steven Bethard <steven.bethard(a)gmail.com>: >>>> The first release where any real deprecation message would show up is >>>> Python 3.4, more than 3 years away. If you think 3 years isn't long >>>> enough for people to be over the Python 3 transition, let's stick in >>>> another version in there and make it 4.5 years. >>> >>> So, why even bother deprecating it if nobody is going to see the warnings? >> >> I feel like I'm repeating the PEP, but here it is again anyway. There >> will be messages in the docs and pending deprecation warnings (which >> don't show up by default but can be requested) starting in Python 2.7 >> and 3.2. Regular deprecation warnings wouldn't show up until Python >> 3.4, 3 years away. This compromise was intended exactly to address the >> issue you brought up about people getting over the Python 3 >> transition. > > But that doesn't tell me why we should deprecate optparse, when it may > work perfectly well for some people. Because it's basically unmaintained, and anything you can do in optparse you can do in argparse with almost identical syntax. So encouraging people to move from getopt and optparse to argparse is a net gain for us as Python maintainers -- that's two fewer modules in the standard library that someone has to take care of bug reports for. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus

1 0

PEP 3144: IP Address Manipulation Library for the Python Standard Library
by Peter Moody Sept. 27, 2009

Sept. 27, 2009

Howdy folks, I have a first draft of a PEP for including an IP address manipulation library in the python stdlib. It seems like there are a lot of really smart folks with some, ahem, strong ideas about what an IP address module should and shouldn't be so I wanted to solicit your input on this pep. the pep can be found here: http://www.python.org/dev/peps/pep-3144/ the code can be found here: http://ipaddr-py.googlecode.com/svn/branches/2.0.x/ Please let me know if you have any comments (some already coming :) Cheers, /peter

22 76

Python build question (fixing pymath.c).
by Mark Dickinson Sept. 27, 2009

Sept. 27, 2009

Hello all, I'm looking for advice on how to clean up an ugliness (one that I'm at least partly responsible for) in the Python build setup. Here's the problem: some of the exported functions (e.g. atanh, log1p) in the Python/pymath.c file aren't needed by the Python core at all; they're exported solely for use in the math and cmath modules. Even worse, these exported functions have no '_Py' or 'Py' prefix. Since I'm currently working on adding some oft-requested functions to the math module (gamma, lgamma, erf, ...) it seemed like a good time to clean this up. So I've now got a file Modules/math_support.c that contains some functions needed by both mathmodule.c and cmathmodule.c, as well as a couple of functions only currently needed by the math module. How should I incorporate this file into the build? One obvious solution seems to be to build an extra math_support.so file that's then used by both mathmodule.so and cmathmodule.so. Is this a sensible solution? Are there better ways? A complication to bear in mind is that some users may want to alter Modules/Setup.dist so that either the math module and/or the cmath module is included in the core Python executable. Cluelessly yours, Mark

2 2

Misc/maintainers.rst
by R. David Murray Sept. 27, 2009

Sept. 27, 2009

I floated a proposal on stdlib-sig to create a file named Misc/maintainers.rst. The purpose of this file is to collect knowledge about who knows which modules well enough to make decision about issues in the tracker when the participants in the issue aren't sure, and to write down the community knowledge about who has special interest and expertise in specific topic areas. This proposal was met with approval and, after a couple of small modifications of the proposal, no dissent; so I've created the skeleton of the file. I've filled in some of the blanks where I had personal knowledge, was told info on IRC, from the two referenced PEPs, and from PEP 11. Feel free to respond with comments about the header text, but more importantly let me know what you know about who (especially if it is you) should be listed for each module, platform, and topic, and feel free to suggest additional topics. My goal is to record the community knowledge. Another topic of discussion that is orthogonal to filling in the table is whether or not to publish it outside the repository. Jesse would like to see it included in the Python Documentation, and Georg has suggested the possibility of creating a separate, sphinx-based, automatically-uploaded document collection in the repository to contain this and related information (Misc/devdocs?). The module list was built from the py3k documentation module index, with the addition of 'pybench' from PEP 291. If there are other modules/tools that are missing, or submodules that should be broken out into separate lines, please let me know. After the initial flurry of updates and comments dies down I will check this in. --David ---------------------------------------------------------------------- Maintainers Index ================= This document cross references Python Modules (first table) and platforms (second table) with the Tracker user names of people who are experts and/or resources for that module or platform. This list is intended to be used by issue submitters, issue triage people, and other issue participants to find people to add to the nosy list or to contact directly by email for help and decisions on feature requests and bug fixes. People on this list may be asked to render final judgement on a feature or bug. If no active maintainer is listed for a given module, then questionable changes should go to python-dev, while any other issues can and should be decided by any committer. The last part of this document is a third table, listing broader topic areas in which various people have expertise. These people can also be contacted for help, opinions, and decisions when issues involve their areas. If a listed maintainer does not respond to requests for comment for an extended period (three weeks or more), they should be marked as inactive in this list by placing the word 'inactive' in parenthesis behind their tracker id. They are of course free to remove that inactive mark at any time. Committers should update this table as their areas of expertise widen. New topics may be added to the third table at will. The existence of this list is not meant to indicate that these people *must* be contacted for decisions; it is, rather, a resource to be used by non-committers to find responsible parties, and by committers who do not feel qualified to make a decision in a particular context. See also `PEP 291`_ and `PEP 360`_ for information about certain modules with special rules. .. _`PEP 291`: http://www.python.org/dev/peps/pep-0291/ .. _`PEP 360`: http://www.python.org/dev/peps/pep-0360/ ================== =========== Module Maintainers ================== =========== __future__ __main__ gvanrossum _dummy_thread brett.cannon _thread abc aifc r.david.murray array ast asynchat josiahcarlson asyncore josiahcarlson atexit audioop base64 bdb binascii binhex bisect builtins bz2 calendar cgi cgitb chunk cmath cmd code codecs codeop collections colorsys compileall configparser contextlib copy copyreg cProfile crypt csv ctypes theller curses datetime dbm decimal difflib dis distutils tarek doctest dummy_threading brett.cannon email barry encodings errno exceptions fcntl filecmp fileinput fnmatch formatter fpectl fractions ftplib functools gc getopt getpass gettext glob grp gzip hashlib heapq hmac html http imaplib imghdr imp importlib brett.cannon inspect io pitrou, benjamin.peterson itertools json keyword lib2to3 benjamin.peterson linecache locale logging vsajip macpath mailbox mailcap marshal math mimetypes mmap modulefinder theller, jvr msilib msvcrt multiprocessing jnoller netrc nis nntplib numbers operator optparse aronacher os ossaudiodev parser pdb pickle pickletools pipes pkgutil platform lemburg plistlib poplib posix pprint pstats pty pwd py_compile pybench lemburg pyclbr pydoc queue quopri random re readline reprlib resource rlcompleter runpy sched select shelve shlex shutil signal site smtpd smtplib sndhdr socket socketserver spwd sqlite3 ssl stat string stringprep struct subprocess astrand (inactive) sunau symbol symtable sys syslog tabnanny tarfile telnetlib tempfile termios test textwrap threading time timeit tkinter gpolo token tokenize trace traceback tty turtle gregorlingl types unicodedata unittest michael.foord urllib uu uuid warnings wave weakref webbrowser georg.brandl winreg winsound wsgiref pje xdrlib xml loewis xml.etree effbot (inactive) xmlrpc loewis zipfile zipimport zlib ================== =========== ================== =========== Platform Maintainer ------------------ ----------- AIX Cygwin jlt63 FreeBSD Linux Mac ronaldoussoren NetBSD1 OS2/EMX aimacintyre Solaris HP-UX ================== =========== ================== =========== Interest Area Maintainers ------------------ ----------- algorithms ast/compiler autoconf bsd buildbots data formats database documentation georg.brandl GUI i18n import machinery brett.cannon io pitrou, benjamin.peterson locale makefiles mathematics marketdickinson, eric.smith memory management networking packaging release management time and dates testing michael.foord threads unicode windows ================== ===========

11 21

LAST CHANCE: PyCon 2010: Call for Proposals
by Aahz Sept. 27, 2009

Sept. 27, 2009

Just four more days to propose a presentation! Call for proposals -- PyCon 2010 -- <http://us.pycon.org/2010/> =============================================================== Due date: October 1st, 2009 Want to showcase your skills as a Python Hacker? Want to have hundreds of people see your talk on the subject of your choice? Have some hot button issue you think the community needs to address, or have some package, code or project you simply love talking about? Want to launch your master plan to take over the world with python? PyCon is your platform for getting the word out and teaching something new to hundreds of people, face to face. Previous PyCon conferences have had a broad range of presentations, from reports on academic and commercial projects, tutorials on a broad range of subjects and case studies. All conference speakers are volunteers and come from a myriad of backgrounds. Some are new speakers, some are old speakers. Everyone is welcome so bring your passion and your code! We're looking to you to help us top the previous years of success PyCon has had. PyCon 2010 is looking for proposals to fill the formal presentation tracks. The PyCon conference days will be February 19-22, 2010 in Atlanta, Georgia, preceded by the tutorial days (February 17-18), and followed by four days of development sprints (February 22-25). Online proposal submission is open now! Proposals will be accepted through October 1st, with acceptance notifications coming out on November 15th. For the detailed call for proposals, please see: <http://us.pycon.org/2010/conference/proposals/> For videos of talks from previous years - check out: <http://pycon.blip.tv> We look forward to seeing you in Atlanta! -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet

1 0

thinking about 2.7
by Benjamin Peterson Sept. 25, 2009

Sept. 25, 2009

Hi everyone, I've started plotting the release of 2.7. I'd like to try for a final release mid next summer. 3.2 should be released, if not at the same time as 2.7, within a few weeks to avoid 2.x having features which 3.x doesn't. If no one has problems with this, I will draft a schedule. Are we still planning to make 3.3 the main development focus and start the 5 years of 2.x maintenance after this release? Additionally, I'm very apprehensive about doing any kind of release without the buildbots running. Does anyone know when they might be up? -- Regards, Benjamin

13 34