On Fri, Jan 07, 2022 at 04:27:37PM -0800, Christopher Barker wrote:

Note that if PEP 563 is ultimately accepted, then Annotations would be strings, and type checkers could use any language they wanted.

Annotations still have to be syntactically valid Python expressions. >>> from __future__ import annotations >>> def func(arg: array[1...10] of float) -> str: pass File "<stdin>", line 1 def func(arg: array[1...10] of float) -> str: pass ^^^ SyntaxError: invalid syntax Of course if you explicitly wrap your annotation in quotation marks, you can use any syntax you like (think: regexes, SQL, etc). But without a *standard* annotation syntax: - static checkers will disagree on what annotations mean; - runtime introspection will be difficult; and - IDEs and syntax colourisers are going to just treat them as strings. We can write little DSLs with any syntax we like using explicitly quoted strings. We're not limited to do this in annotations. But while DSLs tend to be specific to your own library or application, annotations exist in a wide ecosystem of both static and runtime tools that expect to interpret annotations. Writing your own little DSL for annotations cuts you off from the rest of the Python ecosystem. -- Steve

I find this a really elegant approach. While the SC's decision to keep the syntax uniform is certainly laudable, it's creating the issue of packaging new complexities into a very limited syntactic & semantic space (e.g. no new magic symbols like "->", which I agree with BTW), leaving only very verbose solutions that the typing crowd is chafing against. I think accepting that typing has a syntactic cost on the python language as a whole is unavoidable at some point (and I'm not saying that's a bad thing). Having a separate & opt-in mini-language for type declarations seems like a really clean way to delineate that cost resp. extension, and I especially like the t''-string syntax. Best, H.

On Sat, Jan 08, 2022 at 12:32:35PM +0200, Serhiy Storchaka wrote:

08.01.22 01:59, jack.jansen@cwi.nl пише:

...

...

If I can make a wild suggestion: why not create a little language for type specifications?

We need a way to define aliases. For example, write:

Data = Mapping[str, Sequence[Tuple[int, T]]] Factory = Callable[[int, Iterable[str]], Optional[list[Data[T]]]]

Can't we already do that? https://docs.python.org/3/library/typing.html#type-aliases Type aliases are great. But there are times where we don't want to write an alias when we can just write the type in-place, just as there are times where we don't want to write a function when we can just use an in-place expression. -- Steve

The advantage to users of keeping the languages the same is that readers of your code don’t have to learn two disparate syntaxes to make sense of what they’re reading. One of Python’s enduring strengths has been its readability. In many ways, type annotations challenge that, but the trade-off (so far) has been worth it (IMHO). The trick is to balance the expressability that typing needs with the intuitive understanding of “regular” Python code. FWIW, this is something I struggled with while on the SC during the Pattern Matching debates. I think the right balance was found, ultimately. -Barry On Sat, Jan 8, 2022, at 03:06, Stéfane Fermigier wrote:

On 8 Jan 2022 at 00:59:38, jack.jansen@cwi.nl wrote:

...

I posted this suggestion earlier in the callable type syntax discussion, at which point it was completely ignored. Possibly because it’s a really stupid idea, but let me post it again on the off chance that it isn’t a stupid idea but was overlooked.

...

If I can make a wild suggestion: why not create a little language for type specifications?

Indeed.

Using the same syntax may have some benefits for language implementors (e.g. less complex grammar to implement), but I don’t really see these benefits for language users.

As an example, and I don’t know if this has been discussed before, I think a pretty neat syntax construct for optional argument would be (like, for instance, in Kotlin):

def f(x: int? = None): ...

Instead of:

def f(x: Optional[int] = None): …

or

def f(x: int | None = None): …

One could even argue that the “= None” part would be redundant (def f(x: int?): ...) and could be made optional. But that would open another can of worms.

S.

-- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Co-Founder & Co-Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel Libre (APELL) - https://www.apell.info/ Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) - https://www.euclidia.eu/ Founder, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PDRKIUCG... Code of Conduct: http://python.org/psf/codeofconduct/

On 1/8/2022 2:05 PM, Skip Montanaro wrote:

...

... make sense of what they’re reading.

