Mailman 3 Advice in stat.py - Python-Dev

Advice in stat.py

Greg Ward

27 Jul 2001 27 Jul '01

2:14 p.m.

stat.py in 2.2a1 starts with the following sage advice: """Constants/functions for interpreting results of os.stat() and os.lstat(). Suggested usage: from stat import * """ Is ths still the suggested usage? Greg -- Greg Ward - geek gward@python.net http://starship.python.net/~gward/ A man without religion is like a fish without a bicycle.

Show replies by date

Fred L. Drake, Jr.

27 Jul 27 Jul

2:27 p.m.

Greg Ward writes:

...

Suggested usage: from stat import * """

Is ths still the suggested usage?

Well, I would never suggest that, but I didn't write the stat module. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

Guido van Rossum

3:47 p.m.

...

stat.py in 2.2a1 starts with the following sage advice:

"""Constants/functions for interpreting results of os.stat() and os.lstat().

Suggested usage: from stat import * """

Is ths still the suggested usage?

I don't see why not. --Guido van Rossum (home page: http://www.python.org/~guido/)

Greg Ward

4:51 p.m.

On 27 July 2001, Guido van Rossum said:

...

...
stat.py in 2.2a1 starts with the following sage advice:

"""Constants/functions for interpreting results of os.stat() and os.lstat().

