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
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
> - Typing is optional (there are still folks who don't want to lean into that and it simply isn't always necessary)
> - Class construction should be faster (which intuitively you would think shouldn't matter, but I have talked to folks where this is an actual concern, especially when startup time is critical)
> - Syntax typically leads to better tooling support since there's no ambiguity
> - Easier to teach than (data)classes, so can act as a stepping stone towards classes
> - Better semantics than dataclasses have by default (at least in my opinion )
Honestly why would you cater to people who want to write worse code? Should Python have a mode with implicit type coercion too because some people can't be bothered to type `int()`?
> Class construction should be faster.
It's Python. You accepted your code would be extremely slow going in. Fiddling with the syntax isn't going to make it fast.
Not that it's not worth spending some effort to optimize, of course. But the lower bound is quite high even if you're very careful.
Someone who really wants to avoid type annotations at all costs can just use ": object" everywhere
Who are people who are against typing in this day and age?
People who don't find the benefits of typing are worth the overhead?
Python is, after all, a dynamically-typed language, so it is, surely, not too surprising that those who use it might include those who want a ... dynamic language ?
If it's too much to take the joys of Java are freely available.
What overhead, specifically?
I've found it reduces overhead. Rather than using English to describe the types, in the comments/docstrings, I can just type the terse type hint in the function definition, and leave the rest to the documentation renderer. If you don't document anyways, sure.
FWIW I think this article mentioning them at all is sort of weird because the article doesn't propose them either, lmao
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.I was looking for a solution in pydantic that is wildly relevant. Thanks, I didn’t realize that was implemented/existed.
My only objection is using ABC in your MRO. Haha, just a little bit overloaded with abstract base classes and using A, B, and C.
I got it eventually! Cool.
I don't know if type checkers can figure out if a pattern match statement is exhaustive yet though, that would be interesting.
[1]: https://stackoverflow.com/questions/16258553/how-can-i-defin...
Then again, you can just create newtype wrappers, and that's essentially the same thing as different constructors for a sum type.
To that end, I'm curious what defaults you didn't use?