What the future of this? I looked at type annotations in networkx recently ( https://github.com/networkx/networkx/pull/4014), and I wanted to keep things simple, so I proposed and implemented Graph[NodeType] However, I knew that they may ultimately want Graph[NodeType, EdgeTypedDict, NodeTypedDict] but no one is going to want to replace their calls with Graph[str, dict[str, Any], dict[str, Any]] That's what too noisy. This proposal would allow you to have default parameters. But what's the future looking like now? Do we expect to have a type constructor? class Graph: def T(node_type, edge_type_dict=..., node_type_dict=...) -> a type annotation And then g: Graph.T(whatever) = Graph(....) Does that work? On Friday, July 10, 2020 at 4:20:58 AM UTC-4, Stefano Borini wrote:
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 <and...@tantosonline.com <javascript:>> 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 -- python...@python.org <javascript:> To unsubscribe send an email to python-id...@python.org <javascript:> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6OGAFD... Code of Conduct: http://python.org/psf/codeofconduct/
-- Kind regards,
Stefano Borini _______________________________________________ Python-ideas mailing list -- python...@python.org <javascript:> To unsubscribe send an email to python-id...@python.org <javascript:> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UHVZLO... Code of Conduct: http://python.org/psf/codeofconduct/