Mailman 3 December 2008 - Python-Dev

Holding a Python Language Summit at PyCon
by A.M. Kuchling 10 Dec '08

10 Dec '08

The PyCon organizers are planning a Python Language Summit to be held in Chicago just before the conference, on Thursday March 26 2009. (This is the second day of tutorials, and the day before PyCon officially starts.) The purpose of the Python Language Summit is to let the developers of Python implementations discuss issues that affect us all, and to let the developers of a particular implementation discuss their own project-specific issues. PyCon brings a lot of the core developers together into one place and there's been a "Python core" sprint for a long time, but we haven't had a formal time and place for *discussion* among core developers. Attending the summit will be free; registration for PyCon is *not* included, but won't be required to attend the summit. I e-mailed some CPython, Jython, IronPython, PyPy, etc. developers asking for topic suggestions, and assembled a draft of a schedule from some of the most commonly mentioned topics; the current draft schedule is below. The schedule is very 'loose', leaving a fair bit of open space so that we can hopefully begin working on ideas arising from the discussion. * What do you think of the selected topics? * I'd like to have a champion for each session, who will make a brief presentation about the session's topic at the start, laying out the issues and possible courses of action to guide the resulting discussion. If you wish to volunteer as the champion for a session, please let me know. (Preference will be given to people actively working on the particular topic.) * For CPython, invitations will be sent to everyone with committer status (plus a few book authors, significant patch contributors who aren't committers yet, etc.). If you're not a committer but think you can contribute, please let me know privately. Also, please suggest other * There will probably be summit-related sponsorship opportunities for interested companies. Andrew M. Kuchling amk(a)amk.ca Registration Manager, PyCon 2009 http://us.pycon.org 9:00 - 10:30 ============= Open discussion session 11:00 - 12:30 ============= Transition plan for rest of 2.x series; goals for 2.7/3.1. - New features & future plans? - Is 2.7 last of the 2.x releases? - Unicode issues - Stdlib plans? Champion needed. 12:30 - 14:00 ============= Lunch (probably provided by the PSF or a sponsor). 14:00 - 15:30 ============= Two tracks: Cross-implementation issues: What do the various VMs want/need from CPython to help with their implementations? * Marking CPython-specific tests in the test suite? * Getting an implementation agnostic test suite for the Python language? * Separating the language tests and the pure Python part of the stdlib into a separate project? (Or publish them as a separate package.) * Transition plans for 3.0? Champion needed. Package distribution & installation. * setting up an organized network of mirrors ? la CPAN * adding a commenting system on PyPI * think about a reference implementation for a PyPI client in the stdlib (XML-RPC client+upload and register) * improvments on packaging matters - this includes distutils but also setuptools. Champion needed. 16:00 - 17:30 ============= Free space for sprinting, hacking, further discussion, etc. 18:00-ish ============= Group dinners.

5 11

Forking and pipes
by Lars Kotthoff 10 Dec '08

10 Dec '08

Dear list, I recently noticed a python program which uses forks and pipes for communication between the processes not behaving as expected. The minimal example program: -------------------------------------------------------------------------------- #!/usr/bin/python import os, sys r, w = os.pipe() write = os.fdopen(w, 'w') print >> write, "foo" pid = os.fork() if pid: os.waitpid(pid, 0) else: sys.exit(0) write.close() read = os.fdopen(r) print read.read() read.close() -------------------------------------------------------------------------------- This prints out "foo" twice although it's only written once to the pipe. It seems that python doesn't flush file descriptors before copying them to the child process, thus resulting in the duplicate message. The equivalent C program behaves as expected, -------------------------------------------------------------------------------- #include <stdio.h> #include <stdlib.h> #include <unistd.h> int main(void) { int fds[2]; pid_t pid; char* buf = (char*) calloc(4, sizeof(char)); pipe(fds); write(fds[1], "foo", 3); pid = fork(); if(pid) { waitpid(pid, NULL, 0); } else { return EXIT_SUCCESS; } close(fds[1]); read(fds[0], buf, 3); printf("%s\n", buf); close(fds[0]); free(buf); return EXIT_SUCCESS; } -------------------------------------------------------------------------------- Is this behaviour intentional? I've tested both python and C on Linux, OpenBSD and Solaris (python versions 2.5.2 and 2.3.3), the behaviour was the same everywhere. Thanks, Lars

