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 
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.


On Fri, Aug 14, 2020 at 6:30 AM Paul Moore <> wrote:
On Fri, 14 Aug 2020 at 13:12, Jonathan Fine <> 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".

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: