On Wed, 11 Aug 2021 at 07:37, Larry Hastings <la...@hastings.org> wrote: > [...] > I think PEP 649 should be considered in the same way. In my opinion, the > important thing is to figure out what semantics we want for the language.
I think this is a very important point. As originally implemented, annotations allowed attaching arbitrary data to function arguments and return values. That was a simple language capability, with no particular nuances, although the intended use case was very much type annotations. Later, the decision was made that typing would be the primary and "official" use for annotations - but even at that point, the semantics were still impartial. String annotations are changing the fundamental semantics of annotations (introspection returns the source code string, not a Python object) and there's even discussion of how this allows the possibility for annotations to not even conform to standard Python syntax. Surely, before we start changing the fundamental syntax and semantics of a language feature for a single (albeit officially blessed) use case, we should look at what capabilities *in the abstract* are missing from the current behaviour, and work out how or if we can implement them. Proposers on python-ideas are routinely asked to demonstrate how their suggestion affects cases other than their particular use case. Why shouldn't we hold typing to a similar PEP 563 states that it's addressing two issues: * Forward references for type hints * Module import time cost of having type hints at all Both of those are real and valid problems that deserve a solution. PEP 563 is asserting that no solution is possible within the existing semantics, and it's necessary to significantly break backward compatibility in terms of semantics, and also opens up the possibility of annotations not even being normal Python syntax in future (the PEP says that any such change would need a further PEP, but definitely does *not* say that the possibility is out of the question). PEP 649, in my opinion, is exploring the option of addressing these two issues *within Python's existing syntax and semantics*. How we look at it IMO depends significantly on how we view the whole question of typing and what it means for typing to be "optional". Personally, my experience is that typing is indeed optional for small or personal projects. But for larger projects, where there's a team of people involved, it's very hard to argue against typing. Even if you're not convinced personally that the benefits justify the costs, it's hard to make that case persuasive, so typing pretty much always wins. With that in mind, if we *are* saying (as PEP 563 is, in effect) that we're at the breaking point where we cannot support the typing use case with existing Python syntax (note that PEP 563 essentially makes annotations a new syntax for string literals[1]) then I would far prefer it if Python gave up on this ambivalent attitude towards annotations, and made a proper commitment to having a way of expressing types within the language. That means defining type syntax as Python *language* syntax and treating type syntax as subject to all of the compatibility guarantees that the rest of the language adheres to. It may still mean that we define new, type-specific syntax, but we can put it in the language definition, and say that it's only valid in annotations. That's not a showstopper. And it means that we don't open ourselves up to tool-specific interpretation of core Python syntax. What that would mean is: 1. What is valid as an annotation would probably need to be specified once and for all at the language level. That's a compatibility break, but we'd be making it with our eyes open, having found that the "a single Python expression" approach isn't sufficient for the typing use case. 2. The forward reference issue is treated as a *python language* issue, not just a typing issue. It may be that we decide to only *solve* it for typing, but we can still look to the wider context for ideas and inspiration. 3. The idea of having "special syntax" for type expressions would be dropped - it's not "special syntax" if it's part of the language, any more than assignment expressions or conditional expressions are "special syntax". It's possible that this is something that's already been discussed in the typing community. But if so, then that's a discussion that should have involved python-dev, as it's fairly basic to how Python as a language is evolving. On the other hand, PEP 647 is saying that we think that typing can still be supported with existing syntax, and we don't need to (yet) have that discussion. Although maybe the typing experts have further plans (the whole "support non-Python syntax" hint suggests that they might) that mean new syntax is an inevitability - but if so, let's get that proposal out in the open where it can be discussed, and not use PEP 563 as a "back door" to avoid that discussion. [...] > Once we figure out what semantics we want, we should implement them, and > only then should we start worrying about performance. Fretting about > performance at this point is premature and a distraction. For the forward reference question, definitely. But PEP 563 also states that it's addressing the issue that annotations have a runtime cost - and as an alternative to PEP 563, PEP 649 needs to be clear on what it's position is on that issue. I'd have sympathy for the argument "any non-trivial type annotations need the user to import the typing module, so make the runtime cost of *that* import go away, and then we'll talk". Also, I don't think that improving performance is a justification for a non-trivial backward compatibility break (I don't recall a case where we've taken that view in the past) so "PEP 649 solves forward references without a backward compatibility impact, and performance is a small issue in the face of that" is a reasonable position to take. Paul _______________________________________________ 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/YTPAKFIYTRX3XSUO7Y5QQJQ7HNNDZH7A/ Code of Conduct: http://python.org/psf/codeofconduct/