Some of us have that problem with type-embellished code now.I'm not sure a little language would be such a bad idea. 🤔Fortunately, my relationship to the working world allows me to simply ignore explicit typing. 😉

Way, way BITD I recall leaning on a crutch to generate complex C type declarations. I no longer recall what it was called, but you gave it a restricted English description of what you wanted ("function returning pointer to function returning void pointer" or something similar) and it spit out the necessary line noise.

Skip

Oh yes, I remember that... went Googling and found https://cdecl.org/ which is apparently the "modern" online version of that old tool. I guess typing features might be useful for people that refuse to write/read comments, but I mostly ignore the typing stuff too... and hope I can continue to.

On Sun, Jan 09, 2022 at 01:30:33AM +0100, jack.jansen@cwi.nl wrote:

In the last year I’ve contributed mods to two packages that were rejected because I hadn’t provided typing (and black formatting, but that’s a different subject). I’ve reluctantly done so. And while I *hated* it because of the unreadability I _do_ like the outcome

Typing is hard because it is often more abstract and less concrete than the code you are adding type hints to. It is *metaprogramming*. And it involves unfamiliar jargon (covariant, contravariant, typeguards, etc). But the annotations themselves are plain ol' Python expressions. So if you hate type annotations because they are unreadable, then you hate Python because Python is unreadable. There may be some unfamiliarity if you aren't doing a lot of typing (what's a ParamSpec?), and due to the use of square brackets instead of round, but if you can read expressions: spam(eggs | cheese, aardvark) then you can read type expressions: Spam[Eggs | Cheese, Aardvark] Creating a whole new language to describe type hints will go against that. All the existing complexity of typing will still exist, but on top of that, there will *also* be the problem that the syntax used for type expressions will *not be Python* but a second language. Wrapping that second language in t"..." will not change that. -- Steve

On Sat, Jan 08, 2022 at 06:30:53PM -0800, Ethan Furman wrote:

On 1/8/22 5:46 PM, Steven D'Aprano wrote:

...

[...] if you hate type annotations because they are unreadable, then you hate Python because Python is unreadable.

Not so.

Are you disputing that annotations use the same syntax as other Python expressions? If not, I don't see how you can deny that "type annotations are unreadable" implies "Python expressions are unreadable", which in turn implies "Python is unreadable".

A simple list comprehension is (usually) quite readable, while a triply-nested list comprehension all on one line is not.

Indeed. We can abuse any syntax. So do we conclude that comprehensions are "unreadable" because we can write obfuscated triply-nested list comprehensions?

Similarly, adding type information in between a variable name and its value is not (for me, and apparently others too) readable.

I think that "unreadable" or "not readable" is a complaint that gets overused, often for the most trivial cases, to the point that it loses all credibility. Especially when it comes from people who are fluent in C (which may not be you, Ethan). http://unixwiz.net/techtips/reading-cdecl.html "Easily learned", huh. I think that this is one of the clearest examples of the curse of knowledge as it applies to programming that one could hope to find. Anyway, let's compare: # C int n = 44; # Pascal var n: integer; n := 44; # Typescript var n: number = 44; # Java int n = 44; # Python n: int = 44 There are millions who find the C, Pascal, TypeScript and Java perfectly readable. I don't find it credible that people are incapable of reading the last one. Aside: such a type hint is redundant, as mypy is perfectly capable of inferring that n = 44 makes n an int. Style guides should recommend against such redundancy, and I would certainly flag that in a code review. A better example of a *useful* type hint would be: L: list[str] = []

Most horribly of all, cluttering a function header with type information is most unreadable.

I hear you. Adding redundant or unnecessary type hints to parameters just for the sake of having type hints is just clutter, especially if they are never tested by actually running a type checker over the file. (Untested code is broken code. If not right now, it soon will be.) Fortunately, we have *gradual typing*, and nobody should be forced to use type hints in their projects if they don't want them. Just as we don't make linters mandatory, we don't make typing mandatory either. I think that, outside of very simple functions, once we make the decision to annotate a function, we should space them out: # Better def func(spam: list[str], eggs: float, cheese: str = 'cheddar', aardvark: str|bytes = "", eels: Optional[Tuple[int, str]] = None ) -> Hovercraft: which makes them much easier to read. Trying to cram them all into one line is abuse of the syntax every bit as bad as cramming a triply-nested list comp into one line: # Worse def func(spam: list[str], eggs: float, cheese: str = 'cheddar', aardvark: str|bytes = "", eels: Optional[Tuple[int, str]] = None) -> Hovercraft: I can read it, I just don't want to. It is too much like hard work compared to the previous layout. Even if you don't run a type-checker, those annotations can make useful documentation. (At least *sometimes*.) If the parameter name doesn't make it clear what types are allowed, then the annotation can make it clear. So if you don't use a static checker, you can think of type annotations as introspectable documentation.

I started using Python at 2.5. It was simple, clean, and elegant.

And I started using Python at 1.5, when the syntax was even simpler and cleaner. And to this day I will never forget the first time I read Python code, after being told repeatedly how easy to read it, and I couldn't make head or tails of it. All those colons and square brackets, it might as well have been APL. (Not that I knew what APL was back then.) I knew what a for-loop was, from Pascal, Hypertalk and HP RPN calculators: # Pascal for i := 0 to 10 do begin block; end; # Hypertalk repeat with i = 0 to 10 block end repeat # HP-48 RPN language 0 10 FOR I block NEXT but I kept seeing loops like this in Python: for i in range(11): or worse: for somename in [stuff, thing, another_thing, widget]: and worse of all: for somename in values[1:-1]: Python for loops looked nothing like any for loop I had seen before, and they freaked me out, and at the time (early 1990s) there was no publicly available internet where I could look anything up or ask for help. And then there were the brackets. Why does Python sometimes use round brackets, sometimes curly brackets, and sometimes square brackets? x[a] versus x(a)? Why were there sometimes colons inside square brackets and curly brackets {a:b} but never inside round brackets? What was the difference between [1, 2, 3] and (1, 2, 3)? The whole thing was intimidating, and I just put Python away for about a year and didn't look at it again until I had bought Mark Lutz' "Python Pocket Reference" which helped me make sense of it all. That and his "Learning Python". And never looked back. (Since then, I've often felt that Python has spoiled me from learning other languages. The point I am making here is not that I was a dimwit who couldn't even read Python, but that "easy to read" and "readable" is more a matter of familiarity than an inherent property of the language itself. With enough familiarity, even APL is easy to read.

If I had stumbled on it at 3.16 with samples, tutorials, and books all infused with typing clutter (which *looks* like boiler-plate even if it isn't) I wouldn't have given it a second glance.

And again, I hear you. I too wish people would tone down their enthusiasm for adding typing to examples that don't need type hints. We should remember that type hints are a feature aimed at large code bases, where static typing really is valuable. For three line example functions, not so much, not even as documentation. -- Steve

To that extent, I definitely want to keep annotation syntax and Python syntax the same; if there's a new feature needed for annotations, add it to the

Perhaps it's worth remembering that this thread spun off one about adding syntax to Python because the current syntax isn't capable of easily expressing an important type hinting concept (i.e. Callable). So arguing that Python is completely readable for type hints is a bit off-mark, isn't it? The question at hand is whether changes in syntax that are desirable for type hinting should be applied across the board in all of Python. I think the debate boils down to: Is it more clear for readers to have two different (but related) related syntaxes for two different (but related) purposes, or to have one Sytax that is used in different ways? Chris A addresses this specifically: base language, even without any useful semantics. And here's where reasonable people can disagree :-)

(Valid syntax without semantics is what we have with the matmul operator. I can syntactically parse "f@g(y)" because I know how the matmul operator works, even without knowing the data types involved.

If "x->y" is syntactically valid anywhere in Python code, it's not a

Sure: because it's a binary operator like all the other binary operators. problem that there are no core data types for which it's meaningful.) Here's where I'm not so sure -- this looks a lot like a binary operator, but it behaves quite differently. IIUC it would always create a Callable, regardless of what the types were of the two other types. And it would not invoke a dinder on either, yes. Nor would it be like assignment. This is even worse than the use of [] in type hinting which is also using the same sytax for a very different meaning -- at least that one is stil calling __getitem__ :-) -CHB On Sat, Jan 8, 2022 at 8:46 PM Steven D'Aprano <steve@pearwood.info> wrote:

