Re: [Python-Dev] Packaging in Python 2 anyone ?

2011-08-15 Thread Tarek Ziadé 
On Mon, Aug 15, 2011 at 1:20 AM, Nick Coghlan  wrote:
> On Sun, Aug 14, 2011 at 7:41 PM, Tarek Ziadé  wrote:
>> Hi all,
>>
>> I am lacking of time right now to finish an important task before 3.2
>> final is out:
>
> If anyone else got at all confused by Tarek's email, s/3.x/3.x+1/ and
> it will all make sense (the mentioned release numbers in the 3.x
> series are all one lower than they should be - packaging is planned
> for 3.3, but a standalone library will allow feedback to be gathered
> from 2.x and 3.2 users before the API is 'locked in' for 3.3).

Oh yeah sorry for the version mess up :)

> How far has packaging diverged from distutils2, though? Wasn't that
> the planned venue for any backports in order to avoid name conflicts?

The plan is to provide under earlier versions of Python a standalone
project that does not use the "packaging" namespace, but the
"distutils2" namespace.

IOW, the task to do is:

1/ copy packaging and all its stdlib dependencies in a standalone project
2/ rename packaging to distutils2
3/ make it work under older 2.x and 3.x (2.x would be the priority)  <
4/ release it, promote its usage
5/ consolidate the API with the feedback received

I realize it's by far the less interesting task to do in packaging,
but it's by far one of the most important

Cheers
Tarek

-- 
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Antoine Pitrou 
Le lundi 15 août 2011 à 13:16 +1000, Nick Coghlan a écrit :
> On Mon, Aug 15, 2011 at 12:34 PM, Brett Cannon  wrote:
> > On Thu, Aug 11, 2011 at 00:02, Antoine Pitrou  wrote:
> >> It would sound more useful to have a generic Py_RETURN() macro rather than
> >> some specific forms for each and every common object.
> >
> > Since the macro is rather generic, sure, but the name should probably be
> > better since it doesn't necessarily convene the fact that a INCREF has
> > occurred. So maybe Py_INCREF_RETURN()?
> 
> Aside from None and NotImplemented, do we really do the straight
> incref-and-return all that often?

AFAICT, often with True and False:

x = (some condition) ? Py_True : Py_False;
Py_INCREF(x);
return x;

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Nick Coghlan 
On Mon, Aug 15, 2011 at 10:17 PM, Antoine Pitrou  wrote:
> AFAICT, often with True and False:
>
>    x = (some condition) ? Py_True : Py_False;
>    Py_INCREF(x);
>    return x;

And that's an idiom that works better with a Py_RETURN macro than it
would separate macros:

Py_RETURN(cond ? Py_True : Py_False);

OK, I'm persuaded that "Py_RETURN(Py_NotImplemented);" would be a
better way to handle this change: +1

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Raymond Hettinger 

On Aug 15, 2011, at 5:35 AM, Nick Coghlan wrote:

> On Mon, Aug 15, 2011 at 10:17 PM, Antoine Pitrou  wrote:
>> AFAICT, often with True and False:
>> 
>>x = (some condition) ? Py_True : Py_False;
>>Py_INCREF(x);
>>return x;
> 
> And that's an idiom that works better with a Py_RETURN macro than it
> would separate macros:
> 
> Py_RETURN(cond ? Py_True : Py_False);
> 
> OK, I'm persuaded that "Py_RETURN(Py_NotImplemented);" would be a
> better way to handle this change: +1

I don't think that is worth it.
There is some value to keeping the API consistent with the style that has been 
used in the past.
So, I vote for Py_RETURN_NOTIMPLEMENTED.  There's no real need to factor this 
any further.
It's not hard and not important enough to introduce a new variation on return 
macros.
Adding another return style makes the C API harder to learn and remember.
If we we're starting from scratch, Py_RETURN(obj) would make sense.
But we're not starting from scratch, so we should stick with the precedents.


Raymond


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Antoine Pitrou 
On Mon, 15 Aug 2011 05:46:12 -0700
Raymond Hettinger  wrote:
> 
> I don't think that is worth it.
> There is some value to keeping the API consistent with the style that has 
> been used in the past.
> So, I vote for Py_RETURN_NOTIMPLEMENTED.  There's no real need to factor this 
> any further.
> It's not hard and not important enough to introduce a new variation on return 
> macros.

