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

M.-A. Lemburg mal at egenix.com
Mon Jan 11 17:38:40 EST 2016


On 11.01.2016 22:38, Guido van Rossum wrote:
> On Mon, Jan 11, 2016 at 12:22 PM, Andrew Barnert <abarnert at yahoo.com> wrote:
> 
>> On Jan 11, 2016, at 10:42, Gregory P. Smith <greg at krypto.org> wrote:
>>
>> 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__).
>>
>>
>> These same arguments were made against PEP 484 in the first place, and (I
>> think rightly) dismissed.
>>
> 
> The way I recall it the argument was made against using decorators for PEP
> 484 and we rightly decided not to use decorators.

To clarify: My suggestion to use a simple decorator with essentially
the same syntax as proposed for the "# type: comments " was meant
as *additional* allowed syntax, not necessarily as the only one
to standardize.

I'm a bit worried that by standardizing on using comments
for these annotations only, we'll end up having people not
use the type annotations because they simply don't like the
style of having function bodies begin with comments instead
of doc-strings. I certainly wouldn't want to clutter up my
code like that. Tools parsing Python 2 source code may
also have a problem with this (e.g. not recognize the
doc-string anymore).

This simply reads better, IMO:

    @typehint("(str, int, *str) -> None")
    def embezzle(self, account, funds=1000000, *fake_receipts):
        """Embezzle funds from account using fake receipts."""
        <code goes here>

and it has the advantage of allowing to have the decorator
do additional things such as taking the annotations and
writing out a type annotations file for Python 3 and other
tools to use.

We could also use a variant of the two proposals and
additionally allow this syntax:

    #@typehint("(str, int, *str) -> None")
    def embezzle(self, account, funds=1000000, *fake_receipts):
        """Embezzle funds from account using fake receipts."""
        <code goes here>

to avoid memory and runtime overhead, if that's a problem.

Moving from one to the other would then be a simple
search&replace over the source code.

Or we could have -O remove all those typehint decorator
calls from the byte code to a similar effect.

Code written for Python 2 & 3 will have to stick to the
proposed syntax for quite a while, so we should try to find
something that doesn't introduce a new syntax variant of how
to specify additional function/method properties, because people
are inevitably going to start using the same scheme for all
sorts of other crazy stuff and this would make Python code look
closer to Java than necessary, IMO:

@public_interface
@rest_accessible
@map_exceptions_to_http_codes
def embezzle(self, account, funds=1000000, *fake_receipts):
    # type: (str, int, *str) -> None
    # raises: ValueError, TypeError
    # optimize: jit, inline_globals
    # tracebacks: hide_locals
    # reviewed_by: xyz, abc
    """Embezzle funds from account using fake receipts."""
    <code goes here>

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 11 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/



More information about the Python-ideas mailing list