Fix false positives on v1 models in mypy plugin for from_orm check requiring from_attributes=True config

[radekwlsk]

Change Summary

This is a fix for bug reported in #9936 when using both v1 and v2 for migration period with pydantic.mypy plugin enabled the "<ModelName>" does not have from_attributes=True [pydantic-orm] error is getting raised for pydantic.v1.BaseModel models that should not be checked by pydantic.mypy plugin (that is supposed to work on current - v2 - pydantic).

Please review but note that test will fail unless the other bug with @typing_extensions.deprecated decorator mentioned in #9936 is fixed.

Open for discussion how to address the decorator messing with mypy hooks.

Related issue number

fix #9936

Checklist

• The pull request title is a good summary of the changes - it will be used in the changelog
• Unit tests for the changes exist
• Tests pass on CI
• Documentation reflects the changes where applicable
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @sydney-runkle

[codspeed-hq]

CodSpeed Performance Report

Merging #9938 will not alter performance

_{Comparing radekwlsk:radekwlsk/fix-mypy-plugin-pydantic-orm (d3f6567) with main (fe08181)}

Summary

✅ 14 untouched benchmarks

[dmontagu]

This looks good to me, other than — can we try removing the duplicates of the from_orm_v1_noconflict.py file so we only keep the one in the 1.0.1 folder? I think that will still pass CI since it seems there are no changes in the subsequent versions.

[dmontagu]

Unfortunately it seems that it may be difficult to resolve the issue with deprecated, as I think mypy doesn't have a way for plugins to override the behavior of decorated methods. I might be misinterpreting something, but it seems that python/mypy#9915 might be necessary to achieve this (not sure).

I think there are things we could do to avoid the decorator affecting the plugin behavior, but I would expect that to get in the way of some desirable errors produced by calling deprecated methods. So I'm not sure what's best here

[radekwlsk]

@dmontagu Thanks for the review, removed the duplicate result files. For the decorator I have no clue how to approach it without breaking the deprecation warning either.

One way to "resolve" it would be to focus the unit of test on not raising "pydantic-orm" error for v1.BaseModel and skip the case for raising it where expected. WDYT? See the last commit.

[radekwlsk]

This looks good to me, other than — can we try removing the duplicates of the from_orm_v1_noconflict.py file so we only keep the one in the 1.0.1 folder? I think that will still pass CI since it seems there are no changes in the subsequent versions.

CI passes as expected, thanks.

[radekwlsk]

@dmontagu Please re-review. Is there a hope to get this fix included in a 2.8 patch release without waiting for 2.9 rollout?

[radekwlsk]

Please review
It is stuck in waiting for review for over a week now 😞

[sydney-runkle]

@radekwlsk,

Thanks for the ping. I messaged @dmontagu and we'll take a look shortly!

[dmontagu]

I think you shouldn’t need this file at all if there are no mypy errors produced

[radekwlsk]

@sydney-runkle Are you able to provide any timeline for release containing that fix?

[sydney-runkle]

@radekwlsk,

Was planning on releasing this with v2.9 in late August!

[radekwlsk]

So I guess I shouldn't wait for 2.8.3 with bugfixes? Thanks, I'll fork-patch mypy plugin locally for the time being.

[sydney-runkle]

Right, I don't think we're in a rush for a v2.8.3 at the moment, but I'll keep you updated!