Victor Stinner writes:
> 2013/10/29 Jim Jewett :
> > reset() function:
> >
> > Clear traces of memory blocks allocated by Python.
> >
> > Does this do anything besides clear? If not, why not just re-use the
> > 'clear' name from dicts?
>
> (I like the reset() name. Charles-F
Nick Coghlan writes:
> 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 :)
OMG! Even Nick does that. I feel better now! ;)
___
Python-Dev mailing list
Python-Dev@pytho
(Tue Oct 29 12:37:52 CET 2013) Victor Stinner wrote:
> For consistency, you cannot keep traces when tracing is disabled.
> The free() must be enabled to remove allocated memory blocks, or
> next malloc() may get the same address which would raise an assertion
> error (you cannot have two memory
On 30 October 2013 09:02, Eric Snow wrote:
> On Tue, Oct 29, 2013 at 3:32 AM, Nick Coghlan wrote:
>> On 29 Oct 2013 14:45, "Eric Snow" wrote:
>>> I'd rather give loaders another optional method:
>>> supports_reload(name). Complicating the spec methods signatures (to
>>> support passing the old
On Tue, Oct 29, 2013 at 3:32 AM, Nick Coghlan wrote:
> On 29 Oct 2013 14:45, "Eric Snow" wrote:
>> I'd rather give loaders another optional method:
>> supports_reload(name). Complicating the spec methods signatures (to
>> support passing the old spec through) just for the sake of reload
>> seems
2013/10/26 Kristján Valur Jónsson :
> In that case, how about adding a client/server feature?
>
> If you standardize the format, a minimal tracing client could write a log,
> or send it to a socket, in a way that can be turned into a snapshot by a
> corresponsing utility reading from a file or list
Thanks Barry!
That was a great announcement note, right from the heart. Python 2.6 may
retire, but Python is far from retired, and I am looking forward to many
more great interactions with you here on python-dev. Cheers!
--Guido
On Tue, Oct 29, 2013 at 10:48 AM, Barry Warsaw wrote:
> Hello Pyt
Hello Pythoneers and Pythonistas,
Five years ago this month, we released Python 2.6. It was an important
version in Python's evolution, as it was developed in tandem with Python 3.0
and had the express intent of starting the transition toward Python 3.
Amazingly, here we are five years later, an
> Gesendet: Dienstag, 29. Oktober 2013 um 10:54 Uhr
> Von: "Victor Stinner"
> An: "Georg Brandl"
> Cc: "Python Dev"
> Betreff: Re: [Python-Dev] cpython: Issue #18408: Fix
> PyUnicode_AsUTF8AndSize(), raise MemoryError exception on
>
> 2013/10/29 Georg Brandl :
> >> diff --git a/Objects/unicodeo
> Gesendet: Dienstag, 29. Oktober 2013 um 10:38 Uhr
> Von: "Victor Stinner"
> An: "Georg Brandl"
> Cc: "Python Dev"
> Betreff: Re: [Python-Dev] cpython: Issue #18408: Add a new
> PyFrame_FastToLocalsWithError() function to handle
>
> 2013/10/29 Georg Brandl :
> > Am 29.10.2013 01:19, schrieb vi
2013/10/29 Nick Coghlan :
> I was thinking you could turn on warnings->errors and then catch the
> exception, and use that to get hold of the original object that
> triggered the resource warning, and then fed *that* into
> tracemalloc.get_object_traceback(). But, alas, even if we tweaked
> Resourc
On 29 October 2013 22:07, Victor Stinner wrote:
> Hi,
>
> Since Python 3.3, when a file or socket object is destroyed before
> being closed, a ResourceWarning is emitted. The warning is emitted
> where the object is destroyed: it's common to see "gc.collect()"
> location in the Python test suite f
On 29 October 2013 19:54, Victor Stinner wrote:
>
> If there is really a regression, I prefer to limit it to the new
> version, not to a stable version.
>
> Note: I'm not saying that I'm 0% confident in my changes :-)
Sounds like a solid rationale for limiting the changes to 3.4 to me :)
/me sho
Hi,
Since Python 3.3, when a file or socket object is destroyed before
being closed, a ResourceWarning is emitted. The warning is emitted
where the object is destroyed: it's common to see "gc.collect()"
location in the Python test suite for example.
Tarek Ziadé asked on Twitter if there is a tool
2013/10/29 Jim Jewett :
> reset() function:
>
> Clear traces of memory blocks allocated by Python.
>
> Does this do anything besides clear? If not, why not just re-use the
> 'clear' name from dicts?
(I like the reset() name. Charles-François suggested this name
inspired by OProfile AP
2013/10/29 Georg Brandl :
>> diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
>> --- a/Objects/unicodeobject.c
>> +++ b/Objects/unicodeobject.c
>> @@ -3766,6 +3766,7 @@
>> return NULL;
>> _PyUnicode_UTF8(unicode) = PyObject_MALLOC(PyBytes_GET_SIZE(bytes)
>> + 1)
A
>
>
> disable() function:
>
> Stop tracing Python memory allocations and clear traces of
> memory blocks allocated by Python.
>
> I would disable to stop tracing, but I would not expect it to clear out the
> traces it had already captured. If it has to do that, please put
Le Tue, 29 Oct 2013 10:38:23 +0100,
Victor Stinner a écrit :
> 2013/10/29 Georg Brandl :
> > Am 29.10.2013 01:19, schrieb victor.stinner:
> >> http://hg.python.org/cpython/rev/4ef4578db38a
> >> changeset: 86715:4ef4578db38a
> >> user:Victor Stinner
> >> date:Tue Oct 29 01:19:37
2013/10/29 Georg Brandl :
> Am 29.10.2013 01:19, schrieb victor.stinner:
>> http://hg.python.org/cpython/rev/4ef4578db38a
>> changeset: 86715:4ef4578db38a
>> user:Victor Stinner
>> date:Tue Oct 29 01:19:37 2013 +0100
>> summary:
>> Issue #18408: Add a new PyFrame_FastToLocalsWi
On 29 Oct 2013 14:45, "Eric Snow" wrote:
>
> On Sat, Oct 26, 2013 at 11:03 PM, Nick Coghlan wrote:
> > I don't think we can postpone it to later, as we need to be clear on:
> >
> > 1. Does reload use __name__ or __spec__.name when both are available?
> > 2. Does __name__ get restored to its origi
20 matches
Mail list logo
