Latest Results
Add `dataclass_compatible` flag
Short of having some
[stdlib fields interface](https://discuss.python.org/t/add-a-fields-interface/108364),
the de facto standard for marking a class as "some non-opaque class that
you can iterate over the fields of" is the presence of `__dataclass_fields__`.
One example of this de facto standard (and the motivation for this PR) is in
Pydantic. Pydantic will happily use dataclass definitions for (de)serialization,
both in the case of nested definitions, and when using `pydantic.TypeAdapter(T)`.
The only way it can tell if something is a dataclass is using
`dataclasses.is_dataclass`, which itself just checks for the presence of
`__dataclass_fields__`. An `attrs` class masquerading as a dataclass
via `__dataclass_fields__` works just fine. Using `pydantic.TypeAdapter`
at the edges and normal `attrs` in the core application avoids @tinche's
concerns around things like:
> Is it really necessary to re-validate all your objects while reading
> them from a trusted database?
that this PR's author [largely agrees with](https://leontrolski.github.io/pydantic-wrong.html).
Another example would be a "map over everything" function like the following:
```python
def map_[T](o: T, f: Callable[[T], T]) -> T:
if isinstance(o, list):
return [map_(v, f) for v in o]
# ditto for tuple, set, frozenset, dict, then,
if has_fields(o):
kwargs = {k: map_(getattr(o, field.name), f) for field in dataclasses.fields(o)}
return copy.replace(o, **kwargs)
return o
```
With `dataclass_compatible=True` set, functions like this will work without
having to muck around checking for the installation of `attrs` and using the
subtly different `attrs.fields` function.leontrolski:add-dataclass-compatible Add `dataclass_compatible` flag
Short of having some
[stdlib fields interface](https://discuss.python.org/t/add-a-fields-interface/108364),
the de facto standard for marking a class as "some non-opaque class that
you can iterate over the fields of" is the presence of `__dataclass_fields__`.
One example of this de facto standard (and the motivation for this PR) is in
Pydantic. Pydantic will happily use dataclass definitions for (de)serialization,
both in the case of nested definitions, and when using `pydantic.TypeAdapter(T)`.
The only way it can tell if something is a dataclass is using
`dataclasses.is_dataclass`, which itself just checks for the presence of
`__dataclass_fields__`. An `attrs` class masquerading as a dataclass
via `__dataclass_fields__` works just fine. Using `pydantic.TypeAdapter`
at the edges and normal `attrs` in the core application avoids @tinche's
concerns around things like:
> Is it really necessary to re-validate all your objects while reading
> them from a trusted database?
that this PR's author [largely agrees with](https://leontrolski.github.io/pydantic-wrong.html).
Another example would be a "map over everything" function like the following:
```python
def map_[T](o: T, f: Callable[[T], T]) -> T:
if isinstance(o, list):
return [map_(v, f) for v in o]
# ditto for tuple, set, frozenset, dict, then,
if has_fields(o):
kwargs = {k: map_(getattr(o, field.name), f) for field in dataclasses.fields(o)}
return copy.replace(o, **kwargs)
return o
```
With `dataclass_compatible=True` set, functions like this will work without
having to muck around checking for the installation of `attrs` and using the
subtly different `attrs.fields` function.leontrolski:add-dataclass-compatible Add `dataclass_compatible` flag
Short of having some
[stdlib fields interface](https://discuss.python.org/t/add-a-fields-interface/108364),
the de facto standard for marking a class as "some non-opaque class that
you can iterate over the fields of" is the presence of `__dataclass_fields__`.
One example of this de facto standard (and the motivation for this PR) is in
Pydantic. Pydantic will happily use dataclass definitions for (de)serialization,
both in the case of nested definitions, and when using `pydantic.TypeAdapter(T)`.
The only way it can tell if something is a dataclass is using
`dataclasses.is_dataclass`, which itself just checks for the presence of
`__dataclass_fields__`. An `attrs` class masquerading as a dataclass
via `__dataclass_fields__` works just fine. Using `pydantic.TypeAdapter`
at the edges and normal `attrs` in the core application avoids @tinche's
concerns around things like:
> Is it really necessary to re-validate all your objects while reading
> them from a trusted database?
that this PR's author [largely agrees with](https://leontrolski.github.io/pydantic-wrong.html).
Another example would be a "map over everything" function like the following:
```python
def map_[T](o: T, f: Callable[[T], T]) -> T:
if isinstance(o, list):
return [map_(v, f) for v in o]
# ditto for tuple, set, frozenset, dict, then,
if has_fields(o):
kwargs = {k: map_(getattr(o, field.name), f) for field in dataclasses.fields(o)}
return copy.replace(o, **kwargs)
return o
```
With `dataclass_compatible=True` set, functions like this will work without
having to muck around checking for the installation of `attrs` and using the
subtly different `attrs.fields` function.leontrolski:add-dataclass-compatible Latest Branches
0%
gyanu2507:fix/these-leftover-ib-sentinels 0%
weed33834:fix/734-kw-only-exception-pickle 0%
cjchanh:expose-cached-properties © 2026 CodSpeed Technology