PEP 428 looks nice. Thanks, Antoine!
I have a couple of questions about the module name and API. I think
I've read through most of the previous discussion, but may have missed
some, so please point me to the right place if there have already been
discussions about these things.
1) Someone on reddit.com/r/Python asked "Is the import going to be
'pathlib'? I thought the renaming going on of std lib things with the
transition to Python 3 sought to remove the spurious usage of
appending 'lib' to libs?" I wondered about this too. Has this been
2) I think the operation of "suffix" and "suffixes" is good, but not
so much the name. I saw Ben Finney's original suggestion about
multiple extensions etc
However, it seems there was no further discussion about why not
"extension" and "extensions"? I have never heard a filename extension
being called a "suffix". I know it is a suffix in the sense of the
English word, but I've never heard it called that in this context, and
I think context is important. Put another way, "extension" is obvious
and guessable, "suffix" isn't.
3) Obviously pathlib isn't going in the stdlib in Python 2.x, but I'm
wondering about writing portable code when you want the string version
of the path. In Python 3.x you'll call str(path_obj), but in Python
2.x that will fail if the path has unicode chars in it, and you'll
need to use unicode(path_obj), which of course doesn't work 3.x. Is
this just a fact of life, or would .str() or .as_string() help for
4) Is path_obj.glob() recursive? In the PEP it looks like it is if the
pattern starts with '**', but in the pep428 branch of the code there
are both glob() and rglob() functions. I've never seen the ** syntax
before (though admittedly I'm a Windows dev), and much prefer the
explicitness of having two functions, or maybe even better,
Seems much more Pythonic to provide an actual argument (or different
function) for this change in behaviour, rather than stuffing the
"recursive flag" inside the pattern string.
Has this ship already sailed with http://bugs.python.org/issue13968?
Which I also think should also be rglob(pattern) or glob(pattern,
recursive=True). Of course, if this ship has already sailed, it's
definitely better for pathlib's glob to match glob.glob.
On behalf of the Python development team, it's my privilege to announce
the first 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 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 453, a bundled installer for the *pip* package manager
* 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 late February 2014.
To download Python 3.4.0b1 visit:
Please consider trying Python 3.4.0b1 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)
I've got a nice ARM box to add to the pool (it should be a lot faster and
more reliable than warsaw-ubuntu-arm; hopefully making its way to stable).
proposed slave name: gps-ubuntu-exynos5-armv7l
description: Ubuntu ARM - Dual Cortex A15 2GiB (ie: a repurposed samsung
Please refrain from checking in any new features to Python trunk until
after the 3.4 release branch is created (which will be a few months).
Instead, let's concentrate our efforts on polishing Python 3.4 until
it's the best and most-defect-free release yet!
On Sun, 24 Nov 2013 05:58:24 +0100 (CET)
alexandre.vassalotti <python-checkins(a)python.org> wrote:
> changeset: 87486:a68c303eb8dc
> user: Alexandre Vassalotti <alexandre(a)peadrop.com>
> date: Sat Nov 23 20:58:24 2013 -0800
> Disable annoying tests which doesn't work optimized pickles.
We should probably disable them only on optimized pickles, then :-)
I've pushed pathlib to the repository. I'm hopeful there won't be
new buildbot failures because of it, but still, there may be some
platform-specific issues I'm unaware of.
I hope our Release Manager is doing ok :-)
> changeset: 87468:6bee0fdcba39
> user: Guido van Rossum <guido(a)python.org>
> date: Sat Nov 23 15:09:16 2013 -0800
> asyncio: Change bounded semaphore into a subclass, like threading.[Bounded]Semaphore.
> Lib/asyncio/locks.py | 36 ++++++++--------
> Lib/test/test_asyncio/test_locks.py | 2 +-
> 2 files changed, 20 insertions(+), 18 deletions(-)
> diff --git a/Lib/asyncio/locks.py b/Lib/asyncio/locks.py
> --- a/Lib/asyncio/locks.py
> +++ b/Lib/asyncio/locks.py
> @@ -336,22 +336,15 @@
> +class BoundedSemaphore(Semaphore):
> + def release(self):
> + if self._value >= self._bound_value:
> + raise ValueError('BoundedSemaphore released too many times')
> + super().release()
If there's a lock and parallelism involved, this release()
implementation is vulnerable to races: any number of threads can see
"self._value < self._bound_value" before one of them manages to call
the superclass release(), and so self._value can become arbitrarily
larger than self._bound_value. I fixed the same bug in threading's
similar bounded semaphore class a few weeks ago.
I'm happy to officially accept PEP 454 aka tracemalloc.
The API has substantially improved over the past weeks, and is now
both easy to use and suitable as a fundation for high-level tools for
Thanks to Victor for his work!
[Redirecting to Python Dev]
On 11/22/2013 10:25 AM, Richard Tew wrote:
> On Sat, Nov 23, 2013 at 3:16 AM, Ethan Furman <ethan(a)stoneleaf.us> wrote:
>> On 11/22/2013 01:00 AM, Richard Tew wrote:
>>> Yet, suddenly, the chance that we may release a "Stackless Python
>>> 2.8", is a concern.
>> Because there is no CPython 2.8 to mirror, and we've said there will not be
>> It certainly didn't help that this was presented one week before the feature
>> freeze deadline for 3.4 and Christian stated  his "2.8" release was going
>> to happen in one week unless we talked him out of it.
>>> We're not talking about releasing a Python 2.8 against anyone's wishes
>> Having "Python 2.8" in the name is going to be a PR nightmare. Other names
>> have been suggested.
> But how is it going to be a PR nightmare? You and others can say it,
> but is it reasonable to do so?
Apparently some of us think so. ;) There isn't supposed to be a Python 2.8. If you create one, people will find it.
There are other distributions that package and present Python x.y, so it would be reasonable to think that a Stackless
Python 2.8 meant a regular Python 2.8.0
> No-one has ever mistaken us for Python. We're not, and never will be
> high enough in the search results. Our web site is not, and has never
> been misrepresentative in a way where people could assume it is the
> proper Python web site. In our history of releasing versions with
> matching numbers, no-one has yet mistaken us.
I suspect you would find many more hits if you were the only ones to have a Python 2.8. See above for why that would be
> Yet, we're told we should adopt wacky version numbers like 10, or
> rename our project from Stackless Python.
Sometimes we have to do wacky stuff to avoid unnecessary confusion.