Why is Py_RETURN_NOTIMPLEMENTED important at all?

Regards

Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Stefan Behnel 

Nick Coghlan, 15.08.2011 14:35:

On Mon, Aug 15, 2011 at 10:17 PM, Antoine Pitrou  wrote:

AFAICT, often with True and False:

x = (some condition) ? Py_True : Py_False;
Py_INCREF(x);
return x;


And that's an idiom that works better with a Py_RETURN macro than it
would separate macros:

Py_RETURN(cond ? Py_True : Py_False);


And that would do what exactly? Duplicate the evaluation of the condition?

Stefan

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Antoine Pitrou 
On Mon, 15 Aug 2011 15:21:43 +0200
Stefan Behnel  wrote:

> Nick Coghlan, 15.08.2011 14:35:
> > On Mon, Aug 15, 2011 at 10:17 PM, Antoine Pitrou  
> > wrote:
> >> AFAICT, often with True and False:
> >>
> >> x = (some condition) ? Py_True : Py_False;
> >> Py_INCREF(x);
> >> return x;
> >
> > And that's an idiom that works better with a Py_RETURN macro than it
> > would separate macros:
> >
> > Py_RETURN(cond ? Py_True : Py_False);
> 
> And that would do what exactly? Duplicate the evaluation of the condition?

You don't need to.

#define Py_RETURN (x) do { \
 PyObject *_tmp = (x); \
 Py_INCREF(_tmp);  \
 return _tmp;  \
} while(0)



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Barry Warsaw 
On Aug 15, 2011, at 05:46 AM, Raymond Hettinger wrote:

>I don't think that is worth it.  There is some value to keeping the API
>consistent with the style that has been used in the past.  So, I vote for
>Py_RETURN_NOTIMPLEMENTED.  There's no real need to factor this any further.
>It's not hard and not important enough to introduce a new variation on return
>macros.  Adding another return style makes the C API harder to learn and
>remember.  If we we're starting from scratch, Py_RETURN(obj) would make
>sense.  But we're not starting from scratch, so we should stick with the
>precedents.

I can see the small value in the convenience, but I tend to agree with Raymond
here.  I think we have to be careful about not descending into macro
obfuscation world.

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Antoine Pitrou 
On Mon, 15 Aug 2011 09:49:43 -0400
Barry Warsaw  wrote:
> On Aug 15, 2011, at 05:46 AM, Raymond Hettinger wrote:
> 
> >I don't think that is worth it.  There is some value to keeping the API
> >consistent with the style that has been used in the past.  So, I vote for
> >Py_RETURN_NOTIMPLEMENTED.  There's no real need to factor this any further.
> >It's not hard and not important enough to introduce a new variation on return
> >macros.  Adding another return style makes the C API harder to learn and
> >remember.  If we we're starting from scratch, Py_RETURN(obj) would make
> >sense.  But we're not starting from scratch, so we should stick with the
> >precedents.
> 
> I can see the small value in the convenience, but I tend to agree with Raymond
> here.  I think we have to be careful about not descending into macro
> obfuscation world.

How is Py_RETURN(Py_NotImplemented) more obfuscated than
Py_RETURN_NOTIMPLEMENTED ???


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: Mirroring Python repos to Bitbucket

2011-08-15 Thread Petri Lehtinen 
Doug Hellmann wrote:
> 
> Charles McLaughlin of Atlassian has set up mirrors of the Mercurial
> repositories hosted on python.org as part of the ongoing
> infrastructure improvement work. These mirrors will give us a public
> fail-over repository in the event that hg.python.org goes offline
> unexpectedly, and also provide features such as RSS feeds of changes
> for users interested in monitoring the repository passively.

As a side note, for those preferring git there's also a very
unofficial git mirror at https://github.com/jonashaag/cpython. It uses
hg-git for converting and syncs once a day.

Petri
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Terry Reedy 

On 8/15/2011 9:49 AM, Barry Warsaw wrote:

