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 Thu, Sep 17, 2020 at 8:33 PM Alexis Masson mailto:a.masson555@ntymail.com> wrote:

...

On Fri, Sep 18, 2020 at 2:13 AM Alexis Masson mailto:a.masson555@ntymail.com 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 situation where locals() is globals(). So what you're suggesting would work fine in the REPL but not in any production usage.

ChrisA

That surprises me. I put a quick test to check :

...

def f() :     print(locals())     locals().update(dict(a=3))     print(locals())

f()

prints :

...

================= RESTART: ****/test.py ================ {} {'a': 3} >>>

So maybe the specs don't force it, but under the current implementation, it seems to work.

No it doesn't, try `print(a)`.

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}")

 This has the same problem for the same underlying reasons, it won't work in a function either.

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 dynamically generate enum members.

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().

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.

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.

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