On 2019-04-24 22:42, Guido van Rossum wrote:

Thanks for posting. I agree that Callable is ugly (even hideous :-), but when we introduced type annotations in PEP 484, we didn't want to introduce new syntax. The existing syntax (using -> in function headings) was supported since Python 3.0.

Since then we've introduced other new syntax (in particular PEP 526) so we could indeed try adding something better for Callable.

I think we should probably at least have parentheses around the arguments, so you'd write

f: (int) -> str g: (int, str) -> float

That looks elegant.

But we should also try to support optional arguments and keyword arguments.

Also, some groups of people would like to see a more concise notation for lambdas, and maybe they'd want to write

x = (a, b) -> a + b

as sugar for

x = lambda a, b: a + b

We probably can't have both, so we should at least decide which is more important.

Too bad we can't use Unicode arrows. :-)

Some languages use ->; some others use =>. As Python already uses -> for the return type, it could use => for lambdas.

On Wed, Apr 24, 2019 at 2:30 PM Vaibhav Karve <vaibhavskarve@gmail.com <mailto:vaibhavskarve@gmail.com>> wrote:

(Note: This idea is about a particular static typecheking (typing?) annotation syntax). The idea is that currently the use of the "->" (right arrow) is restricted to only function definition annotation. Can we extent it to declaration of type for functions even outside their definitions? Example:

Currently we write:     f: Callable[[int, Dict[str, int]], str]  # declaring the type of some fake function

This would be much cleaner if we could write:     f: int -> Dict[str, int] -> str   # One of the possibilities

or even:     f: int, Dict[str, int] -> str      # Another possibility

I have no idea how this will affect the existing syntax (and if this will have any bad repercussions/notational misuse). I just thought it would be nicer to: a) Not have to spell out Callable b) Not have to use all those square brackets c) Have the same notation work for both the function annotation as well as for declaring the type.

This is my first time posting an idea to python-ideas. So apologies if i am not following some conventions that i might not be aware of.

Ivan Levkivskyi <levkivskyi@gmail.com> wrote:

Callable[[X, Y], Z] becomes (X, Y) -> Z Union[X, Y] becomes X | Y Tuple[X, Y] becomes (X, Y) Optional[X] becomes X? (Intersection[X, Y] when added becomes X & Y)

I really like this idea, but I could also see this getting a bit confusing because the syntax preceding type annotations (e.g. ":") is so lightweight/subtle---it might be difficult distinguish were annotations end and subsequent code begins. Defining some sort of wrapper function might help here; e.g.: Callable[[X, Y], Z] becomes EzType[(X, Y) => Z] Union[X, Y] becomes EzType[X | Y] Tuple[X, Y] becomes EzType[X, Y] Optional[X] becomes EzType[X?] ... The name EzType is certainly not ideal, but you get the basic idea. --- Tony On Thu, Apr 25, 2019 at 3:51 PM Ivan Levkivskyi <levkivskyi@gmail.com> wrote:

TBH, I don't think it is so bad that it requires a new syntax. But I am not strongly against it either. What I would like to add here is that if we will go with the replacement:

Callable[[X, Y], Z] becomes (X, Y) -> Z

then we should also go with

Union[X, Y] becomes X | Y Tuple[X, Y] becomes (X, Y) Optional[X] becomes X? (Intersection[X, Y] when added becomes X & Y)

The current syntax (although really verbose) is consistent, so if we want to improve it I would like to keep consistency. Also if we are going forward with this, should we allow mixing old and new syntax? Will the old syntax be deprecated after we introduce the new one?

-- Ivan

On Wed, 24 Apr 2019 at 14:43, Guido van Rossum <guido@python.org> wrote:

...

Thanks for posting. I agree that Callable is ugly (even hideous :-), but when we introduced type annotations in PEP 484, we didn't want to introduce new syntax. The existing syntax (using -> in function headings) was supported since Python 3.0.

Since then we've introduced other new syntax (in particular PEP 526) so we could indeed try adding something better for Callable.

I think we should probably at least have parentheses around the arguments, so you'd write

f: (int) -> str g: (int, str) -> float

That looks elegant.

But we should also try to support optional arguments and keyword arguments.

Also, some groups of people would like to see a more concise notation for lambdas, and maybe they'd want to write

x = (a, b) -> a + b

as sugar for

x = lambda a, b: a + b

We probably can't have both, so we should at least decide which is more important.

Too bad we can't use Unicode arrows. :-)

On Wed, Apr 24, 2019 at 2:30 PM Vaibhav Karve <vaibhavskarve@gmail.com> wrote:

...

(Note: This idea is about a particular static typecheking (typing?) annotation syntax). The idea is that currently the use of the "->" (right arrow) is restricted to only function definition annotation. Can we extent it to declaration of type for functions even outside their definitions? Example:

Currently we write: f: Callable[[int, Dict[str, int]], str] # declaring the type of some fake function

This would be much cleaner if we could write: f: int -> Dict[str, int] -> str # One of the possibilities

or even: f: int, Dict[str, int] -> str # Another possibility

I have no idea how this will affect the existing syntax (and if this will have any bad repercussions/notational misuse). I just thought it would be nicer to: a) Not have to spell out Callable b) Not have to use all those square brackets c) Have the same notation work for both the function annotation as well as for declaring the type.

This is my first time posting an idea to python-ideas. So apologies if i am not following some conventions that i might not be aware of. Vaibhav Karve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...> _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Guido van Rossum wrote:

Also, some groups of people would like to see a more concise notation for lambdas, and maybe they'd want to write

x = (a, b) -> a + b

We probably can't have both,

I think we could if we wanted to. In an annotation, -> could be treated as sugar for Callable[], and in other expressions as sugar for lambda. -- Greg

