Dataclass-mapper

Documentation: Support for Python 3.12

Python 3.12 is already supported for a long time, however Pypi doesn't show the 3.12 flag, since `poetry` didn't add the `Programming Language :: Python :: 3.12` classifier automatically.
This release should fix this behavior.

Documentation: Support for Python 3.12

No change in any features or behaviors of the library.
Only the documentation and CI pipeline have been updated for the new Python version.

Feature: Recursive mappings with dictionary values

It is now possible to map a field of type `Dict[T, Foo]` to `Dict[T, Bar]`, if there is a mapping defined between `Foo` and `Bar`.

python
dataclass
class Bar:
...

mapper(Bar)
dataclass
class Foo:
...

dataclass
class BarDict:
d: Dict[str, Bar]

mapper(BarDict)
dataclass
class FooDict:
d: Dict[str, Foo]

Feature: Pydantic v2 support

Pydantic release v2 of their library a couple days ago, in which they changed the underlying implementation and speed (using Rust) and also a lot of their syntax (https://docs.pydantic.dev/dev-v2/migration/).
This new release implements support for the new pydantic dataclass, and still also supports the old version in case somebody still uses the old one.

Feature: Allow mappings from subunions

It is now possible to map from more restricted Union type to a more relaxed Union type.
E.g. you can map from a `Union[str, int]` to a `Union[str, int, float]` field, as every instance of the first type is necessary also an object of the second type. But not the other way around.

Technical improvement: Code generation

Generating the code for the efficient mapping was painful, and involved dealing with a lot of strings, keeping track of indentations, etc...
This code logic is not abstracted away via some helper classes - kinda like an AST.

Technical improvement: Start of architecture documentation

As the project gets more complicated, a good documentation of the ideas, decisions, etc... of the architecture makes sense. I've started using Arc42 for it: https://dataclass-mapper.readthedocs.io/en/latest/architecture.html

Bug Fix: allow arbitrary callables as factories, not just functions

Until now it was only possible to pass functions (global functions or lambdas) as a factory to a mapping due to a check with `isfunction(...)`. This limitation prevents passing a lot of other objects with a `__call__` method. This restriction was never intended, and was now removed. Now also this code works:

python
class Incrementor:
def __init__(self):
self.value: int = 0

def __call__(self) -> int:
self.value += 1
return self.value

mapper(Target, {"x": Incrementor()})
dataclass
...


Improvement: error message if mapping already exists

The library will now check that only one mapping exists between two classes. If there are two mappings, one of the mapper would have been overwritten and not used.

Improvement: error message if you use the wrong classes

If you use dataclasses/pydantic classes with the `enum_mapper`, or if you use any enum classes with the normal `mapper`, you will get a `ValueError` with a hint that you should use the other method.

Bug Fix: mapping for multiple classes with the same name

The previous versions have a bug, where it was not possible to create multiple mappings to classes with the same name.
E.g. when a mapping from `lib.Bar` to `lib.submodule1.Foo` was defined, and also a mapping from `lib.Bar` to `lib.submodule2.Foo`. Then one mapping would overwrite the other mapping. See 14 for more details.

Thanks nufny for reporting and fixing it.