Proposing a struct syntax for Python (snarky.ca)

How does this avoid name collisions with the built-in standard library module "struct"? Don't you think that's a pretty important consideration?

This is already handled with dataclasses

https://docs.python.org/3/library/dataclasses.html#module-da...

..and the syntax is way better, handling more members, with room to document, handling methods, and not conflicting with Mojo or stdlib

    class A(BaseModel):
      status: Literal["success"]

    class B(BaseModel):
      status: Literal["error"]

    class C(BaseModel, ABC):
      __root__: Union[A, B] = Field(discriminator="status")

    aorb = C.parse_obj(blah…).__root__

    if aorb.status == "error":
      # aorb will type check as B.

Don’t steal Mojo’s mojo

Oh no, not more unnecessary syntax

To add this to python I feel like you would have it has an external package and or write a pep about it and judge by how prevalent it becomes due to the fact that it says it will replace other features…

Here's a long-running question I have; please tell me if I'm confused / missing something obvious.

Say I want to model in Python some collection of key-value pairs. It's a singleton -- I don't need a class or namedtuple that can be instantiated. So for example, I just want something like:

  SingletonDataContainer Config:
      root_directory: str = "/tmp"
      should_frobnicate: bool = False

So of course, it could be a dict. But I want type annotations, and dotted attribute access syntax (and pretty syntax-highlighting!). It's tempting to use a class with class attributes for this, but that seems wrong since then you end up with something that can be instantiated, but which you never actually want to instantiate.

    from importlib.machinery import ModuleSpec
    import importlib.util
    import sys

    spec = ModuleSpec("mymodule", loader=None)
    module = importlib.util.module_from_spec(spec)

    module.__dict__.update({"a": 42})

    sys.modules["mymodule"] = module

    import mymodule

    print(mymodule.a)  # -> 42

   import sys
   from types import SimpleNamespace
   sys.modules["mymodule"] = SimpleNamespace(b=37)

   import mymodule
   print(mymodule.b)  # -> 37

   # ^^^ This is literally just calling __getattr__ on the module object. Do with that what you will.

  Module MyModule
      a = 42
      b = 37

    import sys

    class DataModule:
      def __init_subclass__(cls):
        sys.modules[cls.__name__.lower()] = cls

    class MyModle(DataModule):
      a = 42
      b = 37

    import mymodule

    mymodule.a == 42

    def datamodule(cls):
        sys.modules[cls.__name.__.lower()] = cls

    @datamodule
    class MyModule:
      a = 42

    import mymodule
    mymodule.a = 42

  class Config:
      root_directory: str = "/tmp"
      should_frobnicate: bool = False
  
  if __name__=="__main__":
      print(f"{Config.root_directory=}\n{Config.should_frobnicate=}")

    const config = {
      rootDirectory: "/tmp",
      shouldFrobnicate: false,
    }

    from dataclasses import dataclass
    
    def _create_config():
      @dataclass(kw_only=True)
      class Config:
        root_directory: str = "/tmp"
        should_frobnicate: bool = False
      return Config()
    config = _create_config()

    @iife
    def config():
      @dataclass(kw_only=True)
      class Config:
        root_directory: str = "/tmp"
        should_frobnicate: bool = False
      return Config()

I'm on board with wanting an alternative to dataclasses that's faster, doesn't require types, and is less noisy (having to put @dataclass on its own line before every class is annoying when defining many small dataclasses).

But not having methods would produce APIs that feel really non-idiomatic. Essentially all Python types have methods, even immutable 'pure data' types. str has methods (though some things like `len` and regex search, which are methods in other languages, are functions in Python). int has methods (though they're rarely used). Immutable standard library classes – say, datetime or Path – have lots and lots of methods.

And inheritance… well, I could live without it but I've made good use of inheritance with dataclasses.

And as others have mentioned, the syntax is awkward.

I think my ideal solution would basically be dataclasses, but implemented in C and with more syntax sugar:

    # Instead of "@dataclass\nclass Foo:"
    struct Foo:
        # Allow untyped fields:
        x

        # Make this do what you'd expect, instead of
        # requiring "field(default_factory=list)":
        y = []

        # Of course, types are still allowed:
        z: int = 0

Methods and inheritance would be allowed as usual.

It might be interesting if these structs acted as true value types, so that e.g. just assigning an instance from one variable to another would make a copy of all the fields. That way you could mutate the object without worrying about sharing. But arguably, having both value types and reference types would overcomplicate the mental model.

> I want syntax that will keep people from using collections.namedtuple() just for its attribute API and ignoring/regretting its index API.

The author is proposing a worse dataclass, because they don't want to ignore positional indexing on namedtuple?

Type creep can be a serious concern for dynamic language ecosystems. The Javascript/Typescript schism is a tragic case in point. It appears that young developers are indoctrinated into the belief that strong types are an invincible hammer and can't see the drawbacks that lack of flexibility can introduce. Clojure began with defstruct, and Rich Hickey regrets its addition to the language now. While python certainly is a kitchen sink language, and the addition of structs on top is probably sustainable, but I am of the belief that such suggestions need more counter-arguments lest we lose another mainstream dynamic language to naive good intentions.

What's unsaid here, is that such construct could be optimized way more for speed than data classes because:

- it's immutable

- doesn't have methods so no overloaded operator or dynamic attribute/index accesss

- shape is known and is set in stone

That's why Mojo has them, and why they are the bread and butter in Rust.

It's one of the step in the direction of a faster Python.

I dislike this general mode of defining an ADT by first having to create multiple separate nominal types and then combining them using another free-floating statement (e.g. 3 dataclasses and then a Union in Python). An ADT is conceptually one thought, so its definition should syntactically be able to be one statement too.

i want something like this for lots of reasons, but the headliner is structual typing.

It should be possible to get simple attribute access while not creating a new nominal type and not going outside the Python stdlib.

I'm constantly using NamedTuples when what i really want is an anonymous struct.