On Sun, Sep 16, 2018 at 5:24 PM Stefan Behnel <stefan...@behnel.de> wrote:
> Jeroen Demeyer schrieb am 22.08.2018 um 13:10: > > On 2018-08-19 08:26, Stefan Behnel wrote: > >> Should we make that a new directive rather than a language level? Like > >> "py2_str=str"? That would allow its use together with language_level=3 > >> already in the next release. > > > > With a new new directive, you also run into compatibility problems. What > > should the default be? py2_str=str or py2_str=unicode? The former breaks > > code assuming that it's unicode and the latter doesn't really solve > > anything: stuff will still break when language_level=3 becomes the > default. > > > > My proposal is a new setting language_level=3str (meaning: everything > that > > language_level=3 does, except unicode_literals) and make that the > default. > > That way, you keep full compatibility with code already setting the > > language_level. You also have reasonably good chances that code that > > currently uses the implicit language_level=2 will continue to work with > > language_level=3str. > > I thought about this some more and I like the idea. There's still the > true-division issue, but strings are certainly the biggest blocker in > migrations. As long as people want to support Python 2.x, "3str" is a way > to help them with it, and for Py3-only users, it won't make a difference. > Yes, this does seem worth handling differently. I've also been wondering if the c_string_type directive would work for this. (Unfortunately, we let c_string_type=str mean c_string_type=bytes, where a more natural interpretation for c_string_type=str would be "bytes in py2, unicode in py3." Would it be good enough to disallow str for a release before going to 3.0? (Or would a warning be good enough, given that Cython 3.0 is backwards incompatible?)
_______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