Suggested usage: from stat import * """

Is ths still the suggested usage?

I don't see why not.

My understanding was that it's generally considered Bad Form to do this at module level, while doing it at function level is tricky (or a performance hit? whatever...) because of nested scopes. Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ No animals were harmed in transmitting this message.

barry＠zope.com

5:12 p.m.

...

...
...
...
...
"GW" == Greg Ward writes:

GW> My understanding was that it's generally considered Bad Form GW> to do this at module level, while doing it at function level GW> is tricky (or a performance hit? whatever...) because of GW> nested scopes. Yes, but some modules are designed for from-import-* so they're less evil. types, stat, and Tkinter are the three most common ones for me. Usually though if I'm importing fewer than about 3 symbols, I'll import then explicitly. -Barry

Guido van Rossum

5:14 p.m.

...

...
...
Suggested usage: from stat import *

Is ths still the suggested usage?

I don't see why not.

My understanding was that it's generally considered Bad Form to do this at module level, while doing it at function level is tricky (or a performance hit? whatever...) because of nested scopes.

Generally yes, but there's an explicit disclaimer "unless the module is written for this". And stat.py is (hence the recommendation in the docstring). Inside a function, from ... import * is always bad form. --Guido van Rossum (home page: http://www.python.org/~guido/)

Tim Peters

28 Jul 28 Jul

8:12 a.m.

[Guido]

...

... Inside a function, from ... import * is always bad form.

Worse, according to the Reference Manual, The "from" form with "*" may only occur in a module scope.

Guido van Rossum

1:54 p.m.

...

Worse, according to the Reference Manual,

The "from" form with "*" may only occur in a module scope.

I don't know when that snuck in, but it's not enforced. If we're serious, we should at least add a warning! I'll add a bug report. --Guido van Rossum (home page: http://www.python.org/~guido/)

Tim Peters

29 Jul 29 Jul

11:10 a.m.

[Tim]

...

Worse, according to the Reference Manual,

The "from" form with "*" may only occur in a module scope.

[Guido]

...

I don't know when that snuck in,

On Friday, 14 Aug 1992: it's in rev 1.1 of ref6.tex, and was there in the 0.98 release. This proved tedious to trace backwards, because you and Fred went through an amazing variety of ways to mark up "*" <wink>.

...

but it's not enforced. If we're serious, we should at least add a warning!

I thought we had agreed to do this back when the nested-scopes warnings were being added; guess not.

...

I'll add a bug report.

aka-the-retroactive-todo-list-ly y'rs - tim

Thomas Wouters

3:33 p.m.

On Sat, Jul 28, 2001 at 09:54:21AM -0400, Guido van Rossum wrote:

...

...
Worse, according to the Reference Manual,

...

...
The "from" form with "*" may only occur in a module scope.

...

I don't know when that snuck in, but it's not enforced. If we're serious, we should at least add a warning!

Eh, last I looked, you and Jeremy were most serious about this :) It came up during the nested-scopes change in 2.1, where it was first made illegal, and later just illegal in the presence of a nested scope: (without future statement)

...

...
...
def spam(x): ... from stat import * ... def eggs(): ... print x ... <stdin>:1: SyntaxWarning: local name 'x' in 'spam' shadows use of 'x' as global in nested scope 'eggs' <stdin>:1: SyntaxWarning: import * is not allowed in function 'spam' because it contains a nested function with free variables

(with future statement)

...

...
...
def spam(x): ... from stat import * ... def eggs(): ... print x ... File "<stdin>", line 2 SyntaxError: import * is not allowed in function 'spam' because it contains a nested function with free variables

...

I'll add a bug report.

Should we warn about exec (without 'in' clause) in functions as well ? (without future statement)

...

...
...
def spam(x,y): ... exec y ... def eggs(): ... print x ... <stdin>:1: SyntaxWarning: local name 'x' in 'spam' shadows use of 'x' as global in nested scope 'eggs' <stdin>:1: SyntaxWarning: unqualified exec is not allowed in function 'spam' it contains a nested function with free variables

(with future statement)

...

...
...
def spam(x,y): ... exec y ... def eggs(): ... print x ... File "<stdin>", line 2 SyntaxError: unqualified exec is not allowed in function 'spam' it contains a nested function with free variables

The warnings *only* occur in the presence of a nested scope, though. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Guido van Rossum

5 p.m.

...

On Sat, Jul 28, 2001 at 09:54:21AM -0400, Guido van Rossum wrote:

...
...
Worse, according to the Reference Manual,

...
...
The "from" form with "*" may only occur in a module scope.

...
I don't know when that snuck in, but it's not enforced. If we're serious, we should at least add a warning!

Eh, last I looked, you and Jeremy were most serious about this :) It came up during the nested-scopes change in 2.1, where it was first made illegal, and later just illegal in the presence of a nested scope:

(without future statement)

...
...
...
def spam(x): ... from stat import * ... def eggs(): ... print x ... <stdin>:1: SyntaxWarning: local name 'x' in 'spam' shadows use of 'x' as global in nested scope 'eggs' <stdin>:1: SyntaxWarning: import * is not allowed in function 'spam' because it contains a nested function with free variables

(with future statement)

...
...
...
def spam(x): ... from stat import * ... def eggs(): ... print x ... File "<stdin>", line 2 SyntaxError: import * is not allowed in function 'spam' because it contains a nested function with free variables

...
I'll add a bug report.

Hm. I'm curious why it was not made a warning without a nested function. Perhaps because too much 3rd party code would trigger the warning? (I have a feeling that lots of amateur programmers are a lot fonder of import * than they should be :-( ).

...

Should we warn about exec (without 'in' clause) in functions as well ?

(without future statement)

...
...
...
def spam(x,y): ... exec y ... def eggs(): ... print x ... <stdin>:1: SyntaxWarning: local name 'x' in 'spam' shadows use of 'x' as global in nested scope 'eggs' <stdin>:1: SyntaxWarning: unqualified exec is not allowed in function 'spam' it contains a nested function with free variables

(with future statement)

...
...
...
def spam(x,y): ... exec y ... def eggs(): ... print x ... File "<stdin>", line 2 SyntaxError: unqualified exec is not allowed in function 'spam' it contains a nested function with free variables

The warnings *only* occur in the presence of a nested scope, though.

That one is just fine I think. --Guido van Rossum (home page: http://www.python.org/~guido/)

Thomas Wouters

6:23 p.m.

On Sun, Jul 29, 2001 at 01:00:59PM -0400, Guido van Rossum wrote:

...

...
(with future statement)

...
...
...
def spam(x): ... from stat import * ... def eggs(): ... print x ... File "<stdin>", line 2 SyntaxError: import * is not allowed in function 'spam' because it contains a nested function with free variables

...

Hm. I'm curious why it was not made a warning without a nested function. Perhaps because too much 3rd party code would trigger the warning?

Yes.

...

(I have a feeling that lots of amateur programmers are a lot fonder of import * than they should be :-( ).

Oh yeah. If ActiveState's mailinglist statistics were extended to show howmany of my posts preach against using 'import *', I'd be top dog in the python-list stats :-) I also still owe Fred a tutorial chapter on why not to use import * :)

...

...
...
...
...
def spam(x,y): ... exec y ... def eggs(): ... print x

...

That one is just fine I think.

Why is 'import *' inside a function fine, but a bare exec isn't ? Weren't you going to deprecate bare exec's altogether ? -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Guido van Rossum

10:40 p.m.

...

...
...
...
...
...
def spam(x,y): ... exec y ... def eggs(): ... print x

...
That one is just fine I think.

Why is 'import *' inside a function fine, but a bare exec isn't ? Weren't you going to deprecate bare exec's altogether ?

You mean the other way around don't you? I proposed a warning for import * but not for bare exec. I guess for me the difference is that import * is just stupid (potentially lots of work going on every time you call the function) while the main problem with bare exec is that it gets in the way of optimizers and the like. Since we don't have an optimizer (yet) I don't care so much (yet). --Guido van Rossum (home page: http://www.python.org/~guido/)

Greg Ewing

11:47 p.m.

Guido:

...

...
Suggested usage: from stat import * """

