On Tue, May 10, 2011 at 11:53 AM, Marvin Humphrey
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
> a refcount
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 t
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
>>
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 cor
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" o
On Fri, May 6, 2011 at 8:27 PM, Antoine Pitrou wrote:
> On Fri, 06 May 2011 13:28:11 +1200
> Greg Ewing 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 no
On 06.05.2011 12:27, Antoine Pitrou wrote:
> On Fri, 06 May 2011 13:28:11 +1200
> Greg Ewing 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 importan
On 06.05.2011 10:18, Amaury Forgeot d'Arc wrote:
> Le vendredi 6 mai 2011, Mark Shannon 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
Antoine Pitrou wrote:
On Fri, 06 May 2011 13:28:11 +1200
Greg Ewing 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 to the obje
On Fri, 06 May 2011 13:28:11 +1200
Greg Ewing 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 to the object,
> > On
Le vendredi 6 mai 2011, Mark Shannon 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 would apply to
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 sepa
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
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 point
On 05.05.2011 19:17, Amaury Forgeot d'Arc wrote:
> 2011/5/5 Guido van Rossum :
>> 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
>> wh
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
> wrote:
>> 2011/5/5 Guido van Rossum :
>>> Seems you're in agreement with this. IMO when references are borrowed
>>> it is not very interesting. The interesting thing is when calling a
>
On Thu, 5 May 2011 19:17:30 +0200
"Amaury Forgeot d'Arc" wrote:
> 2011/5/5 Guido van Rossum :
> > 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 th
On 05.05.2011 19:00, Guido van Rossum wrote:
> On Thu, May 5, 2011 at 3:38 AM, Amaury Forgeot d'Arc
> wrote:
>> Hi,
>>
>> Le jeudi 5 mai 2011, Greg Ewing a écrit :
>>> Amaury Forgeot d'Arc wrote:
>>>
>>>
>>> It's in the file Doc/data/refcounts.dat
>>> in some custom format.
>>>
>>>
>>> However,
On Thu, May 5, 2011 at 10:17 AM, Amaury Forgeot d'Arc
wrote:
> 2011/5/5 Guido van Rossum :
>> 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
2011/5/5 Guido van Rossum :
> 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 value (if it
On Thu, May 5, 2011 at 3:38 AM, Amaury Forgeot d'Arc wrote:
> Hi,
>
> Le jeudi 5 mai 2011, Greg Ewing 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 l
Hi,
Le jeudi 5 mai 2011, Greg Ewing 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 translating
> that into t
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 kno
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 *** PyList_SetIte
Hi,
Le mercredi 4 mai 2011, Mark Shannon 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?
It's in the f
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
___
Python-
26 matches
Mail list logo
