Re: Cleaning some house of imports and one letters

[Ben Bangert]

On Dec 19, 2007, at 8:37 AM, Ian Bicking wrote:

My concern here has actually been the reactions I've gotten from people

experienced with Python when they first look at Pylons.  Several

something that stuck out to them, and just seemed to smell a bit off.
It's more about the emotional response.

different people have mentioned this -- not as a horrible thing, but as

Yes, and I think the emotional response does count. It's why many people choose Python over Ruby, the syntax gives them a better emotional response in most cases.

import * isn't just about ugly, it's also how easy it is to dive into
code you don't know and find your way around.  Again, for people

one import * makes it harder to understand a module.

experienced with Python but not Pylons this can be a problem. More than one import * in a file is horrible, but that isn't happening -- but just

It also makes things feel 'magic' since variables just end up there, and many tools that do basic variable checks can't properly account for names landing in a module from a import * statement.

As a special case, few people understand what pylons.g is and
self-documentation there would be really helpful.  When someone

also a sign of some underlying weirdness there.

mentioned app_locals as a name, that actually made more sense to me than app_globals. But that it is unclear if it's a local or global value is

Agreed.

pylons.c is just a little odd -- if we could change the render function

to just take substitution variables as keyword arguments then I
personally would just stop using pylons.c, and probably be happier for
it.  Right now I guess I have to do variables=dict(...), which isn't
horrible but doesn't look pretty for such a common construct.

Quite a few people actually want this, also because it forces their templates to fail. Of course, many people absolutely require the current methodology since they setup 'c' options in the BaseController for use in all templates, which is a great and intended use of the global ability to set 'c' options. Whether thats a 'good' usage or not is somewhat more debateable, since in systems where you can't do this, its hardly too crippling to have a function you call that sets up some basic options, which also makes it clearer how those extra options land in the template....

Besides being hard to understand, they are a pain to debug.  That's
actually my concern with them.  Oh, and they have weird performance
characteristics that have frequently caught people.

I don't see any way to remove them.... but we could go back to just thread-locals, and tell people not to use Pylons apps in front of Pylons apps (does anyone actually do this???). We are incurring a lot of complexity with SOP's for a 0.01% use-case here...

But short of getting request-local values via a function instead of a
proxy, I don't think there's a very good solution.  Attaching stuff to
the request at least makes them a little clearer, and makes the
performance at least slightly clearer (you can do something like c =

import the name directly at a global scope.

request.c, and get a bound value for c that isn't a proxy). What makes the performance clearer also, as Max noted, also makes it impossible to

Cheers,
Ben

I'm really not a fan of having to dig into a hierarchy under a 'request' object to get to everything.

smime.p7s
Description: S/MIME cryptographic signature