On Sat, Jan 9, 2016 at 1:54 AM, Pavol Lisy <pavol.lisy@gmail.com> wrote:

Could not something like this ->

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

make
1. transition from python2 to python3 more simple?
2. python3 checkers more easily changeable to understand new python2 standard?
3. simpler impact to documentation (means also simpler knowledbase to
be learn) about annotations?

There would still have to be some marker like "# type:" for the type checker to recognize -- I'm sure that plain comments with alternate 'def' statements are pretty common and we really don't want the type checker to be confused by those.

I don't like that the form you propose has so much repetition -- the design of Python 3 annotations intentionally is the least redundant possible, and my (really Jukka's) proposal tries to keep that property.

Modifying type checkers to support this syntax is easy (Jukka already did it for mypy).

Note that type checkers already have to parse the source code without the help of Python's ast module, because there are other things in comments: PEP 484 specifies variable annotations and a few forms of `# type: ignore` comments.

Regarding the idea of a decorator, this was discussed and rejected for the original PEP 484 proposal as well. The problem is similar to that with your 'def' proposal: too verbose. Also a decorator is more expensive (we're envisioning adding many thousands of decorators, and it would weigh down program startup). We don't envision needing to introspect __annotations__ at run time. (Also, we already use decorators quite heavily -- introducing a @typehint decorator would make the code less readable due to excessive stacking of decorators.)

Our needs at Dropbox are several: first, we want to add annotations to the code so that new engineers can learn their way around the code quicker and refactoring will be easier; second, we want to automatically check conformance to the annotations as part of our code review and continuous integration processes (this is where mypy comes in); third, once we have annotated enough of the code we want to start converting it to Python 3 with as much automation is feasible. The latter part is as yet unproven, but there's got to be a better way than manually checking the output of 2to3 (whose main weakness is that it does not know the types of variables). We see many benefits of annotations and automatically checking them using mypy -- but we don't want the them to affect the runtime at all.