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.