I'm working on an article about Python introspection and came across something I consider a blemish. I thought I'd ask about it here and see how you folks feel about it. BTW, I'm looking at Python 2.2.2 on Linux. If you look at the keyword module, you'll see that it has a keyword attribute:
Basically, the keyword attribute is just the last value from this process: kwdict = {} for keyword in kwlist: kwdict[keyword] = 1 So it is a bit of extraneous cruft, I believe. No big deal, and nothing that a del keyword couldn't fix. But it does look sloppy when you are writing about introspection and you see an attribute that has no real value. I wish it weren't there, as I'd rather not have to explain it. But it got me thinking whether other modules in the standard library have this issue, and whether this is something that should be cleaned up. Thoughts? -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
Lots of modules have attributes that are cruft according to this definition. I personally see no reason to get rid of all these -- they're harmless and "from M import *" doesn't import them. Feel free to hold your own code to a higher standard though. ;-) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tuesday 29 October 2002 04:41 pm, Guido van Rossum wrote:
I understand what you are saying, and respectfully disagree. Extraneous attributes are harmful to the extent that one has to know to ignore them. Knowing what to ignore is difficult when learning Python or working with an unfamiliar module. And extraneous attributes are cumbersome when making use of Python's introspection features, such as dir(object), or when using a Python shell or editor that offers autocompletion. And, finally, they get in the way while writing an article about Python introspection. ;-) Also, little things like this make it more challenging to present Python in its most positive light for a general audience, featuring characteristics of the language that are supposed to show how it is a better choice than other languages. I'm not saying that having a few extraneous attributes is a huge flaw. And you know how much of a fan of Python I am. But anything that has to be "brushed under the rug" can create doubt among those who aren't already part of the Python community. And I don't think a higher standard would hurt the standard library. Just something to think about. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
"Patrick K. O'Brien" <pobrien@orbtech.com> writes:
Normally, this is fixed with __all__: The module may have arbitrary variables; the interface is only those identifiers mentioned in __all__ (in absence of __all__, its only those identifiers which are documented). So I don't think this is an issue, in general. In a specific case, there is nothing wrong with fixing it. Regards, Martin
On Tuesday 29 October 2002 05:02 pm, Martin v. Loewis wrote:
Well, in this case, keyword's __all__ looks like: __all__ = ["iskeyword"] Which leaves out keyword.kwlist, a pretty useful attribute.
So I don't think this is an issue, in general. In a specific case, there is nothing wrong with fixing it.
I'd also suggest that __all__ as a determiner of a module's api is severely underdocumented. Maybe I just picked the wrong module to start off my article. ;-) -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
On Tuesday 29 October 2002 11:19 pm, Raymond Hettinger wrote:
Done. SF# 631055. Thanks. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
Lots of modules have attributes that are cruft according to this definition. I personally see no reason to get rid of all these -- they're harmless and "from M import *" doesn't import them. Feel free to hold your own code to a higher standard though. ;-) --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tuesday 29 October 2002 04:41 pm, Guido van Rossum wrote:
I understand what you are saying, and respectfully disagree. Extraneous attributes are harmful to the extent that one has to know to ignore them. Knowing what to ignore is difficult when learning Python or working with an unfamiliar module. And extraneous attributes are cumbersome when making use of Python's introspection features, such as dir(object), or when using a Python shell or editor that offers autocompletion. And, finally, they get in the way while writing an article about Python introspection. ;-) Also, little things like this make it more challenging to present Python in its most positive light for a general audience, featuring characteristics of the language that are supposed to show how it is a better choice than other languages. I'm not saying that having a few extraneous attributes is a huge flaw. And you know how much of a fan of Python I am. But anything that has to be "brushed under the rug" can create doubt among those who aren't already part of the Python community. And I don't think a higher standard would hurt the standard library. Just something to think about. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
"Patrick K. O'Brien" <pobrien@orbtech.com> writes:
Normally, this is fixed with __all__: The module may have arbitrary variables; the interface is only those identifiers mentioned in __all__ (in absence of __all__, its only those identifiers which are documented). So I don't think this is an issue, in general. In a specific case, there is nothing wrong with fixing it. Regards, Martin
On Tuesday 29 October 2002 05:02 pm, Martin v. Loewis wrote:
Well, in this case, keyword's __all__ looks like: __all__ = ["iskeyword"] Which leaves out keyword.kwlist, a pretty useful attribute.
So I don't think this is an issue, in general. In a specific case, there is nothing wrong with fixing it.
I'd also suggest that __all__ as a determiner of a module's api is severely underdocumented. Maybe I just picked the wrong module to start off my article. ;-) -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
On Tuesday 29 October 2002 11:19 pm, Raymond Hettinger wrote:
Done. SF# 631055. Thanks. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------
participants (4)
-
Guido van Rossum -
martin＠v.loewis.de -
Patrick K. O'Brien -
Raymond Hettinger