Is ths still the suggested usage?

I don't see why not.

Because it flies in the face of the usual advice, which is never to use import *. How are we supposed to convince impressionable newbies to stay away from the evil drug of import * if the docs for one of the standard modules is brazenly advocating its use? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+

Fred L. Drake, Jr.

30 Jul 30 Jul

5:12 a.m.

Greg Ewing writes:

...

How are we supposed to convince impressionable newbies to stay away from the evil drug of import * if the docs for one of the standard modules is brazenly advocating its use?

If Guido will back off on saying that it's acceptable to use it that way, I can assure you the docs will be corrected. But if he's still advocating that usage (silly Dutchman), I don't think I should touch it. Even if it is silly. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

Tim Peters

5:43 a.m.

[Fred L. Drake, Jr., on import *]

...

If Guido will back off on saying that it's acceptable to use it that way, I can assure you the docs will be corrected. But if he's still advocating that usage (silly Dutchman), I don't think I should touch it. Even if it is silly.

Guido never advocates it, but you're not going to get him to say it's Evil either. The thing is, an intelligent adult can use import-* profitably and safely, in the handful of cases an intelligent adult realizes it's profitable and safe to do so <wink>. When Jeremy played w/ "import *"-inside-functions wngs, most popped up in Guido's code. This was most often from Tkinter import * in a module's _test() function, where doing so was handy amd harmless. I never use it myself -- but then I never write Tkinter code, and "stat" is some Unix abomination <wink>. It couldn't hurt to add an "intelligent adult" warning to the docs! I suggest an icon showing a refined English lady trying hard not to notice a West Virginian next to her picking his nose. perfect-images-are-too-rare-to-pass-up-ly y'rs - tim

aahz＠rahul.net

2:51 a.m.

Guido van Rossum wrote:

...

Greg Ward:

...
Suggested usage: from stat import *

Is ths still the suggested usage?

I don't see why not.

Here's why not: from stat import * from threading import * # Look at the docs if you don't believe me from Tkinter import * from types import * If you have a single module that imports all four of these (and I don't think that's particularly bizarre), tracing back any random symbol to its source becomes an annoying trek through *five* modules. There are probably a few other modules I don't know about that are declared "safe" for import *. IMO, this quickly leads to disaster, particularly when trying to debug someone else's code (and I've wasted more time than I'd like over this). It just plain goes against "explicit is better than implicit". I think we should declare a universal policy of NEVER recommending import *, except for interactive use. -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista I don't really mind a person having the last whine, but I do mind someone else having the last self-righteous whine.

barry＠zope.com

3:21 a.m.

...

...
...
...
...
"AM" == Aahz Maruch writes:

AM> If you have a single module that imports all four of these AM> (and I don't think that's particularly bizarre), tracing back AM> any random symbol to its source becomes an annoying trek AM> through *five* modules. There are probably a few other AM> modules I don't know about that are declared "safe" for import AM> *. IMO, this quickly leads to disaster, particularly when AM> trying to debug someone else's code (and I've wasted more time AM> than I'd like over this). AM> It just plain goes against "explicit is better than implicit". AM> I think we should declare a universal policy of NEVER AM> recommending import *, except for interactive use. Just because you can doesn't mean you should. :) I think it's a good thing that those modules you mention are declared safe for import-* but certainly in the situation you describe it isn't a good idea to use them that way. I don't remember a situation where I've ever import-*'d more than a couple of modules in any single file. There are often good reasons to use import-* at the module global level. Mailman has two places where this is used effectively. The more interesting place is in a configuration file called mm_cfg.py. This file is where users are supposed to put all their customizations overriding out-of-the-box defaults. At the top of the file there's a line like from Defaults import * Which brings all the symbols from the out-of-the-box default file (i.e. Defaults.py) into mm_cfg.py. Overrides go after this import line. Mailman modules always import mm_cfg and never import Defaults, so it makes for a very convenient way to arrange things so users only have to care about overriding specific variables, and never have to worry about the installation procedure overwriting their defaults ("make install" may write a new Defaults.py but never a mm_cfg.py). import-* is often good for creating this kind of transparent aliasing of one module's namespace into a second. I know <wink> no one's talking about outlawing from-import-*. It needs to be used judiciously, but it definitely has its uses. -Barry