On Sat, Jan 08, 2022 at 06:30:53PM -0800, Ethan Furman wrote:

...

On 1/8/22 5:46 PM, Steven D'Aprano wrote:

...

[...] if you hate type annotations because they are unreadable, then you hate Python because Python is unreadable.

Not so.

Are you disputing that annotations use the same syntax as other Python expressions? If not, I don't see how you can deny that "type annotations are unreadable" implies "Python expressions are unreadable", which in turn implies "Python is unreadable".

...

A simple list comprehension is (usually) quite readable, while a triply-nested list comprehension all on one line is not.

Indeed. We can abuse any syntax. So do we conclude that comprehensions are "unreadable" because we can write obfuscated triply-nested list comprehensions?

...

Similarly, adding type information in between a variable name and its value is not (for me, and apparently others too) readable.

I think that "unreadable" or "not readable" is a complaint that gets overused, often for the most trivial cases, to the point that it loses all credibility. Especially when it comes from people who are fluent in C (which may not be you, Ethan).

http://unixwiz.net/techtips/reading-cdecl.html

"Easily learned", huh. I think that this is one of the clearest examples of the curse of knowledge as it applies to programming that one could hope to find.

Anyway, let's compare:

# C int n = 44;

# Pascal var n: integer; n := 44;

# Typescript var n: number = 44;

