[Python-Dev] Re: Suggestion: a little language for type definitions
08.01.22 01:59, jack.jan...@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 def get_foo_factory(type: str, id: int) -> Factory[Foo]: ... instead of def get_foo_factory(type: str, id: int) -> Callable[[int, Iterable[str]], Optional[list[Mapping[str, Sequence[Tuple[int, Foo]]: ... ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/42A5UC246FL2C57WSXP5Y2DANFGTG4PU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
Indeed, there needs to be a way to get back and forth from the little typing
language to Python and back.
That’s why I suggested the t-string format: in analogy to f-strings you could
use {expression} constructs in there that would be evaluated in the normal
Python environment (and syntax).
For the sake of argument lets assume for now that the little language uses
- a : b to be equivalent to Mapping[a, b]
- [a] to be Sequence[a]
- (a, b) being Tuple[a, b]
- (a, b) -> c being Callable,
- *a being Iterable[a]
- ?a being Optional[a]
Then your example would become something like
T = TypeVar(’T’)
Data = t’str : [(int, T)]’
Factory = t’(int, *str) -> ?[Data(T)]’
And note that I’m making up the syntax as I’m typing. Maybe it’s much better to
use keywords (like optional, iterable) in stead of symbols).
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
> On 8 Jan 2022, at 11:32, Serhiy Storchaka wrote:
>
> 08.01.22 01:59, jack.jan...@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
>
> def get_foo_factory(type: str, id: int) -> Factory[Foo]: ...
>
> instead of
>
> def get_foo_factory(type: str, id: int) -> Callable[[int,
> Iterable[str]], Optional[list[Mapping[str, Sequence[Tuple[int,
> Foo]]: ...
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@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/42A5UC246FL2C57WSXP5Y2DANFGTG4PU/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/WAGSHSCI7TULRYM367S2SXWJOVJIHLKK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
On 8 Jan 2022 at 00:59:38, jack.jan...@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-le...@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/PDRKIUCGM257VRZCPGBVB2LN34XAIZZR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
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.jan...@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-le...@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/PDRKIUCGM257VRZCPGBVB2LN34XAIZZR/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/AYELXS66CTVDQR5QMIWRSCVGCEJ63M7X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
> ... 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
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/SHHUA4SBSEIT2GFZRYUTGF4EJHETHUY3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
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.___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/6XLUYYGPIPXMSRM5NTW4QVU3SDG6SRX4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
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. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/OLI7H6H6COIREFFY3VMJDVPJHNI5HVGS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
On Sat, Jan 08, 2022 at 12:32:35PM +0200, Serhiy Storchaka wrote: > 08.01.22 01:59, jack.jan...@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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/ZRYSXMF2HRC5HXIZLQ4FTSL44PF6TXPS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
On 8 Jan 2022, at 23:05, 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. 😉 Yeah, that was my take too, until about a year ago. 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: I changed some of the APIs because they were doing things “my way”, but that was really pretty impossible to explain to the typing system. The modified APIs are arguably cleaner. I’m not yet at the point where I’m going to type all the packages and other stuff I maintain, but I _am_ contemplating doing it, eventually, maybe, if I find the time, procrastination willing, …. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/52PLPW735QJD235BEKOBCHJREI6MWBRT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
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, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/HLHH3VFNA32M2JHJIZ5OSWKHTCZLOJLH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
On Sat, Jan 08, 2022 at 12:59:38AM +0100, jack.jan...@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.
https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html
https://www.curiousefficiency.org/posts/2011/04/musings-on-culture-of-python-dev.html
> > If you look at other programming languages you’ll see that the “type
> > definition sub-language” is often completely different from the
> > “execution sub-language”
[...]
Yes, and that makes other programming languages harder to use and harder
to learn. Even Pascal, which has a nice human-readable declaration
syntax, requires you to learn more before you can do anything. C is
particularly bad, since there are effectively three distinct languages
to learn: macros, type declarations, and C code.
Anyone who has learned enough C to get good at it is likely to under-
estimate how hard C is to learn, due to survivorship bias (those who
have survived their apprenticeship as a newbie C coder to become an
expert are not representative of all newbie C coders) and the curse of
knowledge (experts often find it hard to put themselves in the shoes of
non-experts).
So I think that we should avoid the temptation to have a distinct
language for type annotations. I think that Guido's initial reasoning,
that type annotations are Python expressions, rather than distinct
syntax for declarations, was correct, and I think that the Steering
Council is right to insist on keeping annotations aligned as Python
code.
Mind you, that doesn't necessarily mean that we cannot introduce new
syntax for use in annotations. (Just as we added three-argument slicing
and Ellipsis specifically for use in Numpy.) So long as they are usable
outside of annotations, they remain "part of the Python language" rather
than a distinct "type declaration syntax".
For example, the arrow syntax for Callable `(int) -> str` (if accepted)
could be a plain old Python expression, usable anywhere the plain old
Python expression `Callable[[int], str]` would be.
> > Python typing uses basically a subset of the execution expression
> > syntax as its declarative typing language.
I think a good way of putting it is that the typing module defines a
little DSL (Domain Specific Language) for type hints, but annotations
themselves are just Python expressions.
> > What if we created a little language that is clearly flagged, for
> > example as t”….” or t’….’? Then we could simply define the
> > typestring language to be readable, so you could indeed say t”(int,
> > str) -> bool”. And we could even allow escapes (similar to
> > f-strings) so that the previous expression could also be specified,
> > if you really wanted to, as t”{typing.Callable[[int, str], bool}”.
The following are not rhetorical questions. I don't know the answers,
which is why I am asking.
1. Are these t-strings only usable inside annotations, or are they
expressions that are usable everywhere?
2. If only usable inside annotations, why bother with the extra prefix
t" and suffix "? What benefit do they give versus just the rule
"annotations use this syntax"?
3. If usable outside of annotations, what runtime effect do they have?
The t-string must evaluate to an object. What object?
4. If the syntax allowed inside the t-string is specified as part of the
Python language definition, why do we need the prefix and suffix?
E.g. if we can write:
# Equivalent to T = Callable[[int], str]
T = t"(int) -> str"
and have the arrow syntax defined by the language, then surely the
prefix and suffix is redundant.
Likewise, if this is allowed:
def func(arr: t"array [1...10] of int") -> str: ...
why not just allow this?
def func(arr: array [1...10] of int) -> str: ...
5. What difference, if any, is there between `t"{expression}"` and
`expression`?
If there is no difference, then I don't think that the t-string syntax
adds anything to this proposal. Remove the t-string syntax, and just
write the type expression.
This is not the case with f-strings, where they actually do add
something to the code:
[Python-Dev] Re: Suggestion: a little language for type definitions
On Sun, Jan 09, 2022 at 01:30:33AM +0100, jack.jan...@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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/7L2GBLWKQYRKLUZAJBSH3EH77JXG5NLO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
On Sun, Jan 09, 2022 at 02:20:45AM +0100, jack.jan...@cwi.nl wrote: > 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 disagree. > I don’t > think f-strings are seen as a problem, far from it, because they’re > clearly flagged. On the contrary, f-strings are not really a second language. f-strings involve *ordinary Python expressions* plus a set of formatting codes which are mostly similar or identical to those used by the format method and string interpolation with the `%` operator. > 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... Nothing is being *indexed* here either: mydict[key] I don't think that Mathematica code is harder to read because it uses square brackets for function calls instead of round brackets. I challenge you to say that you cannot read these: Range[10] FindShortestPath[graph, start_vertex, target_vertext] Even when Mathematica uses syntax that is unfamiliar, I expect that you would be able to guess what this does: StringReplace["abbaabbaa", "ab" -> "X"] and if you can't, it's not because of the square brackets. As I mentioned in a previous email, I can see a number of reasons why typing is hard, but the syntax (ordinary Python expressions) is not why it is hard. We can, I think, improve elements of the typing DSL. `T|S` is, I think, an improvement over `Union[T, S]` for the same reason that `a|b` would be an improvement over `bitwise_and(a, b)` or `set_intersection(a, b)`. Likewise, I think that we should accept PEP 677 (arrow notation as sugar for Callable). But I wouldn't want to see type hints diverge into a completely different language from Python. > 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. And that is exactly why I think that it is not a good idea. Having type hints use regular Python syntax is not a design flaw to be fixed. -- Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/N42DDG3MKIVBSWHMONSBJIVMVK5H2COA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
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. A simple list comprehension is (usually) quite readable, while a triply-nested list comprehension all on one line is not. Similarly, adding type information in between a variable name and its value is not (for me, and apparently others too) readable. Most horribly of all, cluttering a function header with type information is most unreadable. I started using Python at 2.5. It was simple, clean, and elegant. 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. -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/MHS5I56U2BMCGYUILXBZN3DS2PPIGVEK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
> > 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. Typing was always supposed to be optional, 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. 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). 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. Skip ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/RSFLXNJIXM7TSIQS5GS3UOJCU7P2ULIU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
This really needs a new thread, maybe even a new PEP, but ...
On Sat, Jan 8, 2022 at 5:27 PM Steven D'Aprano wrote:
> > > 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 ...".
>
OK -- we should create a little language for type specifications because
it's proving to be really difficult to cleanly express types with Python's
current allowable syntax. This is documented by the PEP that started this
thread -- if you have to expand the syntax of Python to make clean
expression of typing possible, it's time to make a new language., rather
than complicating Python.
> ... we should be conservative when it comes
> to language changes (including syntax).
exactly -- we are now faced with changing language syntax to satisfy the
needs of one particular optional corner of Python -- we should be
particularly very careful about that!
(and it's not just callables -- there was a long thread in python-ideas
about a yeear (?) ago about extending indexing syntax, that started with
the needs of typing.
> > If you look at other programming languages you’ll see that the “type
> > > definition sub-language” is often completely different from the
> > > “execution sub-language”
>
> Yes, and that makes other programming languages harder to use and harder
> to learn.
I would argue that hat's because you have to learn type specifications at
all -- not because they have different syntax.
IN fact, in my very limited C experience I found it very confusing that
often declare a function was the same as defining it -- which is this bit
of code doing? In practice the declarations are usually in a header file,
but that's not (I think) required by the language. IT would be less
confusing if the type declaration were clearly different.
But anyway, right now in PYthon, type declarations use standard
Pyhton syntax, but they use it in a non-convensional way. Is it more or
less confusing that:
list[int]
means "a list full of integers"
and
a_list[an_int] means return the value (which could be any type) of the item
at index an_int?
Does the same syntax with very different meanings make it easier or harder
to learn??
> For example, the arrow syntax for Callable `(int) -> str` (if accepted)
> could be a plain old Python expression, usable anywhere the plain old
> Python expression `Callable[[int], str]` would be.
>
but what would `` -> `` mean ?!?! if all it meant was create an instance of
the Callable class, then you have a typing mini-language that can be used
anywhere -- more or less confusing ?!?
Or it could be used as a new way to spell lambda -- I know a lot of folks
would like a cleaner way to spell lambda, but would that really make the
language simpler?
I think a good way of putting it is that the typing module defines a
> little DSL (Domain Specific Language) for type hints, but annotations
> themselves are just Python expressions.
>
OK -- and if you had t" " -- then that would be a Python expression, too :-)
>
> > > What if we created a little language that is clearly flagged, for
> > > example as t”….” or t’….’? Then we could simply define the
> > > typestring language to be readable, so you could indeed say t”(int,
> > > str) -> bool”. And we could even allow escapes (similar to
> > > f-strings) so that the previous expression could also be specified,
> > > if you really wanted to, as t”{typing.Callable[[int, str], bool}”.
>
> The following are not rhetorical questions. I don't know the answers,
> which is why I am asking.
>
>
> 1. Are these t-strings only usable inside annotations, or are they
> expressions that are usable everywhere?
>
as you say -- not much point if they aren't usable anywhere -- why not?
> 2. If only usable inside annotations, why bother with the extra prefix
> t" and suffix "? What benefit do they give versus just the rule
> "annotations use this syntax"?
>
Agreed - -though I think there is a certain clarity about it -- also, it
would make a the transition a bit easier if the idea was adopted.
> 3. If usable outside of annotations, what runtime effect do they have?
> The t-string must evaluate to an object. What object?
>
I'm just spit-balling here, but maybe an "Annotation Object" -- which could
be a pre-compiled or normalized version of the annotation string. kind of
like a pre-compiled regex, maybe? I have not idea if MyPy and friends have
sucha. normalized version, but it does seem like it could be handy.
> 4. If the syntax allowed inside the t-string is specified as part of the
> Python language definition, why do we need the prefix and suffix?
>
> E.g. if we can write:
>
> # Equivalent to T = Callable[[int], str]
> T = t"(int) -> str"
>
> and have the arrow syntax defined by the language, then surely the
> prefix and suffix is redundant.
>
I think the idea is that , e.g. -> wouldn't b
[Python-Dev] Re: Suggestion: a little language for type definitions
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 sometime
[Python-Dev] Re: Suggestion: a little language for type definitions
On Sun, Jan 9, 2022 at 3:47 PM Steven D'Aprano wrote: > 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. > Can attest. Not specifically about APL, but there are times when I've watched an expert casually reading off a series of electrical meters or other indicators and immediately knowing what something means. For myself, I've read hex dumps as easily as software code, because specific constructs are incredibly obvious (a series of 32-bit Hollerith strings, for instance, is quite easy to read if you know what you're looking at). The most important feature of Python's type hints, like most other constructs, is knowing where one begins and ends. If you're eyeballing a massive blob of code and you find an open quote character, it should be straight-forward to figure out the extent of the string literal. If you're browsing a function and come across a 'while' loop, you should be able to find the end of that loop. And if you're reading a function's parameters, you should be able to understand how much of it is the annotation and where the next parameter begins. 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 base language, even without any useful semantics. (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 problem that there are no core data types for which it's meaningful.) ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/I6ZIGQJ525JAEAIR2VMSOION5CB2F5TI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
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-make-type-checking-undecidable/ 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, descri