Fred L. Drake, Jr.

5:23 a.m.

Aahz Maruch writes:

...

If you have a single module that imports all four of these (and I don't think that's particularly bizarre), tracing back any random symbol to

Only if you import-* them all, and that *is* a pathelogical case. Any time you import-* *two* modules, you have a pathelogical case on your hands, just ready to explode.

...

It just plain goes against "explicit is better than implicit". I think we should declare a universal policy of NEVER recommending import *, except for interactive use.

I'd be willing to give it up even there, esp. now that we have import-as. Barry sez:

...

There are often good reasons to use import-* at the module global level. Mailman has two places where this is used effectively. The more interesting place is in a configuration file called mm_cfg.py. This file is where users are supposed to put all their customizations overriding out-of-the-box defaults. At the top of the file there's a

This is about the only kind of thing I've ever found it useful for: re-implementing a module's interface, but when I only want to change a few things. Needing to do this never feels like a good solution, and probably indicates that some object needs to accept a parameter that offers the module's interface instead of finding it by name. So yeah, I'd give up import-*. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

barry＠zope.com

5:38 a.m.

...

...
...
...
...
"Fred" == Fred L Drake, Jr writes:

Fred> This is about the only kind of thing I've ever found it Fred> useful for: re-implementing a module's interface, but when I Fred> only want to change a few things. I call it "aliasing" a module (i.e. aliasing module A's symbols exported through module B). Fred> Needing to do this never feels like a good solution, and Fred> probably indicates that some object needs to accept a Fred> parameter that offers the module's interface instead of Fred> finding it by name. Um, sure, but it's can be pretty inconvenient to export 193 symbols this way :).

...

...
...
len(dir(Defaults)) 193

I've often thought that it would be nice to have better delegation support in Python, and no __getattr__() doesn't really hack it. I'm encouraged that some of the Py2.2 descr-branch stuff might actually make this valid programming technique more useful and then even I could see (eventually) giving up on import-*. -Barry

Fred L. Drake, Jr.

4:51 p.m.

Barry A. Warsaw writes:

...

Um, sure, but it's can be pretty inconvenient to export 193 symbols this way :).

Yeah, that's a lot. ;-)

...

I've often thought that it would be nice to have better delegation support in Python, and no __getattr__() doesn't really hack it. I'm encouraged that some of the Py2.2 descr-branch stuff might actually make this valid programming technique more useful and then even I could see (eventually) giving up on import-*.

Definately; it would be good to have nicer delegation support. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

Thomas Wouters

1:39 p.m.

On Mon, Jul 30, 2001 at 01:23:39AM -0400, Fred L. Drake, Jr. wrote:

...

Aahz Maruch writes:

...
If you have a single module that imports all four of these (and I don't think that's particularly bizarre), tracing back any random symbol to

Only if you import-* them all, and that *is* a pathelogical case. Any time you import-* *two* modules, you have a pathelogical case on your hands, just ready to explode.

We could generate a warning if the compiler detects two or more import *'s in the same codeblock ;) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

8299

Age (days ago)

8302

Last active (days ago)

List overview

Download

21 comments

8 participants

participants (8)

aahz＠rahul.net
barry＠zope.com
Fred L. Drake, Jr.
Greg Ewing
Greg Ward
Guido van Rossum
Thomas Wouters
Tim Peters

Advice in stat.py

Guido van Rossum

Guido van Rossum

Tim Peters

Guido van Rossum

Tim Peters

Guido van Rossum

Guido van Rossum

Tim Peters

aahz＠rahul.net

tags

participants (8)