In the first example of the "PEP 409: Suppressing exception context"
section, I read "from None...".
It's confusing because I don't remember what was the last choice for
the PEP: None or ... :-)
The reST "code" looks correct in Doc/whatsnew/3.3.rst:
... raise AttributeError(attr) from None
On behalf of the Python development team, I'm delighted to announce the
first release candidate of Python 3.3.0.
This is a preview release, and its use is not recommended in
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. Major new features and changes
in the 3.3 release series are:
* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 80x speedup
for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
PEP 411) policy that adds much improved unicode support for email
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default
In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see
To download Python 3.3.0 visit:
Please consider trying Python 3.3.0 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.3's contributors)
I've set up a bunch of Snakebite build slaves over the past week.
One of the original goals was to provide Python committers with
full access to the slaves, which I'm still keen on providing.
What's a nice simple way to achieve that in the interim? Here's
what I was thinking:
- Create a new hg repo: hg.python.org/keys.
- Committers can push to it just like any other repo (i.e.
same ssh/authz configuration as cpython).
- Repo is laid out as follows:
ssh (ssh public key)
gpg (gpg public key)
- Prime the repo with the current .ssh/authorized_keys
(presuming you still use the --tunnel-user facility?).
That'll provide me with everything I need to set up the relevant
.ssh/authorized_keys stuff on the Snakebite side. GPG keys will
be handy if I ever need to send passwords over e-mail (which I'll
probably have to do initially for those that want to RDP into the
As for the slaves, here's what's up and running now:
- AMD64 Mountain Lion [SB]
- AMD64 FreeBSD 8.2 [SB]
- AMD64 FreeBSD 9.1 [SB]
- AMD64 NetBSD 5.1.2 [SB]
- AMD64 OpenBSD 5.1 [SB]
- AMD64 DragonFlyBSD 3.0.2 [SB]
- AMD64 Windows Server 2008 R2 SP1 [SB]
- x86 NetBSD 5.1.2 [SB]
- x86 OpenBSD 5.1 [SB]
- x86 DragonFlyBSD 3.0.2 [SB]
- x86 Windows Server 2003 R2 SP2 [SB]
- x86 Windows Server 2008 R2 SP1 [SB]
All the FreeBSD ones use ZFS, all the DragonFly ones use HAMMER.
DragonFly, NetBSD and OpenBSD are currently reporting all sorts
of weird and wonderful errors, which is partly why I want to set
up ssh access sooner rather than later.
Other slaves on the horizon (i.e. hardware is up, OS is installed):
- Windows 8 x64 (w/ VS2010 and VS2012)
- HP-UX 11iv2 PA-RISC
- HP-UX 11iv3 Itanium (64GB RAM)
- AIX 5.3 RS/6000
- AIX 6.1 RS/6000
- AIX 7.1 RS/6000
- Solaris 9 SPARC
- Solaris 10 SPARC
Nostalgia slaves that probably won't ever see green:
- IRIX 6.5.33 MIPS
- Tru64 5.1B Alpha
If anyone wants ssh access now to the UNIX platforms in order to
debug/test, feel free to e-mail me directly with your ssh public
For committers on other Python projects like Buildbot, Django and
Twisted that may be reading this -- yes, the plan is to give you
guys Snakebite access/slaves down the track too. I'll start looking
into that after I've finished setting up the remaining slaves for
Python. (Setting up a keys repo will definitely help (doesn't have
to be hg -- feel free to use svn/git/whatever, just try and follow
the same layout).)
Trent "that-took-a-bit-longer-than-expected" Nelson.
On Mon, Aug 13, 2012 at 3:00 PM, Terry Reedy <tjreedy(a)udel.edu> wrote:
> On 8/13/2012 10:45 AM, Guido van Rossum wrote:
>> Not so fast. If you make this a language feature you force all Python
>> implementations to support an identical AST API. That's a big step.
> I have been wondering about this. One could think from the manuals that we
> are there already. From the beginning of the ast chapter:
> "The ast module helps Python applications to process trees of *the* Python
> abstract syntax grammar. ... An abstract syntax tree can be generated by
> passing ast.PyCF_ONLY_AST as a flag to the compile() built-in function"
> (emphasis on *the* added).
> and the entry for compile(): "Compile the source into a code or AST
> I see nothing about ast possibly being CPython only. Should there be?
Time to ask the other VMs what they are currently doing (the ast module
came into existence in Python 2.6 so all the VMs should be answer the
question since Jython is in alpha for 2.7 compatibility).
This feels like a bug, but just wanted to check here before filing a
report if I've missed something:
Enthought Python Distribution -- www.enthought.com
Version: 7.2-2 (32-bit)
Python 2.7.2 |EPD 7.2-2 (32-bit)| (default, Sep 7 2011, 09:16:50)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "packages", "demo" or "enthought" for more information.
>>> import tarfile
>>> source = open('/src/Python-2.6.7.tgz', 'rb')
>>> tar = tarfile.open(fileobj=source, mode='r|*')
>>> member = tar.extractfile('Python-2.6.7/Lib/genericpath.py')
>>> data = member.read()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
line 815, in read
buf += self.fileobj.read()
line 735, in read
line 742, in readnormal
self.fileobj.seek(self.offset + self.position)
line 554, in seek
raise StreamError("seeking backwards is not allowed")
tarfile.StreamError: seeking backwards is not allowed
The key is the "mode='r*|" which I understood to be specifically for
reading blocks from a stream without seeking that would cause problems.
I've reproduced on Py26 and Py27 on Mac OS X, and Py26 on SUSE.
Simplistix - Content Management, Batch Processing & Python Consulting
root@python is indirectly trying to send doc cron job failure messages
to the python-checkings list. headers below. They are caught and held
for moderation since "Blind carbon copies or other implicit destinations
are not allowed." I think it is a mistake to send these messages to
checkins, which has enough checkins traffic already, but I do not know
who is responsible to fix the situation. The last two examples:
"home/docs/devguide/documenting.rst:773: WARNING: term not in glossary:
"abort: error: Connection timed out"
Received: from albatross.python.org (localhost [127.0.0.1])
by mail.python.org (Postfix) with ESMTP id 3X2G3z3xCNzQjK;
Wed, 22 Aug 2012 19:30:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
X-Spam-Status: OK 0.009
X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00;
'received:dinsdale.python.org': 0.03; 'error:': 0.05;
'subject:build': 0.07; 'subject: <': 0.09; 'message-
id:@dinsdale.python.org': 0.16; 'subject:home': 0.16; 'timed':
0.16; 'from:addr:python.org': 0.17; 'subject:/': 0.28;
'connection': 0.30; 'received:python.org': 0.31; 'received:org':
0.36; 'subject:-': 0.40; 'header:Message-Id:1': 0.62;
'to:addr:docs': 0.68; 'subject:@': 0.81
Received: from localhost (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 22 Aug 2012 19:30:23 +0200
Received: from dinsdale.python.org (svn.python.org
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by mail.python.org (Postfix) with ESMTPS;
Wed, 22 Aug 2012 19:30:23 +0200 (CEST)
Received: from docs by dinsdale.python.org with local (Exim 4.72)
for docs(a)dinsdale.python.org; Wed, 22 Aug 2012 19:30:23 +0200
Date: Wed, 22 Aug 2012 19:30:23 +0200
From: root(a)python.org (Cron Daemon)
Subject: Cron <docs@dinsdale> /home/docs/build-devguide
Content-Type: text/plain; charset=UTF-8
Terry Jan Reedy
The issue came up in python-list about string operations being slower in
3.3. (The categorical claim is false as some things are actually
faster.) Some things I understand, this one I do not.
Win7-64, 3.3.0b2 versus 3.2.3
print(timeit("c in a", "c = '…'; a = 'a'*1000+c")) # ord(c) = 8230
# .6 in 3.2, 1.2 in 3.3
Why is searching for a two-byte char in a two-bytes per char string so
much faster in 3.2? Is this worth a tracker issue (I searched and could
not find one) or is there a known and un-fixable cause?
print(timeit("a.encode()", "a = 'a'*1000"))
# 1.5 in 3.2, .26 in 3.3
print(timeit("a.encode(encoding='utf-8')", "a = 'a'*1000"))
# 1.7 in 3.2, .51 in 3.3
This is one of the 3.3 improvements. But since the results are equal:
('a'*1000).encode() == ('a'*1000).encode(encoding='utf-8')
and 3.3 should know that for an all-ascii string, I do not see why
adding the parameter should double the the time. Another issue or known
Terry Jan Reedy
It seems that Jython is under the Python Foundation, but I can't find a
roadmap, a plan, or instructions about how to contribute to it reaching
2.7 and 3.3.
Are there any pages that describe the process?
Thanks in advance,
On Tue, Aug 21, 2012 at 11:55 AM, Ezio Melotti <ezio.melotti(a)gmail.com> wrote:
>> +Sequence Types --- :class:`list`, :class:`tuple`, :class:`range`
> These 3 links in the section title redirect to the functions.html page. I
> think it would be better if they linked to the appropriate subsection
> instead, and in the case of the subsections (e.g. "Text Sequence Type ---
> str") they shouldn't be links. The same comment can be applied to other
> titles as well.
I made a start on moving the info out of functions.html and adding
appropriate noindex entries. str, bytes and bytearray haven't been
consolidated at all yet.
>> +| ``s * n, n * s`` | *n* shallow copies of *s* | (2)(7) |
> I would use '``s * n`` or ``n * s``' here.
>> +| ``s.index(x, [i[, j]])`` | index of the first occurence | \(8) |
> This should be ``s.index(x[, i[, j]])``
>> + * if concatenating :class:`tuple` objects, extend a :class:`list`
>> + * for other types, investigate the relevant class documentation
> The trailing punctuation of the elements in this list is inconsistent.
Just removed all trailing punctuation from these bullet points for now.
> You missed clear() from this list.
The problem was actually index() and count() were missing from the
index for the "common sequence operations" table. Added them there,
and moved that index above the table.
copy() was missing from the index list for the mutable sequence
methods, so I added that.
> Also in the "Result" column the descriptions in prose are OK, but I find
> some of the "same as ..." ones not very readable (or even fairly obscure).
> (I think I saw something similar in the doc of list.append() too.)
These are all rather old - much of this patch was just moving things
around rather than fixing the prose, although there was plenty of the
latter, too :)
I tried to improve them a bit.
> Is it worth mentioning a function call as an example of syntactic ambiguity?
> Someone might wonder if foo(a, b, c) is actually passing a 3-elements tuple
> or 3 distinct values.
> This claim is maybe a bit too strong. I think the main reason to use
> namedtuples is being able to access the elements via t.name, rather than
> t[pos], and while this can be useful for basically every heterogeneous
> tuple, I think that plain tuples are still preferred.
> On a separate note, should tuple unpacking be mentioned here? (a link to a
> separate section of the doc is enough.)
Not really - despite the name, tuple unpacking isn't especially
closely related to tuples these days.
> I would mention explicitly "in :keyword:`for` loops" -- ranges don't loop on
> their own (I think people familiar with Ruby and/or JQuery might get
> confused here).
> I thought that these two paragraphs were talking about positive and negative
> start/stop/step until I reached the middle of the second paragraph (the word
> "indices" wasn't enough to realize that these paragraphs are about
> indexing/slicing, probably because they are rarely used and I wasn't
> expecting to find them at this point of the doc). Maybe it's better to move
> the paragraphs at the bottom of the section.
For the moment, I've just dumped the old range builtin docs into this
section. They need a pass to remove the duplication and ensure
everything makes sense in context.
>> +String literals that are part of a single expression and have only
>> +between them will be implicitly converted to a single string literal.
> Is it a string /literal/ they are converted to?
>>> ast.dump(compile('"hello world"', '', 'eval', flags=ast.PyCF_ONLY_AST))
>>> ast.dump(compile('"hello" " world"', '', 'eval', flags=ast.PyCF_ONLY_AST))
> Anyway a simple ('foo' 'bar') == 'foobar' example might make this sentence
> more understandable.
>> +There is also no mutable string type, but :meth:`str.join` or
>> +:class:`io.StringIO` can be used to efficiently construct strings from
>> +multiple fragments.
> str.format() deserves to be mentioned here too.
For the kinds of strings where quadratic growth is a problem,
str.format is unlikely to be appropriate.
> I noticed that here there's this fairly long section about the "old" string
> formatting and nothing about the "new" formatting. Maybe this should be
> moved together with the new formatting doc, so that all the detailed
> formatting docs are in the same place. (This would also help making this
> less noticeable)
Probably. There are a lot of structural problems in the current docs,
because the layout hasn't previously changed to suit the language
>> +While bytes literals and representations are based on ASCII text, bytes
>> +objects actually behave like immutable sequences of integers, with each
>> +value in the sequence restricted such that ``0 <= x < 256`` (attempts to
> Earlier you used 0 <= x <= 255.
The current docs are the result of many merges, much of which I didn't
write. This is only the start of improving them by breaking away from
the old 1.x structure with a few autocratic decisions on my part to
establish a new layout that makes more sense given the evolution of
the language, especially the big changes in 2.2 and 3.0 :)
> Using ``'abc'.replace('a', 'f')`` and ``b'abc'.replace(b'a', b'f')`` inline
> would be better IMHO, given that the current note takes lot of space to
> explain a trivial concept.
Stylistics edits are always fair game, they don't have to be made by
me. While I skipped a lot of your specific suggestions that weren't
correcting actual errors, that doesn't mean I'm especially opposed to
them, just that I didn't like them enough to implement myself :)
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia