Mirrored modules in v1 namespace to fix typing and object resolution in python>3.11
#9660
Conversation
6a73698 to
003273b
Compare
|
please review |
|
@sydney-runkle attempted a fix for the typing issue / python 3.12 issue |
|
I tried installing this but v1 path isn't listed as a package so it didn't get included suggested fix diff --git a/setup.py b/setup.py
index 8e5f82e9..63f16f87 100644
--- a/setup.py
+++ b/setup.py
@@ -132,7 +132,7 @@ setup(
author_email='s@muelcolvin.com',
url='https://github.com/pydantic/pydantic',
license='MIT',
- packages=['pydantic'],
+ packages=['pydantic', 'pydantic.v1'],
package_data={'pydantic': ['py.typed']},
python_requires='>=3.7, <3.13',
zip_safe=False, # https://mypy.readthedocs.io/en/latest/installed_packages.html |
|
This does appear to resolve the issues noted in home-assistant/core#119430 and uilibs/uiprotect#39 once the setup.py was modified, make clean was run, cython downgraded to 0.29, and reinstalled. The test suites both pass |
|
Nice, thanks for the check - its pretty frustrating trying to make a subpackage appear like the package itself, bound to have some issues associated with it. Will add this change 👍 Kinda surprised that the CI tests pass without this though. Somewhat worrying 😓 |
| from pydantic.typing import * | ||
| else: | ||
| # explicit importing | ||
| from pydantic.typing import ( |
There was a problem hiding this comment.
Note I'm a bit worried about these, for example if a module uses a __all__ it does not stop someone using from pydantic.<module> import <SymbolNotProvidedInAllButPresent> whereas with these imports from pydantic.v1.<module> import <SymbolNotProvidedInAllButPresent> will not be found.
I'm not sure how common this will actually be (I'm sure some people will definitely import objects from a module that does not have them defined in __all__ 🙃) but I'm also not too sure whether we want to support that in this either.
Personally I'm kinda fine with this, but happy to take opinions. Also, this will likely need a migration guide update too right?
There was a problem hiding this comment.
I'd argue that from pydantic.<module> import <SymbolNotProvidedInAllButPresent> amounts to depending on an undocumented implementation detail in the old API, and that you should be free to avoid replicating that in the "new" pydantic.v1.* API.
|
So I think once we decide on a fix here, we'll want to do another We'll probably have to modify the logic to update I think we'll want to discard the We can probably remove the |
|
yep I agree, when pushing the We'd likely have to update the migration guide for |
|
Ah also one thing that this complicates is new development in |
Yeah, that'd be great. @exs-dwoodward, any interest in opening a docs update PR with these changes? Thanks for all of your help with these fixes thus far 🚀 ! |
|
Yeah I can take a look at it - any links you provide to point me in the right direction? First time looking at pydantic's docs compliation so would probably be quicker with some pointers 👀 |
Worth me adding something to any |
|
@exs-dwoodward, Great! You'll want to edit You can run |
Change Summary
Attempt to fix the typing issue with
.v1.pyand the python 3.12 issue regarding objects imported through__getattr__not being the same object as when imported directly.This PR:
v1/subpackage, that mirrors the modules inpydanticwhere each module simply imports all symbols from the corresponding parent.my mypy seems to be happy with imports from
pydantic.v1.fields.ModelFieldnow as well.Note that the one downside to this is that the modules are no longer the same, i.e.
pydantic.fields is pydantic.v1.fields # == Falsewhereas it wasTruewith the previous PR.I'm not entirely sure there is a way round both issues ..
Related issue number
fix #9656
skip change file check
Checklist
Selected Reviewer: @samuelcolvin