3 ms·

Next step: Auto-inferring the correct (most narrow) TypedDict type from a frozendict. (Think `const foo = { … } as const` in TypeScript.) I miss this TS feature

Next step: Auto-inferring the correct (most narrow) TypedDict type from a frozendict. (Think `const foo = { … } as const` in TypeScript.) I miss this TS feature in Python on the daily.

tweakimp 10mo ago
Can you give a Python example of a use case for this?
virtue3 10mo ago
I also SUPER LOVE this feature. Especially when you make a type union of the keys for easier indexing.
adzm 10mo ago
Curious what this means for typescript as well; honestly I've only reached for as const rarely.
mrweasel 10mo ago
What would that do exactly? Auto-generate a TypedDict class? Bringing up TypedDict is sort of interesting, because it seems like a frozen dictionary could have been implemented by PEP 705, if typing.ReadOnly was enforced at runtime, and not just a hint to a static type checker.
- dmurray 10mo ago
  Auto-generate a TypedDict type while type checking, while doing nothing at runtime. I expect this is not a very big ask and the various typecheckers will have versions of this soon after release.
  - mrweasel 10mo ago
    Okay so basically just "inline": class MyType(TypedDict): a: str b: int or infer the type hint in: my_typed_dict: dict[str, int] = {"a": 5} It should probably be something like: auto_typed: dict[typing.Const, typing.Const] = {"a": 5} where typing.Const defaults to Any for an empty dict.
    - codethief 10mo ago
      Not sure we're talking about the same thing. Inline TypedDicts are already in the process of being formalized, see https://peps.python.org/pep-0764/ https://peps.python.org/pep-0764/ , and have experimental support in e.g. Pyright. What I meant was that foo = {"a": 5} should be inferred as foo: TypedDict[{ "a": Literal[5] }] = {"a": 5}
      - mrweasel 10mo ago
        Ah, I didn't know about PEP 795. I don't really know if I like it though. It looks like something someone invented because they don't want to write classes or specifically want to be able to access a data structure like a dict, for whatever reason. It basically provides data types, but also ensures that you have no easy way to reuse them, and it will miss cases where two data structures happen to have the same signature. It's getting a little messy when we have class, namedtuple and TypedDict, which all can do much the same thing.
        codethief 10mo ago
        > it will miss cases where two data structures happen to have the same signature. Huh. That's exactly the point: TypedDicts are structural types. > we have class, namedtuple and TypedDict, which all can do much the same thing. No, they can't. The former two are nominal types.
  - codethief 10mo ago
    After what release? Type checkers already support the various TypedDict PEPs, even those that haven't been accepted yet. Yet, none of them infers TypedDict types.
anentropic 10mo ago
Agreed... but it shouldn't need a frozendict for this IMHO TypedDict in Python are essentially broken/useless as is What is needed is TS style structural matching, like a Protocol for dicts

Next step: Auto-inferring the correct (most narrow) TypedDict type from a frozendict. (Think `const foo = { … } as const` in TypeScript.) I miss this TS feature in Python on the daily.

tweakimp 10mo ago

Can you give a Python example of a use case for this?

virtue3 10mo ago

I also SUPER LOVE this feature. Especially when you make a type union of the keys for easier indexing.

adzm 10mo ago

Curious what this means for typescript as well; honestly I've only reached for as const rarely.

mrweasel 10mo ago

What would that do exactly? Auto-generate a TypedDict class? Bringing up TypedDict is sort of interesting, because it seems like a frozen dictionary could have been implemented by PEP 705, if typing.ReadOnly was enforced at runtime, and not just a hint to a static type checker.

dmurray 10mo ago
Auto-generate a TypedDict type while type checking, while doing nothing at runtime. I expect this is not a very big ask and the various typecheckers will have versions of this soon after release.
- mrweasel 10mo ago
  Okay so basically just "inline": class MyType(TypedDict): a: str b: int or infer the type hint in: my_typed_dict: dict[str, int] = {"a": 5} It should probably be something like: auto_typed: dict[typing.Const, typing.Const] = {"a": 5} where typing.Const defaults to Any for an empty dict.
  - codethief 10mo ago
    Not sure we're talking about the same thing. Inline TypedDicts are already in the process of being formalized, see https://peps.python.org/pep-0764/ https://peps.python.org/pep-0764/ , and have experimental support in e.g. Pyright. What I meant was that foo = {"a": 5} should be inferred as foo: TypedDict[{ "a": Literal[5] }] = {"a": 5}
    - mrweasel 10mo ago
      Ah, I didn't know about PEP 795. I don't really know if I like it though. It looks like something someone invented because they don't want to write classes or specifically want to be able to access a data structure like a dict, for whatever reason. It basically provides data types, but also ensures that you have no easy way to reuse them, and it will miss cases where two data structures happen to have the same signature. It's getting a little messy when we have class, namedtuple and TypedDict, which all can do much the same thing.
      - codethief 10mo ago
        > it will miss cases where two data structures happen to have the same signature. Huh. That's exactly the point: TypedDicts are structural types. > we have class, namedtuple and TypedDict, which all can do much the same thing. No, they can't. The former two are nominal types.
- codethief 10mo ago
  After what release? Type checkers already support the various TypedDict PEPs, even those that haven't been accepted yet. Yet, none of them infers TypedDict types.

anentropic 10mo ago

Agreed... but it shouldn't need a frozendict for this IMHO TypedDict in Python are essentially broken/useless as is What is needed is TS style structural matching, like a Protocol for dicts