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.



Le 17/09/2020 à 20:38, Alex Hall a écrit :

On Thu, Sep 17, 2020 at 8:33 PM Alexis Masson <a.masson555@ntymail.com> wrote:

On Fri, Sep 18, 2020 at 2:13 AM Alexis Masson <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.

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

def 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.