# Java int n = 44;

# Python n: int = 44

There are millions who find the C, Pascal, TypeScript and Java perfectly readable. I don't find it credible that people are incapable of reading the last one.

Aside: such a type hint is redundant, as mypy is perfectly capable of inferring that n = 44 makes n an int. Style guides should recommend against such redundancy, and I would certainly flag that in a code review. A better example of a *useful* type hint would be:

L: list[str] = []

...

Most horribly of all, cluttering a function header with type information is most unreadable.

I hear you. Adding redundant or unnecessary type hints to parameters just for the sake of having type hints is just clutter, especially if they are never tested by actually running a type checker over the file.

(Untested code is broken code. If not right now, it soon will be.)

Fortunately, we have *gradual typing*, and nobody should be forced to use type hints in their projects if they don't want them. Just as we don't make linters mandatory, we don't make typing mandatory either.

I think that, outside of very simple functions, once we make the decision to annotate a function, we should space them out:

# Better def func(spam: list[str], eggs: float, cheese: str = 'cheddar', aardvark: str|bytes = "", eels: Optional[Tuple[int, str]] = None ) -> Hovercraft:

which makes them much easier to read.

Trying to cram them all into one line is abuse of the syntax every bit as bad as cramming a triply-nested list comp into one line:

# Worse def func(spam: list[str], eggs: float, cheese: str = 'cheddar', aardvark: str|bytes = "", eels: Optional[Tuple[int, str]] = None) -> Hovercraft:

I can read it, I just don't want to. It is too much like hard work compared to the previous layout.

Even if you don't run a type-checker, those annotations can make useful documentation. (At least *sometimes*.) If the parameter name doesn't make it clear what types are allowed, then the annotation can make it clear. So if you don't use a static checker, you can think of type annotations as introspectable documentation.

...

I started using Python at 2.5. It was simple, clean, and elegant.

And I started using Python at 1.5, when the syntax was even simpler and cleaner. And to this day I will never forget the first time I read Python code, after being told repeatedly how easy to read it, and I couldn't make head or tails of it. All those colons and square brackets, it might as well have been APL. (Not that I knew what APL was back then.)

I knew what a for-loop was, from Pascal, Hypertalk and HP RPN calculators:

# Pascal for i := 0 to 10 do begin block; end;

# Hypertalk repeat with i = 0 to 10 block end repeat

# HP-48 RPN language 0 10 FOR I block NEXT

but I kept seeing loops like this in Python:

for i in range(11):

or worse:

for somename in [stuff, thing, another_thing, widget]:

and worse of all:

for somename in values[1:-1]:

Python for loops looked nothing like any for loop I had seen before, and they freaked me out, and at the time (early 1990s) there was no publicly available internet where I could look anything up or ask for help.

