On Sun, May 29, 2011 at 2:13 AM, gregory.p.smith
> Ironically: I don't think any platform should ever actually _use_ the
> pure Python subprocess code on POSIX platforms anymore. This at least
> tests it properly in this stable branch. The pure python code for
> this is likely to be removed in 3.3.
Don't do that - keeping the pure Python equivalents around can help
reduce the level of effort for other implementations (especially
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
In Python 2, codecs.open() is the best way to read and/or write files
using Unicode. But in Python 3, open() is preferred with its fast io
module. I would like to deprecate codecs.open() because it can be
replaced by open() and io.TextIOWrapper. I would like your opinion and
that's why I'm writing this email.
codecs.open() and StreamReader, StreamWriter and StreamReaderWriter
classes of the codecs module don't support universal newlines, still
have some issues with stateful codecs (like UTF-16/32 BOMs), and each
codec has to implement a StreamReader and a StreamWriter class.
StreamReader and StreamWriter are stateless codecs (no reset() or
setstate() method), and so it's not possible to write a generic fix for
all child classes in the codecs module. Each stateful codec has to
handle special cases like seek() problems. For example, UTF-16 codec
duplicates some IncrementalEncoder/IncrementalDecoder code into its
The io module is well tested, supports non-seekable streams, handles
correctly corner-cases (like UTF-16/32 BOMs) and supports any kind of
newlines including an "universal newline" mode. TextIOWrapper reuses
incremental encoders and decoders, so BOM issues were fixed only once,
It's trivial to replace a call to codecs.open() by a call to open(),
because the two API are very close. The main different is that
codecs.open() doesn't support universal newline, so you have to use
open(..., newline='') to keep the same behaviour (keep newlines
unchanged). This task can be done by 2to3. But I suppose that most
people will be happy with the universal newline mode.
I don't see which usecase is not covered by TextIOWrapper. But I know
some cases which are not supported by StreamReader/StreamWriter.
I opened an issue for this idea. Brett and Marc-Andree Lemburg don't
want to deprecate codecs.open() & friends because they want to be able
to write code working on Python 2 and on Python 3 without any change. I
don't think it's realistic: nontrivial programs require at least the six
module, and most likely the 2to3 program. The six module can have its
"codecs.open" function if codecs.open is removed from Python 3.4.
StreamReader, StreamWriter, StreamReaderEncoder and EncodedFile are not
used in the Python 3 standard library. I tried removed them: except
tests of test_codecs which test them directly, the full test suite pass.
Read the issue for more information: http://bugs.python.org/issue8796
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.5.6. There were no changes
since the release candidate.
This is a source-only release that only includes security fixes. The
last full bug-fix release of Python 2.5 was Python 2.5.4. Users are
encouraged to upgrade to the latest release of Python 2.7 (which is
2.7.1 at this point). This release is most likely the final release of
Python 2.5; under the current release policy, no security issues in
Python 2.5 will be fixed after October, 2011.
This releases fixes issues with the urllib, urllib2, SimpleHTTPServer,
and audiop modules. See the release notes at the website (also
available as Misc/NEWS in the source distribution) for details of bugs
For more information on Python 2.5.6, including download links for
various platforms, release notes, and known issues, please see:
Highlights of the previous major Python releases are available from
the Python 2.5 page, at
Enjoy this release,
Martin v. Loewis
Python Release Manager
(on behalf of the entire python-dev team)
Le jeudi 26 mai 2011 à 08:13 -0400, Eric Smith a écrit :
> If you're ever going to add code at the end of these functions, it's
> unlikely you'll remember that you need to add these increments back in.
You don't have to remember. Test the result of the function, it will not
give the expected output. I don't think that you need fuzzing or a
complex tool to detect that the new code doesn't behave correctly.
> It's a bug waiting to happen
What? It's not a bug. Ading new non-tested code is a bug :-)
> I don't see any harm leaving them in.
> Maybe we should add a comment about why they're done.
It makes Python faster (!) and make silent the Clang Static Analyzer :-)
On Wed, 25 May 2011 18:26:46 +0200
senthil.kumaran <python-checkins(a)python.org> wrote:
> A new method called service_action is made available in BaseServer, called by
> serve_forever loop. This useful in cases where Mixins can use it for cleanup
> action. ForkingMixin class uses service_action to collect the zombie child
> processes. Initial Patch by Justin Wark.
Is it reasonable, performance-wise, to do this at every iteration of
the loop (that is, at every incoming connection)?
This just in from pypy-dev. I am reposting it here because I
am fairly certain that nobody on the pypy-dev mailing list
uses the multibytecodex, but there has got to be at least one
person here who does.
Please reply to the pypy-dev article, not here, or mail to pypy-dev(a)python.org
if you are not on the pypy-dev mailing list (but have delivery turned off
as many of you do.)
------- Forwarded Message
From: Armin Rigo <arigo(a)tunes.org>
Date: Wed, 25 May 2011 21:39:35 +0200
Subject: [pypy-dev] multibytecodec: missing features
Here are the missing features in multibytecodec:
* support for ``errors !=3D "strict"''.
* classes MultibyteIncrementalEncoder, MultibyteIncrementalDecoder,
MultibyteStreamReader and MultibyteStreamWriter.
One reason I didn't implement the classes yet is that I couldn't
understand two points in how they are supposed to work. But it seems
that there are really two bugs, as I've been pointed to:
http://bugs.python.org/issue12171 . So the question is if we should
be bug-compatible with Python 2.7 or if we should instead implement
some fixed version.
I suppose I'm rather for the fixed version, but I'd like to hear some
feedback from people that actually use multibytecodecs. Also, I
wouldn't mind if someone would pick up the work and just do it, either
the classes or ``errors !=3D "strict"'' :-)
pypy-dev mailing list
------- End of Forwarded Message
I've posted a very preliminary Python 3.3 release schedule as PEP 398.
The final release is set to be about 18 months after 3.2 final, which
is in August 2012.
For 3.3, I'd like to revive the tradition of listing planned large-scale
changes in the PEP. Please let me know if you plan any such changes,
at any time. (If they aren't codified in PEP form, we should think about
whether they should be.)
The "Candidate PEPs" I listed are those open PEPs that in my opinion have
the highest chance to be accepted and implemented for 3.3. It is by no
Le mardi 24 mai 2011 à 11:27 -0400, Terry Reedy a écrit :
> > +.. function:: RAND_bytes(num)
> > +
> > + Returns *num* cryptographically strong pseudo-random bytes.
> > +
> > + .. versionadded:: 3.3
> > +
> > +.. function:: RAND_pseudo_bytes(num)
> > +
> > + Returns (bytes, is_cryptographic): bytes are *num* pseudo-random bytes,
> > + is_cryptographic is True if the bytes generated are cryptographically
> > + strong.
> > +
> > + .. versionadded:: 3.3
> I am curious what 'cryptographically strong' means, what the real
> difference is between the above two functions, and how these do not
> duplicate what is in random.random.
An important feature of a CPRNG (cryptographic pseudo-random number
generator) is that even if you know all of its output, you cannot
rebuild its internal state to guess next (or maybe previous number). The
CPRNG can for example hash its output using SHA-1: you will have to
"break" the SHA-1 hash (maybe using "salt").
Another important feature is that even if you know the internal state,
you will not be able to guess all previous and next numbers, because the
internal state is regulary updated using an external source of entropy.
Use RAND_add() to do that explicitly.
We may add a link to Wikipedia:
Read the "Requirements" section, it's maybe more correct than my
About the random module, it must not be used to generate passwords or
certificates, because it is easy to rebuild the internal state of a
Mersenne Twister generator if you know the previous 624 numbers. Since
you know the state, it's also easy to generate all next numbers. Seed a
Mersenne Twister PRNG doesn't help. See my Hasard project if you would
like to learn more about PRNG ;-)
We may also add a link from random to SSL.RAND_bytes() and