Re: [Python-Dev] PEP 454: add a new tracemalloc module (second round)
2013/9/17 Victor Stinner :
> Issue tracking the implementation:
> http://bugs.python.org/issue18874
If you want to test the implementation, you can try the following repository:
http://hg.python.org/features/tracemalloc
Or try the patch attached on the issue #18874 on the Python default
version. Compile Python and use "-X tracemalloc" command line option
to enable the module at startup. Then you can play with
tracemalloc.DisplayTopTask.display() and
tracemalloc.TakeSnapshot.take_snapshot().
To create Python snapshots easily, modify Lib/test/regrtest.py to use
the following block:
take = tracemalloc.TakeSnapshot()
# tracemalloc.set_traceback_limit(15); take.with_traces = True
take.filename_template = "/tmp/tracemalloc-$pid-$counter.pickle"
take.start(10)
And then start:
./python -X tracemalloc -m test
"take.with_traces = True" is slower but required if you want to use
cumulative views, show the traceback, or group traces by address. Use
a lower traceback limit if the test suite is too slow.
When you get a snapshot file, you can analyze it using:
./python -m tracemalloc /tmp/tracemalloc-1564-0001.pickle
Add --help to see all options. I like the --traceback option.
> ``get_filters()`` function:
>
> Get the filters on Python memory allocations as list of ``Filter``
> instances.
I hesitate to add a Filters class which would contain a list of
filters. The logic to check if list of filters matchs is non-trivial.
You have to split inclusive and exclusive filters and take care of
empty list of inclusive/exclusive filters. See the code of
Snapshot.apply_filters() for example.
> ``get_object_trace(obj)`` function:
>
> Get the trace of a Python object *obj* as a ``Trace`` instance.
>
> The function only returns the trace of the memory block directly
> holding to object. The ``size`` attribute of the trace is smaller
> than the total size of the object if the object is composed of more
> than one memory block.
>
> Return ``None`` if the ``tracemalloc`` module did not trace the
> allocation of the object.
>
> See also ``gc.get_referrers()`` and ``sys.getsizeof()`` functions.
The function can be see of a lie because it does not count all bytes
of a object (as explained in the doc above). The function should maybe
be renamed to "get_trace(address)" to avoid the confusion.
> DisplayTop class
>
Oh, I forgot to document the new "previous_top_stats" attribute. It is
used to compare two snapshots.
> DisplayTopTask class
>
>
> ``start(delay: int)`` method:
>
> Start a task using the ``start_timer()`` function calling the
> ``display()`` method every *delay* seconds.
I should probably repeat here that only one timer can used at the same
time. So only one DisplayTopTask or one TakeSnapshot instance can be
used at the same time.
It's a design choice to keep start_timer() simple, there is no need
for a complex scheduler for such simple debug tool.
You *can* run the two tasks at the same time by writing your own function:
def mytask(top_task, snapshot_task):
top_task.display()
snapshot_task.take_snapshot()
tracemalloc.start_timer(10, mytask, top_task, snapshot_task)
> Snapshot class
> --
>
> ``create(\*, with_traces=False, with_stats=True,
> user_data_callback=None)`` classmethod:
It's the only function using keyword-only parameters. I don't know
it's a good practice and should be used on other methods, or if it
should be avoided?
> *user_data_callback* is an optional callable object. Its result
> should be serializable by the ``pickle`` module, or
> ``Snapshot.write()`` would fail. If *user_data_callback* is set, it
> is called and the result is stored in the ``Snapshot.user_data``
> attribute. Otherwise, ``Snapshot.user_data`` is set to ``None``.
The idea is to attach arbitrary data to a snapshot. Examples:
* size of Python caches: cache of linecache and re modules
* size of the internal Unicode intern dict
* gc.get_stats()
* gc.get_count()
* len(gc.get_objects())
* ("tracemalloc_size" should maybe moved to the user_data)
I hesitate to use a dictionary for user_data. The problem is to decice how to
display such data in DisplayTop. For example, gc.get_count() is a number
whereas tracemalloc_size is size is bytes (should be formatted using kB, MB,
etc. suffixes).
What do you think?
Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 453: Explicit bootstrapping of pip
After a couple of rounds of review on distutils-sig, and with Martin agreeing to serve as BDFL-Delegate, it's time for the pip bootstrapping proposal to run the gauntlet of python-dev :) The last round of review showed that there were a few things we were assuming people knew (based on the many, many discussions around this topic on distutils-sig, starting even before Richard wrote PEP 439), so I hope I've managed to cover those better in this version. It also goes into more details on the proposed module API for getpip and the associated API updates in venv. There are still a couple of open questions related to the Windows installers, and there may still be unasked questions affecting the Mac OS X installers. HTML version: http://www.python.org/dev/peps/pep-0453/ For those that reviewed the previous versions on distutils-sig, the latest diff is here: http://hg.python.org/peps/rev/df9e4c301415 Cheers, Nick. == PEP: 453 Title: Explicit bootstrapping of pip in Python installations Version: $Revision$ Last-Modified: $Date$ Author: Donald Stufft , Nick Coghlan BDFL-Delegate: Martin von Löwis Status: Draft Type: Process Content-Type: text/x-rst Created: 10-Aug-2013 Post-History: 30-Aug-2013, 15-Sep-2013, 18-Sep-2013 Abstract This PEP proposes that the `pip`_ package manager be made available by default when installing CPython and when creating virtual environments using the standard library's ``venv`` module (including via the ``pyvenv`` command line utility). To clearly demarcate development responsibilities, and to avoid inadvertently downgrading ``pip`` when updating CPython, the proposed mechanism to achieve this is to include an explicit `pip`_ bootstrapping mechanism in the standard library that is invoked automatically by the CPython installers provided on python.org. The PEP also strongly recommends that CPython redistributors and other Python implementations ensure that ``pip`` is available by default, or at the very least, explicitly document the fact that it is not included. Proposal This PEP proposes the inclusion of a ``getpip`` bootstrapping module in Python 3.4, as well as in the next maintenance releases of Python 3.3 and 2.7. This PEP does *not* propose making pip (or any dependencies) part of the standard library. Instead, pip will be a bundled application provided along with CPython for the convenience of Python users, but subject to its own development life cycle and able to be upgraded independently of the core interpreter and standard library. Rationale = Currently, on systems without a platform package manager and repository, installing a third-party Python package into a freshly installed Python requires first identifying an appropriate package manager and then installing it. Even on systems that *do* have a platform package manager, it is unlikely to include every package that is available on the Python Package Index, and even when a desired third-party package is available, the correct name in the platform package manager may not be clear. This means that, to work effectively with the Python Package Index ecosystem, users must know which package manager to install, where to get it, and how to install it. The effect of this is that third-party Python projects are currently required to choose from a variety of undesirable alternatives: * assume the user already has a suitable cross-platform package manager installed * duplicate the instructions and tell their users how to install the package manager * completely forgo the use of dependencies to ease installation concerns for their users All of these available options have significant drawbacks. If a project simply assumes a user already has the tooling then beginning users may get a confusing error message when the installation command doesn't work. Some operating systems may ease this pain by providing a global hook that looks for commands that don't exist and suggest an OS package they can install to make the command work, but that only works on Linux systems with platform package managers. No such assistance is availabe for Windows and Mac OS X users. The challenges of dealing with this problem are a regular feature of feedback the core Python developers receive from professional educators and others introducing new users to Python. If a project chooses to duplicate the installation instructions and tell their users how to install the package manager before telling them how to install their own project then whenever these instructions need updates they need updating by every project that has duplicated them. This is particular problematic when there are multiple competing installation tools available, and different projects recommend different tools. This specific problem can be partially alleviated by strongly promoting ``pip`` as the default installer and recommending that other projects reference `pip's own bootstrapping instructions
[Python-Dev] License() release list is imcomplete; intentional?
On 2.7, >>> license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived YearOwner GPL- fromcompatible? (1) 0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRIyes 1.6 1.5.2 2000CNRIno 2.0 1.6 2000BeOpen.com no ... 2.6.5 2.6.4 2010PSF yes 2.7 2.6 2010PSF yes Was it intentional to stop with 2.7 and not continue with 2.7.1, etc? On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list? ... 2.6.4 2.6.3 2009PSF yes 2.6.5 2.6.4 2010PSF yes 3.0 2.6 2008PSF yes 3.0.1 3.0 2009PSF yes ... 3.2.4 3.2.3 2013PSF yes 3.3.0 3.2 2012PSF yes 3.3.1 3.3.0 2013PSF yes -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
On 17/09/2013 16:37, Terry Reedy wrote: On 2.7, >>> license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived YearOwner GPL- fromcompatible? (1) 0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRIyes 1.6 1.5.2 2000CNRIno 2.0 1.6 2000BeOpen.com no ... 2.6.5 2.6.4 2010PSF yes 2.7 2.6 2010PSF yes Was it intentional to stop with 2.7 and not continue with 2.7.1, etc? On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list? ... 2.6.4 2.6.3 2009PSF yes 2.6.5 2.6.4 2010PSF yes 3.0 2.6 2008PSF yes 3.0.1 3.0 2009PSF yes ... 3.2.4 3.2.3 2013PSF yes 3.3.0 3.2 2012PSF yes 3.3.1 3.3.0 2013PSF yes To me it looks like Python 2.7 isn't mentioned in the licence for Python 3 because Python 3 is derived from Python 2.6 and Python 2.7 is on a different branch, so it isn't relevant. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
Le Tue, 17 Sep 2013 11:37:48 -0400, Terry Reedy a écrit : > On 2.7, >>> license() return a text that includes a complete list of > releases from 1.6 to 2.7 and stops there > Release Derived YearOwner GPL- > fromcompatible? > (1) > > 0.9.0 thru 1.2 1991-1995 CWI yes > 1.3 thru 1.5.2 1.2 1995-1999 CNRIyes > 1.6 1.5.2 2000CNRIno > 2.0 1.6 2000BeOpen.com no > ... > 2.6.5 2.6.4 2010PSF yes > 2.7 2.6 2010PSF yes > > Was it intentional to stop with 2.7 and not continue with 2.7.1, etc? > > On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. > Intentional? It then jumps back to 3.0 and ends with the 'previous' > release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list? > > ... > 2.6.4 2.6.3 2009PSF yes > 2.6.5 2.6.4 2010PSF yes > 3.0 2.6 2008PSF yes > 3.0.1 3.0 2009PSF yes > ... > 3.2.4 3.2.3 2013PSF yes > 3.3.0 3.2 2012PSF yes > 3.3.1 3.3.0 2013PSF yes I don't really understand why the releases should be manually listed. Is it some kind of defensive coding? Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 453: Explicit bootstrapping of pip
This PEP looks great to me. Thanks to everyone involved. On Wed, 18 Sep 2013 00:46:01 +1000, Nick Coghlan wrote: > Reducing the burden of actually installing a third-party package should > also decrease the pressure to add every useful module to the standard > library. This will allow additions to the standard library to focus more > on why Python should have a particular tool out of the box instead of > using the general difficulty of installing third-party packages as > justification for inclusion. I don't think this PEP changes the inclusion calculus, because I don't think we've given any real weight to that in stdlib inclusion decisions. I think the decision making is already focused on why Python should have a particular tool out of the box. The only context I recall where "installation difficulty" has been considered relevant is the issue of corporate users restricted from installing 3rd party packages...which will not be affected at all by this PEP. --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 453: Explicit bootstrapping of pip
On Sep 17, 2013, at 12:25 PM, "R. David Murray" wrote: > This PEP looks great to me. Thanks to everyone involved. > > On Wed, 18 Sep 2013 00:46:01 +1000, Nick Coghlan wrote: >> Reducing the burden of actually installing a third-party package should >> also decrease the pressure to add every useful module to the standard >> library. This will allow additions to the standard library to focus more >> on why Python should have a particular tool out of the box instead of >> using the general difficulty of installing third-party packages as >> justification for inclusion. > > I don't think this PEP changes the inclusion calculus, because I don't > think we've given any real weight to that in stdlib inclusion decisions. > I think the decision making is already focused on why Python should have > a particular tool out of the box. When I originally wrote this statement I wasn't trying to say that modules were included because of the lack of an easy installer, but instead that a not insignificant number of people had wanted to include stuff and some of their reasoning that I had seen in the past included the difficulty in bootstrapping the installer. So it decreases the *pressure* from others to include stuff for connivence not that it necessarily changes how python-dev itself weighs the decision to do so (but it might for some people?). > > The only context I recall where "installation difficulty" has been > considered relevant is the issue of corporate users restricted from > installing 3rd party packages...which will not be affected at all by > this PEP. > > --David > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
> I don't really understand why the releases should be manually listed. > Is it some kind of defensive coding? I think it's to give people who care about such things all the information they need to make informed decisions. As I recall, the 1.6 series was problematic, because it wasn't actually open source. That's why 2.0 is a derivative of 1.5.2. I doubt there are other licensing weirdities lurking, but better to give people everything they might need, especially if it's not difficult. At this point I think the hard work is done. Release managers or their minions just need to remember to tack on the next line. Skip ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
On Tue, Sep 17, 2013 at 8:47 AM, Antoine Pitrou wrote: > Le Tue, 17 Sep 2013 11:37:48 -0400, > Terry Reedy a écrit : > > > On 2.7, >>> license() return a text that includes a complete list of > > releases from 1.6 to 2.7 and stops there > > Release Derived YearOwner GPL- > > fromcompatible? > > (1) > > > > 0.9.0 thru 1.2 1991-1995 CWI yes > > 1.3 thru 1.5.2 1.2 1995-1999 CNRIyes > > 1.6 1.5.2 2000CNRIno > > 2.0 1.6 2000BeOpen.com no > > ... > > 2.6.5 2.6.4 2010PSF yes > > 2.7 2.6 2010PSF yes > > > > Was it intentional to stop with 2.7 and not continue with 2.7.1, etc? > > > > On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. > > Intentional? It then jumps back to 3.0 and ends with the 'previous' > > release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list? > > > > ... > > 2.6.4 2.6.3 2009PSF yes > > 2.6.5 2.6.4 2010PSF yes > > 3.0 2.6 2008PSF yes > > 3.0.1 3.0 2009PSF yes > > ... > > 3.2.4 3.2.3 2013PSF yes > > 3.3.0 3.2 2012PSF yes > > 3.3.1 3.3.0 2013PSF yes > > I don't really understand why the releases should be manually listed. > Is it some kind of defensive coding? > Worse, it's superstition based on myth. IIRC this table was added when a few core Python developers including myself left CNRI in 2000. We had a bit of an argument about the license (not too much though -- in the end things came out alright). Some lawyer at CNRI thought it was a good idea to record a release history like this with the license, as a defense against whatever claims of ownership to the code someone else might suddenly come up with. Since all I wanted was to get out of there while causing them minimal upset, I told them I'd comply. But that's over 13 years ago now, and I'm not sure if it ever made sense (the internet is a different place than CNRI's lawyers envisioned). Only the top 10 of so lines of the table are in the least interesting (note that it describes a graph). I propose that we truncate the table and add a note saying that all following releases are owned by the PSF, GPL-compatible, and derived from previous PSF-owned and GPL-compatible releases. That should do until the PSF goes out of business (which I hope will never happen -- this is one reason why I wish the conferences were run by a separate entity, to avoid a conference bankruptcy from risking Python's continued open-source status). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
On Tue, Sep 17, 2013 at 10:39 AM, Antoine Pitrou wrote: > On Tue, 17 Sep 2013 09:47:48 -0700 > Guido van Rossum wrote: > > > > IIRC this table was added when a few core Python developers including > > myself left CNRI in 2000. We had a bit of an argument about the license > > (not too much though -- in the end things came out alright). Some lawyer > at > > CNRI thought it was a good idea to record a release history like this > with > > the license, as a defense against whatever claims of ownership to the > code > > someone else might suddenly come up with. Since all I wanted was to get > out > > of there while causing them minimal upset, I told them I'd comply. But > > that's over 13 years ago now, and I'm not sure if it ever made sense (the > > internet is a different place than CNRI's lawyers envisioned). Only the > top > > 10 of so lines of the table are in the least interesting (note that it > > describes a graph). I propose that we truncate the table and add a note > > saying that all following releases are owned by the PSF, GPL-compatible, > > and derived from previous PSF-owned and GPL-compatible releases. That > > should do until the PSF goes out of business (which I hope will never > > happen -- this is one reason why I wish the conferences were run by a > > separate entity, to avoid a conference bankruptcy from risking Python's > > continued open-source status). > > The PSF isn't technically the copyright holder, so would that pose a > significant threat? > I have no idea. If you want a real answer talk to a lawyer. > (at worse the PSF could relicense Python based on the copyright > agreements, but Python would still be distributable under the original > license) > But only the PSF has the list of original contributors and their licenses. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
On Tue, 17 Sep 2013 09:47:48 -0700 Guido van Rossum wrote: > > IIRC this table was added when a few core Python developers including > myself left CNRI in 2000. We had a bit of an argument about the license > (not too much though -- in the end things came out alright). Some lawyer at > CNRI thought it was a good idea to record a release history like this with > the license, as a defense against whatever claims of ownership to the code > someone else might suddenly come up with. Since all I wanted was to get out > of there while causing them minimal upset, I told them I'd comply. But > that's over 13 years ago now, and I'm not sure if it ever made sense (the > internet is a different place than CNRI's lawyers envisioned). Only the top > 10 of so lines of the table are in the least interesting (note that it > describes a graph). I propose that we truncate the table and add a note > saying that all following releases are owned by the PSF, GPL-compatible, > and derived from previous PSF-owned and GPL-compatible releases. That > should do until the PSF goes out of business (which I hope will never > happen -- this is one reason why I wish the conferences were run by a > separate entity, to avoid a conference bankruptcy from risking Python's > continued open-source status). The PSF isn't technically the copyright holder, so would that pose a significant threat? (at worse the PSF could relicense Python based on the copyright agreements, but Python would still be distributable under the original license) Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 453: Explicit bootstrapping of pip
On Tue, 17 Sep 2013 12:38:31 -0400, Donald Stufft wrote: > On Sep 17, 2013, at 12:25 PM, "R. David Murray" wrote: > > I don't think this PEP changes the inclusion calculus, because I don't > > think we've given any real weight to that in stdlib inclusion decisions. > > I think the decision making is already focused on why Python should have > > a particular tool out of the box. > > When I originally wrote this statement I wasn't trying to say that modules > were included because of the lack of an easy installer, but instead that > a not insignificant number of people had wanted to include stuff and some > of their reasoning that I had seen in the past included the difficulty in > bootstrapping the installer. > > So it decreases the *pressure* from others to include stuff for connivence > not that it necessarily changes how python-dev itself weighs the decision > to do so (but it might for some people?). I see. Yes, that makes sense. --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
On 9/17/2013 10:51 AM, Guido van Rossum wrote: But only the PSF has the list of original contributors and their licenses. So can that list be made public, and available in multiple archives? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
On 9/17/2013 11:48 AM, MRAB wrote: On 17/09/2013 16:37, Terry Reedy wrote: On 2.7, >>> license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived YearOwner GPL- fromcompatible? (1) 0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRIyes 1.6 1.5.2 2000CNRIno 2.0 1.6 2000BeOpen.com no ... 2.6.5 2.6.4 2010PSF yes 2.7 2.6 2010PSF yes Was it intentional to stop with 2.7 and not continue with 2.7.1, etc? On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list? ... 2.6.4 2.6.3 2009PSF yes 2.6.5 2.6.4 2010PSF yes 3.0 2.6 2008PSF yes 3.0.1 3.0 2009PSF yes ... 3.2.4 3.2.3 2013PSF yes 3.3.0 3.2 2012PSF yes 3.3.1 3.3.0 2013PSF yes To me it looks like Python 2.7 isn't mentioned in the licence for Python 3 because Python 3 is derived from Python 2.6 and Python 2.7 is on a different branch, so it isn't relevant. I thought of that, but if that were the reason, nothing after 2.6(.0) should be listed. I think we should follow Guido's idea of truncating after n lines, summarizing the rest, and freezing the file until there is a significant change. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
On Tue, Sep 17, 2013 at 2:45 PM, Glenn Linderman wrote: > On 9/17/2013 10:51 AM, Guido van Rossum wrote: > > But only the PSF has the list of original contributors and their licenses. > > > So can that list be made public, and available in multiple archives? > Technically it already is public based on the * next to your name on bugs.python.org. As for a concise list that's more human readable I'm sure it could if someone chose to put the effort in to write the code to make the list. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
On Tue, 17 Sep 2013 15:39:25 -0400, Brett Cannon wrote: > On Tue, Sep 17, 2013 at 2:45 PM, Glenn Linderman wrote: > > On 9/17/2013 10:51 AM, Guido van Rossum wrote: > > > > But only the PSF has the list of original contributors and their licenses. > > > > So can that list be made public, and available in multiple archives? > > > > Technically it already is public based on the * next to your name on > bugs.python.org. As for a concise list that's more human readable I'm sure > it could if someone chose to put the effort in to write the code to make > the list. The list is public in that sense (but probably not complete). However, whatever is considered to be the legal info, including the license the contributor chose, is not in the tracker. That information is in the hands of the PSF secretary, and to my (outsider, and therefore possibly incorrect :) understanding most of it is currently in the form of physical paper in a filing cabinet. I don't know if there is a project to digitize the archives or not, but it would seem like a sensible thing to do, for backup reasons if nothing else (perhaps there are already physical backups, though). --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 450 adding statistics module
Congrats, I've accepted the PEP. Nice work! Please work with the reviewers on the issue on the code. (Steven or Oscar, if either of you could work Oscar's list of resolved issues into a patch for the PEP I'll happily update it, just mail it to [email protected].) On Mon, Sep 16, 2013 at 5:06 PM, Guido van Rossum wrote: > On Mon, Sep 16, 2013 at 4:59 PM, Steven D'Aprano wrote: > >> On Mon, Sep 16, 2013 at 08:42:12AM -0700, Guido van Rossum wrote: >> > I'm ready to accept this PEP. Because I haven't read this entire thread >> > (and 60 messages about random diversions is really too much to try and >> > catch up on) I'll give people 24 hours to remind me of outstanding >> > rejections. >> > >> > I also haven't reviewed the code in any detail, but I believe the code >> > review is going well, so I'm not concerned that the PEP would have to >> > revised based on that alone. >> >> There are a couple of outstanding issues that I am aware of, but I don't >> believe that either of these affect acceptance/rejection of the PEP. >> Please correct me if I am wrong. >> >> 1) Implementation details of the statistics.sum function. Oscar is >> giving me a lot of very valuable assistance speeding up the >> implementation of sum. >> >> 2) The current implementation has extensive docstrings, but will also >> need a separate statistics.rst file. >> >> >> I don't recall any other outstanding issues, if I have forgotten any, >> please remind me. >> > > Those certainly don't stand in the way of the PEP's acceptance (but they > do block the commit of the code :-). > > The issues that Oscar listed also all seem resolved (though they would > make a nice addition to the "Discussion" section in the PEP). > > -- > --Guido van Rossum (python.org/~guido) > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 450 adding statistics module
On Tue, Sep 17, 2013 at 02:21:16PM -0700, Guido van Rossum wrote: > Congrats, I've accepted the PEP. Nice work! Please work with the reviewers > on the issue on the code. Thank you, and thanks to everyone who contributed with the discussion. > (Steven or Oscar, if either of you could work Oscar's list of resolved > issues into a patch for the PEP I'll happily update it, just mail it to > [email protected].) I will do this. -- Steven ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 450 adding statistics module
On 09/17/2013 02:21 PM, Guido van Rossum wrote: Congrats, I've accepted the PEP. Nice work! Please work with the reviewers on the issue on the code. Congratulations, Stephen! -- ~Ethan~ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] benchmark
benchmark.patch Description: Binary data ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 450 adding statistics module
On 18 Sep 2013 08:36, "Ethan Furman" wrote: > > On 09/17/2013 02:21 PM, Guido van Rossum wrote: >> >> Congrats, I've accepted the PEP. Nice work! Please work with the reviewers on the issue on the code. > > > Congratulations, Stephen! Yay! Cheers, Nick. > > -- > ~Ethan~ > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 428: Pathlib -> stat caching
On Sep 16, 2013, at 1:05 PM, Antoine Pitrou wrote: > On Mon, 16 Sep 2013 15:48:54 -0400 > Brett Cannon wrote: >>> >>> So I would like to propose the following API change: >>> >>> - Path.stat() (and stat-accessing methods such as get_mtime()...) >>> returns an uncached stat object by default >>> >>> - Path.cache_stat() can be called to return the stat() *and* cache it >>> for future use, such that any future call to stat(), cache_stat() or >>> a stat-accessing function reuses that cached stat >>> >>> In other words, only if you use cache_stat() at least once is the >>> stat() value cached and reused by the Path object. >>> (also, it's a per-Path decision) >>> >> >> Any reason why stat() can't get a keyword-only cached=True argument >> instead? Or have stat() never cache() but stat_cache() always so that >> people can choose if they want fresh or cached based on API and not whether >> some library happened to make a decision for them? > > 1. Because you also want the helper functions (get_mtime(), etc.) to > cache the value too. It's not only about stat(). With the proposed rich stat object the convenience methods living on Path wouldn't result in much added convenience: p.is_dir() vs p.stat().is_dir() Why not move these methods from Path to a rich stat obj and not cache stat results at all? It's easy enough for users to cache them themselves and much more explicit. -- Philip Jenvey ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 428: Pathlib -> stat caching
On 18 September 2013 11:10, Philip Jenvey wrote: > > On Sep 16, 2013, at 1:05 PM, Antoine Pitrou wrote: > >> On Mon, 16 Sep 2013 15:48:54 -0400 >> Brett Cannon wrote: So I would like to propose the following API change: - Path.stat() (and stat-accessing methods such as get_mtime()...) returns an uncached stat object by default - Path.cache_stat() can be called to return the stat() *and* cache it for future use, such that any future call to stat(), cache_stat() or a stat-accessing function reuses that cached stat In other words, only if you use cache_stat() at least once is the stat() value cached and reused by the Path object. (also, it's a per-Path decision) >>> >>> Any reason why stat() can't get a keyword-only cached=True argument >>> instead? Or have stat() never cache() but stat_cache() always so that >>> people can choose if they want fresh or cached based on API and not whether >>> some library happened to make a decision for them? >> >> 1. Because you also want the helper functions (get_mtime(), etc.) to >> cache the value too. It's not only about stat(). > > With the proposed rich stat object the convenience methods living on Path > wouldn't result in much added convenience: > > p.is_dir() vs p.stat().is_dir() > > Why not move these methods from Path to a rich stat obj and not cache stat > results at all? It's easy enough for users to cache them themselves and much > more explicit. Because that doesn't help iterator based os.walk inspired APIs like walkdir, which would benefit greatly from a path type with implicit caching, but would have to complicate their APIs significantly to pass around separate stat objects. Rewriting walkdir to depend on pathlib has been on my todo list for a while, as it solves a potentially serious walkdir performance problem where chained iterators have to make repeated stat calls to answer questions that were already asked by earlier iterators in the pipeline. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 450 adding statistics module
On 17 September 2013 22:21, Guido van Rossum wrote: > Congrats, I've accepted the PEP. Nice work! Please work with the reviewers > on the issue on the code. Good work, Steven! ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
Just drop support for 10.6 with Python 3.4. Problem solved. People on that old of a version of the OS can build their own Python 3.4 or do the right thing and upgrade or just install Linux. This isn't Windows. Compiler tool chains are freely available for the legacy platform. We don't need to maintain such a long legacy support tail there ourselves. -gps On Mon, Sep 16, 2013 at 1:28 PM, Ryan Gonzalez wrote: > Meh...I hate it when tools download stuff without me noticing. > > Honestly, a separate 10.6 build would work well. Plus, if a new Clang > versions includes some awesome feature that could make Python builds > better, you'd be able to take advantage of it better. > > > On Mon, Sep 16, 2013 at 2:56 PM, Bill Janssen wrote: > >> Russell E. Owen wrote: >> >> > In article , >> > Raymond Hettinger wrote: >> > >> > > On Sep 14, 2013, at 1:32 PM, Ned Deily wrote: >> > > > The >> > > > most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, >> have >> > > > a mature clang but do not provide a 10.6 SDK. Even with using an >> SDK, >> > > > it's still possible to end up inadvertently linking with the wrong >> > > > versions of system libraries. We have been burned by that in the >> past. >> > > >> > > I think we should offer a separate Mac build just for 10.6 >> > > (much like we do for the 32-bit PPC option for 10.5). >> > >> > If Apple drops support for gcc in 10.9 I guess we have to go this route, >> >> Could go the Sage route -- Sage first checks for an up-to-date version >> of gcc, and downloads it and builds it for its own use if necessary. >> >> Bill >> >> > but please be careful. Every time you add a new version of python for >> > MacOS X it means that folks providing binary installers (e.g. for numpy) >> > have to provide another binary, and folks using those installers have >> > another chance of picking the wrong one. >> > >> > If you do make a 10.6-only installer, what is the minimum version of >> > MacOS X the modern compiler would support? 10.7 gives a more measured >> > upgrade path, but 10.8 gives a better compiler. >> > >> > -- Russell >> > >> > ___ >> > Python-Dev mailing list >> > [email protected] >> > https://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/bill%40janssen.org >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> > > > > -- > Ryan > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/greg%40krypto.org > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
