Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐛 Add update_forward_refs with local models #494

Merged
merged 2 commits into from
May 4, 2021
Merged

🐛 Add update_forward_refs with local models #494

merged 2 commits into from
May 4, 2021

Conversation

Kludex
Copy link
Contributor

@Kludex Kludex commented May 3, 2021

Hi there! 👋

Let me start with: I don't know exactly how this start failing. 😅

Maybe you'll understand better looking at the explanation: pydantic/pydantic#2678 (comment)

The solution I proposed is the one presented in the link above. An alternative could be:

ArgModel.update_forward_refs(**globals())

(but you'll get more than you need... and I'm not sure it works in all cases)

@ines
Copy link
Member

ines commented May 4, 2021

Omg, thanks! 🙏🎉 (Also, I feel kinda stupid for not seeing this... I even vaguely remember thinking "hmm, I wish there was a way to just tell it what the modules are 🤔" hahaha)

So I'm assuming the reason it doesn't work out-of-the-box, even with the imports in the top scope of util.py, is because the actual forward refs are defined outside of that scope? And that's what actually matters, not the scope updating the forward refs?

I'll add some small comments for our team that are mostly about how we want to structure the call to update_forward_refs, now that we know it's possible to just pass in the refs like this.

thinc/util.py Outdated
Comment on lines 443 to 450
Floats2d=Floats2d,
Floats1d=Floats1d,
Floats3d=Floats3d,
Floats4d=Floats4d,
Ints1d=Ints1d,
Ints2d=Ints2d,
Ints3d=Ints3d,
Ints4d=Ints4d
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should just pass in all the **types here? Because in theory, there are more types that the forward functions could use. And using the globals() is more vague, and makes it less obvious that the imports in util.py matter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, it can't be **types because that's a module, but you get the idea 😅

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I guess it's fine now? 😗

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think the solution I came up with works and does what we want 🎉 Thanks again!

@ines ines merged commit bd50727 into explosion:master May 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants