[Python-ideas] PEP 484 (Type Hints) -- second draft

[Guido van Rossum]

Yeah, I've considered that, but it feels too punctuation-heavy (as does the
C++ cast<T>(x)). Also, we need cast() to be a fast no-op; cast[T](x)
necessarily means calling two functions rather than one.

On Mon, Mar 23, 2015 at 1:13 PM, Ryan Gonzalez <rymg19 at gmail.com> wrote:

> On Mon, Mar 23, 2015 at 2:55 PM, Guido van Rossum <guido at python.org>
> wrote:
>
>> On Sun, Mar 22, 2015 at 11:02 PM, David Foster <davidfstr at gmail.com>
>> wrote:
>>
>>> * It's a bit vague how local variables should be typed in the presence of
>>>   multiple assignments. Consider:
>>>
>>>   ```
>>>   if x > 0:
>>>       root = sqrt(x)  # type: int
>>>   else:
>>>       root = None
>>>   ```
>>>
>>>   It seems that the type of `root` should be inferred as `Union[int,
>>> None]`
>>>   (AKA `Optional[int]`), but there's no discussion about this type of
>>>   inference in the PEP.
>>>
>>>   Cases like this are the only way that the proposed blank `Undefined`
>>>   value makes sense to me, using an example like:
>>>
>>>   ```
>>>   root = Undefined    # type: Optional[int]
>>>   if x > 0:
>>>       root = sqrt(x)  # type: int
>>>   else:
>>>       root = None
>>>   ```
>>>
>>
>> Right. Another use case for Undefined is class variables (serving as
>> instance variable initialization/declaration).
>>
>> If you feel strongly that this needs to be mentioned in the PEP, can you
>> send a PR to github.com/ambv/typehinting ?
>>
>>
>>> * +1 for only allowing .pyi as the extension for stub files (and not
>>> also .py).
>>>   Makes it very clear that they should only be interpreted as stubs.
>>>
>>
>> Perhaps. Though there are also downsides.
>>
>>
>>> * -1 that `Optional[T1]` is unnecessary. It's conceptually more clean and
>>>   directly corresponds conceptually to types like `int?` and `?int` from
>>>   other languages.
>>>
>>
>> Indeed, Optional[t] is much clearer to the human reader than Union[t,
>> None].
>>
>>
>>> * +1 for the argument order cast(x, T). This is consistent with (x: T)
>>> elsewhere.
>>>
>>
>> I disagree on this. It goes against the argument order of casts in other
>> languages, e.g. C, C++, Java, and even in Python -- you write int(x), not
>> x(int).
>>
>
> I brought this up somewhere before, but I still think this would be great
> for casts:
>
> cast[T](x)
>
> Like C++'s named casts (static_cast<T>(x), dynamic_cast<T>(x), etc.). It
> gives the notion that T is a type, not some random variable, and that cast
> is NOT a normal function call.
>
>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
> --
> Ryan
> [ERROR]: Your autotools build scripts are 200 lines longer than your
> program. Something’s wrong.
> http://kirbyfan64.github.io/
>
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150323/f838e24b/attachment.html>