[Python-ideas] Proposal to extend PEP 484 (gradual typing) to support Python 2.7

[Brett Cannon]

On Fri, 22 Jan 2016 at 11:35 Andrew Barnert <abarnert at yahoo.com> wrote:

> On Jan 22, 2016, at 10:37, Brett Cannon <brett at python.org> wrote:
>
>
> On Thu, 21 Jan 2016 at 10:45 Guido van Rossum <guido at python.org> wrote:
>
>>
>> Yes, this is a useful thing to discuss.
>>
>> Maybe we can standardize on the types defined by the 'six' package, which
>> is commonly used for 2-3 straddling code:
>>
>> six.text_type (unicode in PY2, str in PY3)
>> six.binary_type (str in PY2, bytes in PY3)
>>
>> Actually for the latter we might as well use bytes.
>>
>
> I agree that `bytes` should cover str/bytes in Python 2 and `bytes` in
> Python 3.
>
> As for the textual type, I say either `text` or `unicode` since they are
> both unambiguous between Python 2 and 3 and get the point across.
>
>
> The only problem is that, while bytes is a builtin type in both 2.7 and
> 3.x, with similar behaviour (especially in 3.5, where simple %-formatting
> code works the same as in 2.7), unicode exists in 2.x but not 3.x, so that
> would require people writing something like "try: unicode except:
> unicode=str" at the top of every file (or monkeypatching builtins
> somewhere) for the annotations to actually be valid 3.x code.
>

But why do they have to be valid code? This is for Python 2/3 code which
means any typing information is going to be in a comment and so it isn't
important that it be valid code as-is as long as the tools involved realize
what `unicode` represents. IOW if mypy knows what the `unicode` type
represents in PY3 mode then what does it matter if `unicode` is not a
built-in type of Python 3?


> And, if you're going to do that, using something that's already
> wide-spread and as close to a de facto standard as possible, like the six
> type suggested by Guido, seems less disruptive than inventing a new
> standard (even if "text" or "unicode" is a little nicer than
> "six.text_type").
>
> (Or, of course, Guido could just get in his time machine and, along with
> restoring the u string literal prefix in 3.3, also restore the builtin name
> unicode as a synonym for str, and then this whole mail thread would fade
> out like Marty McFly.)
>

I long thought about that option, but I don't think it buys us enough to
bother to add the alias for `str` in Python 3. Considering all of the other
built-in tweaks you typically end up making, I don't think this one change
is worth it.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160123/2b0d1d31/attachment-0001.html>