And then there were the brackets. Why does Python sometimes use round brackets, sometimes curly brackets, and sometimes square brackets? x[a] versus x(a)? Why were there sometimes colons inside square brackets and curly brackets {a:b} but never inside round brackets? What was the difference between [1, 2, 3] and (1, 2, 3)?

The whole thing was intimidating, and I just put Python away for about a year and didn't look at it again until I had bought Mark Lutz' "Python Pocket Reference" which helped me make sense of it all. That and his "Learning Python". And never looked back. (Since then, I've often felt that Python has spoiled me from learning other languages.

The point I am making here is not that I was a dimwit who couldn't even read Python, but that "easy to read" and "readable" is more a matter of familiarity than an inherent property of the language itself. With enough familiarity, even APL is easy to read.

...

If I had stumbled on it at 3.16 with samples, tutorials, and books all infused with typing clutter (which *looks* like boiler-plate even if it isn't) I wouldn't have given it a second glance.

And again, I hear you. I too wish people would tone down their enthusiasm for adding typing to examples that don't need type hints.

We should remember that type hints are a feature aimed at large code bases, where static typing really is valuable. For three line example functions, not so much, not even as documentation.

-- Steve _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/35G7WXSH... Code of Conduct: http://python.org/psf/codeofconduct/

-- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

El dom, 9 ene 2022 a las 10:50, Chris Angelico (<rosuav@gmail.com>) escribió:

On Mon, Jan 10, 2022 at 3:49 AM Christopher Barker <pythonchb@gmail.com> wrote:

...

...

If "x->y" is syntactically valid anywhere in Python code, it's not a problem that there are no core data types for which it's meaningful.)

Here's where I'm not so sure -- this looks a lot like a binary operator, but it behaves quite differently. IIUC it would always create a Callable, regardless of what the types were of the two other types. And it would not invoke a dinder on either, yes.

Nor would it be like assignment.

This is even worse than the use of [] in type hinting which is also using the same sytax for a very different meaning -- at least that one is stil calling __getitem__ :-)

From my understanding, "x->y" would create a Callable if given two *types*, but its meaning if given two other objects is still undefined. So there's still room for it to be an operator, just like [] is, and for it to be given semantic meaning for the 'type' type and all of its subclasses. Or alternatively, there's room for it to be given meaning in a completely different way, but still universally (there's a proposal for it to be a form of inline function, although I'm not 100% sure of the details there).

With the current iteration of PEP 677, `(x) -> y` would return a special object (defined in the `types` module) that simply holds whatever `x` and `y` evaluate to. You could put whatever expression you want at runtime and it would work, though a static checker may be unhappy with you.

ChrisA _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/R6OIHWU5... Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Jan 10, 2022 at 12:05 PM Steven D'Aprano <steve@pearwood.info> wrote:

On Mon, Jan 10, 2022 at 05:39:42AM +1100, Chris Angelico wrote:

...

From my understanding, "x->y" would create a Callable if given two *types*, but its meaning if given two other objects is still undefined.

The PEP requires parentheses around the argument list, so that would be a SyntaxError.

That's a small restriction that makes it less clear as an operator, but sure, pretend I wrote "(x)->y" in the examples.

The PEP also states that the arrow syntax would be equivalent to calling Callable. Callable currently enforces that the return type actually is a type, but doesn't check the input types.

