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

[Gregory P. Smith]

On Sat, Jan 9, 2016 at 4:48 AM M.-A. Lemburg <mal at egenix.com> wrote:

> On 09.01.2016 00:04, Guido van Rossum wrote:
> > Since Python 2 doesn't support function annotations we've had to look for
> > alternatives. We considered stub files, a magic codec, docstrings, and
> > additional `# type:` comments. In the end we decided that `# type:`
> > comments are the most robust approach. We've experimented a fair amount
> > with this and we have a proposal for a standard.
> >
> > The proposal is very simple. Consider the following function with Python
> 3
> > annotations:
> >
> >     def embezzle(self, account: str, funds: int = 1000000,
> *fake_receipts:
> > str) -> None:
> >         """Embezzle funds from account using fake receipts."""
> >         <code goes here>
> >
> > An equivalent way to write this in Python 2 is the following:
> >
> >     def embezzle(self, account, funds=1000000, *fake_receipts):
> >         # type: (str, int, *str) -> None
> >         """Embezzle funds from account using fake receipts."""
> >         <code goes here>
>
> By using comments, the annotations would not be available at
> runtime via an .__annotations__ attribute and every tool would
> have to implement a parser for extracting them.
>
> Wouldn't it be better and more in line with standard Python
> syntax to use decorators to define them ?
>
>     @typehint("(str, int, *str) -> None")
>     def embezzle(self, account, funds=1000000, *fake_receipts):
>         """Embezzle funds from account using fake receipts."""
>         <code goes here>
>
> This would work in Python 2 as well and could (optionally)
> add an .__annotations__ attribute to the function/method,
> automatically create a type annotations file upon import,
> etc.
>

The goal of the # type: comments as described is to have this information
for offline analysis of code, not to make it available at run time.  Yes, a
decorator syntax could be adopted if anyone needs that. I don't expect
anyone does. Decorators and attributes would add run time cpu and memory
overhead whether the information was going to be used at runtime or not
(likely not; nobody is likely to *deploy* code that looks at
__annotations__).

-gps


>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Jan 09 2016)
> >>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
> >>> Python Database Interfaces ...           http://products.egenix.com/
> >>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
> ________________________________________________________________________
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>    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/
>                       http://www.malemburg.com/
>
> _______________________________________________
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160111/e4ba30ff/attachment.html>