Yup! It's that time again, I'm encouraging anyone involved in core
development, or wanting to talk about core development - or
python-core internals to submit talk proposals. Lots of people have
expressed interest in such talks.
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:
For videos of talks from previous years - check out:
We look forward to seeing you in Atlanta!
[moving this from the bug tracker]
Alexandre Vassalotti wrote:
> Alexandre Vassalotti added the comment:
> Not a bug.
> The list comprehension in your chunker:
> while True:
> target.send([ (yield) for i in range(chunk_size) ])
> is equivalent to the following generator in Python 3:
> while True:
> def g():
> for i in range(chunk_size):
> yield (yield)
> This clearly needs not what you want.
Does this do anything meaningful, or would it make sense to output a
compiler warning (or better: an error) here?
Using yield in a comprehension (as opposed to a generator expression, which
I intuitively expected not to work) doesn't look any dangerous at first
glance, so it was quite surprising to see it fail that drastically.
This is also an important issue for other Python implementations. Cython
simply transforms comprehensions into the equivalent for-loop, so when we
implement PEP 342 in Cython, we will have to find a way to emulate
CPython's behaviour here (unless we decide to stick with Py2.x sematics,
which would not be my preferred solution).
> So, just rewrite your code using for-loop:
> while True:
> result = 
> for i in range(chunk_size):
> nosy: +alexandre.vassalotti
> resolution: -> invalid
> status: open -> closed
The following sites are up again on a new machine, but cannot be
updated through SVN hooks or whatever mechanism:
www.python.orgdocs.python.orgwww.jython.orgplanet.python.orgplanet.jython.orgsvn.python.org was deliberately not brought up again. The backups
were a few hours behind and missing the ~10 most recent commits. Not
disastrous, but it could probably mess up people's SVN trees, so after
some IRC discussion, the decision was to wait until the original disks
are available again. That will probably not occur until Monday, maybe
I've disabled donations to the PSF through credit cards, which pointed
to a CGI script that doesn't currently work; PayPal donations still
Do we want to make any edits to the 3.1 or 3.0 pages about the I/O
bug? I can do that manually if someone will provide the text and/or a
patch to put up.
Unfortunately without SVN we probably can't cut a new 3.1 release,
unless Benjamin or someone has a really up-to-date copy of the
Mercurial tree and wants to work from that.
Dear Python developer,
within the scope of my diploma thesis at the University of Paderborn, Germany, with the title "Study about communication and collaboration in software development in teams" I am conducting a survey of members of software development teams.
I would be very grateful if you help me in my studies and answer the survey at http://thales.cs.upb.de/limesurvey185/index.php?lang=en&sid=91192&token=kkz…
This is the official description of the survey:
In the last years many means of communication and collaboration were introduced in software projects to assist the development teams with their daily work.
With this study we want to identify requirements for a communication- and collaboration-supporting platform for software development. For this purpose we will evaluate the utilization and effectiveness of different means of communication and collaboration in solving software and managerial problems in software development teams.
The survey will take about 10-15 minutes and contains 55 questions that cover various topics.
Many thanks for your support of my research. If there are any further questions, don't hesitate to contact me.
Best regards from Paderborn, Germany
Martin Gelhaus (gelhaus(a)uni-paderborn.de)
Click here to do the survey:
Graduand at Didactics of Informatics chair at University of Paderborn
I added http://bugs.python.org/issue6654
I also put a not to python-ideas but have had no response yet. Any comments?
Here's the summary:
I've created http://codereview.appspot.com/100046 on Rietveld:
by passing the "path" component of the xmlrpc request to the dispatch
method, itbecomes possible to dispatch differently according to this. This patch
Additionally, it provides an MultiPathXMLRPCDispatcher mixin
class and a MultiPathXMLRPCServer that uses it, to have multiple dispatchers for
This allows a single server port to serve different XMLRPC servers as
differentiated by the HTTP path. A test is also preovided.
Once Subversion is back up (today, tomorrow?), I will tag the 3.1
maintence branch as 3.1.1rc1. The tree will remain frozen until
Saturday. If at that time, no one has found something wrong with the
RC, I will retag it as the final bugfix release.
> M.-A. Lemburg wrote:
>> ... and because of this, the feature is already available if
>> you use codecs.open() instead of the built-in open():
Neil Hodgson asked:
> So should I not add an issue for the basic open because codecs.open
> should be used for this case?
In python 3, why does codecs.open even still exist?
As best I can tell, codecs.open should be the same as regular open,
but for a unicode file -- and all text files are treated as unicode in
So at this point, are there any differences beyond:
(a) The builtin open doesn't work on multi-byte line-endings other
than the multi-character CRLF. (In other words, it goes by the
traditional Operating System conventions developed when a char was a
byte, but the Unicode standard allows for a few more possibilities,
which are currently rare in practice.)
(b) The codecs version is much slower, because it hasn't seen the
> Kristján Valur Jónsson wrote:
>> I've never understood the need to have a distinction betwen statements
>> and expressions, not when expressions can have side effects.
Alex Martelli responded:
> If you're interested in understanding it better, research
> Query-Command Separation (QCS), e.g. starting at
Either you missed Kristján's point, or your answer was so
subtle that I missed yours.
QCS makes it easy to determine which pieces of code
(queries) are free of side-effects. I see value in that
for both debugging and optimization.
What I don't see is how that relates to expressions vs
statements **when expressions can have side effects.**
(Actually, in Python, I would say that statements are far
*more* likely to be free of side-effects, as they are often
there for flow control.)
Both www.python.org and svn.python.org are down. They're hosted on
the same machine, and it seems to have run into disk problems and
hasn't rebooted even after power-cycling. Thomas Wouters will be
visiting the machine physically tomorrow to try to diagnose the
(The machine also hosts planet.python.org and hg.python.org.)