Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-03-18 Thread Nick Coghlan
On 19 Mar 2014 07:34, "MRAB"  wrote:
> FWIW, I haven't been following the discussion,

Note that this about correctness, not just clarity - using DECREF on member
attributes is not safe, as you may end up exposing a partially destroyed
object to other code.

> but, after a (very)
> quick look, to me:
>
> Py_XDECREF(ptr);
> ptr = NULL;
>
> would be clearer as:
>
> Py_CLEAR_REF(ptr);

Already exists as Py_CLEAR (with the correct temp variable usage).

> and:
>
>  Py_XDECREF(ptr);
>  ptr = new_value;
>
> would be clearer as:
>
> Py_REPLACE_REF(ptr, new_value);

That is indeed the one we're aiming to find a suitable name for.

Cheers,
Nick.

>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-03-18 Thread MRAB

On 2014-03-18 21:06, Nick Coghlan wrote:


On 19 Mar 2014 05:10, "Larry Hastings" mailto:la...@hastings.org>> wrote:
 >
 > On 03/18/2014 12:05 PM, Georg Brandl wrote:
 >>
 >> Am 18.03.2014 19:29, schrieb Serhiy Storchaka:
 >>>
 >>> 26.02.14 11:40, Serhiy Storchaka написав(ла):
 
  Let's choose the least confusing names.
 
  See discussions at:
 
  http://bugs.python.org/issue3081
  http://bugs.python.org/issue16447
  http://bugs.python.org/issue20440
  http://comments.gmane.org/gmane.comp.python.devel/145346
 
 >>>
 >>> Poll results:
 >>>
 >>> Py_(X)SETREF:  +3  (Antoine, Kristján, Nick)
 >>
 >> Well, now that I know that -1 are counted, -1 to this.
 >
 >
 > Me too, -1 to Py_SETREF / Py_XSETREF.

I think we're going to have to resort to BDFL appeal on this one -
consensus seems unlikely at this point.


FWIW, I haven't been following the discussion, but, after a (very)
quick look, to me:

Py_XDECREF(ptr);
ptr = NULL;

would be clearer as:

Py_CLEAR_REF(ptr);

and:

 Py_XDECREF(ptr);
 ptr = new_value;

would be clearer as:

Py_REPLACE_REF(ptr, new_value);

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-03-18 Thread Serhiy Storchaka

26.02.14 11:40, Serhiy Storchaka написав(ла):

Let's choose the least confusing names.

See discussions at:

http://bugs.python.org/issue3081
http://bugs.python.org/issue16447
http://bugs.python.org/issue20440
http://comments.gmane.org/gmane.comp.python.devel/145346



Updated poll results. There are two leaders:

Py_(X)SETREF (originally proposed by Antoine in issue3081):
+4 (Antoine, Kristján, Nick, Barry) -2 (Georg, Larry)

Py_(X)DECREC_REPLACE (originally proposed by Victor in issue16447):
+3 (Ryan, Georg, Larry) -2 (Antoine, Kristján)


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-03-18 Thread Nick Coghlan
On 19 Mar 2014 05:10, "Larry Hastings"  wrote:
>
> On 03/18/2014 12:05 PM, Georg Brandl wrote:
>>
>> Am 18.03.2014 19:29, schrieb Serhiy Storchaka:
>>>
>>> 26.02.14 11:40, Serhiy Storchaka написав(ла):

 Let's choose the least confusing names.

 See discussions at:

 http://bugs.python.org/issue3081
 http://bugs.python.org/issue16447
 http://bugs.python.org/issue20440
 http://comments.gmane.org/gmane.comp.python.devel/145346

>>>
>>> Poll results:
>>>
>>> Py_(X)SETREF:  +3  (Antoine, Kristján, Nick)
>>
>> Well, now that I know that -1 are counted, -1 to this.
>
>
> Me too, -1 to Py_SETREF / Py_XSETREF.

I think we're going to have to resort to BDFL appeal on this one -
consensus seems unlikely at this point.

Cheers,
Nick.

>
>
> /arry
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-03-18 Thread Larry Hastings

On 03/18/2014 12:05 PM, Georg Brandl wrote:

Am 18.03.2014 19:29, schrieb Serhiy Storchaka:

26.02.14 11:40, Serhiy Storchaka написав(ла):

Let's choose the least confusing names.

See discussions at:

http://bugs.python.org/issue3081
http://bugs.python.org/issue16447
http://bugs.python.org/issue20440
http://comments.gmane.org/gmane.comp.python.devel/145346


Poll results:

Py_(X)SETREF:  +3  (Antoine, Kristján, Nick)

Well, now that I know that -1 are counted, -1 to this.