4 3

RELEASED Python 3.0 final
by Barry Warsaw 09 Dec '08

09 Dec '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team and the Python community, I am happy to announce the release of Python 3.0 final. Python 3.0 (a.k.a. "Python 3000" or "Py3k") represents a major milestone in Python's history, and was nearly three years in the making. This is a new version of the language that is incompatible with the 2.x line of releases, while remaining true to BDFL Guido van Rossum's vision. Some things you will notice include: * Fixes to many old language warts * Removal of long deprecated features and redundant syntax * Improvements in, and a reorganization of, the standard library * Changes to the details of how built-in objects like strings and dicts work * ...and many more new features While these changes were made without concern for backward compatibility, Python 3.0 still remains very much "Pythonic". We are confident that Python 3.0 is of the same high quality as our previous releases, such as the recently announced Python 2.6. We will continue to support and develop both Python 3 and Python 2 for the foreseeable future, and you can safely choose either version (or both) to use in your projects. Which you choose depends on your own needs and the availability of third-party packages that you depend on. Some other things to consider: * Python 3 has a single Unicode string type; there are no more 8-bit strings * The C API has changed considerably in Python 3.0 and third-party extension modules you rely on may not yet be ported * Tools are available in both Python 2.6 and 3.0 to help you migrate your code * Python 2.6 is backward compatible with earlier Python 2.x releases We encourage you to participate in Python 3.0's development process by joining its mailing list: http://mail.python.org/mailman/listinfo/python-3000 If you find things in Python 3.0 that are broken or incorrect, please submit bug reports at: http://bugs.python.org/ For more information, links to documentation, and downloadable distributions, see the Python 3.0 website: http://www.python.org/download/releases/3.0/ Enjoy, - -Barry Barry Warsaw barry(a)python.org Python 2.6/3.0 Release Manager (on behalf of the entire python-dev team) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSTc3pXEjvBPtnXfVAQI69wP/dPHh8IL3GxziEV9QzlveKG+KyZb2X16x fxJnTCiXAbiAhT5C+m43OEnbF1PJgMDKtcZ5b7aQb4TQ0mJxISTQh0RfLCpArmlo tdTbzCLnh13KzB+3sUHCx+MeQNXERoWDV8hLz+4Ae71UsuUGynhtyP7ZJMJDue8j so2gv3fOMSs= =vkiy -----END PGP SIGNATURE-----

27 70

Self in method body
by Filip Gruszczyński 09 Dec '08

09 Dec '08

There is a large discussion on python-list about Guido's article about new self syntax, therefore I would like to use that to raise similar question: self in the body. Some time ago I was coding in Magik language (http://en.wikipedia.org/wiki/Magik_(programming_language), which is dynamically typed and similar to Smalltalk and actually to Python too - although the syntax is far less appalling. As you can see in the examples, defining methods is very similar to what Guido proposed in his blog, though you don't provide the name of the argument, but the name of the class. Then you just precede attributes with a '.', which is 4 letters less than self. And, well, this rocks ;-) It is really not a problem to type 4 letters (well, six with a coma and a space) in the signature, but it takes a lot of time to type all those selfs inside the function's body. So I was thinking, if this issue could be raised too, when new self syntax is proposed. Simple example looks like this: class bar: def bar.foo(): .x = 5 This could really save a lot of code, while attributes are still easily distinguishable. -- Filip Gruszczyński

3 3

Nonlocal shortcut
by Fabio Zadrozny 08 Dec '08

08 Dec '08

