I am one of the authors of the PEP. My problem was to deal with natural notation in quantum chemistry mostly. It had no technical purpose, but I still think it would open some interesting options. The PEP was rejected mostly because of lack of interest.
On Mon, 4 May 2020 at 00:07, Andras Tantos <[email protected]> wrote: > > Hello! > > I'm not sure I'm addressing the right audience here, so please direct me to > the appropriate channel if that's the case... > > My name is Andras Tantos and I'm working on a Python library desscribing HW > designs. I came across this problem of __getitem__ and co. not supporting > kwargs. Apparently this extension was proposed and rejected as PEP 472. > > Apart from my use-case, which is arguably a corner-case and not worth > modifying the language for, I believe there are two important use-cases that > are worth considering with the latest improvements in the language: > > 1. With the recent type-hint support, the feature could be made way more > descriptive if this PEP got implemented. > > For example, instead of doing the following: > > def func(in: Dict[str, int]) > > one could write: > > def func(in: Dict[key=str, value=int]) > > 2. It would also make 'generic classes' much cleaner to implement, similar to > the way type-hints look. Consider the following code: > > class _Generic(object): > Specializations = [] > @classmethod > def __getitem__(cls, *args): > name = f"Generic_{len(cls.Specializations)}" > Specialized = type(name, (cls,), {"specials": tuple(args)}) > cls.Specializations.append(Specialized) > return Specialized > def __init__(self, value = None): > self.value = value > def __str__(self): > if hasattr(self, "specials"): > return(f"[{type(self)} - " + ",".join(str(special) for special in > self.specials) + f"] - {self.value}") > else: > return(f"[{type(self)} - GENERIC" + f"] - {self.value}") > Generic = _Generic() > #g = Generic() - fails because of no specialization is given > s1 = Generic[12]() > s2 = Generic[42]("Hi!") > print(s1) > print(s2) > > Running this simple example results in: > > python3 -i python_test.py > [<class '__main__.Generic_0'> - 12] - None > [<class '__main__.Generic_1'> - 42] - Hi! > > You can see how the specialized parameters got passed as well as the ones to > '__init__'. Obviously, in real code the idea would be to filter generic > parameters and set up 'Specialized' with the right set of methods and > arguments. > > Now, without kwargs support for __getitem__, it's impossible to pass named > arguments to the specialization list, which greatly limits the usability of > this notation. > > I don't know how convincing these arguments and use-cases are for you, but > could you advise me about how to start the 'ball rolling' to drum-up support > for re-activating this PEP? > > Thanks again, > Andras Tantos > > > _______________________________________________ > Python-ideas mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/6OGAFDWCXT5QVV23OZWKBY4TXGZBVYZS/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/UHVZLOU57HS2HGH6E4JCDW6ETAIORKG7/ Code of Conduct: http://python.org/psf/codeofconduct/
