[Python-ideas] Type hints for text/binary data in Python 2+3 code

Guido van Rossum guido at python.org
Tue Mar 22 17:07:40 EDT 2016


Good point -- changing the 2.7 backport is simpler than changing the
3.5 stdlib. And it's beyond a shadow of a doubt that in 3.x it'll just
be an alias for str.

On Tue, Mar 22, 2016 at 1:27 PM, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Mar 22, 2016, at 10:58, Guido van Rossum <guido at python.org> wrote:
>>
>> One thing I can do without committing to too much is to add a Text
>> type to typing.py. It would have no (defined) behavior but it could be
>> imported and used in annotations. Then mypy and other checkers could
>> start using it and we could even experiment with different proposals
>> without having to make more changes to typing.py (which we've found
>> are hard to push out, because it's in the 3.5 stdlib -- it's
>> provisional so we can change it, but we can't easily change what's
>> already in 3.5.0 or 3.5.1).
>>
>> Should it be possible to subclass Text, and what should it mean?
>>
>> Or perhaps at runtime (i.e. in typing.py) Text would just be an alias
>> for str in Python 3 and an alias for unicode in Python 2? That's
>> easiest.
>
> It seems like the worry is that you may need to change it again (e.g., to some "virtual type" that's like unicode in 2.7 except that it doesn't have a constructor from str or methods that accept str), and changing something that's in the stdlib (even in a provisional module) is hard?
>
> If so, could you define it as an alias for str in Python 3.5+, and leave it up to backports to define appropriately? Of course you're writing the 2.7 backport, and you'll define it as an alias for unicode--but if you later decide that was too inflexible, you can change the backport without having any effect on the PEP, 3.5 docs, or 3.5 stdlib.
>



-- 
--Guido van Rossum (python.org/~guido)


More information about the Python-ideas mailing list