Re: Python-ideas Digest, Vol 166, Issue 76
I agree that it's bad practice anyway; a correct solution to the original question might surely involve something akin to :for key, value in parsed.items() :
for key, value in parsed.items() :
exec(f"{key} = {value}")
I like the idea of needing to format a string in the process of parsing another ;) Anyway, back on topic !
OK, I admit defeat, you're indeed right. I thought it worked, but it doesn't; well, I've learned something today, thank you for that ! However, I stand firm on my original idea (just the same as what Brendan Barnwell wrote earlier) : I still think returning a dict is the best way to implement the proposed feature, among others because potentially popping a bunch of variables in the local namespace is clumsy, if not dangerous. As for making it a str method, I feel like what we're doing is the same kind of interaction between strings as in str.split, and should therefore be treated the same way. Regards, Alexis Le 17/09/2020 à 20:38, Alex Hall a écrit :
On Fri, Sep 18, 2020 at 4:32 AM Alexis Masson <a.masson555@ntymail.com> wrote:
It isn't supported, which means that sometimes it'll appear to work, but you can't depend on it. For instance:
The only time you can safely mutate locals() is when you're at top level and it's the same as globals(). Plus, assignment might not even affect locals(), and it'd be extremely weird if your parse operation couldn't assign to something declared global :) ChrisA
On Thu, Sep 17, 2020 at 8:49 PM Chris Angelico <rosuav@gmail.com> 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 dynamically generate enum members.
On Fri, Sep 18, 2020 at 4:55 AM Alex Hall <alex.mojaki@gmail.com> wrote:
Hmm. I'm not actually sure there, but my belief is that it still isn't guaranteed - it just happens to work in current versions of CPython. locals() Return a dictionary containing the current scope's local variables. NOTE: Whether or not updates to this dictionary will affect name lookups in the local scope and vice-versa is *implementation dependent* and not covered by any backwards compatibility guarantees. ChrisA
On Thu, 17 Sep 2020 at 20:07, Chris Angelico <rosuav@gmail.com> wrote:
Correct, it's not guaranteed behaviour. "It seems to work" is as good as you'll get. PEP 558 (not yet accepted) proposes to standardise the behaviour. See the PEP for more detail. Paul
OK, I admit defeat, you're indeed right. I thought it worked, but it doesn't; well, I've learned something today, thank you for that ! However, I stand firm on my original idea (just the same as what Brendan Barnwell wrote earlier) : I still think returning a dict is the best way to implement the proposed feature, among others because potentially popping a bunch of variables in the local namespace is clumsy, if not dangerous. As for making it a str method, I feel like what we're doing is the same kind of interaction between strings as in str.split, and should therefore be treated the same way. Regards, Alexis Le 17/09/2020 à 20:38, Alex Hall a écrit :
On Fri, Sep 18, 2020 at 4:32 AM Alexis Masson <a.masson555@ntymail.com> wrote:
It isn't supported, which means that sometimes it'll appear to work, but you can't depend on it. For instance:
The only time you can safely mutate locals() is when you're at top level and it's the same as globals(). Plus, assignment might not even affect locals(), and it'd be extremely weird if your parse operation couldn't assign to something declared global :) ChrisA
On Thu, Sep 17, 2020 at 8:49 PM Chris Angelico <rosuav@gmail.com> 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 dynamically generate enum members.
On Fri, Sep 18, 2020 at 4:55 AM Alex Hall <alex.mojaki@gmail.com> wrote:
Hmm. I'm not actually sure there, but my belief is that it still isn't guaranteed - it just happens to work in current versions of CPython. locals() Return a dictionary containing the current scope's local variables. NOTE: Whether or not updates to this dictionary will affect name lookups in the local scope and vice-versa is *implementation dependent* and not covered by any backwards compatibility guarantees. ChrisA
On Thu, 17 Sep 2020 at 20:07, Chris Angelico <rosuav@gmail.com> wrote:
Correct, it's not guaranteed behaviour. "It seems to work" is as good as you'll get. PEP 558 (not yet accepted) proposes to standardise the behaviour. See the PEP for more detail. Paul
participants (4)
-
Alex Hall -
Alexis Masson -
Chris Angelico -
Paul Moore