Why are these functions (get_traces and get_object_traceback) private?
(1) Is the whole module provisional? At one point, I had thought so, but
I don't see that in the PEP or implementation. (I'm not sure that it
should be provisional, but I want to be sure that the decision is
(2) This implementation does lock in certain choices about the nature of
traces. (What data to include for analysis vs excluding to save memory;
which events are tracked separately and which combined into a single total;
organizing the data that is saved in a hash by certain keys; etc)
While I would prefer more flexibility, the existing code provides a
reasonable default, and I can't forsee changing traces so much that these
functions *can't* be reasonably supported unless the rest of the module API
(3) get_object_traceback is the killer app that justifies the specific
data-collection choices Victor made; if it isn't public, the implementation
starts to look overbuilt.
(4) get_traces is about the only way to get at even the all the data that
*is* stored, prior to additional summarization. If it isn't public, those
default summarization options become even more locked in..
On Mon, Nov 25, 2013 at 3:34 AM, victor.stinner
> changeset: 87551:2e2ec595dc58
> user: Victor Stinner <victor.stinner(a)gmail.com>
> date: Mon Nov 25 09:33:18 2013 +0100
> Close #19762: Fix name of _get_traces() and _get_object_traceback()
> name in their docstring. Patch written by Vajrasky Kok.
> Modules/_tracemalloc.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
> diff --git a/Modules/_tracemalloc.c b/Modules/_tracemalloc.c
> --- a/Modules/_tracemalloc.c
> +++ b/Modules/_tracemalloc.c
> @@ -1018,7 +1018,7 @@
> - "get_traces() -> list\n"
> + "_get_traces() -> list\n"
> "Get traces of all memory blocks allocated by Python.\n"
> "Return a list of (size: int, traceback: tuple) tuples.\n"
> @@ -1083,7 +1083,7 @@
> - "get_object_traceback(obj)\n"
> + "_get_object_traceback(obj)\n"
> "Get the traceback where the Python object obj was allocated.\n"
> "Return a tuple of (filename: str, lineno: int) tuples.\n"
> Repository URL: http://hg.python.org/cpython
> Python-checkins mailing list
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!