Mike Orr wrote: > There are three arguments, not all made by the same people. > > 1) 1-letter variables are bad because they're not self-documenting. > Ben and some others are pushing this, > > 2) "import *" is ugly, do anything to get rid of it. Ben has proposed > reducing imports > to the minimum necessary. Some of the other imports may survive as comments. > Ian and I have proposed importing the base module as 'base'. Ben and > some others are pushing this.
My concern here has actually been the reactions I've gotten from people experienced with Python when they first look at Pylons. Several different people have mentioned this -- not as a horrible thing, but as something that stuck out to them, and just seemed to smell a bit off. It's more about the emotional response. 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 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 one import * makes it harder to understand a module. Removing import * is also easy, as it's mostly a change to the paster templates with no backward compatible issue. As a special case, few people understand what pylons.g is and self-documentation there would be really helpful. When someone 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 also a sign of some underlying weirdness there. pylons.h is worth learning IMHO; I don't really mind it -- except that there's no reason it needs to be under "pylons" -- but that's already deprecated. I also wish url_for was promoted to a more prominent position during template substitution -- there's not much of a backward compatibility issue there since it's easy enough to have it in two places. 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. > 3) Mimimize StackedObjectProxies. That's the only reason for moving pylons.* > . > Ben has not acknowledged this as a problem. But I and others think > they're fragile and > hard to understand, and thus make Pylons hard to understand. (Which > was Ben's motivation > for (1) and (2).) Some have suggested moving them onto a single SOP > as attributes. > Ian suggested putting them all on 'request', which by definition is > request-local information. > (Whether some of the information persists beyond the request is a > different question.) 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. 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 = 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 import the name directly at a global scope. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~----------~----~----~----~------~----~------~--~---
