[Python-ideas] Re: Generics alternative syntax
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. I am not per se convinced of the syntax I wrote. Any suggestion to make it better is more than welcomed, which I clearly stated in the post. I don’t know the covariance thing either but I put it there because TypeVar function has those keyword parameters. So if we are going to replace TypeVar, the alternative needs to have them as well. The reason this might be wanted is to reduce global variables for the TypeVars and make them contained/local to the class and function. When I encounter functions or classes with those TypeVars in people codes, I have to scroll up to see what they represent. Several languages are opting to make the generics bound to the function/class, so it’s not like what I am bringing here is completely insane. But I understand if the syntax is not suitable for python or if it will add unnecessary complexity to the developers and users for little gain. Abdulla > On 8 Feb 2022, at 9:49 AM, Stephen J. Turnbull > wrote: > > Abdulla Al Kathiri writes: > >> Sorry to bother you again with the generic thing. >> Golang will soon release a new version with Generics. I like their >> way of doing it. Like Rust, they don’t bother with TypeVars. It >> makes you wonder why we are not doing something similar in Python. > > Typing syntax at present is required to be Python syntax. New typing > syntax must be introduced to Python, so this is a huge hurdle and you > probably won't get much sympathy here, because most of us have no idea > what you're talking about, and the syntax looks awful if you don't > know why you'd even want it. Even helpful discussion is going to be > in short supply on this list (for example, I myself understand the > definition of covariance when I read it, but I still have to look it > up every time :-). > > Your audience is really in the Typing SIG. Happy hunting! > > Steve > > > ___ 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/OXBZC7GHD75GTUIBJSTP5IPVUFOYNIIO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Generics alternative syntax
Abdulla Al Kathiri writes: > Sorry to bother you again with the generic thing. > Golang will soon release a new version with Generics. I like their > way of doing it. Like Rust, they don’t bother with TypeVars. It > makes you wonder why we are not doing something similar in Python. Typing syntax at present is required to be Python syntax. New typing syntax must be introduced to Python, so this is a huge hurdle and you probably won't get much sympathy here, because most of us have no idea what you're talking about, and the syntax looks awful if you don't know why you'd even want it. Even helpful discussion is going to be in short supply on this list (for example, I myself understand the definition of covariance when I read it, but I still have to look it up every time :-). Your audience is really in the Typing SIG. Happy hunting! Steve ___ 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/HZQCGWHZVKDCOI4IWQUEYV4TGSUVFUDO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Generics alternative syntax
Hello all, Sorry to bother you again with the generic thing. Golang will soon release a new version with Generics. I like their way of doing it. Like Rust, they don’t bother with TypeVars. It makes you wonder why we are not doing something similar in Python. [T: Type] ——> T is invariant and Type is the bound. [T] is Ok. [T_co:: Type] ——> T is covariant and Type is the bound. [T_co::] is Ok. [T_contra::: Type] —-> T is contravariant and Type is the bound . [T_contra:::] is Ok. Or some other symbol next to : to distinguish the variance. [T: Type1 | Type2] —-> T is invariant and Type1 and Type2 are the constraints. Or anything else to communicate these are constraints (maybe enclose them in parentheses — tuple) Example: class Indexable[T_co::](Protocol[T_co]): def __getitem__(self, n: int) -> T_co: … @dataclass class AInt: seq: list[int] def __getitem__(self, n: int) -> Int: return self.seq[n] @dataclass class BStr: seq: list[str] def __getitem__(self, n: int) -> str: return self.seq[n] def get[T: int | str](n: int, object: Indexable[T]) -> T: return object[n] get(1, AInt([1, 2])) # ok get(1, BStr([“one”, “two”])) # ok Abdulla Sent from my iPhone ___ 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/3EKKM6JEJYH2XN6OCIBUPCH7PLTEXVMN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Consider moving abstract method checking logic from ABCMeta into object
Currently, some type checkers rightly complain that a method is decorated with abc.abstractmethod when the class's type does not inherit from ABCMeta. Adding a metaclass is a fairly heavy dependency since you're forced to poison all of your other metaclasses with the same base metaclass. It also brings in possibly unwanted type registration that ABC comes with. Now that abstractmethod's usage is extremely well-understood, would it make sense to move the checking logic out of ABCMeta? It could either be put into object so that no base class is necessary (at the cost of slightly slower class creation), or else in a non-meta base class (say, HasAbstractMethods) now that __init_subclass__ is in all extant versions of Python. Inheriting from such a non-meta base class would avoid the poisoning problem described above. As far as I can tell, neither solution breaks code. Best, Neil ___ 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/XXWLARRYM2D4R6RHMP5CTQ7WN2WXU6TK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Mapping unpacking assignment
> On Feb 7, 2022, at 1:55 AM, Chris Angelico wrote:
>
…
> def spam():
>bird = "Norwegian Blue"
>volts = 4e6
>return "{volts}V insufficient to voom {bird}".format(**locals())
This is completely off topic, but: the better way to do this is with
.format_map(locals()).
This public service announcement is part of my goal to increase knowledge of
format_map().
Eric
___
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/546JXWP7JCXQ3GLAUQYE77FM2DYCCHBU/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Mapping unpacking assignment
On Tue, 8 Feb 2022 at 01:27, Eric V. Smith wrote:
>
>
> > On Feb 7, 2022, at 1:55 AM, Chris Angelico wrote:
> >
> …
> > def spam():
> >bird = "Norwegian Blue"
> >volts = 4e6
> >return "{volts}V insufficient to voom {bird}".format(**locals())
>
> This is completely off topic, but: the better way to do this is with
> .format_map(locals()).
>
> This public service announcement is part of my goal to increase knowledge of
> format_map().
>
Fair point. Still, my original statement was that it is even better to do it as:
return f"{volts}V insufficient to voom {bird}"
which treats it fully as code. But if the information wasn't from
locals and was from some other dict, then yes, I fully accept the
correction, format_map would have been the correct choice.
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/FGIZLGYEVG6BBOEPJB2H72I2NBMQB6X7/
Code of Conduct: http://python.org/psf/codeofconduct/
