Mailman 3 Keyword module cruft question - Python-Dev

newer
Re: [Python-Dev] metaclass insanity

Keyword module cruft question

Patrick K. O'Brien

29 Oct 2002 29 Oct '02

10:21 p.m.

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:

...

...
...
import keyword dir(keyword) ['__all__', '__builtins__', '__doc__', '__file__', '__name__', 'iskeyword', 'keyword', 'kwdict', 'kwlist', 'main'] keyword.keyword 'yield'

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." -----------------------------------------------

Show replies by date

Guido van Rossum

29 Oct 29 Oct

10:41 p.m.

...

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:

...
...
...
import keyword dir(keyword) ['__all__', '__builtins__', '__doc__', '__file__', '__name__', 'iskeyword', 'keyword', 'kwdict', 'kwlist', 'main'] keyword.keyword 'yield'

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?

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/)

Patrick K. O'Brien

11:52 p.m.

On Tuesday 29 October 2002 04:41 pm, Guido van Rossum wrote:

...

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. ;-)

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." -----------------------------------------------

martin＠v.loewis.de

11:02 p.m.

"Patrick K. O'Brien" writes:

...

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?

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

Patrick K. O'Brien

11:27 p.m.

On Tuesday 29 October 2002 05:02 pm, Martin v. Loewis wrote:

...

"Patrick K. O'Brien" writes:

...
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?

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).

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." -----------------------------------------------

Raymond Hettinger

30 Oct 30 Oct

5:19 a.m.

[Patrick K. O'Brien]

...

Well, in this case, keyword's __all__ looks like:

__all__ = ["iskeyword"]

Which leaves out keyword.kwlist, a pretty useful attribute.

Fixed.

...

I'd also suggest that __all__ as a determiner of a module's api is severely underdocumented.

Agreed. Please file a documentation bug report and assign to me. Raymond Hettinger

Patrick K. O'Brien

2:23 p.m.

On Tuesday 29 October 2002 11:19 pm, Raymond Hettinger wrote:

...

...
I'd also suggest that __all__ as a determiner of a module's api is severely underdocumented.

Agreed. Please file a documentation bug report and assign to me.

Done. SF# 631055. Thanks. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------

7846

Age (days ago)

7847

Last active (days ago)

List overview

Download

6 comments

4 participants

participants (4)

Guido van Rossum
martin＠v.loewis.de
Patrick K. O'Brien
Raymond Hettinger

Keyword module cruft question

Patrick K. O'Brien

Guido van Rossum

Patrick K. O'Brien

martin＠v.loewis.de

Patrick K. O'Brien

Raymond Hettinger

Patrick K. O'Brien

tags

participants (4)