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 <thiagocavila@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): `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 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 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), 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-leave@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/