(I don't know if that is a deliberate design or an oversight.)

Assuming that it is an oversight, I would expect that only the following values would be legal for the x and y objects:

- a type; - a string (which gets converted to a ForwardRef); - None;

and anything else would result in a TypeError.

TypeError is absolutely fine; it's still part of the core language syntax.

...

...

1 @ 3 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for @: 'int' and 'int'

If I want to create my own class that responds to matmul, I can do that, even though core data types will all TypeError; it's part of the core language and has syntactic, if not semantic, meaning in any context. ChrisA

TL;DR: declaration only syntax is a non-starter. Even if we tried to add specialised syntax that only appears in annotations, it would become a regular Python expression almost immediately. On Sun, Jan 09, 2022 at 08:42:14AM -0800, Christopher Barker wrote:

Is it more clear for readers to have two different (but related) related syntaxes for two different (but related) purposes, or to have one Sytax that is used in different ways?

That is not a valid "either/or" choice. The choice is: * Python expressions that have multiple meanings (the status quo); (e.g. subscripting `obj[x]` already had 4+ meanings before its use in typing) * or Python expressions that have multiple meanings, PLUS new declaration syntax that is only valid in annotations. And I will argue below that the culture of Python is such that the second choice is practically *impossible* without a radical shift in the culture. Let's say that we decide to add specialist declaration-only syntax for type-hints. What next? First, we need a way to distinguish between type-hints that are declarations from type-hints that are expressions. Let's say that we use the proposed t-string syntax: spam: t"declaration goes here" That tells the interpreter to treat everything inside the quotes as a pure declaration, not an expression, with no runtime effect. I'm going to put aside the question of what syntax is allowed for the declarations inside the quotes, because that's actually not that important. What happens after we add this declaration syntax? The first thing that happens is that people interested in runtime processing of annotations will want to inspect the declaration, without having to scan the source code (which might not be available). Python has a strong culture of runtime introspection, starting with dir() way back in Python 1.x days, so if you think the core devs are going to resist the call to make those annotations visible at runtime, I think you are remarkably ~~wrong~~ optimistic :-) That means that the declaration has to have a runtime effect. Something has to go into the `__annotations__` dict: __annotations__['spam'] = ... # what goes here? (It doesn't matter precisely what the value that goes into the mapping is, it could be a string, or a type object, whatever it is, it is a value.) So our declaration is no longer a declaration, like `global`, it is an expression that returns a value. The parser merely restricts its use to annotations like `spam: t"declaration"`. Why can't we use that nifty new declaration syntax in type aliases? I mean, it already evaluates to a value that can be inspected at runtime, so we just have to relax the restriction on where it can appear so we can use it in type aliases as well as directly in annotations: T = t"declaration goes here" spam: T|None But if we can do that, then our declaration is just another expression. It has a value, it can appear outside of annotations. People are going to want to treat it as a first-class value (no pun intended), even if only for testing purposes: # Unit tests for T in [t"declaration", t"another declaration", t"yet another", t"my hovercraft is full of eels"]: self.assertIsInstance(T, typing.Generic) ... Even if it doesn't happen from day 1, rapidly whatever restrictions on where the syntax is allowed will be relaxed, because that's the sort of language Python is. Once we make that first (and inevitable!) step to give these type declarations an introspectable value, then they will become first-class expressions as sure as death and taxes. So I maintain that *declaration only syntax* is doomed. Whatever syntax we invent, there is going to be irresistable pressure to make it a first-class expression and not just restrict it to annotations. And if that is the case, then why do we need the t-string quotes? That's not a rhetorical question. Something like t-string quotes, or some other pair of delimiters, *may* be useful if we have our hearts set on syntax which is radically different from regular Python expressions: spam: t"array 1 to 50 of int" # Hybrid of Pascal and Hyperscript eggs: t"{(+⌿⍵)÷≢⍵}" # I don't even... Just as we have `[ ... ]` delimiters for list comprehensions. Maybe it turns out that there are cases where we need delimiters. But if so, I hope they aren't quotation marks (with or without the t-prefix), since that will be confusing as far as the existing use of strings as forward references. But why do we want type hints to be so radically different from regular Python expressions? How does that make typing easier to read and the language less complicated, if we have to learn *two* languages to be fluent in Python instead of one? Outside of that, the t-string delimiters are redundant. There is no need to wrap the proposed arrow syntax in quotes, as the PEP makes clear they can be handled just fine as an expression. The arrow expression doesn't need extra delimiters, it adds nothing. They're just noise.

...

If "x->y" is syntactically valid anywhere in Python code, it's not a problem that there are no core data types for which it's meaningful.)

Here's where I'm not so sure -- this looks a lot like a binary operator, but it behaves quite differently.

How is it different? Aside from the syntax requirement that the left operand is parenthesized, we can treat it as an operator: (one of more input args) arrow operator return-arg Whether the parser treats it as a binary operator or something different, like the dot name.expression, isn't really important. It is a symbol that has a left-operand and a right-operand, using infix syntax. I call that an operator, at least in informal language. There's no dunder for the arrow, just like `is`, `is not`, `or`, `and`, `not`, so no operator overloading. Just like `is` etc. They are still operators. And just like other operators, if you pass the wrong input types, it will raise a TypeError. -- Steve

