Typing on child class' methods of a Generic base class
Hello,
I am wondering about a situation involving typing, Generic and a child
class.
The documentation about "user-defined generic types"[1] says that I can
fix some types on a child class (class MyDict(Mapping[str, T]):) but
doesn't say much about the signature of the methods I need to
implement/override on that child class.
Should I keep the TypeVar and remember that I fixed the type(alternative
1) or change the signature of the method to replace the TypeVar by the
type I set (alternative 2)?
Mypy seems to prefer the second alternative but changing the signature
feels wrong to me for some reason. That's why I'm asking :-)
Below is a small example to illustrate:
from abc import ABCMeta, abstractmethod
from typing import TypeVar, Generic
T = TypeVar("T")
class Base(Generic[T], metaclass=ABCMeta):
"""A base class."""
@abstractmethod
def _private_method(self, an_arg: T) -> T:
...
def public_method(self, an_arg: T) -> T:
from_private_method = self._private_method(an_arg)
return from_private_method
class Alternative1(Base[int]):
def _private_method(self, an_arg: T) -> T: # I keep T
return 42
class Alternative2(Base[int]):
def _private_method(self, an_arg: int) -> int: # I replace T
return 42
Thanks,
--
Nicolas Haller
[1]:
https://docs.python.org/3/library/typing.html#user-defined-generic-types
--
https://mail.python.org/mailman/listinfo/python-list
Re: PSA: Linux vulnerability
So my laziness pays. I use only LTS distros, and I update only when there are security updates. PS: any suggestions for a new LTS distro? My Lubuntu is reaching its end-of-life. I prefer lightweight debian-like distros. On Tue, 8 Mar 2022 at 19:56, Ethan Furman wrote: > > https://arstechnica.com/information-technology/2022/03/linux-has-been-bitten-by-its-most-high-severity-vulnerability-in-years/ > > -- > ~Ethan~ > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
PEPs will move to peps.python.org
With the acceptance of PEP 676, the canonical home of the Python Enhancement Proposal series will shortly move to peps.python.org. All existing links will redirect when the change is made, this announcement is to promote awareness of the new domain as canonical. Thanks, Adam Turner PEP Editor and author of PEP 676 -- https://mail.python.org/mailman/listinfo/python-list
Could frozendict or frozenmap be of some use for PEP 683 (Immortal objects)?
As title. dict can't be an immortal object, but hashable frozendict and frozenmap can. I think this can increase their usefulness. Another advantage: frozen dataclass will be really immutable if they could use a frozen(dict|map) instead of a dict as __dict__ -- https://mail.python.org/mailman/listinfo/python-list
Re: Behavior of the for-else construct
On 2022-03-07 06:00:57 -0800, Grant Edwards wrote: > On 2022-03-07, Peter J. Holzer wrote: > > On 2022-03-06 18:34:39 -0800, Grant Edwards wrote: > >> On 2022-03-06, Avi Gross via Python-list wrote: > >> > Python is named after a snake right? > >> > >> No. It's named after a comedy troupe. > > > > He actually wrote that two sentences later. > > Yes, I missed that. His messages wrap very strangely in my newsreader. Yes, he writes every paragraph as a single long line which makes it hard to read. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Could frozendict or frozenmap be of some use for PEP 683 (Immortal objects)?
I perhaps didn't understand the PEP completely but I think that the goal of marking some objects as immortal is to remove the refcount from they. For immutable objects that would make them truly immutable. However I don't think that the immortality could be applied to any immutable object by default. Think in the immutable strings (str). What would happen with a program that does heavy parsing? I imagine that it will generate thousands of little strings. If those are immortal, the program will fill its memory very quickly as the GC will not reclaim their memory. The same could happen with any frozenfoo object. Leaving immortality to only a few objects, like True and None makes more sense as they are few (bound if you want). On Wed, Mar 09, 2022 at 09:16:00PM +0100, Marco Sulla wrote: As title. dict can't be an immortal object, but hashable frozendict and frozenmap can. I think this can increase their usefulness. Another advantage: frozen dataclass will be really immutable if they could use a frozen(dict|map) instead of a dict as __dict__ -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: PSA: Linux vulnerability
On 3/9/22 13:05, Marco Sulla wrote: > So my laziness pays. I use only LTS distros, and I update only when > there are security updates. > PS: any suggestions for a new LTS distro? My Lubuntu is reaching its > end-of-life. I prefer lightweight debian-like distros. Maybe Debian itself? -- https://mail.python.org/mailman/listinfo/python-list
