[Python-ideas] Proposal: Use mypy syntax for function annotations

[M.-A. Lemburg]

On 22.08.2014 03:24, Antoine Pitrou wrote:
> Le 21/08/2014 20:40, Nick Coghlan a écrit :
>> On 22 Aug 2014 03:27, "Antoine Pitrou"
>> <antoine at python.org
>> <mailto:antoine at python.org>> wrote:
>>  >
>>  >
>>  > Le 21/08/2014 12:15, Nick Coghlan a écrit :
>>  >
>>  >>
>>  >> Given:
>>  >>
>>  >>      Sequence[Number]
>>  >>      Sequence[Number|None]
>>  >>
>>  >> There's still at least three options for extending the syntax even
>> further:
>>  >>
>>  >>      Sequence[Number](EXPR)
>>  >>      Sequence[Number:EXPR]
>>  >>      Sequence[Number,EXPR]
>>  >>
>>  >> You'd probably want to use strings at that point, for the same reasons
>>  >> PyContracts does. For example:
>>  >>
>>  >>      Number,"N>0" # Positive number
>>  >>      Sequence[Number,"N>0"] # Sequence of positive numbers
>>  >>      Sequence[Number],"N>0" # Non-empty sequence
>>  >
>>  >
>>  > All of those are horrible and un-Pythonic, though.
>>  > Python has one of the most powerful and user-friendly function call
>> syntaxes around, why reinvent something clearly inferior and alien?
>>
>> I don't think it's possible to have "Pythonic" design by contract
> 
> We're not talking about design by contract, we're talking about type annotations. "A list of X
> integers" isn't exactly an extremely complicated notion. We shouldn't need weird convoluted syntaxes
> to express it.

I agree with Antoine. Those EXPRs should not be needed for
type annotations. The above is mixing type information with
runtime information.

All a linter needs to know is that the result of operation1(type1)
is of type2, i.e. the information about certain features of those
types is implicit in the type name and the information about whether
types can be adapted to each other.

If the linter then finds that the result of operation1() is
being used as input for operation2(), which only supports
type1 arguments, and it doesn't have information about how
to adapt type2 to type1, it comes back with an error message.

It's all abstract. Trying to conflate arbitrary type properties
into the syntax is not needed - after all, type annotations are
not meant for runtime checks.

Regarding the whole idea of inline type annotations, I'm at most +0
on those. They add more complexity to the language and make it less
readable for little added value.

Making the type annotations external is much better in this respect
and I'm sure IDEs could even help with this by providing nice
interfaces for adding the type information. They could semi-
automate the process and make suggestions based on the functions
used inside the functions/method body.

Now, since these tools would have to read and write the annotations
programmatically, the syntax does not have to be nicely readable or
Pythonic. It could just as well be a YAML/JSON/XML file.

But hey, I don't want to spoil all the fun in defining a little
language for type annotations, so please do continue to have
fun defining Python .pyh header files ;-)

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 22 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2014-09-19: PyCon UK 2014, Coventry, UK ...                28 days to go
2014-09-30: Python Meeting Duesseldorf ...                 39 days to go

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/