Re: [Python-Dev] Updated PEP 454 (tracemalloc): no more metrics!
I updated the PEP according to different comments:
* replace Snapshot.create() class method with take_snapshot() function
* get_traces() now returns a list instead of a dict (remove addresses)
* remove get_stats()
* unknown frames are now stored as ("", 0) instead of (None, None)
* remove get_object_address()
* remove get_trace()
* remove add_inclusive_filter() and add_exclusive_filter() functions
* remove "address" key type from Snapshot.group_by()
http://www.python.org/dev/peps/pep-0454/
(not updated yet)
Remaining questions:
* do you have a better suggestion for GroupedStats.stats attribute or
GroupedStats.statistics() method: "stats" and "statistics" are too
close
* should GroupedStats.statistics() and GroupedStats.compare_to()
always sort the result to drop the sort=True parameter?
* do you prefer Snapshot.create() class method or take_snapshot()
function? There is also a Snapload.load() class method
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
Re: [Python-Dev] PEP 451 update
On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan wrote: > Now, regarding the signature of exec_module(): I'm back to believing > that loaders should receive a clear indication that a reload is taking > place. Legacy loaders have to figure that out for themselves (by > seeing that the module already exists in sys.modules), but we can do > better for the new API by making the exec_module signature look like: > > def exec_module(self, module, previous_spec=None): > # module is as per the current PEP 451 text > # previous_spec would be set *only* in the reload() case > # loaders that don't care still need to accept it, but can > just ignore it Just to be clear, this means that a lazy import implementation that creates a module object without a __spec__ in the first place will look like an initial import? Or will that crash importlib because of a missing __spec__ attribute? That is, is reload()'s contract adding a new prerequisite for the object passed to it? (The specific use case is creating a ModuleType subclass instance for lazy importing upon attribute access. Pre-importlib, all that was needed was a working __name__ attribute on the module.) ___ 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] OrderedDict.values() behavior for modified instance
On 10/26/2013 08:32 PM, Nikolaus Rath wrote: Ethan Furman writes: Good write-up. Please submit it to the bug tracker: http://bugs.python.org Submitted as http://bugs.python.org/issue19414. If someone gives me the go-ahead for one of the proposed solutions, I'd be happy to create a full patch. That would be Raymond's call. Give him a few days to respond. -- ~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
Re: [Python-Dev] Updated PEP 454 (tracemalloc): no more metrics!
Hum, timestamp and traceback_limit attributed of GroupedStats can also be removed, they are just of the same attribute of the Snapshot class and GroupedStats is created from Snapshot.group_by(). Le 27 oct. 2013 17:26, "Victor Stinner" a écrit : > * do you have a better suggestion for GroupedStats.stats attribute or > GroupedStats.statistics() method: "stats" and "statistics" are too > close An option is to modify GroupedStats to inherit from dict, so GroupedStats.stats would be GroupedStats directly. > * should GroupedStats.statistics() and GroupedStats.compare_to() > always sort the result to drop the sort=True parameter? The result is a list which can be bigger than 100,000 items. The question is if it would inefficient to sort the list twice. Another option is to replace sort parameter with a new sort_key parameter (callable), passed to list.sort as the ke parameter. 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] [RELEASE] Python 2.7.6 release candidate 1
I'm happy to announce the availability of Python 2.7.6 release candidate 1. Most importantly, this release candidate resolves crashes of the interactive interpreter on OS X 10.9. It also includes the usual collection of bugfixes over 2.7.5. These are described in excruciating detail in the Misc/NEWS file of the source tarball. You can view it online at http://hg.python.org/cpython/raw-file/9750acbf7c40/Misc/NEWS Downloads are at http://python.org/download/releases/2.7.6/ As always, please test the release and report bugs to http://bugs.python.org/ With any luck, the final release will follow in a week. Enjoy, Benjamin Peterson 2.7 Release Manager ___ 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] [RELEASED] Python 3.3.3 release candidate 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm quite happy to announce the Python 3.3.3 release candidate 1. Python 3.3.3 includes several security fixes and over 150 bug fixes compared to the Python 3.3.2 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.3 also contains a new batteries-included feature for OS X users of IDLE and other Tkinter-based programs. The python.org Mac OS X 64-bit/32-bit x86-64/i386 Installer for OS X 10.6+ now includes its own builtin version of Tcl/Tk 8.5. It is no longer necessary to install a third-party version of Tcl/Tk 8.5 to workaround the problematic system versions. See http://www.python.org/download/mac/tcltk/ for more information. 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 http://docs.python.org/3.3/whatsnew/3.3.html and for the detailed changelog of 3.3.3, see http://docs.python.org/3.3/whatsnew/changelog.html To download Python 3.3.3 rc1 visit: http://www.python.org/download/releases/3.3.3/ This is a preview release, please report any bugs to http://bugs.python.org/ The final version is scheduled to be released in two weeks' time, on or about the 10th of November. Enjoy! - -- 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) iEYEARECAAYFAlJte8kACgkQN9GcIYhpnLDx8wCgqtabbC8DaoW+Vy03AYGWyLhw sWcAoIK5jQeXDAxHayG+VWH/rRF1+qHC =yOed -END PGP SIGNATURE- ___ 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 451 update
On 28 Oct 2013 02:37, "PJ Eby" wrote: > > On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan wrote: > > Now, regarding the signature of exec_module(): I'm back to believing > > that loaders should receive a clear indication that a reload is taking > > place. Legacy loaders have to figure that out for themselves (by > > seeing that the module already exists in sys.modules), but we can do > > better for the new API by making the exec_module signature look like: > > > > def exec_module(self, module, previous_spec=None): > > # module is as per the current PEP 451 text > > # previous_spec would be set *only* in the reload() case > > # loaders that don't care still need to accept it, but can > > just ignore it > > Just to be clear, this means that a lazy import implementation that > creates a module object without a __spec__ in the first place will > look like an initial import? Or will that crash importlib because of > a missing __spec__ attribute? > > That is, is reload()'s contract adding a new prerequisite for the > object passed to it? > > (The specific use case is creating a ModuleType subclass instance for > lazy importing upon attribute access. Pre-importlib, all that was > needed was a working __name__ attribute on the module.) For custom loaders, that's part of the contract for create_module() (since you'll get an ordinary module otherwise), and so long as *setting* the special module attributes doesn't cause the module to be imported during the initial load operation, attribute access based lazy loading will work fine (and you don't even have to set __name__, since the import machinery will take care of that). For module level lazy loading that injects a partially initialised module object into sys.modules rather than using a custom loader or setting a __spec__ attribute, yes, the exec_module invocation on reloading would always look like a fresh load operation (aside from the fact that the custom instance would already be in sys.modules from the first load operation). It *will* still work, though (at least, it won't break any worse than such code does today, since injecting a replacement into sys.modules really isn't reload friendly in the first place). Cheers, Nick. ___ 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] pathlib (PEP 428) status
Hi, Christian Heimes python.org> writes: > [...] Last week at PyCon.DE in Cologne > several people have asked me about pathlib. We even had a BarCamp > session about path libraries for Python. A couple of German Python users > have promised to contribute doc improvements soonish. Yes I am one of those germans :) I gave a talk there, where I asked the naive question about the 'missing' path class in Python and it resonated with quite a few of the participants, so I guess this would be appreciated by a lot of Python users. Anyway - I am willing to give Antoine a hand in getting pathlib into Python 3.4. I will see what I can do. So +1 from me :) Cheers Oliver ___ 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 451 update
On Sun, Oct 27, 2013 at 4:59 PM, Nick Coghlan wrote:
>
> On 28 Oct 2013 02:37, "PJ Eby" wrote:
>>
>> On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan wrote:
>> > Now, regarding the signature of exec_module(): I'm back to believing
>> > that loaders should receive a clear indication that a reload is taking
>> > place. Legacy loaders have to figure that out for themselves (by
>> > seeing that the module already exists in sys.modules), but we can do
>> > better for the new API by making the exec_module signature look like:
>> >
>> > def exec_module(self, module, previous_spec=None):
>> > # module is as per the current PEP 451 text
>> > # previous_spec would be set *only* in the reload() case
>> > # loaders that don't care still need to accept it, but can
>> > just ignore it
>>
>> Just to be clear, this means that a lazy import implementation that
>> creates a module object without a __spec__ in the first place will
>> look like an initial import? Or will that crash importlib because of
>> a missing __spec__ attribute?
>>
>> That is, is reload()'s contract adding a new prerequisite for the
>> object passed to it?
>>
>> (The specific use case is creating a ModuleType subclass instance for
>> lazy importing upon attribute access. Pre-importlib, all that was
>> needed was a working __name__ attribute on the module.)
>
> For custom loaders, that's part of the contract for create_module() (since
> you'll get an ordinary module otherwise),
Huh? I don't understand where custom loaders come into it. For that
matter, I don't understand what "get an ordinary module object" means
here, either.
I'm talking about userspace code that implements lazy importing
features, like the lazyModule() function in this module:
http://svn.eby-sarna.com/Importing/peak/util/imports.py?view=markup
Specifically, I'm trying to get an idea of how much that code will
need to change under the PEP (and apparently under importlib in
general).
> and so long as *setting* the
> special module attributes doesn't cause the module to be imported during the
> initial load operation, attribute access based lazy loading will work fine
> (and you don't even have to set __name__, since the import machinery will
> take care of that).
There's no "initial load operation", just creation of a dummy module
and stuffing it into sys.modules. The way it works is that in, say,
foo/__init__.py, one uses:
bar = lazyModule('foo.bar')
baz = lazyModule('foo.baz')
Then anybody importing 'foo.bar' or 'foo.baz' (or using "from foo
import bar", etc.) ends up with the lazy module. That is, it's for
lazily exposing APIs, not something used as an import hook.
> For module level lazy loading that injects a partially initialised module
> object into sys.modules rather than using a custom loader or setting a
> __spec__ attribute, yes, the exec_module invocation on reloading would
> always look like a fresh load operation (aside from the fact that the custom
> instance would already be in sys.modules from the first load operation).
Right.
> It *will* still work, though (at least, it won't break any worse than such
> code
> does today, since injecting a replacement into sys.modules really isn't
> reload friendly in the first place).
Wait, what? Who's injecting a replacement into sys.modules? A
replacement of what? Or do you mean that loaders aren't supposed to
create new modules, but use the one in sys.modules?
Honestly, I'm finding all this stuff *really* confusing, which is kind
of worrying. I mean, I gather I'm one of the handful of people who
really understood how importing *used to work*, and I'm having a lot
of trouble wrapping my brain around the new world.
(Granted, I think that may be because I understand how a lot of old
corner cases work, but what's bugging me is that I no longer
understand how those old corners work under the new regime, nor do I
feel I understand what the *new* corners will be. This may also just
be communication problems, and the fact that it's been months since I
really walked through importlib line by line, and have never really
walked through it (or PEP 451) quite as thoroughly as I have import.c.
I also seem to be having trouble grokking why the motivating use
cases for PEP 451 can't be solved by just providing people with good
base classes to use for writing loaders -- i.e., I don't get why the
core protocol has to change to address the use case of writing loaders
more easily. The new protocol seems way more complex than PEP 302,
and ISTM the complexity could just be pushed off to the loader side of
the protocol without creating more interdependency between importlib
and the loaders.)
___
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 451 update
On 28 Oct 2013 08:41, "PJ Eby" wrote:
>
> On Sun, Oct 27, 2013 at 4:59 PM, Nick Coghlan wrote:
> >
> > On 28 Oct 2013 02:37, "PJ Eby" wrote:
> >>
> >> On Sun, Oct 27, 2013 at 1:03 AM, Nick Coghlan
wrote:
> >> > Now, regarding the signature of exec_module(): I'm back to believing
> >> > that loaders should receive a clear indication that a reload is
taking
> >> > place. Legacy loaders have to figure that out for themselves (by
> >> > seeing that the module already exists in sys.modules), but we can do
> >> > better for the new API by making the exec_module signature look like:
> >> >
> >> > def exec_module(self, module, previous_spec=None):
> >> > # module is as per the current PEP 451 text
> >> > # previous_spec would be set *only* in the reload() case
> >> > # loaders that don't care still need to accept it, but can
> >> > just ignore it
> >>
> >> Just to be clear, this means that a lazy import implementation that
> >> creates a module object without a __spec__ in the first place will
> >> look like an initial import? Or will that crash importlib because of
> >> a missing __spec__ attribute?
> >>
> >> That is, is reload()'s contract adding a new prerequisite for the
> >> object passed to it?
> >>
> >> (The specific use case is creating a ModuleType subclass instance for
> >> lazy importing upon attribute access. Pre-importlib, all that was
> >> needed was a working __name__ attribute on the module.)
> >
> > For custom loaders, that's part of the contract for create_module()
(since
> > you'll get an ordinary module otherwise),
>
> Huh? I don't understand where custom loaders come into it. For that
> matter, I don't understand what "get an ordinary module object" means
> here, either.
>
> I'm talking about userspace code that implements lazy importing
> features, like the lazyModule() function in this module:
>
>http://svn.eby-sarna.com/Importing/peak/util/imports.py?view=markup
>
> Specifically, I'm trying to get an idea of how much that code will
> need to change under the PEP (and apparently under importlib in
> general).
If the lazy import is injected by a *different* module, then nothing
changes.
> > and so long as *setting* the
> > special module attributes doesn't cause the module to be imported
during the
> > initial load operation, attribute access based lazy loading will work
fine
> > (and you don't even have to set __name__, since the import machinery
will
> > take care of that).
>
> There's no "initial load operation", just creation of a dummy module
> and stuffing it into sys.modules. The way it works is that in, say,
> foo/__init__.py, one uses:
>
> bar = lazyModule('foo.bar')
> baz = lazyModule('foo.baz')
>
> Then anybody importing 'foo.bar' or 'foo.baz' (or using "from foo
> import bar", etc.) ends up with the lazy module. That is, it's for
> lazily exposing APIs, not something used as an import hook.
I was thinking of the more complex case where a module causes *itself* to
be loaded lazily. Nothing changes for the simpler case where the injection
occurs in a different module.
> > For module level lazy loading that injects a partially initialised
module
> > object into sys.modules rather than using a custom loader or setting a
> > __spec__ attribute, yes, the exec_module invocation on reloading would
> > always look like a fresh load operation (aside from the fact that the
custom
> > instance would already be in sys.modules from the first load operation).
>
> Right.
>
>
> > It *will* still work, though (at least, it won't break any worse than
such code
> > does today, since injecting a replacement into sys.modules really isn't
> > reload friendly in the first place).
>
> Wait, what? Who's injecting a replacement into sys.modules? A
> replacement of what? Or do you mean that loaders aren't supposed to
> create new modules, but use the one in sys.modules?
>
> Honestly, I'm finding all this stuff *really* confusing, which is kind
> of worrying. I mean, I gather I'm one of the handful of people who
> really understood how importing *used to work*, and I'm having a lot
> of trouble wrapping my brain around the new world.
Provide test cases that exercise the situations you're concerned about
supporting and then you don't need to worry about them breaking.
>
> (Granted, I think that may be because I understand how a lot of old
> corner cases work, but what's bugging me is that I no longer
> understand how those old corners work under the new regime, nor do I
> feel I understand what the *new* corners will be. This may also just
> be communication problems, and the fact that it's been months since I
> really walked through importlib line by line, and have never really
> walked through it (or PEP 451) quite as thoroughly as I have import.c.
> I also seem to be having trouble grokking why the motivating use
> cases for PEP 451 can't be solved by just providing people with good
> base classes to use for writing loaders -- i.e., I don't ge
