[Cython] Preparing the language level change - Re: [cython-users] Cython 0.29 beta 1 released

Stefan Behnel stefan_ml at behnel.de
Fri Sep 21 03:38:32 EDT 2018


Jeroen Demeyer schrieb am 20.09.2018 um 10:59:
> On 2018-09-20 10:15, Jeroen Demeyer wrote:
>> On 2018-09-20 07:55, Stefan Behnel wrote:
>>> I can see that this would be helpful. It's unfortunate, though, that this
>>> would introduce a temporary option that complicates the current integer
>>> "language_level".
>>
>> Does it really have to be an integer? We can make it a string
>> internally, but allow it to be set as integer too. That's just a matter
>> of putting "language_level = str(language_level)" in the appropriate places.

That's pretty much what I meant with "complicates". :)

It's very easy to compare "language_level < 3" now. With strings, not so
much. In fact, maybe that's not even the way to go. There are two parts of
information here, so maybe we should actually split them internally (in
"Main.Context.set_language_level() ?) and keep the language_level = 3 but
just avoid the "unicode_literals" part.


>> Once it's a string, we can add an additional language level "3str". I'm
>> willing to make a PR if you agree with this strategy.

I think a PR that takes care of splitting the two parts would be worth
looking at. Then, make sure we do the right checks for either of them in
the right places. The language level isn't always the right indication for
specific behaviour.


> Further brainstorming: you could also re-purpose language_level as a set of
> flags describing various features, like the __future__ flags.

I faintly remember proposals for a "from __past__ import …". One more use
case right here. But the problem is that there are really different things
to support. One is setting the behaviour globally, e.g. via setup.py. The
other is setting it on a file-by-file basis. I expect projects to settle on
one way to write code, so a global setting is definitely required, and
that's the language level. But then, there are probably cases where this is
worth overriding for a single file or two. And the language level doesn't
seem right for that. Explicitly opting out of "unicode_literals" would be
cleaner. So, maybe just allow "cython: unicode_literals=False" ?

Stefan


More information about the cython-devel mailing list