Mailman 3 November 2013 - Python-Dev

Re: [Python-Dev] [Python-checkins] cpython: Close #19762: Fix name of _get_traces() and _get_object_traceback() function
by Jim Jewett 25 Nov '13

25 Nov '13

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 intentional.) (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 changes too. (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.. -jJ On Mon, Nov 25, 2013 at 3:34 AM, victor.stinner <python-checkins(a)python.org>wrote: > http://hg.python.org/cpython/rev/2e2ec595dc58 > changeset: 87551:2e2ec595dc58 > user: Victor Stinner <victor.stinner(a)gmail.com> > date: Mon Nov 25 09:33:18 2013 +0100 > summary: > Close #19762: Fix name of _get_traces() and _get_object_traceback() > function > name in their docstring. Patch written by Vajrasky Kok. > > files: > 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 @@ > } > > PyDoc_STRVAR(tracemalloc_get_traces_doc, > - "get_traces() -> list\n" > + "_get_traces() -> list\n" > "\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 @@ > } > > PyDoc_STRVAR(tracemalloc_get_object_traceback_doc, > - "get_object_traceback(obj)\n" > + "_get_object_traceback(obj)\n" > "\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 > Python-checkins(a)python.org > https://mail.python.org/mailman/listinfo/python-checkins > >

2 1

PEP 428 - pathlib API questions
by Ben Hoyt 25 Nov '13

25 Nov '13

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 discussed/answered? 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 (https://mail.python.org/pipermail/python-ideas/2012-October/016437.html). 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 2.x/3.x portability? 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, path_obj.glob('*.py', recursive=True). 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. Thanks, Ben

6 9

[RELEASED] Python 3.4.0b1
by Larry Hastings 24 Nov '13

24 Nov '13

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 production settings. 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 in subprocesses * 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: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0b1 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors)

2 2

can someone create a buildbot slave name & password for me?
by Gregory P. Smith 24 Nov '13

24 Nov '13

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 ARM chromebook) thanks, -gps

3 5

Python 3.4.0b1 is now tagged, feature-freeze is now in effect
by Larry Hastings 24 Nov '13

24 Nov '13

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! Thanks, //arry/

1 0

Re: [Python-Dev] cpython: Disable annoying tests which doesn't work optimized pickles.
by Antoine Pitrou 24 Nov '13

24 Nov '13

On Sun, 24 Nov 2013 05:58:24 +0100 (CET) alexandre.vassalotti <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/a68c303eb8dc > changeset: 87486:a68c303eb8dc > user: Alexandre Vassalotti <alexandre(a)peadrop.com> > date: Sat Nov 23 20:58:24 2013 -0800 > summary: > Disable annoying tests which doesn't work optimized pickles. We should probably disable them only on optimized pickles, then :-) Regards Antoine.

1 0

PEP 428 (pathlib) now committed
by Antoine Pitrou 24 Nov '13

24 Nov '13

Hello, 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 :-) Regards Antoine.

5 7

Re: [Python-Dev] [Python-checkins] cpython: asyncio: Change bounded semaphore into a subclass, like
by Tim Peters 23 Nov '13

23 Nov '13

[guido] > http://hg.python.org/cpython/rev/6bee0fdcba39 > changeset: 87468:6bee0fdcba39 > user: Guido van Rossum <guido(a)python.org> > date: Sat Nov 23 15:09:16 2013 -0800 > summary: > asyncio: Change bounded semaphore into a subclass, like threading.[Bounded]Semaphore. > > files: > 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.

1 0

PEP 454 - tracemalloc - accepted
by Charles-François Natali 23 Nov '13

23 Nov '13

Hi, 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 memory-profiling. Thanks to Victor for his work! Charles-François

6 8

Reminder: Less than 24 hours until 3.4 feature freeze
by Larry Hastings 23 Nov '13

23 Nov '13

I hope to tag 3.4 in less than 24 hours from now. Last call, folks. Here's hoping the buildbots all get green soon, //arry/

1 0