On Jan 7, 2011, at 2:15 AM, puercoespin wrote: > >> Indeed. >> >> Moreover, while it's not best practice, it's certainly common enough to see >> >> from somewhere import * >> >> which "magically" injects a bunch of names into the namespace. >> >> Your suggestion that web2py simply has a small set of built-ins strikes me >> as right on. > > For exemple > > from gluon.tools import * > > in db.py. > > :)
Exactly right. I've removed a few of those, but it's tedious work. I've been using pyflakes as a quick check on my Python coding. Pyflakes is very handy, but it's also fairly simpleminded. If you say "from gluon.tools import *", it doesn't look in gluon.tools to see what that might mean; it just turns off its search for undefined symbols. So to get its benefit, you have to fix the import *. For the same reason, a lot of my code starts out with: if False: import request, response, session, T, (etc) OTOH, pyflakes has built-in knowledge of built-in Python globals. One of the things that the web2py-imports discussion tends to miss, though, is that the web2py "globals" exist precisely because they're *not* globals--they have request scope, not global scope. They can't be imported (in a straightforward way, anyway), and it would be a PITA to have to pass them around everywhere. That would have been an alternative strategy for web2py: every argument list starts with the request-global, which would include all that stuff.