On Fri, Dec 3, 2010 at 1:05 PM, Guido van Rossum <guido(a)python.org> wrote:
> On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray <rdmurray(a)bitdance.com> wrote:
>> I believe MAL's thought was that the addition of these methods had
>> been approved pre-moratorium, but I don't know if that is a
>> sufficient argument or not.
> It is not.
> The moratorium is intended to freeze the state of the language as
> implemented, not whatever was discussed and approved but didn't get
> implemented (that'd be a hole big enough to drive a truck through, as
> the saying goes :-).
> Regardless of what I or others may have said before, I am not
> currently a fan of adding transform() to either str or bytes.
I would like to restart the discussion under a separate subject
because the original thread  went off the specific topic of the six
new methods (2 methods x 3 types) added to builtins shortly before 3.2
beta was released.  The ticket that introduced the change is
currently closed  even though the last message suggests that at
least part of the change needs to be reverted.
Note that reverting part of the patch is not entirely trivial because
new codecs' documentation refers to bytes.[un]transform() both in the
docstrings and the library reference.
I think it will be the best to revert r86934 and resume the discussion
of adding this functionality to 3.3 when we won't be constrained by
the language moratorium. I will write a separate message with my
thoughts about adding bytes codecs in 3.3. Let's keep this thread
focused on what has to be done for 3.2.
On Thu, Dec 9, 2010 at 2:46 AM, Vinay Sajip <vinay_sajip(a)yahoo.co.uk> wrote:
> Nick Coghlan <ncoghlan <at> gmail.com> writes:
>> P.S. On a completely unrelated note, has anyone thought about creating
>> a write-only TextIO stream that outputs received writes via the
>> logging module?
> Is this for use at the C level? At the Python level, there's a post I wrote a
> while back which shows how to use a logger like an output stream:
Similar in concept, but more full-featured (i.e. supporting the
relevant IO ABCs), allowing it to be used as a replacement for
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
-----BEGIN PGP SIGNED MESSAGE-----
On behalf of the Python development team, I'm happy to announce the
first of two beta preview releases of Python 3.2.
Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line. Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.
Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3. Highlights are:
* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* countless fixes regarding bytes/string issues; among them full
support for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations
* a sysconfig module to access configuration information
* a pure-Python implementation of the datetime module
* additions to the shutil module, among them archive file support
* improvements to pdb, the Python debugger
For a more extensive list of changes in 3.2, see
To download Python 3.2 visit:
Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.2's contributors)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
-----END PGP SIGNATURE-----
Two recently reported issues brought into light the fact that Python
language definition is closely tied to character properties maintained
by the Unicode Consortium. [1,2] For example, when Python switches to
Unicode 6.0.0 (planned for the upcoming 3.2 release), we will gain two
additional characters that Python can use in identifiers. 
With Python 3.1:
>>> exec('\u0CF1 = 1')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 1
ೱ = 1
SyntaxError: invalid character in identifier
but with Python 3.2a4:
>>> exec('\u0CF1 = 1')
Of course, the likelihood is low that this change will affect any
user, but the change in str.isspace() reported in  is likely to
cause some trouble:
While we have little choice but to follow UCD in defining
str.isidentifier(), I think Python can promise users more stability in
what it treats as space or as a digit in its builtins. For example,
I don't think that supporting
is more important than to assure users that once their program
accepted some text as a number, they can assume that the text is
> Author: ronald.oussoren
> New Revision: 87118
> Log: Two small changes to adjust framework builds to the new stable ABI
> Modified: python/branches/py3k/Mac/BuildScript/build-installer.py
> + LDVERSION=None
> + VERSION=None
> + ABIFLAGS=None
> + with open(os.path.join(buildDir, 'Makefile')) as fp:
> + for ln in fp:
> + if ln.startswith('VERSION='):
> + VERSION=ln.split()
> + if ln.startswith('ABIFLAGS='):
> + ABIFLAGS=ln.split()
> + if ln.startswith('LDVERSION='):
> + LDVERSION=ln.split()
> + LDVERSION = LDVERSION.replace('$(VERSION)', VERSION)
> + LDVERSION = LDVERSION.replace('$(ABIFLAGS)', ABIFLAGS)
Isn’t this a perfect use case for the new sysconfig module?
I'd like to tighten PEP 11, and declare a policy that systems
older than ten years at the point of a feature release are not
supported anymore by default. Older systems where support is still
maintained need to be explicitly listed in the PEP, along with
the name of the responsible maintainer (I think this would currently
only cover OS2/EMX which is maintained by Andrew MacIntyre).
Support for such old platforms can then be removed from the codebase
immediately, no need to go through a PEP 11 deprecation cycle.
As a consequence, I would then like to remove support for Solaris
versions older than Solaris 8 (released in January 2000, last updated
by Sun in 2004) from the configure script for 3.2b2. A number of other
tests in configure.in could probably also be removed, although I
personally won't touch them before 3.2.
The other major system affected by this would be Windows 2000, for which
we already decided to not support it anymore.
I've just been notified via being added to the nosy list of
about the deprecation of ConfigParser for 3.2. I presume I was added to this
list because logging.config uses ConfigParser, but logging.config doesn't use
any interpolation features so I could easily change all usages to
SafeConfigParser; should I do it now (before the 3.2 beta is cut) or hold off
To build the trunk Python 3k, it seems that Python 2 has to be installed.
This is because Objects/typeslots.py is called in the Makefile, and this
file uses Python 2 "print statement" syntax, which fails if $(PYTHON) is
actually Python 3.
Can anyone reproduce this?
Since discussion has trailed off without any blocking objections, I'm
accepting PEP 384. Martin, you may mark the PEP accepted and proceed
with merging the implementation for the beta on Saturday.