There is absolutely no possibility that this will go anywhere. It breaks every single Python program written since 1989, with absolutely ZERO new functionally. Changing the spelling of a few of the most come keywords is a non-starter.
If you can time travel to 1987 and propose differently spelled keywords, yours are no worse... But also no better. On Mon, Jul 20, 2020, 6:06 PM Thiago Carvalho D' Ávila < thiagocav...@gmail.com> wrote: > Python is a simple language to understand, but to me functions are a > special case. And according to the Zen of Python (PEP20 > <https://www.python.org/dev/peps/pep-0020/>): `Special cases aren't > special enough to break the rules.`. > > For beginners, Python functions can cause some pain that boils down to > three points that shows some lack of standardization. > > 1. Function declaration needs keyword `def`: > > If you are a long time Python (1991) developer, you surely got used to the > keyword `def` to declare a function, same goes if you are a Ruby (1995) > programmer. In Fortran (1957) you start them with the word `function` and > in Perl (1987) you use the word `sub`. > > In C-family languages C (1972), C++ (1985), C# (2000), also in Java (1995) > you don't need any word to declare it: > > return_type function_name(args) > > In languages from the last decade you have Rust (2010) with the keyword > `fn`, Kotlin with `fun`. Dart (2011) follows C-family style and Julia > (2012) offers two ways of defining a named function: using the word > `function` or the compact version with no keyword `f(x,y) = x + y`. > > Following PEP20 <https://www.python.org/dev/peps/pep-0020/> aphorism of > `Simple is better than complex.` I would say no word like C-family is > simpler. But there is also `Explicit is better than implicit.`. I would > choose `fun` or even `fn` since they at least resemble the word function. > Eg: > > >>> def x(args): > > ... pass > > would turn into: > > >>> fun x(args): > > ... pass > > Resemblance of function leads me to my next point. > > 2. Class name > > Again, functions are an exception. > > >>> x = 1 > > >>> type(x) > > <class 'int'> *# not integer* > > >>> x = {"a": 1} > > >>> type(x) > > <class 'dict'> *# not dictionary* > > >>> def x(args): > > ... pass > > ... > > >>> type(x) > > <class 'function'> *# not fun =(* > > 3. Type hinting > > This is when the syntax gets trickier. With PEP 585 > <https://www.python.org/dev/peps/pep-0585/> you don't have to do: > > >>> from typing import Dict, List, Set > > to have: > > >>> def x(foo: dict[string, int], bar: list[float]) -> None: > > ... pass > > But if you have a function as a parameter, your only option is to use > Callable. It breaks the rule again having a totally different syntax: > > >>> from typing import Callable > > >>> def x(method: Callable[[int, dict], None]) -> None: > > ... pass > > So you have `def`, `function`, `Callable` and also this [[args], return] > syntax, also different from the rest of type hinting syntax. I would add a > `fun` type without the need of an import. Also Callable syntax could also > be simplified with the -> operator into something like: > > >>> def x(method: fun[int, dict] -> None) -> None: > > ... pass > > === Preliminary Proposal === > > With the same goal of removing the pain and making life of Python teachers > easier (PEP 585 <https://www.python.org/dev/peps/pep-0585/>), I would > change this: > > >>> from typing import Callable > > >>> def x(method: Callable[[int, dict], None]) -> None: > > ... pass > > ... > > >>> type(x) > > <class 'function'> > > Into something like this: > > >>> fun x(method: fun[int, dict] -> None) -> None: > > ... pass > > ... > > >>> type(x) > > <class 'fun'> > > In order to make this possible the following changes would be needed: > > 1. adding `fun` keyword to method definition (maintaining `def` for > backwards compatibility); > > 2. adding `fun` built-in type in addition to Callable; > > 3. supporting `->` as return syntax for type hinting. > > Isn't it much more `fun` to learn the language this way? > > Kind regards, > > Thiago Carvalho D'Ávila > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/D5ZF3QBOP35XYI5NSOSHYIU44MV3YFBY/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SJ2GFPSNVPSPUEHW6RJEJ2MRQ63R54H2/ Code of Conduct: http://python.org/psf/codeofconduct/
