Ophir LOJKINE comments

Results 1257 comments of


                                            Ophir LOJKINE

When type hint is not recognized (e.g. `pd.Timestamp`), we recursively try to convert into a dataclass which mutates the constructor throughout the codebase

If you want a custom type in your class, the best way is to use a [NewType declaration](https://github.com/lovasoa/marshmallow_dataclass#custom-newtype-declarations)

When type hint is not recognized (e.g. `pd.Timestamp`), we recursively try to convert into a dataclass which mutates the constructor throughout the codebase

I think that would be acceptable...

When type hint is not recognized (e.g. `pd.Timestamp`), we recursively try to convert into a dataclass which mutates the constructor throughout the codebase

In order to avoid breaking compatibility, I am simply adding a new warning that will be displayed before marshmallow_dataclass tries to alter a class : > UserWarning: marshmallow_dataclass was called...

When type hint is not recognized (e.g. `pd.Timestamp`), we recursively try to convert into a dataclass which mutates the constructor throughout the codebase

@prihoda : Could you make a PR with the changes you want to see on the message ? We'll discuss the changes there.

When type hint is not recognized (e.g. `pd.Timestamp`), we recursively try to convert into a dataclass which mutates the constructor throughout the codebase

I think this is a request for marshmallow itself.

Allowing of init=False fields to appear in the schema

I think we should keep this open to discuss whether we want to add this behavior or not. Link to PR: #61

Allowing of init=False fields to appear in the schema

Can you describe your use case and what you are trying to achieve ?

Allowing of init=False fields to appear in the schema

I feel like it would make more sense and be easier to just make your id field `init=True`, and optionally create a separate class method if you want to create...

Allowing of init=False fields to appear in the schema

And what would be the issue with defining class methods for creating instances of them ?

Add explicit documentation regarding the ordering of Union types for serialization/deserialization

Yes, you are right, the documentation is not very clear about how Unions work. PR welcome !