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
help() not helpful with enum #62893
Comments
help(), when used on an enum member or class, returns almost nothing. I suspect the custom __dir__ is at fault, but whatever is causing the problem needs fixing. |
With custom __dir__: Help on class Enum in module enum: Enum = <enum 'Enum'> ---------------------------------------------------- Without custom __dir__: Help on class Enum in module enum: class Enum(builtins.object)
| Generic enumeration.
|
| Derive from this class to define new enumerations.
|
| Methods defined here:
|
| __eq__(self, other)
|
| __getnewargs__(self)
|
| __hash__(self)
|
| __repr__(self)
|
| __str__(self)
|
| | Static methods defined here: --------------------------------------------------------------- I'm thinking we should drop the custom __dir__. help() is far more important than not seeing some things with dir(). |
New changeset 5d417257748e by Ethan Furman in branch 'default': |
Less than two days passed since this issue was opened. No waiting for feedback? No patch? No code review? Maybe there's another solution? Personally I find dir() often more useful than help(). Maybe help() can be adapted to behave nicely for classes with custom __dir__ and it could be useful elsewhere? Is this such a burning immediate need that we forego all the usual discussion channels? |
Sorry, sorry. Long week, felt like more than two days, mild sense of unease and stress due to non-functioning Release Schedule on python.org, and wanting to get Enum used /somewhere/ in the stdlib before 3.4 is locked down. Making help() better would be a better solution, especially if we enhanced it to show docstrings on instances. I'll see what I can figure out. Feel free to beat me to it. :) |
Ethan, http://www.python.org/dev/peps/pep-0429/#release-schedule |
Ethan, as Ned said (and I think you got this answer in the list before), the real feature cutoff is Beta 1. So we have time until the end of November. Note that even new PEPs (like the statistics one) can go in before that. Even after beta, things that appear to be bugs (like this issue) can usually be fixed before the RCs come. So there is no time pressure whatsoever. |
So what do we want Enum's __dir__ to report? Normally we see things like __eq__, __dict__, __getnewargs__, etc. For IntEnum there would be __abs__, __floor__, __div__, etc. Do we want to worry about those kinds of differences? I think we do. And if we do, then we are looking at removing items to make our custom __dir__, and with each release we would have to revisit the blacklist of items we don't want (the tests would catch that for us, but it would still be effort to update the code). What if we took what object.__dir__ gave us, then added the Enum members while removing the private, er, non-public data structures? In other words, this dir in EnumMeta: def __dir__(cls):
items = set(super().__dir__())
disgard = set([m for m in items if _is_sunder(m)])
members = set(cls.__members__)
return sorted((items | members) ^ disgard)
with this Enum: >>> class Color(enum.Enum):
... RED = 1
... BLUE = 2
... GREEN = 3
... gives us this result: >>> dir(Color)
['BLUE', 'GREEN', 'RED', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getnewargs__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'name', 'value'] |
Huh. I just checked |
Ethan, please revert your commit first. I liked the previous dir. The current one is useless. I think you may be right about help, but I didn't dig deep enough to be sure. |
New changeset 39697dcd97e3 by Ethan Furman in branch 'default': |
Do we have enough evidence to open a new bug vs. help() ? |
I've done some more investigation today but I can't tell if the issue is solely in help or if it's some wierd |
On Sun, Sep 1, 2013 at 5:29 PM, Ethan Furman <report@bugs.python.org> wrote:
So you can't reproduce it with other classes that have a custom __dir__ ? |
Nope, not yet. And even a simple dummy metaclass with a custom __dir__ worked fine. |
What I know for sure:
|
That help() is confused by __dir__ is documented in bpo-16938. AFAIK help is fairly fragile in its expectations of the attributes present on classes and the correspondence between dir(cls) and list(cls.__dict__), and that is something that could be fixed in pydoc and/or inspect. |
Found it! It was a combination of __objclass__ not being defined on the enum mmebers, and the metatype not being searched in the __mro__ by inspect. Thanks, Ronald, for the necessary clues. Patch attached. I'm not sure if I have the method wowser showing up in the correct dir(). Thoughts? |
Great, Ethan. I'd say the inspect fix has to be reviewed and committed separately. Maybe bpo-16938 is the right place to post the patch for it. Once that's in, we can review/commit the enum parts. |
help() won't really be fixed with the inspect patch. If no objections within a few hours I'll open a new issue for it. |
Okay, here's the patch after the inspect portion was committed in bpo-18929. Summary:
|
Two issues still remain:
======================================================================================= --> dir(Test) --> dir(Test.this) --> help(Test) class Test(enum.Enum)
| Method resolution order:
| Test
| enum.Enum
| builtins.object
|
| Data and other attributes defined here:
|
| these = <Test.these: 'those'>
|
| this = <Test.this: 'that'>
|
| whose = <Test.whose: 'mine'>
|
| | Data descriptors inherited from enum.Enum: At this point, dir() on an Enum member shows what can be done with the member, and dir() on an Enum class shows what can be done with the class. I'll create new issues to track changes for inspect and help. |
New changeset 353ced6ae182 by Ethan Furman in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: