On behalf of the Python development team, I'm happy to announce the first
release candidate of Python 3.1.
Python 3.1 focuses on the stabilization and optimization of the features and
changes that Python 3.0 introduced. For example, the new I/O system has been
rewritten in C for speed. File system APIs that use unicode strings now handle
paths with undecodable bytes in them. Other features include an ordered
dictionary implementation, a condensed syntax for nested with statements, and
support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1,
see http://doc.python.org/dev/py3k/whatsnew/3.1.html or Misc/NEWS in the Python
This is a release candidate, and as such, we do not recommend use in production
environments. However, please take this opportunity to test the release with
your libraries or applications. This will hopefully discover bugs before the
final release and allow you to determine how changes in 3.1 might impact you.
If you find things broken or incorrect, please submit a bug report at
For more information and downloadable distributions, see the Python 3.1 website:
See PEP 375 for release schedule details:
benjamin at python.org
(on behalf of the entire python-dev team and 3.1's contributors)
My name is Chandler Armstrong and I'm investigating environments of collaboration. I'm a PhD candidate at the University of Illinois, Urbana-Champaign, specialized in internet research and science & technology studies. I'm generally interested in development methods overall, and specifically interested in both artificial languange construction and evolution, and collaboration in open-source models. I would like to talk to some members of the Python development community about what kinds of activities they do within it. If anybody is interested in this please email me at carmstr3(a)illinois.edu. I will send you a document that describes the research and interview in more detail. I'd like to do a voice interview over skype or a phone, but I can accomodate an online chat or even email.
I have some current research on this specific mailing list which is more quantitative in nature. I downloaded the entire mailing list from the archives. Next I looked through all the python-dev summaries and used links provided to referenced threads to indicate that a particular message or thread was meaningful in development. I characterized the mailing list as threads, and each instance with about 30 attributes (things like the number of posts, the depth of the tree, a measure of 'branchyness' of the thread, the standard deviation of post counts across posters, the hour/day/month of the thread, etc). Using these attributes I attempted to classify, using logistic regression, the threads that were indicated as meaningful in the python-dev summaries. There are some significant results. If anyone is interested I can send you my results, or even post them here to the list. I'll be presenting my results at the Classification Society Conference at St. Louis in June. The !
rk is unpublished at the moment but I hope to find a journal for it this summer.
I used entirely Python for all that quantitative work: downloading the mailing list and going through all the summaries, opening the links and matching the referenced message to the correct one in my downloaded database, and cleaning and transforming data. It was a ton of fun. I hope to develop more scripts for other sorts of automated analysis.
At any rate, please contact me if you'de like to contribute to my current tack of investigation. I would ultimately want to interview however many people that are willing to talk with me. I need to do about two in the next couple of weeks, and I would get with other volunteers in the weeks after that.
Consider the code:
code = "def Foo():\n\n pass\n\n "
This code is malformed in that the final indentation (2 spaces) does not agree with the previous indentation of the pass statement (4 spaces). Or maybe it's just fine if you take the blank lines should be ignored statement from the docs to be true. So let's look at different ways I can consume this code.
If I use compile to compile this:
compile(code, 'foo', 'single')
I get an IndentationError: unindent does not match any outer indentation level
But if I put this in a file:
f= file('indenttest.py', 'w')
It imports just fine.
If I run it through the tokenize module it also tokenizes just fine:
>>> import tokenize
>>> from cStringIO import StringIO
1,0-1,3: NAME 'def'
1,5-1,8: NAME 'Foo'
1,8-1,9: OP '('
1,9-1,10: OP ')'
1,10-1,11: OP ':'
1,11-1,12: NEWLINE '\n'
2,0-2,1: NL '\n'
3,0-3,4: INDENT ' '
3,4-3,8: NAME 'pass'
3,8-3,9: NEWLINE '\n'
4,0-4,1: NL '\n'
5,0-5,0: DEDENT ''
5,0-5,0: ENDMARKER ''
And if it fails anywhere it would seem tokenization is where it should fail - especially given that tokenize.py seems to report this error on other occasions.
And stranger still if I add a new line then it will even compile fine:
compile(code + '\n', 'foo', 'single')
Which seems strange because in either case all of the trailing lines are blank lines and as such should basically be ignored according to the documentation.
Is there some strange reason why compile rejects what everything else agrees is perfectly valid code?
I'm not sure there's anything you can do about this, but I thought I
should alert the Python devs that it can happen...
http://allmydata.org/trac/tahoe/ticket/704#comment:7 describes a
situation where my macports-installed python25 had a pyOpenSSL egg
installed in it by something other than macports (possibly by
easy_install-2.5?) that was not compatible with the Python build. My
hunch is that the pyOpenSSL had binaries compiled against a UCS4 Python,
but I don't know for sure. Whatever did the installation of the bad egg
was almost certainly being executed by the macports python25 because
macports is installed in /opt/local, and nothing is likely to have
installed it under that prefix by chance. In other words, this egg
probably couldn't have been left over from some non-macports python
installation. In fact, I haven't had any other version of Python2.5
installed on this machine. Very odd.
I wonder if it makes sense to enhance the extension module system to
record this kind of information so the problem can be diagnosed by the
Hi, there has been a problem in blender3d for 6~ years or so thats
eluded me, I decided to look into today.
- Whenever the a script raises a warnings python prints out binary
garbage in the console. Some users complain when they run python games
in blender they get beeps coming from the PC speaker.
It turns out that _warning.c's setup_context() is taking the first
value of argv (line 534 in 2.6.2), which in our case is the blender
then some part of the binary is printed to the console.
Apart from the beeps and not being helpful this also can mess up the
console's state - a like "cat /dev/random" might.
But the real problem is that warnings expect a file to exist, in
blender we have our own internal text's that dont have a corresponding
file on disk, so setting __file__ in the global dict will just point
to a location that doesn't exist.
It surprises me that warnings do this since exceptions work as
expected, printing useful stack traces from our built in texts.
Incase this helps, the scripts are converted into a buffer and run like this...
text->compiled = Py_CompileString( buf, text->id.name+2, Py_file_input );
PyEval_EvalCode( text->compiled, globaldict, globaldict );
Does anyone know of a workaround for this? Im sure there are other
cases where you may want to run compiled code that isnt related to a
A question came up at work about docstring formatting. It relates to
the description of the summary line in PEP 257.
"""Multi-line docstrings consist of a summary line just like a
one-line docstring, followed by a blank line, followed by a more
elaborate description. The summary line may be used by automatic
indexing tools; it is important that it fits on one line and is
separated from the rest of the docstring by a blank line. The summary
line may be on the same line as the opening quotes or on the next
line. The entire docstring is indented the same as the quotes at its
first line (see example below)."""
It says that the summary line may be used by automatic indexing tools,
but is there any evidence that such a tool actually exists? Or was
there once upon a time? If there are no such tools, do we still think
that it is important that it fits on line line?
I've noticed some problems since this morning with the trunk and 3.x
- x86 XP-4 (trunk and 3x) is throwing an "no space left on device"
error when it compiles the sqlite module in its temp dir
- amd64 gentoo 3.x and ia64 Ubuntu 3.x buildbot versions seem to be
too old to run, they should be upgraded
- ppc Debian unstable trunk keeps on failing to connect to svn.python.org
Tarek Ziadé | http://ziade.org