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/6OGAFDWCXT5QVV23OZWKBY4TXGZBVYZS/
>
> > 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/UHVZLOU57HS2HGH6E4JCDW6ETAIORKG7/
>
> 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/GS45OI4HLBKQ5UVYIU4V74XDROHPYNIV/
Code of Conduct: http://python.org/psf/codeofconduct/
