On 22. 07. 21 15:03, Ethan Furman wrote:
On 7/22/21 1:01 AM, Petr Viktorin wrote:
> On 21. 07. 21 14:18, Nick Coghlan wrote:
>>
>> typedef enum {
>> PyLocals_UNDEFINED = -1;
>> PyLocals_DIRECT_REFERENCE = 0,
>> PyLocals_SHALLOW_COPY = 1
>> } PyLocals_
On 7/22/21 1:01 AM, Petr Viktorin wrote:
> On 21. 07. 21 14:18, Nick Coghlan wrote:
>>
>> typedef enum {
>> PyLocals_UNDEFINED = -1;
>> PyLocals_DIRECT_REFERENCE = 0,
>> PyLocals_SHALLOW_COPY = 1
>> } PyLocals_Kind;
>>
>> PyLocals_Kind PyLocals_GetKind(void);
>
On Thu, 22 Jul 2021, 6:01 pm Petr Viktorin, wrote:
>
>
> On 21. 07. 21 14:18, Nick Coghlan wrote:
> > On Mon, 19 Jul 2021 at 21:32, Petr Viktorin wrote:
> >> The proposal assumes that in the future, ``PyLocals_Get``, and thus
> >> ``locals()``, will never gain another kind of return value, howev
On 21. 07. 21 14:18, Nick Coghlan wrote:
On Mon, 19 Jul 2021 at 21:32, Petr Viktorin wrote:
The proposal assumes that in the future, ``PyLocals_Get``, and thus
``locals()``, will never gain another kind of return value, however
unlikely that is.
AFAICS, code that uses this will usually check
Hi Nick - as for:
> Keys that are not defined as local or closure variables on the underlying
frame are still written to the f_locals cache on optimised frames.
This means current behavior will be kept, right? the f_locals cache is
persistent across descending calls
from the current frame?
To be
Sounds good. Thanks!
On Wed, Jul 21, 2021 at 5:19 AM Nick Coghlan wrote:
> On Mon, 19 Jul 2021 at 21:32, Petr Viktorin wrote:
> > The proposal assumes that in the future, ``PyLocals_Get``, and thus
> > ``locals()``, will never gain another kind of return value, however
> > unlikely that is.
> >
On Mon, 19 Jul 2021 at 21:32, Petr Viktorin wrote:
> The proposal assumes that in the future, ``PyLocals_Get``, and thus
> ``locals()``, will never gain another kind of return value, however
> unlikely that is.
> AFAICS, code that uses this will usually check for a single special case
> and fall b
On Wed, 21 Jul 2021, 10:30 am Guido van Rossum, wrote:
> On Tue, Jul 20, 2021 at 4:52 AM Nick Coghlan wrote:
> [Petr]
>
>> >> int PyLocals_GetReturnBehavior(); # better name?
>>
> [Nick]
>
>> > We've used "Kind" for similar APIs elsewhere, so calling this API
>> "PyLocals_Kind()" would make sen
On Tue, Jul 20, 2021 at 4:52 AM Nick Coghlan wrote:
[Petr]
> >> int PyLocals_GetReturnBehavior(); # better name?
>
[Nick]
> > We've used "Kind" for similar APIs elsewhere, so calling this API
> "PyLocals_Kind()" would make sense to me.
> >
> > However, there's a potential point of confusion her
On Mon, 19 Jul 2021 at 22:08, Nick Coghlan wrote:
> On Mon, 19 Jul 2021, 9:32 pm Petr Viktorin, wrote:
>> The proposal assumes that in the future, ``PyLocals_Get``, and thus
>> ``locals()``, will never gain another kind of return value, however
>> unlikely that is.
>> AFAICS, code that uses this
On Mon, 19 Jul 2021, 9:32 pm Petr Viktorin, wrote:
> Thanks, Nick! This looks wonderful.
> I do have a nitpick, below:
>
> On 18. 07. 21 7:59, Nick Coghlan wrote:
> [...]>
> > Changes to the stable C API/ABI
> > ---
> >
> > Unlike Python code, extension module function
Thanks, Nick! This looks wonderful.
I do have a nitpick, below:
On 18. 07. 21 7:59, Nick Coghlan wrote:
[...]>
Changes to the stable C API/ABI
---
Unlike Python code, extension module functions that call in to the Python C API
can be called from any kind of Python sc
Makes sense. Thanks for the clarification!
On Wed, Jan 1, 2020 at 1:30 AM Nick Coghlan wrote:
> On Wed, 1 Jan 2020 at 10:42, Yonatan Zunger wrote:
> >
> > Thanks for writing this up, Nick!
> >
> > My main question is about the remaining difference between semantics at
> the class/module versus
On Wed, 1 Jan 2020 at 10:42, Yonatan Zunger wrote:
>
> Thanks for writing this up, Nick!
>
> My main question is about the remaining difference between semantics at the
> class/module versus function level: is it worth the additional cognitive
> complexity to have the class/module behavior be di
Thanks for writing this up, Nick!
My main question is about the remaining difference between semantics at the
class/module versus function level: is it worth the additional cognitive
complexity to have the class/module behavior be different from the function
behavior?
The "mutable" class/module b
15 matches
Mail list logo
