Hello, I'm a bit concerned about https://github.com/python/cpython/commit/76d5abc8684bac4f2fc7cccfe2cd9409233... My main gripe is that makes writing C code more tedious. Simple C global variables such as "_once_registry" are now spelled "_PyRuntime.warnings.once_registry". The most egregious example seems to be "_PyRuntime.ceval.gil.locked" (used to be simply "gil_locked"). Granted, C is more verbose than Python, but it doesn't have to become that verbose. I don't know about you, but when code becomes annoying to type, I tend to try and take shortcuts. Regards Antoine.
On Wed, 06 Sep 2017 09:42:29 -0700 Benjamin Peterson <benjamin@python.org> wrote:
Not very often, but if I want to experiment with some low-level implementation details, it is nice to avoid the hassle. There's also a readability argument: with very long names, expressions can become less easy to parse.
If you are using a globals, perhaps the typing time will allow you to fully consider the gravity of the situation.
Right, I needed to be reminded of how perilous the use of C globals is. Perhaps I should contact the PSRT the next time I contemplate using a C global. Regards Antoine.
On Wed, Sep 6, 2017 at 10:26 AM Benjamin Peterson <benjamin@python.org> wrote:
I'm not concerned about moving things into a state structure rather than wildly scattered globals declared all over the place. It is good code hygiene. It ultimately moves us closer (much more work to be done) to being able to actually have multiple independent interpreters within the same process (including potentially even of different Python versions). For commonly typed things that get annoying, #define _Py_grail _PyRuntme.ceval.holy.grail within the .c source file that does a lot of grail flinging seems fine to me. -gps
On 9/6/2017 1:18 PM, Gregory P. Smith wrote:
You just need a PEP 550 (or 555) to use instead of C globals. But why would you ever want multiple Python versions in one process? Sounds like a debug headache in the making. Name collisions would abound for libraries and functions even if globals were cured!
On Wed, Sep 6, 2017 at 8:17 PM, Benjamin Peterson <benjamin@python.org> wrote:
Great. Related to this, there is also discussion on dangers of globals and other widely-scoped variables in the Rationale section of PEP 555 (Context-local variables), for anyone interested. But if you read the draft I posted on python-ideas last Monday, you've already seen it. ––Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven +
On Wed, Sep 6, 2017 at 8:17 PM, Benjamin Peterson <benjamin@python.org> wrote:
Great. Related to this, there is also discussion on dangers of globals and other widely-scoped variables in the Rationale section of PEP 555 (Context-local variables), for anyone interested. But if you read the draft I posted on python-ideas last Monday, you've already seen it. ––Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven +
Is there any issue with unit-at-a-time optimization? I would imagine that a static global would allow optimizations that are not safe for a exported global (not sure the C term for it). I suspect it doesn't matter and I support the idea in general. Global variables in extension modules kills the idea of a mark-and-sweap or some other GC mechanism. That's probably not going to happen but identifying all of the global state seems like a step forward.
participants (6)
-
Antoine Pitrou -
Benjamin Peterson -
Glenn Linderman -
Gregory P. Smith -
Koos Zevenhoven -
Neil Schemenauer