My own personal use for this would be for generating anonymous protocols and dataclasses:

class T(Protocol):
    x: int
    y: str

# with some abuse of notation obviously these would generate unique types
assert T == Struct[x=int, y=str]

# similarly 
@dataclass
class S:
   x: int
   y: str

assert S == Struct[x=int, y=str]

I often want to create such types “on the fly” without needing to put a name on them.

Now as I don’t need mixed keyword / positional arguments I can achieve this with:

# K = dict
Struct[K(x=int, y=str)]

But that costs 3 more keystrokes and is certainly less beautiful.

While I would not personally use this I think a real killer app would be slicing named axis, as the slice syntax is exclusive to geitem and hence can not leverage the dict trick.

Caleb


On Fri, Aug 14, 2020 at 6:30 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Fri, 14 Aug 2020 at 13:12, Jonathan Fine <jfine2358@gmail.com> wrote:
> Anyone who is experimenting with keyword keys would, I think, appreciate having something they can use straight away. Thus, I think, any use case for PEP 472 is also a use case for the general keyword class I'm suggesting. No use cases for PEP 472 would of course be fatal.

When experimenting, I routinely write throwaway classes and functions like

def f(*args, **kw):
    print(f"In f, {args=} {kw=}")

I don't see why writing

class A:
    def __getitem__(self, *args, **kw):
        print(f"Getting {args=}, {kw=}")

would be any more onerous. A stdlib class that used the new syntax
should stand on its own merits, not as "something people can use to
experiment with".

Paul
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/H7KIXVO3ZB45ANYJM5U2CSNSPEFPBHT5/
Code of Conduct: http://python.org/psf/codeofconduct/