On Aug 15, 2011, at 05:46 AM, Raymond Hettinger wrote:


I don't think that is worth it.  There is some value to keeping the API
consistent with the style that has been used in the past.  So, I vote for
Py_RETURN_NOTIMPLEMENTED.  There's no real need to factor this any further.
It's not hard and not important enough to introduce a new variation on return
macros.  Adding another return style makes the C API harder to learn and
remember.  If we we're starting from scratch, Py_RETURN(obj) would make
sense.  But we're not starting from scratch, so we should stick with the
precedents.


I can see the small value in the convenience, but I tend to agree with Raymond
here.  I think we have to be careful about not descending into macro
obfuscation world.


Coming fresh to the C-API, as I partly am, I would rather have exactly 1 
generally useful macro that increments the refcount of an object and 
returns it. To me, multiple special-case, seldom-used macros are a 
better example of 'macro obfuscation'.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Alexander Belopolsky 
On Thu, Aug 11, 2011 at 3:02 AM, Antoine Pitrou  wrote:
..
>>   Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.
>
>
> It would sound more useful to have a generic Py_RETURN() macro rather than
> some specific forms for each and every common object.

Just my $0.02: I occasionally wish we had Py_RETURN_BOOL(1/0) instead
of Py_RETURN_TRUE/FALSE, but I feel proposed Py_RETURN() is too
ambiguous and should be called Py_RETURN_SINGLETON() or
Py_RETURN_NEWREF().  Longer spelling, however makes it less
attractive.  Overall, I am -1 on Py_RETURN().  Introducing the second
obvious way to spell Py_RETURN_NONE/TRUE/FALSE will clutter the API
and novices may be misled into always using Py_RETURN(x) instead of
return x attracting reference leaks.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3154 - pickle protocol 4

2011-08-15 Thread Alexandre Vassalotti 
On Fri, Aug 12, 2011 at 3:58 AM, Antoine Pitrou  wrote:

>
> Hello,
>
> This PEP is an attempt to foster a number of small incremental
> improvements in a future pickle protocol version. The PEP process is
> used in order to gather as many improvements as possible, because the
> introduction of a new protocol version should be a rare occurrence.
>
> Feel free to suggest any additions.
>
>
Your propositions sound all good to me. We will need to agree about the
details, but I believe these improvements to the current protocol will be
appreciated.

Also, one thing keeps coming back is the need for pickling functions and
methods which are not part of the global namespace (e.g. issue
9276).
Support for this would likely help us fixing another related namespace issue
(i.e., issue 3657 ). Finally, we
currently missing support for pickling classes with __new__ taking
keyword-only arguments (i.e. issue 4727 ).

-- Alexandre
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Nick Coghlan 
On Mon, Aug 15, 2011 at 11:59 PM, Antoine Pitrou  wrote:
> On Mon, 15 Aug 2011 09:49:43 -0400
> Barry Warsaw  wrote:
>> I can see the small value in the convenience, but I tend to agree with 
>> Raymond
>> here.  I think we have to be careful about not descending into macro
>> obfuscation world.
>
> How is Py_RETURN(Py_NotImplemented) more obfuscated than
> Py_RETURN_NOTIMPLEMENTED ???

Indeed, this entire discussion was started by the extension of the
Py_RETURN_NONE idiom to also adopt Py_RETURN_NOTIMPLEMENTED.

If the idiom is to be extended at all, why stop there? Why not cover
the Py_RETURN_TRUE and Py_RETURN_FALSE cases as well?

Or, we can add exactly one new macro that covers all 3 cases, and
others besides. I haven't encountered any complaints about people
failing to understand the difference between "return Py_None;" and
"Py_RETURN_NONE;" and see no major reason why "return x;" vs
"Py_RETURN(x);" would be significantly more confusing.

Based on this thread, there are actually two options I'd be fine with:
1. Just revert it and leave Py_RETURN_NONE as a special snowflake
2. Properly generalise the incref-and-return idiom via a Py_RETURN macro

Incrementally increasing complexity by adding a second instance of the
dedicated macro approach is precisely what we *shouldn't* be doing.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3154 - pickle protocol 4

