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
> +pickle
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
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,
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 i
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?
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
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 gat
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.
>
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 n
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_RE
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 f
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
> unexp
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. T
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
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;
>
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
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.
> I
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 ma
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 :
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
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 al
21 matches
Mail list logo
