Re: [Cython] Preparing the language level change - Re: [cython-users] Cython 0.29 beta 1 released
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
Stefan Behnel schrieb am 21.09.2018 um 09:38:
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.
I thought about this some more. The real question is: what should the world be like once Cython 3.0 is out? What we want to do for Cy3 is to change the default behaviour, which mostly impacts Py2/3 ported code. That's why we now warn about a missing "language_level" switch. When people respond to that and set the language level explicitly, that makes them opt out of the default change. Perfect so far. Do we then still want to have a separate option floating around that says "but I want str" ? I don't think so, because that will be the default in Cy3 anyway. Thus, what I think we want is that people either specify the language level explicitly, or get the new default. And to get the new default *now*, in a future proof way, I think the best option is to set an explicit language level, not a separate directive. Thus, I now agree with Jeroen's early intuition that a new language level switch is the right interface. I'll change the implementation to do what I wrote in the quoted paragraph above and push a new RC. Stefan
participants (1)
-
Stefan Behnel