On Tue, May 10, 2011 at 11:53 AM, Marvin Humphrey
mar...@rectangular.com wrote:
With regards to what actually happens to the reference count, I would argue
that incremented and decremented are accurate descriptions.
* When a function returns an incremented object, that function has added
On Fri, May 6, 2011 at 8:27 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 06 May 2011 13:28:11 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Amaury Forgeot d'Arc wrote [concerning the Doc/data/refcounts.dat file]:
This is not always true, for example when the item is already
Nick Coghlan wrote:
One interesting aspect is that from the caller's point of view, a
*new* reference to the relevant behaves like a borrowed reference for
input parameters, but like a stolen reference for output parameters
and return values.
I think it's less confusing to use the term new
Marvin Humphrey wrote:
incremented: The caller has to account for an additional refcount.
decremented: The caller has to account for a lost refcount.
I'm not sure that really clarifies anything. These terms
sound like they're talking about the reference count of the
object, but if they
On Tue, May 10, 2011 at 12:13:47PM +1200, Greg Ewing wrote:
Nick Coghlan wrote:
One interesting aspect is that from the caller's point of view, a
*new* reference to the relevant behaves like a borrowed reference for
input parameters, but like a stolen reference for output parameters
and
On Tue, May 10, 2011 at 01:28:04PM +1200, Greg Ewing wrote:
Marvin Humphrey wrote:
incremented: The caller has to account for an additional refcount.
decremented: The caller has to account for a lost refcount.
I'm not sure that really clarifies anything. These terms
sound like they're
s...@pobox.com wrote:
Georg Let's remove the cruft, and only keep interesting info. This
Georg will also make the file much more manageable.
If I was to do this from scratch I'd think hard about annotating the source
code. No matter how hard you try, if you keep this information
Le vendredi 6 mai 2011, Mark Shannon ma...@dcs.gla.ac.uk a écrit :
What about #defining PY_STOLEN in some header?
Then any stolen parameter can be prefixed with PY_STOLEN in signature.
For return values, similarly #define PY_BORROWED.
Header files are harder to parse, and I don't see how it
On Fri, 06 May 2011 13:28:11 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Amaury Forgeot d'Arc wrote [concerning the Doc/data/refcounts.dat file]:
This is not always true, for example when the item is already present
in the dict.
It's not important to know what the function does
Antoine Pitrou wrote:
On Fri, 06 May 2011 13:28:11 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Amaury Forgeot d'Arc wrote [concerning the Doc/data/refcounts.dat file]:
This is not always true, for example when the item is already present
in the dict.
It's not important to know what
On 06.05.2011 10:18, Amaury Forgeot d'Arc wrote:
Le vendredi 6 mai 2011, Mark Shannon ma...@dcs.gla.ac.uk a écrit :
What about #defining PY_STOLEN in some header?
Then any stolen parameter can be prefixed with PY_STOLEN in signature.
For return values, similarly #define PY_BORROWED.
On 06.05.2011 12:27, Antoine Pitrou wrote:
On Fri, 06 May 2011 13:28:11 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Amaury Forgeot d'Arc wrote [concerning the Doc/data/refcounts.dat file]:
This is not always true, for example when the item is already present
in the dict.
It's
Hi,
Le jeudi 5 mai 2011, Greg Ewing greg.ew...@canterbury.ac.nz a écrit :
Amaury Forgeot d'Arc wrote:
It's in the file Doc/data/refcounts.dat
in some custom format.
However, it doesn't seem to quite convey the same information.
It lists the refcount effect on each parameter, but
On Thu, May 5, 2011 at 3:38 AM, Amaury Forgeot d'Arc amaur...@gmail.com wrote:
Hi,
Le jeudi 5 mai 2011, Greg Ewing greg.ew...@canterbury.ac.nz a écrit :
Amaury Forgeot d'Arc wrote:
It's in the file Doc/data/refcounts.dat
in some custom format.
However, it doesn't seem to quite convey
2011/5/5 Guido van Rossum gu...@python.org:
Seems you're in agreement with this. IMO when references are borrowed
it is not very interesting. The interesting thing is when calling a
function *steals* a reference. The other important thing to know is
whether the caller ends up owning the return
On Thu, May 5, 2011 at 10:17 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2011/5/5 Guido van Rossum gu...@python.org:
Seems you're in agreement with this. IMO when references are borrowed
it is not very interesting. The interesting thing is when calling a
function *steals* a reference.
On 05.05.2011 19:00, Guido van Rossum wrote:
On Thu, May 5, 2011 at 3:38 AM, Amaury Forgeot d'Arc amaur...@gmail.com
wrote:
Hi,
Le jeudi 5 mai 2011, Greg Ewing greg.ew...@canterbury.ac.nz a écrit :
Amaury Forgeot d'Arc wrote:
It's in the file Doc/data/refcounts.dat
in some custom
On Thu, 5 May 2011 19:17:30 +0200
Amaury Forgeot d'Arc amaur...@gmail.com wrote:
2011/5/5 Guido van Rossum gu...@python.org:
Seems you're in agreement with this. IMO when references are borrowed
it is not very interesting. The interesting thing is when calling a
function *steals* a
On May 5, 2011, at 10:18 AM, Guido van Rossum wrote:
On Thu, May 5, 2011 at 10:17 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2011/5/5 Guido van Rossum gu...@python.org:
Seems you're in agreement with this. IMO when references are borrowed
it is not very interesting. The interesting
On 05.05.2011 19:17, Amaury Forgeot d'Arc wrote:
2011/5/5 Guido van Rossum gu...@python.org:
Seems you're in agreement with this. IMO when references are borrowed
it is not very interesting. The interesting thing is when calling a
function *steals* a reference. The other important thing to
Amaury Forgeot d'Arc wrote [concerning the Doc/data/refcounts.dat file]:
This is not always true, for example when the item is already present
in the dict.
It's not important to know what the function does to the object,
Only the action on the reference is relevant.
Yes, that's the whole
Georg Let's remove the cruft, and only keep interesting info. This
Georg will also make the file much more manageable.
If I was to do this from scratch I'd think hard about annotating the source
code. No matter how hard you try, if you keep this information separate
from the code and
Hi,
The online documentation specifies which API function borrow and/or
steal references (as opposed to the default behaviour).
Yet, I cannot find this information anywhere in the source.
Any clues as to where I should look?
Cheers,
Mark
___
Hi,
Le mercredi 4 mai 2011, Mark Shannon ma...@dcs.gla.ac.uk a écrit :
The online documentation specifies which API function borrow and/or steal
references (as opposed to the default behaviour).
Yet, I cannot find this information anywhere in the source.
Any clues as to where I should look?
Mark Shannon wrote:
The online documentation specifies which API function borrow and/or
steal references (as opposed to the default behaviour).
Yet, I cannot find this information anywhere in the source.
There are comments in some places, e.g. in listobject.h:
*** WARNING ***
Amaury Forgeot d'Arc wrote:
It's in the file Doc/data/refcounts.dat
in some custom format.
However, it doesn't seem to quite convey the same information.
It lists the refcount effect on each parameter, but translating
that into the notion of borrowed or stolen references seems
to require
26 matches
Mail list logo
