On Thu, 17 Sep 2020 at 20:07, Chris Angelico wrote:
>
> On Fri, Sep 18, 2020 at 4:55 AM Alex Hall wrote:
> >
> > On Thu, Sep 17, 2020 at 8:49 PM Chris Angelico wrote:
> >>
> >> The only time you can safely mutate locals() is when you're at top
> >> level and it's the same as globals().
> >
> >
>
On Fri, Sep 18, 2020 at 4:55 AM Alex Hall wrote:
>
> On Thu, Sep 17, 2020 at 8:49 PM Chris Angelico wrote:
>>
>> The only time you can safely mutate locals() is when you're at top
>> level and it's the same as globals().
>
>
> It's safe in class definitions, right? At least in CPython it seems to
On Thu, Sep 17, 2020 at 8:49 PM Chris Angelico wrote:
> The only time you can safely mutate locals() is when you're at top
> level and it's the same as globals().
>
It's safe in class definitions, right? At least in CPython it seems to
work. I've done that a few times, most recently to dynamical
On Fri, Sep 18, 2020 at 4:32 AM Alexis Masson wrote:
>
> On Fri, Sep 18, 2020 at 2:13 AM Alexis Masson wrote:
>
> This, in addition with locals().update(_), feels much better to me.
> Furthermore, it would allow other string-like classes, such as bytes or
> bytearray, to use that feature.
>
> B
On Fri, Sep 18, 2020 at 2:13 AM Alexis Masson wrote:
This, in addition with locals().update(_), feels much better to me.
Furthermore, it would allow other string-like classes, such as bytes or
bytearray, to use that feature.
But locals().update() isn't a supported operation, except in the
si
