(original) (raw)

On Wed, Sep 6, 2017, at 10:08, Antoine Pitrou wrote:
\> On Wed, 06 Sep 2017 09:42:29 -0700
\> Benjamin Peterson <benjamin@python.org> wrote:
\> > On Wed, Sep 6, 2017, at 03:14, Antoine Pitrou wrote:
\> > >
\> > > Hello,
\> > >
\> > > I'm a bit concerned about
\> > > https://github.com/python/cpython/commit/76d5abc8684bac4f2fc7cccfe2cd940923357351
\> > >
\> > > 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.
\> >
\> > How often are you actually typing the names of runtime globals, though?
\>
\> Not very often, but if I want to experiment with some low-level
\> implementation details, it is nice to avoid the hassle.

It seems like this could be remediated with some inline functions or
macros, which would also help safely encapsulate state.

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

It's not just you but future readers.