On Sat, Jan 25, 2014, at 10:55 AM, Vincent Davis wrote:
> On Sat, Jan 25, 2014 at 10:12 AM, Benjamin Peterson
> > Internal links with no version redirect to the Python 2 version for
> > backwards compatibility reasons.
> On Sat, Jan 25, 2014 at 10:26 AM, Georg Brandl <g.brandl(a)gmx.net> wrote:
> > Yep, and the URLs without version never served Python 3 docs as far as I
> > can
> remember, so I don't know where Google has these <title>s from.
> That is not consistent with
> http://docs.python.org (no version number) redirects to
This is recent. It used to go to Python 2 docs.
> Maybe this is related to google search results.
> Seems wrong to me to point to 2.7 rather that 3.3 but I am sure there was
> discussion about that.
The internal links all used to go to Python 2.
> I looked (googled) for an example of a google link to current version of
> python 3.3 documentation. My approach was to google "python" and
> listed in
> These results all seem to point to http://docs.python.org/dev/library
> Vincent Davis
-----BEGIN PGP SIGNED MESSAGE-----
On behalf of the Python development team, I'm reasonably happy to announce the
Python 3.3.4 release candidate 1.
Python 3.3.4 includes several security fixes and over 120 bug fixes compared to
the Python 3.3.3 release.
This release fully supports OS X 10.9 Mavericks. In particular, this release
fixes an issue that could cause previous versions of Python to crash when typing
in interactive mode on OS X 10.9.
Python 3.3 includes a range of improvements of the 3.x series, as well as easier
porting between 2.x and 3.x. In total, almost 500 API items are new or improved
in Python 3.3. For a more extensive list of changes in the 3.3 series, see
and for the detailed changelog of 3.3.4, see
To download Python 3.3.4 rc1 visit:
This is a preview release, please report any bugs to
The final version is scheduled to be released in two weeks' time, on or about
the 10th of February.
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----
for two days now, the signature embedding tests in Cython have been failing
with this (doctest) error:
f_D(long double D) -> long double
f_D(long double D) -> long double
The first line that Cython writes into the docstring is the "expected" one
above. So far, all CPython versions have ignored it, Py3.4 then started
picking it up at some point due to the argument clinic changes, but
properly copied it over to the (IIRC) "__signature__" attribute. However,
the recent change now lead to the above being dumped into the docstring.
Could someone please quickly explain what the purpose of the first line is
and why it says "None" at the end?
Is there anything we should do on our side in order to fix this? Since many
of our users embed their signatures for documentation purposes (it was the
only way to make them visible in previous CPython versions and is supported
by several tools, e.g. epydoc), this is a rather annoying result for them.
I tested the latest beta from 3.4 (b3) and noticed there is a new marshal
protocol version 3.
The documentation is a little silent about the new features, not going into
I've run a performance test with the new protocol version and noticed the
new version is two times slower in serialization than version 2. I tested
it with a simple value tuple in a list (500000 elements).
Nothing special. (happens only if the tuple contains also a tuple)
Copy of the test code:
from time import time
from marshal import dumps
for i in range(amount):
yield (i, i+2, i*2, (i+1,i+4,i,4), "my string template %s" % i, 1.01*i,
data = list(genData())
t0 = time()
result = dumps(data, 2)
t1 = time()
print("duration p2: %f" % (t1-t0))
t0 = time()
result = dumps(data, 3)
t1 = time()
print("duration p3: %f" % (t1-t0))
Is the overhead for the recursion detection so high ?
Note this happens only if there is a tuple in the tuple of the datalist.
On 27 January 2014 15:28, Terry Reedy <tjreedy(a)udel.edu> wrote:
> On 1/26/2014 10:22 PM, nick.coghlan wrote:
>> +Terry Reedy has suggested doing an initial filter which specifically
>> +for approved documentation-only patches (~700 of the 4000+ open CPython
>> +issues are pure documentation updates). This approach would avoid several
>> +of the issues related to flaky tests and cross-platform testing, while
>> +still allowing the rest of the automation flows to be worked out (such as
>> +how to push a patch into the merge queue).
>> +The one downside to this approach is that Zuul wouldn't have complete
>> +control of the merge process as it usually expects, so there would
>> +potentially be additional coordination needed around that.
> An essential part of my idea is that Zuul *would* have complete control
> while pushing doc patches to avoid the otherwise inevitable push races.
> Initially, this would be for a part of every day. While it has control, I
> would expect it to push doc patches at intervals of perhaps a minute, or
> even more rapidly with parallel testing. (Since doc patch rarely interfere
> and would be expected to apply after pre-testing, little speculative testing
> would need to be tossed.)
"Exclusive control some of the time" is not the same thing as
"exclusive control". It's not an impossible idea, but certainly not
the way Zuul is currently designed to work :)
>> +It may be worth keeping this approach as a fallback option if the initial
>> +deployment proves to have more trouble with test reliability than is
> I think a doc queue should be a permanent part of the system. There would
> always be doc-only patches -- and I suspect even more than now. One of the
> types of jobs on the main queue could be a periodic 'push all pending doc
> patches' job. I would then think we should try splitting code + doc patches
> into a code patch, pushed first, and a doc patch, added to the doc queue if
> the code patch succeeded.
That seems like added complexity for little gain - note that we can
make the *test runner* smart about how it handles doc-only patches, by
just checking the docs build and skipping the test run.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
On behalf of the Python development team, I'm quite pleased to announce
the third beta release of Python 3.4.
This is a preview release, and its use is not recommended for
Python 3.4 includes a range of improvements of the 3.x series, including
hundreds of small improvements and bug fixes. Major new features and
changes in the 3.4 release series include:
* PEP 428, a "pathlib" module providing object-oriented filesystem paths
* PEP 435, a standardized "enum" module
* PEP 436, a build enhancement that will help generate introspection
information for builtins
* PEP 442, improved semantics for object finalization
* PEP 443, adding single-dispatch generic functions to the standard library
* PEP 445, a new C API for implementing custom memory allocators
* PEP 446, changing file descriptors to not be inherited by default
* PEP 450, a new "statistics" module
* PEP 451, standardizing module metadata for Python's module import system
* PEP 453, a bundled installer for the *pip* package manager
* PEP 454, a new "tracemalloc" module for tracing Python memory allocations
* PEP 456, a new hash algorithm for Python strings and binary data
* PEP 3154, a new and improved protocol for pickled objects
* PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O
Python 3.4 is now in "feature freeze", meaning that no new features will be
added. The final release is projected for mid-March 2014.
To download Python 3.4.0b3 visit:
Please consider trying Python 3.4.0b3 with your code and reporting any
new issues you notice to:
Larry Hastings, Release Manager
larry at hastings.org
(on behalf of the entire python-dev team and 3.4's contributors)
The first release candidate of Python 3.4 will be tagged in about two
weeks. We need to be completely done with the Derby by then. And it's
going to take a while to review and iterate on the patches we've got.
Therefore: I'm going to stop accepting submissions for new patches in
two days. Patches posted to the issue tracker on or after Wednesday Jan
29 at 12:00:01am will not be accepted. If you have a patch you're still
working on, you have until then to get it in.
Please make sure that all patches, whether they've been posted yet or
not, conform to the new conversion policy for the Derby:
Thanks for participating!
I don't like how in Python 3.x, you can't do this:
lambda (x, y): whatever
It's quite useful in Python 2
if I understand correctly, it's a side effect of such packed arguments not
being allowed in function definitions. (i.e. def instead of lambda)
Can you please refer me to the original discussion in which it was decided
to remove this grammar in Python 3? I'd like to understand the arguments