2011-08-15 Thread Nick Coghlan 
On Tue, Aug 16, 2011 at 5:56 AM, Alexandre Vassalotti
 wrote:
>
> On Fri, Aug 12, 2011 at 3:58 AM, Antoine Pitrou  wrote:
>>
>> Hello,
>>
>> This PEP is an attempt to foster a number of small incremental
>> improvements in a future pickle protocol version. The PEP process is
>> used in order to gather as many improvements as possible, because the
>> introduction of a new protocol version should be a rare occurrence.
>>
>> Feel free to suggest any additions.
>>
>
> Your propositions sound all good to me. We will need to agree about the
> details, but I believe these improvements to the current protocol will be
> appreciated.
> Also, one thing keeps coming back is the need for pickling functions and
> methods which are not part of the global namespace (e.g. issue 9276).
> Support for this would likely help us fixing another related namespace issue
> (i.e., issue 3657). Finally, we currently missing support for pickling
> classes with __new__ taking keyword-only arguments (i.e. issue 4727).

In the spirit of PEP 395 and python 3's pickle._compat_pickle, perhaps
it would be worth looking at a mechanism whereby a pickle could
specify "alternate class names" for included class instances in the
pickle itself?

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Barry Warsaw 
On Aug 16, 2011, at 08:32 AM, Nick Coghlan wrote:

>Indeed, this entire discussion was started by the extension of the
>Py_RETURN_NONE idiom to also adopt Py_RETURN_NOTIMPLEMENTED.
>
>If the idiom is to be extended at all, why stop there? Why not cover
>the Py_RETURN_TRUE and Py_RETURN_FALSE cases as well?
>
>Or, we can add exactly one new macro that covers all 3 cases, and
>others besides. I haven't encountered any complaints about people
>failing to understand the difference between "return Py_None;" and
>"Py_RETURN_NONE;" and see no major reason why "return x;" vs
>"Py_RETURN(x);" would be significantly more confusing.
>
>Based on this thread, there are actually two options I'd be fine with:
>1. Just revert it and leave Py_RETURN_NONE as a special snowflake
>2. Properly generalise the incref-and-return idiom via a Py_RETURN macro
>
>Incrementally increasing complexity by adding a second instance of the
>dedicated macro approach is precisely what we *shouldn't* be doing.

My problem with Py_RETURN(x) is that it's not clear that it also does an
incref, and without that, I think it's *more* confusing to use rather than
just writing it out explicitly, Py_RETURN_NONE's historic existence
notwithstanding.

So I'd opt for #1, unless we can agree on a better color for the bikeshed.

-Barry
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Guido van Rossum 
On Mon, Aug 15, 2011 at 3:43 PM, Barry Warsaw  wrote:
> On Aug 16, 2011, at 08:32 AM, Nick Coghlan wrote:
>
>>Indeed, this entire discussion was started by the extension of the
>>Py_RETURN_NONE idiom to also adopt Py_RETURN_NOTIMPLEMENTED.
>>
>>If the idiom is to be extended at all, why stop there? Why not cover
>>the Py_RETURN_TRUE and Py_RETURN_FALSE cases as well?
>>
>>Or, we can add exactly one new macro that covers all 3 cases, and
>>others besides. I haven't encountered any complaints about people
>>failing to understand the difference between "return Py_None;" and
>>"Py_RETURN_NONE;" and see no major reason why "return x;" vs
>>"Py_RETURN(x);" would be significantly more confusing.
>>
>>Based on this thread, there are actually two options I'd be fine with:
>>1. Just revert it and leave Py_RETURN_NONE as a special snowflake
>>2. Properly generalise the incref-and-return idiom via a Py_RETURN macro
>>
>>Incrementally increasing complexity by adding a second instance of the
>>dedicated macro approach is precisely what we *shouldn't* be doing.
>
> My problem with Py_RETURN(x) is that it's not clear that it also does an
> incref, and without that, I think it's *more* confusing to use rather than
> just writing it out explicitly, Py_RETURN_NONE's historic existence
> notwithstanding.
>
> So I'd opt for #1, unless we can agree on a better color for the bikeshed.

