default_factory treated incorrectly, but only in presence of methods

[kmaziarz]

Initial Checks

• I have searched GitHub for a duplicate issue and I'm sure this is something new
• I have searched Google & StackOverflow for a solution and couldn't find anything
• I have read and followed the docs and still think this is a bug
• I am confident that the issue is with pydantic (not my code, or another library in the ecosystem like FastAPI or mypy)

Description

I'm seeing an error very similar to #2555, where pydantic doesn't understand a field marked with default_factory, thinking it's a non-default field, and thus complains it follows a default field. Reportedly that issue has been resolved in 1.10, but I am still observing it as long as some extra method exists in the dataclass; then, the attached code results in

(...)
  File "/data/anaconda/envs/conda-env-name/lib/python3.9/dataclasses.py", line 504, in _init_fn
    raise TypeError(f'non-default argument {f.name!r} '
TypeError: non-default argument 'metadata' follows default argument

Crucially, if the fn method is removed, pydantic no longer reports an error.

One can get around this by reordering the fields in the dataclass, but that affects the order of __init__ arguments, which is undesirable. Note that my code uses plain dataclasses, not pydantic.dataclasses; this is needed for compatibility with other code that does not use pydantic.

Example Code

from dataclasses import dataclass, field
from pydantic import BaseModel


@dataclass
class Data:
    identifier: str = field(default="")
    metadata: dict = field(default_factory=dict)

    def fn(self) -> None:
        pass


class Model(BaseModel):
    class Config:
        arbitrary_types_allowed = True

    data: Data

Python, Pydantic & OS Version

pydantic version: 1.10.2
            pydantic compiled: True
                 install path: /data/anaconda/envs/conda-env-name/lib/python3.9/site-packages/pydantic
               python version: 3.9.7 | packaged by conda-forge | (default, Sep 29 2021, 19:20:46)  [GCC 9.4.0]
                     platform: Linux-4.15.0-1113-azure-x86_64-with-glibc2.23
     optional deps. installed: ['typing-extensions']

Affected Components

• Compatibility between releases
• Data validation/parsing
• Data serialization - .model_dump() and .model_dump_json()
• JSON Schema
• Dataclasses
• Model Config
• Field Types - adding or changing a particular data type
• Function validation decorator
• Generic Models
• Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
• Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

[dmontagu]

@kmaziarz This should be fixed in v1.10.5.

I confirmed that running your code produces an error in v1.10.2 and does not produce an error in v1.10.5. (I don't know when exactly it was fixed but I think 1.10.5 is the latest release.)

(I also did some basic confirmation that it looks like it is behaving as desired/expected when you try to parse data/etc.)

[kmaziarz]

This should be fixed in v1.10.5.

Ah, you're right. I saw that a similar bug was fixed in v1.10.2, which is the version I had, so I assumed this was supposed to be working; I didn't notice that there have been a few releases since then. Things are indeed now working under v1.10.5.