Me too, -1 to Py_SETREF / Py_XSETREF.


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-03-18 Thread Georg Brandl
Am 18.03.2014 19:29, schrieb Serhiy Storchaka:
> 26.02.14 11:40, Serhiy Storchaka написав(ла):
>> Let's choose the least confusing names.
>>
>> See discussions at:
>>
>> http://bugs.python.org/issue3081
>> http://bugs.python.org/issue16447
>> http://bugs.python.org/issue20440
>> http://comments.gmane.org/gmane.comp.python.devel/145346
>>
> 
> Poll results:
> 
> Py_(X)SETREF:  +3  (Antoine, Kristján, Nick)

Well, now that I know that -1 are counted, -1 to this.

> Py_(X)DECREC_REPLACE:+3 (Ryan, Georg, Larry) -2 (Antoine, Kristján)
> 
> Py_(X)ASSIGN, Py_REF_ASSIGN, Py_(X)REPLACE, Py_(X)STORE, 
> Py_SET_AND_(X)DECREF, Py_(X)DECREF_AND_ASSIGN, Py_ASSIGN_AND_(X)DECREF: 
> -1 (Antoine or Kristján)
> 
> Py_CLEAR_AND_SET:  -2 (Antoine, Kristján)

Georg


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-03-18 Thread Barry Warsaw
On Mar 18, 2014, at 08:29 PM, Serhiy Storchaka wrote:

>Poll results:
>
>Py_(X)SETREF:  +3  (Antoine, Kristján, Nick)

+1

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-03-18 Thread Serhiy Storchaka

26.02.14 11:40, Serhiy Storchaka написав(ла):

Let's choose the least confusing names.

See discussions at:

http://bugs.python.org/issue3081
http://bugs.python.org/issue16447
http://bugs.python.org/issue20440
http://comments.gmane.org/gmane.comp.python.devel/145346



Poll results:

Py_(X)SETREF:  +3  (Antoine, Kristján, Nick)

Py_(X)DECREC_REPLACE:+3 (Ryan, Georg, Larry) -2 (Antoine, Kristján)

Py_(X)ASSIGN, Py_REF_ASSIGN, Py_(X)REPLACE, Py_(X)STORE, 
Py_SET_AND_(X)DECREF, Py_(X)DECREF_AND_ASSIGN, Py_ASSIGN_AND_(X)DECREF: 
-1 (Antoine or Kristján)


Py_CLEAR_AND_SET:  -2 (Antoine, Kristján)


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-28 Thread emm . odeke


Sent from my BlackBerry 10 smartphone on the Koodo network.
  Original Message  
From: Barry Warsaw
Sent: Friday, February 28, 2014 3:50 PM
To: python-dev@python.org
Subject: Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

On Mar 01, 2014, at 08:15 AM, Nick Coghlan wrote:

>It *is* playing refcounting games - it's decrefing the existing target
>while stealing a reference to the new target, just like the existing
>SET_ITEM macros and somewhat like Py_CLEAR (although in that case, it's
>more obvious that we will never incref NULL).

Okay, but "setting the reference" isn't one of them, which is what I read when
I see Py_SETREF. ;)

>The whole point of this macro is to take an *existing* reference and safely
>*overwrite* another existing reference, exactly as the SET_ITEM macros do.
>
>That actually gives me an idea that wasn't on Serhiy's original list:
>Py_SET_ATTR(target, value).

That does seem better.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-28 Thread Barry Warsaw
On Mar 01, 2014, at 08:15 AM, Nick Coghlan wrote:

>It *is* playing refcounting games - it's decrefing the existing target
>while stealing a reference to the new target, just like the existing
>SET_ITEM macros and somewhat like Py_CLEAR (although in that case, it's
>more obvious that we will never incref NULL).

Okay, but "setting the reference" isn't one of them, which is what I read when
I see Py_SETREF. ;)

>The whole point of this macro is to take an *existing* reference and safely
>*overwrite* another existing reference, exactly as the SET_ITEM macros do.
>
>That actually gives me an idea that wasn't on Serhiy's original list:
>Py_SET_ATTR(target, value).

That does seem better.
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-28 Thread Nick Coghlan
On 1 Mar 2014 01:22, "Barry Warsaw"  wrote:
>
> On Feb 28, 2014, at 10:27 PM, Nick Coghlan wrote:
>
> >With the new macro in place, the existing Py_CLEAR(x) macro would be
> >equivalent to Py_SETREF(x, NULL).
> >
> >Originally I was also concerned about the "how will people know there's
no
> >implicit incref?", but I've since become satisfied with the fact that the
> >precedent set by the reference stealing SET_ITEM macros is strong enough
to
> >justify the shorter name.
>
> I haven't had time to follow this discussion at all, but for a macro to be
> called Py_SETREF and *not* increment the reference counter seems at best
> confusing.  Despite my hesitation to paint a bike shed I haven't had time
to
> inspect, something more akin to Py_SET_POINTER seems more appropriate
> (i.e. don't put "REF" in the name if it isn't playing refcounting games).

