[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.)
In particular this issue: http://bugs.python.org/issue1628205
I believe we should handle EINTR internally within the
socket._fileobject wrapper as nobody using a file-like object should
ever expect to get an EINTR. EINTR only comes from using the lowest
level system calls.
Anyone strongly disagree?