[Python-Dev] Adding a scarier warning to object.__del__?

2019-12-31 Thread Yonatan Zunger 
Hey everyone,

I just encountered yet another reason to beware of __del__: when it's
called during interpreter shutdown, for reasons which are kind of obvious
in retrospect, if it calls notify() on a threading.Condition, the waiting
thread may or may not ever actually receive it, and so if it does that and
then tries to join() the thread the interpreter may hang in a hard-to-debug
way.

This isn't something that can reasonably be fixed, and (like in most cases
involving __del__) there's a very simple fix of using weakref.finalize
instead. My question for the dev list: How would people feel about changing
the documentation for the method
 to more
bluntly warn people against using it, and refer them to weakref.finalize
and/or atexit.register as an alternative? The text already has an undertone
of "lasciate ogni speranza, voi ch'entrate" but it may be helpful to be
more explicit to avoid people getting caught in unexpected pitfalls.

Yonatan
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/AAZQBWD6PHC4PVNCCPX4A2745SS7B3LS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 558: Defined semantics for locals() (December 2019 edition)

2019-12-31 Thread Yonatan Zunger 
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 behavior is really nice for debuggers, of
course, but when you want that you really want it at *all* scopes, so
having it available only some of the time feels like an unpredictable tool.
I could imagine having a mode where everything (including function scopes)
is required to permit mutability, but that would (a) be a lot of work (as
you pointed out in the design discussion) and (b) would cause "debug mode"
binaries to have to work so differently from "opt mode" ones that debugging
would get harder for other reasons.

I'm not sure that it *isn't* worth it to have this extra flexibility at the
higher scope levels, but it isn't obvious to me that it is, and if that
could lead to some code simplification, I wouldn't be sad!

Yonatan

On Mon, Dec 30, 2019 at 10:47 PM Nick Coghlan  wrote:

> Hi folks,
>
> I've finally updated PEP 558 and it's reference implementation based
> on Nathaniel's feedback back in May.
>
> The latest version of the PEP can now be found at
> https://www.python.org/dev/peps/pep-0558/, and I've created a
> discussion thread on Discourse:
> https://discuss.python.org/t/pep-558-defined-semantics-for-locals/2936
>
> The latest version implements Nathaniel's "independent snapshot"
> proposal, and I like how that has turned out. The one thing that
> changed from the May discussion thread is that the refcount semantics
> of PyEval_GetLocals() (it returns a borrowed reference) meant that it
> had to keep the old behaviour of returning a reference to the internal
> dynamically updated shared "snapshot" at function scope, with a new
> API, PyEval_GetPyLocals(), providing the C equivalent of the locals()
> builtin.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   [email protected]   |   Brisbane, Australia
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/GHN2GYJQRU77EZBXX4SQUZ5XEMEONSFL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/NH2ILSTNK5KGHAXPT7FUPBQSRJBKQKMW/
Code of Conduct: http://python.org/psf/codeofconduct/