[Cython] Cython 3.0 and "unicode_literals"

[Robert Bradshaw]

On Sun, Sep 16, 2018 at 5:24 PM Stefan Behnel <stefan_ml at 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?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20180917/e6dfa8ba/attachment.html>