It *is* playing refcounting games - it's decrefing the existing target
while stealing a reference to the new target, just like the existing
SET_ITEM macros and somewhat like Py_CLEAR (although in that case, it's
more obvious that we will never incref NULL).

The whole point of this macro is to take an *existing* reference and safely
*overwrite* another existing reference, exactly as the SET_ITEM macros do.

That actually gives me an idea that wasn't on Serhiy's original list:
Py_SET_ATTR(target, value).

After all, setting attributes safely from C is the main use case for this,
and I think it strengthens the parallel with the SET_ITEM macros on the
concrete types.

Cheers,
Nick.

>
> -Barry
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-28 Thread Barry Warsaw
On Feb 28, 2014, at 10:27 PM, Nick Coghlan wrote:

>With the new macro in place, the existing Py_CLEAR(x) macro would be
>equivalent to Py_SETREF(x, NULL).
>
>Originally I was also concerned about the "how will people know there's no
>implicit incref?", but I've since become satisfied with the fact that the
>precedent set by the reference stealing SET_ITEM macros is strong enough to
>justify the shorter name.

I haven't had time to follow this discussion at all, but for a macro to be
called Py_SETREF and *not* increment the reference counter seems at best
confusing.  Despite my hesitation to paint a bike shed I haven't had time to
inspect, something more akin to Py_SET_POINTER seems more appropriate
(i.e. don't put "REF" in the name if it isn't playing refcounting games).

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-28 Thread Kristján Valur Jónsson
+1
Also, for the equivalence to hold there is no separate Py_XSETREF, the X 
behaviour is implied, which I favour.  Enough of this X-proliferation already!
But also see the discussion on inlines.  It would be great to make this an 
inline rather than a macro.
K

From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org] 
On Behalf Of Nick Coghlan
Sent: 28. febrúar 2014 12:27
To: Larry Hastings
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

For additional context, the idea itself is necessary for the same reason 
Py_CLEAR was added: to help ensure that an object's state is never pointing at 
another object that is in the process of being deleted. The difference is that 
Py_CLEAR only allows setting the pointer to NULL, while the point of the new 
macro is to set it to an arbitrary existing point. There is no implicit incref 
as that isn't needed for correctness (you can do the incref before the pointer 
replacement, and often the reference count will already be correct without an 
explicit incref anyway).

With the new macro in place, the existing Py_CLEAR(x) macro would be equivalent 
to Py_SETREF(x, NULL).

Originally I was also concerned about the "how will people know there's no 
implicit incref?", but I've since become satisfied with the fact that the 
precedent set by the reference stealing SET_ITEM macros is strong enough to 
justify the shorter name.

Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-28 Thread Nick Coghlan
On 28 Feb 2014 19:05, "Larry Hastings"  wrote:
>
> On 02/26/2014 11:13 PM, Georg Brandl wrote:
>>
>> Am 26.02.2014 17:09, schrieb Ryan Gonzalez:
>>>
>>> I like Py_DECREF_REPLACE. It gives the impression that it decrefs the
original
>>> and replaces it.
>>
>> Agreed, most other suggestions are not really explicit enough.
>
>
> +1 from me too.  When I saw Py_SETREF I thought, oh, it sets the thing
and increfs it.
>
> FWIW this vote is just on the name.  I haven't stared at the whole
Py_REPLACE idea enough to have an opinion about whether or not to use it.
But if we use it I'm +1 on Py_DECREF_REPLACE.

For additional context, the idea itself is necessary for the same reason
Py_CLEAR was added: to help ensure that an object's state is never pointing
at another object that is in the process of being deleted. The difference
is that Py_CLEAR only allows setting the pointer to NULL, while the point
of the new macro is to set it to an arbitrary existing point. There is no
implicit incref as that isn't needed for correctness (you can do the incref
before the pointer replacement, and often the reference count will already
be correct without an explicit incref anyway).

With the new macro in place, the existing Py_CLEAR(x) macro would be
equivalent to Py_SETREF(x, NULL).

Originally I was also concerned about the "how will people know there's no
implicit incref?", but I've since become satisfied with the fact that the
precedent set by the reference stealing SET_ITEM macros is strong enough to
justify the shorter name.

Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-28 Thread Larry Hastings

On 02/26/2014 11:13 PM, Georg Brandl wrote:

Am 26.02.2014 17:09, schrieb Ryan Gonzalez:

I like Py_DECREF_REPLACE. It gives the impression that it decrefs the original
and replaces it.

Agreed, most other suggestions are not really explicit enough.


+1 from me too.  When I saw Py_SETREF I thought, oh, it sets the thing 
and increfs it.


