<div dir="ltr">Interesting. PEP 484 defines an IO generic class, so you can write IO[str] or IO[bytes]. Maybe introducing separate helper functions that open files in text or binary mode can complement this to get a solution?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 22, 2016 at 12:58 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 22 January 2016 at 19:08, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> On Fri, Jan 22, 2016 at 10:37 AM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Thu, 21 Jan 2016 at 10:45 Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
>>><br>
>>> On Thu, Jan 21, 2016 at 10:14 AM, Agustín Herranz Cecilia<br>
>>> <<a href="mailto:agustin.herranz@gmail.com">agustin.herranz@gmail.com</a>> wrote:<br>
>>> [...]<br>
>>> Yes, this is no related with the choice of syntax for annotations<br>
>>> directly. This is intended to help in the process of porting python2 code to<br>
>>> python3, and it's outside of the PEP scope but related to the original<br>
>>> problem. What I have in mind is some type aliases so you could annotate a<br>
>>> version specific type to avoid ambiguousness on code that it's used on<br>
>>> different versions. At the end what I originally try to said is that it's<br>
>>> good to have a convention way to name this type aliases.<br>
>>><br>
>>> Yes, this is a useful thing to discuss.<br>
>>><br>
>>> Maybe we can standardize on the types defined by the 'six' package, which<br>
>>> is commonly used for 2-3 straddling code:<br>
>>><br>
>>> six.text_type (unicode in PY2, str in PY3)<br>
>>> six.binary_type (str in PY2, bytes in PY3)<br>
>>><br>
>>> Actually for the latter we might as well use bytes.<br>
>><br>
>><br>
>> I agree that `bytes` should cover str/bytes in Python 2 and `bytes` in<br>
>> Python 3.<br>
><br>
><br>
> OK, that's settled.<br>
><br>
>><br>
>> As for the textual type, I say either `text` or `unicode` since they are<br>
>> both unambiguous between Python 2 and 3 and get the point across.<br>
><br>
><br>
> Then let's call it unicode. I suppose we can add this to typing.py. In PY2,<br>
> typing.unicode is just the built-in unicode. In PY3, it's the built-in str.<br>
<br>
</div></div>This thread came to my attention just as I'd been thinking about a<br>
related point.<br>
<br>
For me, by far the worst Unicode-related porting issue I see is people<br>
with a confused view of what type of data reading a file will give.<br>
This is because open() returns a different type (byte stream or<br>
character stream) depending on its arguments (specifically 'b' in the<br>
mode) and it's frustratingly difficult to track this type across<br>
function calls - especially in code originally written in a Python 2<br>
environment where people *expect* to confuse bytes and strings in this<br>
context. So, for example, I see a function read_one_byte which does<br>
f.read(1), and works fine in real use when a data file (opened with<br>
'b') is processed, but fails when sys.stdin us used (on Python 3once<br>
someone types a Unicode character).<br>
<br>
As far as I know, there's no way for type annotations to capture this<br>
distinction - either as they are at present in Python3, nor as being<br>
discussed here. But what I'm not sure of is whether it's something<br>
that *could* be tracked by a type checker. Of course I'm also not sure<br>
I'm right when I say you can't do it right now :-)<br>
<br>
Is this something worth including in the discussion, or is it a<br>
completely separate topic?<br>
<span class="HOEnZb"><font color="#888888">Paul<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>