bpo-38155: Adding __all__ to datetime module#16203
Conversation
There was a problem hiding this comment.
Hmm, I think there's a simpler way to test this, just do:
from datetime import *This will throw an AttributeError if you have an invalid attribute defined there.
Example (test.py):
__all__ = ['a']
b = 1>>> from test import *
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: module 'test' has no attribute 'a'cc @pganssle
There was a problem hiding this comment.
@ammaraskar from x import * is only valid at the top level of a file, so this cannot be executed in a test.
There was a problem hiding this comment.
@pganssle Ah, is this already the most viable way to test the validity of the attributes then?
There was a problem hiding this comment.
Well, it's the best one I could think of. There may be better tests for __all__, but given that this module already does some funky and apparently fragile stuff with the import mechanism, I think it's probably best not to try to get too fancy - particularly since it's not that important of a test.
There was a problem hiding this comment.
Made a couple of minor formatting adjustments and removed the part about the tests. News entries typically don't contain information about the tests, as they aren't part of the public API.
| Add __all__ to the datetime module, including unit tests. | |
| Add ``__all__`` to :mod:`datetime`. |
There was a problem hiding this comment.
@tahia-khan You may also want to (optionally) add your name to the news - "Patch by Tahia Khan." (or whatever you prefer to be credited as).
There was a problem hiding this comment.
Please make sure it follows to limit all lines to a maximum of 79 characters.
PEP8: https://www.python.org/dev/peps/pep-0008/#maximum-line-length
There was a problem hiding this comment.
In case this isn't clear, this can easily be fixed by changing it to:
| __all__ = ("date", "datetime", "time", "timedelta", "timezone", "tzinfo", "MINYEAR", "MAXYEAR") | |
| __all__ = ("date", "datetime", "time", "timedelta", "timezone", "tzinfo", | |
| "MINYEAR", "MAXYEAR") |
There was a problem hiding this comment.
This section is also going over the 79 char limit. Please adjust it accordingly.
There was a problem hiding this comment.
For this I'll go with parenthesis notation from the PEP328 rather than backslashes.
There was a problem hiding this comment.
I think you won't need to change this line at all once you have dropped test_c_all.
pganssle
left a comment
There was a problem hiding this comment.
Thanks for the PR @tahia-khan, and thanks for the reviews @aeros167 and @ammaraskar! With the formatting changes and dropping test_c_all, I think this looks pretty good.
I was mildly taken aback that you've defined __all__ as a tuple rather than a list, which is traditional, but I don't see any reason why it shouldn't be a list, and in fact __all__ being immutable makes more sense than mutable, so I'm not sure why it's not more common.
There was a problem hiding this comment.
I do not think this is the right place for this test - datetimetester.py is executed twice - once with the C module and once with the Python module. This may also mess with the state of sys.modules, see this comment.
I think just drop the test_c_all test and just leave the other test.
There was a problem hiding this comment.
@tahia-khan You may also want to (optionally) add your name to the news - "Patch by Tahia Khan." (or whatever you prefer to be credited as).
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
|
Thanks everybody for the detailed change suggestions. I'll wait a bit for the final reviewer and submit all changes in one commit.
@pganssle Ah - I didn't actually realize lists were the usual choice. I was peeking around other files that had an |
Yes, I agree that you made the sensible choice here. I tried looking it up and I could see no one arguing that you shouldn't use a |
|
I have made the requested changes; please review again |
|
Thanks for making the requested changes! @pganssle: please review the changes made to this pull request. |
pganssle
left a comment
There was a problem hiding this comment.
Thanks everyone, this looks good, so I've rebased it and I'm going to merge now.
The alignment in the latest version also looked a little off for whatever reason, I aligned the second line in the __all__ to the parenthesis as part of the rebase.
Co-Authored-By: Paul Ganssle [email protected]
https://bugs.python.org/issue38155