FWIW this vote is just on the name.  I haven't stared at the whole 
Py_REPLACE idea enough to have an opinion about whether or not to use 
it.  But if we use it I'm +1 on Py_DECREF_REPLACE.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-27 Thread Kristján Valur Jónsson
I agree with NICK.  having REF in it is a good idea.
So, I'm +1 on setref.
Having long explicit macros with exact semantics in the name is a bad one.
so I'm -1 on any Py_DECREF_AND_REPLACE or similar daschhunds.

Also, is there any real requirement for having separate non-X versions of these?
The Xs constitue a permutation explosion, particularly if you want then also 
versions that INCREF the source :)
K

From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org] 
On Behalf Of Nick Coghlan
Sent: 27. febrúar 2014 00:12
To: Antoine Pitrou
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc


On 27 Feb 2014 04:28, "Antoine Pitrou" 
mailto:solip...@pitrou.net>> wrote:
>
> On Wed, 26 Feb 2014 11:40:01 +0200
> Serhiy Storchaka mailto:storch...@gmail.com>> wrote:
>
> > There were several suggestions for naming new macros which replace old
> > value with new value and then (x)decref old value.
> >
> > #define Py_XXX(ptr, value)\
> >  { \
> >  PyObject *__tmp__ = ptr;  \
> >  ptr = new_value;  \
> >  Py_DECREF(__tmp__);   \
> >  }
>
>
> > 1. Py_(X)SETREF.
>
> My vote is on this one.
> I'm also -1 on any name which doesn't have "REF" in it; the name should
> clearly suggest that it's a refcounting operation.

Yeah, I think SETREF is my favourite as well (even though some of the later 
suggestions were mine).

Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org<mailto:Python-Dev@python.org>
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-26 Thread Georg Brandl
Am 26.02.2014 17:09, schrieb Ryan Gonzalez:
> I like Py_DECREF_REPLACE. It gives the impression that it decrefs the original
> and replaces it.

Agreed, most other suggestions are not really explicit enough.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-26 Thread Nick Coghlan
On 27 Feb 2014 04:28, "Antoine Pitrou"  wrote:
>
> On Wed, 26 Feb 2014 11:40:01 +0200
> Serhiy Storchaka  wrote:
>
> > There were several suggestions for naming new macros which replace old
> > value with new value and then (x)decref old value.
> >
> > #define Py_XXX(ptr, value)\
> >  { \
> >  PyObject *__tmp__ = ptr;  \
> >  ptr = new_value;  \
> >  Py_DECREF(__tmp__);   \
> >  }
>
>
> > 1. Py_(X)SETREF.
>
> My vote is on this one.
> I'm also -1 on any name which doesn't have "REF" in it; the name should
> clearly suggest that it's a refcounting operation.

Yeah, I think SETREF is my favourite as well (even though some of the later
suggestions were mine).

Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-26 Thread Antoine Pitrou
On Wed, 26 Feb 2014 11:40:01 +0200
Serhiy Storchaka  wrote:

> There were several suggestions for naming new macros which replace old 
> value with new value and then (x)decref old value.
> 
> #define Py_XXX(ptr, value)\
>  { \
>  PyObject *__tmp__ = ptr;  \
>  ptr = new_value;  \
>  Py_DECREF(__tmp__);   \
>  }


> 1. Py_(X)SETREF.

My vote is on this one.
I'm also -1 on any name which doesn't have "REF" in it; the name should
clearly suggest that it's a refcounting operation.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Poll: Py_REPLACE/Py_ASSIGN/etc

2014-02-26 Thread Ryan Gonzalez
I like Py_DECREF_REPLACE. It gives the impression that it decrefs the
original and replaces it.


On Wed, Feb 26, 2014 at 3:40 AM, Serhiy Storchaka wrote:

> There were several suggestions for naming new macros which replace old
> value with new value and then (x)decref old value.
>
> #define Py_XXX(ptr, value)\
> { \
> PyObject *__tmp__ = ptr;  \
> ptr = new_value;  \
> Py_DECREF(__tmp__);   \
> }
>
> Listed in order of receipt:
>
> 1. Py_(X)SETREF.
> 2. Py_(X)ASSIGN.
> 3. Py_(X)DECREC_REPLACE.
> 4. Py_REF_ASSIGN (Py_XREF_ASSIGN? Py_REF_XASSIGN?).
> 5. Py_(X)REPLACE.
> 6. Py_(X)STORE
> 7. Py_CLEAR_AND_SET.
> 8. Py_SET_AND_(X)DECREF.
> 9. Py_(X)DECREF_AND_ASSIGN.
> 10. Py_ASSIGN_AND_(X)DECREF.
> 11. Other...
>
> Let's choose the least confusing names.
>
> See discussions at:
>
> http://bugs.python.org/issue3081
> http://bugs.python.org/issue16447
> http://bugs.python.org/issue20440
> http://comments.gmane.org/gmane.comp.python.devel/145346
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com