On Sat, Jan 08, 2022 at 08:36:57PM -0600, Skip Montanaro wrote:

...

So if you hate type annotations because they are unreadable, then you hate Python because Python is unreadable.

That seems rather harsh. I suspect if those of us who are uncomfortable with the typing subsystem actually hated Python we would have found our way to the exits long ago.

Right. That's my point, or at least part of it. I've read heaps of complicated, confusing, even outright obfuscated Python expressions. Some of it even written by me, that a couple of months later I couldn't work out what I had done. So did I conclude that "Python expressions are unreadable"? No I did not. When I read an obfuscated, confusing, complex type hint, do I decide that all type hints are "unreadable"? No I don't do that either. Here is the type hint for `len`, taken from the stub file in typeshed: def len(__obj: Sized) -> int: ... Putting the mysterious double underscore naming convention aside, I do not find it credible that anyone capable of programming Python beyond a beginner level can find that "unreadable". Not by any definition of unreadable I can think of. Even if you can't guess what "Sized" means, it isn't that hard to track it down: from typing import Sized # among many others and from there to collections.abc. This is not brain surgery folks :-) https://www.youtube.com/watch?v=THNPmhBl-8I We should not dismiss all of typing as "unreadable". Type hints are just expressions. If you can read Python expressions, you can read type hints. Some are simple, some are complex, some are confusing. We should do our best to improve the complex and confusing ones, using all the tools at our disposal: * named type aliases; * style guides for laying out the annotations to make them physically easier to read (one parameter per line in complex function signatures works for me); * improving the `typing` module DSL; * perhaps even adding new syntax like the arrow syntax; but we shouldn't dismiss the whole thing as "unreadable" if what we actually mean is "its unfamiliar and I don't like it".

Typing was always supposed to be optional,

And it still is. Alas, we can't do anything about third-party projects mandating type hints (maybe they have a good reason for mandating them!). But perhaps we can help discourage some of the excessive zeal for annotating everything in sight.

so I didn't worry too much about it at the time. As Jack indicated though, while it may be optional at the language level, it's often not truly optional at the organizational level.

We can't prevent organisations and third-parties mandating the use of linters, or IDEs, or particular naming conventions, or any other style convention they want. PEP 8 zealotry is especially prevalent out in the world. I've come across people with their own idiosyncratic style, like "Never use comprehensions, only for-loops", and others who insist "Never use for-loops, only comprehensions". What are we going to do, dismiss comprehensions as a bad idea because some people are irrationally pro- or anti-comprehensions? I don't think so.

As you indicated, there are two things going on, Python syntax and the semantics which go along with it. Python's economical syntax is a terrific reflection of its runtime semantics, hence the use of the phrase "executable pseudocode" to describe Python (at least in the past).

Right. Beyond the easy cases, typing is hard. It is often easier to write code that works for typical data you care about, than to convince the type-checker that the code works :-) I don't know if this applies to gradual typing, but I imagine it probably does. Type checking is a hard problem, and if your type system is powerful enough to use, it is undecidable: http://composition.al/blog/2017/02/27/why-does-a-turing-complete-type-system... https://forums.swift.org/t/swift-type-checking-is-undecidable/39024 Even if your type system is not Turing complete, it is still going to be pretty powerful. We're not using Pascal any more :-) And that means that the types themselves are communicating some fairly complex semantics. Blaming the syntax for something which is inherently hard is not helpful.

Just because you are using Python syntax for your declarations doesn't mean that (a) mapping the semantics of the desired declarations onto existing syntax will be straightforward or (b) that the semantics of those declarations will be reflected as effortlessly as it reflects runtime semantics.

Indeed. And we can say the same thing about using Python syntax as code. Mapping the semantics of your desired behaviour into syntax is not always straightforward, nor is reading the code and inferring the semantics. If it were, anyone could be a rockstar ninja coder, and programming would be a minimum wage job. We accept without blinking comprehensions, decorators, descriptors, metaclasses, multiple inheritence, horrifically complex class hierarchies, abstraction on top of abstraction, design patterns, metaprogramming, threading, async programming and more, all of which can at times be every bit as complex as typing. I've even had the pleasure of trying to understand Continuation Passing Style in Python. The code clearly worked, but I'm damned if I could understand how. As programmers, there is a ton of complicated stuff we have to deal with. So why the hate towards type hints? -- Steve

