On 11.01.2016 22:38, Guido van Rossum wrote:
On Mon, Jan 11, 2016 at 12:22 PM, Andrew Barnert
wrote: On Jan 11, 2016, at 10:42, Gregory P. Smith
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/