Hi, I'm currently implementing a parser to handle Python 3.0, and one of the points I found conflicting with the grammar specification is the PEP 3104. It says that a shortcut would be added to Python 3.0 so that "nonlocal x = 0" can be written. However, the latest grammar specification (http://docs.python.org/dev/3.0/reference/grammar.html?highlight=full%20gram…) doesn't seem to take that into account... So, can someone enlighten me on what should be the correct treatment for that on a grammar that wants to support Python 3.0? Thanks, Fabio

5 5

Re: [Python-Dev] "as" keyword woes
by Paul Boddie 08 Dec '08

08 Dec '08

On Sat Dec 6 21:29:09 CET 2008, Guido van Rossum wrote: > > On Sat, Dec 6, 2008 at 11:38 AM, Warren DeLano <warren at delsci.com> > wrote: > > As someone somewhat knowledgable of how parsers work, I do not > > understand why a method/attribute name "object_name.as(...)" must > > necessarily conflict with a standalone keyword " as ". It seems to me > > that it should be possible to unambiguously separate the two without > > ambiguity or undue complication of the parser. > > That's possible with sufficiently powerful parser technology, but > that's not how the Python parser (and most parsers, in my experience) > treat reserved words. Reserved words are reserved in all contexts, > regardless of whether ambiguity could arise. Just a quick aside from someone who merely lurks on this list: in SQL, it's quite possible to use keywords in a fashion similar to that desired by the inquirer, and it's actually possible to double-quote keywords and use them as names for things. I'm not advocating more complicated parsing technology for any Python implementation, but I think it's pertinent to point out that the technology isn't particularly obscure. Apologies for the interruption, Paul

2 2

[PATCH] Make 2to3 --write preserve file mode (eg. execution bit)
by Adeodato Simó 08 Dec '08

08 Dec '08

Hello, after using 2to3 --write over some scripts, I found it very cumbersome having to run `chmod +x` on each of them afterwards. The attached patch is a possible way to fix this issue. It'd be great if somebody could apply it, or write a more appropriate fix. Many thanks in advance! P.S.: Please CC me on replies. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Manolo García - Prendí la flor

2 2

3.0.1 possibilities
by Benjamin Peterson 08 Dec '08

08 Dec '08

Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues. Thoughts? [1] http://bugs.python.org/1717 [2] http://bugs.python.org/4533 [3] http://bugs.python.org/4561 [4] http://bugs.python.org/4565 -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."

11 24

Re: [Python-Dev] Python-3.0, unicode, and os.environ
by Bugbee, Larry 08 Dec '08

08 Dec '08

> I'm perhaps biased here; most of my Python programs don't have user > interfaces, because they don't "talk" to people, they talk to other > programs. The binary APIs for the OS are essential. I use and > deeply appreciate all the string handling features in Python, > particularly its firm grip on Unicode issues, but that's *useful* > instead of *essential*. Exactly! Another +1. Larry

1 0

Deciding on dbm API in setup.py
by skip＠pobox.com 08 Dec '08

08 Dec '08

Several packages provide a dbm-compatible API. Currently, the code in Python's setup.py hardcodes the order of consideration: ndbm, then gdbm, then Berkeley DB. While the APIs are compatible, the file formats are all different as far as I know. If you have ndbm but want to use Berkeley DB format, you're stuck. Right now editing setup.py is the only way to influence the order. I opened an issue on the bug tracker about this: http://bugs.python.org/issue4587 It includes a patch which adds an optional environment variable (PYDBMLIBORDER) which builders can use to override the order of the default library checks. I'm not sure that's the "correct" way to do this, but I'm at a loss to figure out how else to do it. Is it possible to easily add a flag to setup.py, say --dbm-order=gdbm:bdb:ndbm? If you've got any -- even passing -- interest in this, please read the issue and add a comment if you feel so moved. This grew out of a change to adapt to new gdbm library organization: http://bugs.python.org/issue4487 Unbeknownst to me, I apparently wound up fixing a previously reported issue about the change: http://bugs.python.org/issue1167 Skip

1 0