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

[evanfwelch]

Reproducible error:

import pandas as pd
import dataclasses

import marshmallow_dataclass

@dataclasses.dataclass
class Something:
    date_i_care_about: pd.Timestamp

print(f"here's a timestamp {pd.Timestamp('2017-01-01')}")

# this mutates the constructor for pd.Timestamp by recursively trying to convert to dataclass
marshmallow_dataclass.class_schema(Something)

print(f"here's a timestamp {pd.Timestamp('2017-01-01')}")

versions:
pandas 0.23.4
marshmallow 2.x
marshmallow_dataclass: 0.6.6

@lovasoa what is the intution behind trying to convert clazz to dataclass here after we fail to get the fields?

https://github.com/lovasoa/marshmallow_dataclass/blob/master/marshmallow_dataclass/__init__.py#L281

I feel that an error (or some kind of strict mode) would be more helpful

[lovasoa]

marshmallow_dataclass allows you to have simple classes, like :

class A:
    a: int

class B:
    b: A

marshmallow_dataclass.class_schema(B)

In order to create a schema for B, it also has to create a schema for A. And in order to apply dataclasses.fields to A, it has to make it a dataclass: https://github.com/lovasoa/marshmallow_dataclass/blob/master/marshmallow_dataclass/__init__.py#L281

I don't think it's possible to fix this issue without breaking backward compatibility...
What behavior would you expect for your example above ?

[lovasoa]

If you want a custom type in your class, the best way is to use a NewType declaration

[evanfwelch]

Ok I see your point. In my (and my colleagues) use case, we would already have made both A and B a dataclass (because we want all the benefits of dataclasses in our application code), and then when it comes to serializing an instance of B, we'd generate a marshmallow schema by doing:

marshmallow_dataclass.class_schema(B).dump(...)

However I guess you've primarily designed for the case where folks are using the marshmallow_dataclass.dataclass decorator to do both at once....

What if we modified the logic for checking whether B should be converted into dataclass to check if it has already has an __init__ defined. I can't think of many cases where someone has a class with a constructor and wants to make it a dataclass

[lovasoa]

I think that would be acceptable...

[lovasoa]

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 on the class Path, which is not a dataclass. It is going to try and convert the class into a dataclass, which may have undesirable side effects. To avoid this message, make sure all your classes and all the classes of their fields are either explicitly supported by marshmallow_datcalass, or are already dataclasses. For more information, see #51

To anyone who would end up here after seeing this warning: to fix this , you should make sure that all the fields of all your classes are either simple base types, or dataclasses themselves.

For instance, the following is good :

import marshmallow_dataclass
import dataclasses

@dataclasses.dataclass
class A:
    a: int

class B:
    b: A

marshmallow_dataclass.class_schema(B)

and the following is bad :

import marshmallow_dataclass

class A:
    a: int

class B:
    b: A

marshmallow_dataclass.class_schema(B)

and this is the worse, because marshmallow_dataclass will change the Path class, and break it globally in your whole application :

from pathlib import Path

class B:
    b: Path

marshmallow_dataclass.class_schema(B)

[prihoda]

Hi all, I think this is quite a serious side effect, for example, it breaks JSON encoding of classes that are handled by a custom JSON encoder, because they are now considered to be dataclasses so they are converted natively.

Can you add an even bigger warning? I didn't actually notice it because it's printed with other messages at flask startup. Also, the warning could contain a suggestion to fix it by adding a marshmallow_field to the field metadata, because that's ultimately the only way to support fields with custom non-dataclass classes, right?

[lovasoa]

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

[mivade]

I got burned by this one trying to use pathlib.Path as a type. Seeing as pathlib is seeing increased usage is there any way to have this type treated correctly? As a workaround I can make a base class like this:

class _HasPaths:
    """Workaround to ensure we get ``pathlib.Path`` types where needed."""

    def __post_init__(self) -> None:
        for fld in fields(self):

            if fld.type == Path:
                attr = getattr(self, fld.name)
                setattr(self, fld.name, Path(attr))

and have any dataclass that uses Path as a type inherit from it but this is less than ideal when pathlib.Path should probably be a type that's handled by default.

The warnings introduced in #130 were helpful in figuring this out but for several hours I was confounded by a bunch of pytest INTERNALERROR messages that were pretty impenetrable.

[lovasoa]

I think this is a request for marshmallow itself.