dataclass-baseclass 0.0.1

Less verbose dataclasses

Module dataclass_baseclass

DataClass - inheritable contagious base class.

Instead of (endless?) @dataclass decorating.

Usage

class A(DataClass):  # it's a dataclass

class B(A):  # it's a dataclass too

as opposed to:

@dataclass
class A(): ...  # it's a dataclass

class B(A): ...  # it's *not* a dataclass, needs decorating

@dataclass
class B(A): ...  # now it's a dataclass

Also:

class B(DataClass, A): ...  # all properties from A are dataclassed

as opposed to:

class A():  ...

@dataclass
class B(A): ...  # no properties from A are dataclassed

Instantiation

class C(DataClass):
    a: str
    b: str

defaults: Data = {"a": "A", "b": "B"}

c = C(defaults, a="a", b="b")

or just:

c = C(a="a", b="b")

Loaders

Tested with following dataclass loaders:

• apischema
• typedload
• dataclasses-json

dataclasses-json

Works with DataClassJsonMixin and from_dict() (actually _decode_dataclass().

I could not get it to work with @dataclass_json decorator, probably did not try hard enough.

Documentation and examples

Documentation

Tests should give a good idea of how to use it.

Test report

Name                     Stmts   Miss  Cover
--------------------------------------------
dataclass_baseclass.py     113      0   100%
--------------------------------------------
TOTAL                      113      0   100%

Notes / FAQ

And Pydantic?

Obvious question. Pydantic is Ok if you want to enter that world and stay there. Like Microsoft or Apple or Google. Want to share between those worlds? Good luck with that. In particular, multiple inheritance:

Straight multiple inheritance

class A(BaseModel): ...

class B(BaseModel): ...

class C(A, B): ...

The official stance on this (at least what I could figure out at the time of writing) is:

It will probably work, but not quaranteed, not officially supported

Of course, it could be argued this is an anti-pattern and it is good that it is not supported. I have no strong opinion on that. But:

Protocols (or mix-ins, or whatever)

class A(BaseModel): ...

class P(Protocol): ...

class C(A, P): ...

This is a no-go.

With DataClass intention is to enable all of that.

Why not from scratch, why wrapping dataclasses?

Considering the effort that was put into dataclasses my conclusu=ion is that dataclasses is the recommended way to standardise directly accessible class/instance properties in the standard library.

Has this been tested in real life?

I am using it in my personal (hobby?) projects. But nothing of a decent size in business environment.

What there anything especially annoying?

Not that anyone wanted to ask this question. But I'll say it anyway.

Metaclasses. A quote from the official docs:

The potential uses for metaclasses are boundless. Some ideas that have been explored include enum, logging, interface checking, automatic delegation, automatic property creation, proxies, frameworks, and automatic resource locking/synchronization.

One could be easily forgiven to think that creating custom metaclasses is a valid thing to do, at least not discouraged. Is there any official example of how to c roll out your own metaclass, how do you subclass type? I could not find it. type (meta)class is implementyed in C, and it is not light reading. Quite frustrating if you are after "what methods are available for overriding and what are their footprints".

One is condemned to trawling the internets, which gives you the venerable "Let's make a singleton" example in 99.98% of the cases. That gives you a clue that you ned to override __new__(), which hase the same footprint as type(). Then you look in some corners of the internet, or much better ask ChatGPT, which will give you a hint that you could play with__call__() method.

To sum it up, a very laborious trial and error process. Why not documenting some examples and make life a tad easier - no idea.