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.

Reply via email to