Jim Jewett writes:
> Later, he wrote:
> > I don't see why disable() would return data.
>
> disable is indeed a bad name for something that returns data.
Note that I never proposed that disable() *return* anything, only that
it *get* the trace. It could store it in some specified object, or
On 31 Oct 2013 08:54, "Eric Snow" wrote:
>
> On Wed, Oct 30, 2013 at 4:09 PM, Nick Coghlan wrote:
> > On 31 Oct 2013 03:41, "Eric Snow" wrote:
> >> Our recent discovery about reloading should probably be reflected in
> >> the signature of finder.find_spec():
> >>
> >> MetaPathFinder.find_spec(
2013/10/31 Victor Stinner :
> Log calls to the memory allocator
> -
>
> A different approach is to log calls to ``malloc()``, ``realloc()`` and
> ``free()`` functions. Calls can be logged into a file or send to another
> computer through the network. Example of a log
New update of the PEP combining various remarks:
* Remove GroupedStats class and Snapshot.group_by(): replaced with a
new Snapshot.statistics() method which combines all features
* Rename reset() to clear_traces() and explain how to get traces
before clearing traces
* Snapshot.apply_filters() now
On Wed, Oct 30, 2013 at 4:09 PM, Nick Coghlan wrote:
> On 31 Oct 2013 03:41, "Eric Snow" wrote:
>> Our recent discovery about reloading should probably be reflected in
>> the signature of finder.find_spec():
>>
>> MetaPathFinder.find_spec(name, path=None, existing=None)
>> PathEntryFinder.fin
On 31 Oct 2013 03:41, "Eric Snow" wrote:
>
> On Tue, Oct 29, 2013 at 7:29 PM, Nick Coghlan wrote:
> > OK, time for me to stop trying to remember the details of the problem
> > I'm trying to solve and go look them up in the source code :)
> >
> > One of my goals here is to be able to migrate exten
Le 30 oct. 2013 20:58, "Jim Jewett" a écrit :
> hough if you use a dict internally, that might not
> be the case.
Tracemalloc uses a {address: trace} duct internally.
> If you return it as a list instead of a dict, but that list is
> NOT in time-order, that is worth documenting
Ok i will docum
On Wed, Oct 30, 2013 at 6:02 AM, Victor Stinner
wrote:
> 2013/10/30 Jim J. Jewett :
>> Well, unless I missed it... I don't see how to get anything beyond
>> the return value of get_traces, which is a (time-ordered?) list
>> of allocation size with then-current call stack. It doesn't mention
>> an
Hi Raymond,
On Wed, 30 Oct 2013 01:12:03 -0600
Raymond Hettinger wrote:
>
> On Oct 28, 2013, at 1:16 PM, Victor Stinner wrote:
>
> > so what is the
> > status of the PEP 455 (TransformDict)?
>
>
> I'm giving a thorough evaluation of the proposal
> and am devoting chunks of time each weekend
> And how does a case-insensitive string compare with a normal
> (case-sensitive) string? This is a can of worms.
I was wondering this myself. I suspect it would depend which string is
on the left hand side of the comparison operator, yes? Can of worms,
indeed.
implicit-insensitve-i-n-ly, y'rs,
On Wed, 30 Oct 2013 16:34:33 +
Nigel Small wrote:
> It strikes me that there could be an alternative approach to some of the
> use cases discussed here. Instead of a new type of dictionary, the
> case-insensitivity problem could be solved with something akin to a *
> CaseInsensitiveString* cla
True, but I could similarly argue that the nice thing about
CaseInsensitiveString is it is usable for much more than dictionary keys -
it just depends on your point of view.
There would be nothing stopping other types of dictionary key
transformation being covered by other key data types in a simi
On Tue, Oct 29, 2013 at 7:29 PM, Nick Coghlan wrote:
> OK, time for me to stop trying to remember the details of the problem
> I'm trying to solve and go look them up in the source code :)
>
> One of my goals here is to be able to migrate extension loading from
> the old API to the new plugin API.
On 10/30/2013 09:34 AM, Nigel Small wrote:
It strikes me that there could be an alternative approach to some of the use
cases discussed here. Instead of a new type
of dictionary, the case-insensitivity problem could be solved with something
akin to a *CaseInsensitiveString* class [...]
The n
> Snapshot
>
>
> ``Snapshot(timestamp: datetime.datetime, traceback_limit: int, stats:
> dict=None, traces: dict=None)`` class:
>
> Snapshot of statistics and traces of memory blocks allocated by
> Python.
>
> ``apply_filters(filters)`` method:
>
> Apply filters on the ``traces
It strikes me that there could be an alternative approach to some of the
use cases discussed here. Instead of a new type of dictionary, the
case-insensitivity problem could be solved with something akin to a *
CaseInsensitiveString* class used for keys within a standard dictionary.
This would be ve
On 10/30/2013 12:12 AM, Raymond Hettinger wrote:
Hopefully, this post will make the thought process more transparent.
Thanks, Raymond. Your time is appreciated.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
On Wed, 30 Oct 2013 01:12:03 -0600, Raymond Hettinger
wrote:
> I'm giving a thorough evaluation of the proposal
> and am devoting chunks of time each weekend
> to reviewing the email threads, the links provided
> in the PEPs, looking at how well the TD fits in existing code.
>
> I'm giving this
On Wed, 30 Oct 2013 01:12:03 -0600, Raymond Hettinger
wrote:
> If I had to choose right now, a safe choice would be to focus on
> the primary use case and implement a clean CaseInsensitiveDict
> without the double-dict first-saved case-preserving feature.
> That said, I find the TD to be fascinat
2013/10/30 Kristján Valur Jónsson :
> The point of a PEP is getting something into standard python. The command
> line flag is also part of this.
> Piggybacking a lightweight client/server data-gathering version of this on
> top of the PEP
> could be beneficial in that respect.
In my opinion, y
> -Original Message-
> From: Victor Stinner [mailto:victor.stin...@gmail.com]
> Sent: 29. október 2013 21:30
> To: Kristján Valur Jónsson
> Cc: python-dev
> Subject: Re: [Python-Dev] Updated PEP 454 (tracemalloc): no more metrics!
> tracemalloc maintains a dictionary of all allocated memo
2013/10/30 Stephen J. Turnbull :
> Just "reset" implies to me that you're ready to start over. Not just
> traced memory blocks but accumulated statistics and any configuration
> (such as Filters) would also be reset. Also tracing would be disabled
> until started explicitly.
If the name is reall
Hi,
2013/10/30 Jim J. Jewett :
> Well, unless I missed it... I don't see how to get anything beyond
> the return value of get_traces, which is a (time-ordered?) list
> of allocation size with then-current call stack. It doesn't mention
> any attribute for indicating that some entries are de-alloc
On Oct 28, 2013, at 1:16 PM, Victor Stinner wrote:
> so what is the
> status of the PEP 455 (TransformDict)?
I'm giving a thorough evaluation of the proposal
and am devoting chunks of time each weekend
to reviewing the email threads, the links provided
in the PEPs, looking at how well the TD f
24 matches
Mail list logo
