Review current scope of the library (aka get rid of unused features)

I’m not sure about some features currently implemented in dacite. The main goal of this project is to build a data class from a plain dictionary. It’s not a serialization/desearialization or validation library. There are many such libs, e.g. DRF or marshmallow, and I don’t want to create another one.

I’m talking about following features:

• Config.remap
• Config.flattened
• Config.prefixed
• Config.cast
• Config.transform

Even from code point of view all of those features live in a separate module -config - and they can be easily decoupled from data classes at all. So maybe this is a good idea for a new library which will allow to transform your dictionary to different dictionary according to provided rules (remap, flattened, prefixed…), but I don’t know should we have such features in dacite.

On the other hand it easier for users to install one lib instead of two.

So I see the following solutions:

1. Do not change anything - leave it as it is
2. Get rid of them
3. Make it 100% decoupled from data classes, e.g.

dacite.from_dict(
    data_class=X, 
    data=dacite.transform_data(data, config=TransformConfig(...)), 
    config=Config(...),
)

Nr 2 is my favourite one.

What do you think @rominf @jasisz?

It’s a good time for such decisions - I want to release 1.0.0 soon.

[condemil]

I use cast / transform, but I don’t mind if you get rid of all of them, but I will be able to pass my own method that will do transformation (no matter what transformation it will be - cast, flatten or something else).

This is how it can be done:

dacite.from_dict(
    data_class=X, 
    data=data, 
    transform=some_method,
)

This way you will leave the possibility to do the same what I was able to do previously, but in a different way.

[rominf]

I’ve never used those features. Also, I think their implementation is not the best (it’s hard to use them without extensive reading of documentation). I agree about existing libraries. I think before dropping those features would be nice to provide examples in the documentation of how to use dacite in combination with existing libraries for hard cases. You mentioned DRF and marshmallow, but for me, it’s non-obvious how to use them in combination with dacite.