On 2019-04-24 22:42, Guido van Rossum wrote:

Thanks for posting. I agree that Callable is ugly (even hideous :-), but when we introduced type annotations in PEP 484, we didn't want to introduce new syntax. The existing syntax (using -> in function headings) was supported since Python 3.0.

Since then we've introduced other new syntax (in particular PEP 526) so we could indeed try adding something better for Callable.

I think we should probably at least have parentheses around the arguments, so you'd write

f: (int) -> str g: (int, str) -> float

That looks elegant.

But we should also try to support optional arguments and keyword arguments.

Also, some groups of people would like to see a more concise notation for lambdas, and maybe they'd want to write

x = (a, b) -> a + b

as sugar for

x = lambda a, b: a + b

We probably can't have both, so we should at least decide which is more important.

Too bad we can't use Unicode arrows. :-)

Some languages use ->; some others use =>. As Python already uses -> for the return type, it could use => for lambdas.

On Wed, Apr 24, 2019 at 2:30 PM Vaibhav Karve <vaibhavskarve@gmail.com <mailto:vaibhavskarve@gmail.com>> wrote:

(Note: This idea is about a particular static typecheking (typing?) annotation syntax). The idea is that currently the use of the "->" (right arrow) is restricted to only function definition annotation. Can we extent it to declaration of type for functions even outside their definitions? Example:

Currently we write:     f: Callable[[int, Dict[str, int]], str]  # declaring the type of some fake function

This would be much cleaner if we could write:     f: int -> Dict[str, int] -> str   # One of the possibilities

or even:     f: int, Dict[str, int] -> str      # Another possibility

I have no idea how this will affect the existing syntax (and if this will have any bad repercussions/notational misuse). I just thought it would be nicer to: a) Not have to spell out Callable b) Not have to use all those square brackets c) Have the same notation work for both the function annotation as well as for declaring the type.

This is my first time posting an idea to python-ideas. So apologies if i am not following some conventions that i might not be aware of.

Ivan Levkivskyi <levkivskyi@gmail.com> wrote:

Callable[[X, Y], Z] becomes (X, Y) -> Z Union[X, Y] becomes X | Y Tuple[X, Y] becomes (X, Y) Optional[X] becomes X? (Intersection[X, Y] when added becomes X & Y)

I really like this idea, but I could also see this getting a bit confusing because the syntax preceding type annotations (e.g. ":") is so lightweight/subtle---it might be difficult distinguish were annotations end and subsequent code begins. Defining some sort of wrapper function might help here; e.g.: Callable[[X, Y], Z] becomes EzType[(X, Y) => Z] Union[X, Y] becomes EzType[X | Y] Tuple[X, Y] becomes EzType[X, Y] Optional[X] becomes EzType[X?] ... The name EzType is certainly not ideal, but you get the basic idea. --- Tony On Thu, Apr 25, 2019 at 3:51 PM Ivan Levkivskyi <levkivskyi@gmail.com> wrote:

TBH, I don't think it is so bad that it requires a new syntax. But I am not strongly against it either. What I would like to add here is that if we will go with the replacement:

Callable[[X, Y], Z] becomes (X, Y) -> Z

then we should also go with

Union[X, Y] becomes X | Y Tuple[X, Y] becomes (X, Y) Optional[X] becomes X? (Intersection[X, Y] when added becomes X & Y)

The current syntax (although really verbose) is consistent, so if we want to improve it I would like to keep consistency. Also if we are going forward with this, should we allow mixing old and new syntax? Will the old syntax be deprecated after we introduce the new one?

-- Ivan

On Wed, 24 Apr 2019 at 14:43, Guido van Rossum <guido@python.org> wrote:

...

Thanks for posting. I agree that Callable is ugly (even hideous :-), but when we introduced type annotations in PEP 484, we didn't want to introduce new syntax. The existing syntax (using -> in function headings) was supported since Python 3.0.

Since then we've introduced other new syntax (in particular PEP 526) so we could indeed try adding something better for Callable.

I think we should probably at least have parentheses around the arguments, so you'd write

f: (int) -> str g: (int, str) -> float

That looks elegant.

But we should also try to support optional arguments and keyword arguments.

Also, some groups of people would like to see a more concise notation for lambdas, and maybe they'd want to write

x = (a, b) -> a + b

as sugar for

x = lambda a, b: a + b

We probably can't have both, so we should at least decide which is more important.

Too bad we can't use Unicode arrows. :-)

On Wed, Apr 24, 2019 at 2:30 PM Vaibhav Karve <vaibhavskarve@gmail.com> wrote:

...

(Note: This idea is about a particular static typecheking (typing?) annotation syntax). The idea is that currently the use of the "->" (right arrow) is restricted to only function definition annotation. Can we extent it to declaration of type for functions even outside their definitions? Example:

Currently we write: f: Callable[[int, Dict[str, int]], str] # declaring the type of some fake function

This would be much cleaner if we could write: f: int -> Dict[str, int] -> str # One of the possibilities

or even: f: int, Dict[str, int] -> str # Another possibility

I have no idea how this will affect the existing syntax (and if this will have any bad repercussions/notational misuse). I just thought it would be nicer to: a) Not have to spell out Callable b) Not have to use all those square brackets c) Have the same notation work for both the function annotation as well as for declaring the type.

This is my first time posting an idea to python-ideas. So apologies if i am not following some conventions that i might not be aware of. Vaibhav Karve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...> _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Guido van Rossum wrote:

Also, some groups of people would like to see a more concise notation for lambdas, and maybe they'd want to write

x = (a, b) -> a + b

We probably can't have both,

I think we could if we wanted to. In an annotation, -> could be treated as sugar for Callable[], and in other expressions as sugar for lambda. -- Greg