Personally, I very much like this approach, although I'd definitely prefer <> brackets instead, like in other languages.
We could possibly think of it as being syntactic sugar for the current TypeVar approach, and have it translated into TypeVars at runtime. However, if we'd define it that way, then these type variables would still end up in the global scope. We don't have scopes at the class/function definition level. That would mean that we can't reuse the same symbol for separate functions, unless the types are identical. Jonathan Le mar. 8 févr. 2022 à 09:15, Chris Angelico <ros...@gmail.com> a écrit : > On Tue, 8 Feb 2022 at 18:59, Abdulla Al Kathiri > <alkathiri.abdu...@gmail.com> wrote: > > > > I thought this is called python-ideas, meaning it’s ok to bring ideas > even if they are ugly or stupid. No need to introduce it in Python if it’s > too much but it might induce discussions. > > > > Yes, it's absolutely okay to bring ideas of all kinds; but every idea > has consequences. What Stephen pointed out was a consequence that you > perhaps hadn't been aware of, due to Python's type syntax being > strictly the same as its expression syntax. > > There's no such thing as "impossible", but the more barriers there are > for an idea, the more useful it has to be in order to be of interest. > Introducing a new @ operator to allow you to create an EmailAddress > class that uses it? Not interesting. Introducing a new @ operator to > allow you to multiply numpy arrays in a different way? Significantly > more interesting, even though the cost to the language is effectively > the same. (And even then it took a long time to happen, because it > broke the pattern that every operator is important to core data > types.) > > What has to change for your idea to be able to happen? > > > class Indexable[T_co::](Protocol[T_co]): > > def __getitem__(self, n: int) -> T_co: … > > This is completely new syntax: between the class name and what it > subclasses, you have a subscript-like syntax. > > This is new semantics for subclassing, I think, unless you want > Indexable to be a subclass of Protocol[T_co], but I'm not entirely > sure how to read this. New semantics aren't as hard as new syntax, > though. > > > def get[T: int | str](n: int, object: Indexable[T]) -> T: > > return object[n] > > Perhaps unsurprisingly, the new syntax needs to work for functions as > well as classes. So that's not really an additional cost, it's just > the same cost seen in another place. > > What would be the semantics of this subscripting? What would be the > meaning of, say, "def spam[42]():"? What if you leave the brackets > empty? Cute syntax on its own doesn't make an idea; the cute syntax > needs to be backed by a demonstration of how it's beneficial. > > ChrisA > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/2C6G3THB5ARRRJ6NQU7LDTNDDZOEH2EX/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5L65SMPYTS3QE4HLEJF5G4VWOT5AO5AX/ Code of Conduct: http://python.org/psf/codeofconduct/