I dunno; if it *didn't* do an INCREF it would be a pretty pointless
macro (just expanding to "return x") and I like reducing the clutter
of a very common idiom. So I favor #2.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Ethan Furman 

Barry Warsaw wrote:

On Aug 16, 2011, at 08:32 AM, Nick Coghlan wrote:

Based on this thread, there are actually two options I'd be fine with:
1. Just revert it and leave Py_RETURN_NONE as a special snowflake
2. Properly generalise the incref-and-return idiom via a Py_RETURN macro

Incrementally increasing complexity by adding a second instance of the
dedicated macro approach is precisely what we *shouldn't* be doing.


My problem with Py_RETURN(x) is that it's not clear that it also does an
incref, and without that, I think it's *more* confusing to use rather than
just writing it out explicitly, Py_RETURN_NONE's historic existence
notwithstanding.

So I'd opt for #1, unless we can agree on a better color for the bikeshed.


My apologies if this is just noise, but are there RETURN macros that 
don't do an INCREF?


~Ethan~
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Nick Coghlan 
On Tue, Aug 16, 2011 at 9:13 AM, Ethan Furman  wrote:
> Barry Warsaw wrote:
>> So I'd opt for #1, unless we can agree on a better color for the bikeshed.
>
> My apologies if this is just noise, but are there RETURN macros that don't
> do an INCREF?

No, Py_RETURN_NONE is the only previous example, and it was added to
simplify the very common idiom of:

Py_INCREF(Py_None);
return Py_None;

It was added originally because it helped to avoid *two* common bugs:

  return Py_None; # segfault waiting to happen

  return NULL; # Just plain wrong, but not picked up until tests are
run and hence irritating

I'd say NotImplemented is the second most common instance of that kind
of direct incref-and-return (since operator methods need to return it
to correctly support type coercion), although, as Antoine noted,
Py_True and Py_False would be up there as well.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-15 Thread Guido van Rossum 
On Mon, Aug 15, 2011 at 4:39 PM, Nick Coghlan  wrote:
> On Tue, Aug 16, 2011 at 9:13 AM, Ethan Furman  wrote:
>> Barry Warsaw wrote:
>>> So I'd opt for #1, unless we can agree on a better color for the bikeshed.
>>
>> My apologies if this is just noise, but are there RETURN macros that don't
>> do an INCREF?
>
> No, Py_RETURN_NONE is the only previous example, and it was added to
> simplify the very common idiom of:
>
>    Py_INCREF(Py_None);
>    return Py_None;
>
> It was added originally because it helped to avoid *two* common bugs:
>
>  return Py_None; # segfault waiting to happen
>
>  return NULL; # Just plain wrong, but not picked up until tests are
> run and hence irritating
>
> I'd say NotImplemented is the second most common instance of that kind
> of direct incref-and-return (since operator methods need to return it
> to correctly support type coercion), although, as Antoine noted,
> Py_True and Py_False would be up there as well.

I betcha if you extend your search to "return " preceded by
"INCREF(variable)" you'll find a whole lot more examples. :-)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] peps: Add Alexandre's suggestions

2011-08-15 Thread Nick Coghlan 
On Tue, Aug 16, 2011 at 11:30 AM, antoine.pitrou
 wrote:
> +Serializing "pseudo-global" objects
> +---
> +
> +Objects which are not module-global, but should be treated in a similar
> +fashion -- such as methods [4]_ or nested classes -- cannot currently be
> +pickled (or, rather, unpickled) because the pickle protocol does not
> +correctly specify how to retrieve them.  One solution would be through the
> +adjunction of a ``__namespace__`` (or ``__qualname__``) to all class and
> +function objects, specifying the full "path" by which they can be retrieved.
> +For globals, this would generally be ``"{}.{}".format(obj.__module__, 
> obj.__name__)``.
> +Then a new opcode can resolve that path and push the object on the stack,
> +similarly to the GLOBAL opcode.
> +

I think this is the part that ties in with the pickle-related aspects
for PEP 395 - using '__qualname__'  would be one way to align a
module's real name with where it should be retrieved from and where
it's documentation lives (I like 'qualified name' as a term, too).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com