As per Brett's target timeline, I've just posted updated versions of
my workflow improvement proposals in PEP 474 and 462
PEP 474 is my proposal to host a Kallithea instance at
forge.python.org: https://www.python.org/dev/peps/pep-0474/
This update was fairly minor, mainly just added some timeline details
based on Brett's proposed schedule for discussions and implementation:
https://www.python.org/dev/peps/pep-0474/#pilot-objectives-and-timeline
The updates to PEP 462, which covers proposed changes to the main
CPython workflow, were more significant, as I've now rewritten that to
depend on PEP 474, and propose replacing the current Rietveld patch
review workflow with an updated approach based on Kallithea and Zuul:
https://www.python.org/dev/peps/pep-0462/
Regards,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
The proposed syntax is abominable. It's the opposite of readable.
The function annotation syntax is ugly, but potentially useful for things
like documentation. While it may very well have been created with the idea
of type-checking, actually using it for such quickly turns into an
unreadable morass of information that is far more difficult for human
brains to parse, which makes this usage the antithesis of pythonic.
I much prefer the idea of a 'where' keyword to denote typing, as discussed
http://aroberge.blogspot.com/2015/01/type-hinting-in-python-focus-on.html,
but I think a refinement of their idea would prove even better:
def retry(callback, timeout, retries=None) where
........callback is Callable[AnyArgs, Any[int, None]],
........timeout is Any[int, None],
........retries is in [int, None], # 'is in' construct is more readable,
dunno about complexity
........return is None:
....pass
def greeting(name) where name is str, return is str:
....return 'Hello ' + name
x, y = [], [] where x, y is List[Employee], List[Manager]
To me, this orders of magnitude more readable than the proposed nonsense.
PS. Obviously the 8-space indent above would only a convention, not
requirement.