On 9/01/22 2:46 pm, Steven D'Aprano wrote:

if you can read expressions:

spam(eggs | cheese, aardvark)

then you can read type expressions:

Spam[Eggs | Cheese, Aardvark]

That's like me saying that I can read Greek just because I know how to pronounce the letters. I do, but that doesn't mean I know what any of it means! Most of the effort of learning to read type expressions, in any language, is learning their semantics, which is very different from value expressions. Whether they happen to superficially resemble other parts of the language is pretty much irrelevant to me. -- Greg

Barry:

The advantage to users of keeping the languages the same is that readers of your code don’t have to learn two disparate syntaxes to make sense of what they’re reading. One of Python’s enduring strengths has been its readability.

Agreed. But if the little language is (a) clearly flagged and (b) has a different domain I think this is much less of a problem. I don’t think f-strings are seen as a problem, far from it, because they’re clearly flagged. That’s why I suggested t-strings. And while from a Python parser point-of-view the grammar of current type expressions are the same as the grammar of other Python code I think that for human readers this is not the case: there’s a lot of square brackets but nothing is being indexed, to name one major readability issue... Stéfane:

Using the same syntax may have some benefits for language implementors (e.g. less complex grammar to implement), but I don’t really see these benefits for language users.

As an example, and I don’t know if this has been discussed before, I think a pretty neat syntax construct for optional argument would be (like, for instance, in Kotlin):

def f(x: int? = None): ...

I introduced the t-strings specifically because I think it would be beneficial to have the little language a clearly flagged and have as little interaction with “normal” Python as possible. Your example here works fine for Optional, and looks pretty understandable if you know C# (or apparently Kotlin), but it doesn’t solve all the other problems with readability. And I think you’ll quickly run out of constructs once you try to fix more problems if you don’t want to clash with existing Python syntax… -- Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

On 9 Jan 2022 at 02:22:31, Steven D'Aprano <steve@pearwood.info> wrote:

On Sat, Jan 08, 2022 at 12:59:38AM +0100, jack.jansen@cwi.nl wrote:

I posted this suggestion earlier in the callable type syntax discussion, at which point it was completely ignored. Possibly because it’s a really stupid idea, but let me post it again on the off chance that it isn’t a stupid idea but was overlooked.

...

If I can make a wild suggestion: why not create a little language

...

for type specifications?

Any time we are tempted to prefix a question with "Why not ...", the question is backwards. The right question is, "why should we ...".

Python is 30 years old and mature, with a HUGE ecosystem of users, libraries, tooling, etc. It is far, far easier to get changes wrong than to get them right, which is why we should be conservative when it comes to language changes (including syntax). Changes to the language are "default deny", not "default accept", and it is up to the proponents of the change to prove their case, not for opponents to disprove it.

I agree 100% on these principles. As a counter-argument, in this specific case, I’d say that the Python typing ecosystem is only ~5 years old and still evolving rapidly, so these principles apply with less force. I personally believe that the syntax for type annotation doesn’t have, from the point of view of users, to be strictly Python, as long as it’s pythonic. I can sympathise with the idea of repurposing the regular Python syntax to describe types, and agree that it makes easier to bootstrap tools (typecheckers, IDEs…) but I think it has its limits in terms of expressivity, first. Second, I think willing to keep the same syntax constructs for the sake of lowering the cognitive burden of new developers is a red herring. These are two different languages, with entirely different semantics, and the links between them is not complement intuitive. As an example (just for the sake of argument, I’m not proposing this kind of change) one could argue that 'list[int]’ doesn’t really relate to how lists are constructed or how the bracket operator is used in regular Python. A more intuitive construct (from this point of view) could have been ‘[int…]’. Same for dictionaries: ‘dict[int, str]’ vs. ‘{int: str}’ which looks closer that how dictionaries are constructed in Python. S. -- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Co-Founder & Co-Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel Libre (APELL) - https://www.apell.info/ Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) - https://www.euclidia.eu/ Founder, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/