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

More precise annotations of utils.timezone functions that return instances of tzinfo subclasses. #209

Merged
merged 5 commits into from
Nov 12, 2019

Conversation

filiplajszczak
Copy link
Contributor

Current annotations for get_fixed_timezone, get_default_timezone and get_current_timezone follow the docstrings of the functions that broadly name returned objects as tzinfo instance. It is true, but imprecise, as the returned objects are instances of subclasses of tzinfo. Mypy complains when any of the methods of that subclasses are called on the returned instance eg. error: "tzinfo" has no attribute "localize"

Proposed changes should fix it.

Copy link
Contributor

@bluetech bluetech left a comment

Choose a reason for hiding this comment

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

I also ran into this issue, will be good to fix. Left some comments.

django-stubs/utils/timezone.pyi Outdated Show resolved Hide resolved
django-stubs/utils/timezone.pyi Show resolved Hide resolved
django-stubs/utils/timezone.pyi Show resolved Hide resolved
@bluetech
Copy link
Contributor

It looks good to me now, though I would add a comment like this above get_current_timezone():

Strictly speaking, it is possible to activate() a non-pytz timezone, in which
case BaseTzInfo is incorrect. However, this is unlikely, so we use it anyway,
to keep things ergonomic for most users.

@filiplajszczak
Copy link
Contributor Author

filiplajszczak commented Oct 17, 2019

OK @bluetech It's included as suggested.

Also, what is breaking the build? I see the output, but what is the difference with the master that causes problems?

@filiplajszczak
Copy link
Contributor Author

@sobolevn Looks like that one has the same build problem as #211

@sobolevn
Copy link
Member

Yes, I will be able to fix it in the evening (Moscow time). Sorry for the inconvenience.

@sobolevn
Copy link
Member

Something broke during this time period:

Снимок экрана 2019-10-21 в 23 48 17

My wild guess is that git submodule changed somehow. Diff:

At first sight - it does not look like something has changed at all.
I have tried to reset build cache, didn't work.

Local build also fails with the very same reason.
Снимок экрана 2019-10-22 в 0 05 43

Then, I have tried to update django-sources to 2.2.6:

--- Subproject commit f452d4232e1c14269bf2f1bd234d6e4ef462dc55
+++ Subproject commit aa28213eb51ba26b349c2e51f2defcc7cc87780e

Still no luck, the error remains. I am out of ideas. And sadly don't have any more time for now.
I would appreciate any help 🙂

@mkurnikov
Copy link
Member

@sobolevn FYI, CI failure happened because of unpinned mypy version. 0.740 broke tests typechecking.

@mkurnikov mkurnikov merged commit e9a90eb into typeddjango:master Nov 12, 2019
@sobolevn
Copy link
Member

That's why I use poetry everywhere 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants