Spider wrote: > Python guru Fredrik Lundh has an article at > http://effbot.org/zone/import-confusion.htm > in which he discusses use of the import statement. He says, > essentially : > "import X" should be the normal method of importing > "from X import *" is bad practice > "from X import Y" is sometime ok > That seems to be the general agreement in the python world. > > Some of the sample pylons applications and documentation use the "from > X import *" format. Maybe we should consider changing that over time. > > For me as a newbie to Pylons, one of the drawbacks to the "from X > import *" method is that imported objects end up in the global > namespace, which makes it difficult to work out where a object comes > from (made more complex since Pylons is a "glue" framework). I think > I'd find Pylons code easier to read if objects were coded as X.<name> > rather than just plain <name>. > This decision was explicitly made, and I have no intention of changing it in the Pylons defaults in the future. The main reason for this is for both DRY and for ease of use. You need several things in all your controllers, why should you import them over and over again in every single controller?
If you do a "import *" from a system installed library, it's going to really suck trying to find out what you just imported. As JJ mentioned, in a Pylons project the "import *" takes from a file in your project, under your control. You know what's going to be imported, and its close by to the controller files that use it. Really, the underlying issue is that DRY and 'explicit' run contrary to each other. Pylons is attempting to facilitate DRY by making the most common names available in all your controllers, and being explicit by putting control over those names in your base.py module so that its close by and you're in control. Also, should you need to make a db session name available in all your controllers, you can change it in one place. Or if you decide instead of using Pylons Response object, you can make your own and put it in base.py so that all your code then uses it by default. As PEP 8 says at the top, "A Foolish Consistency is the Hobgoblin of Little Minds". While Pylons code might or might not be easier to read with 'pylons.Response' or 'pylons.templating.render' all over, consider that you're looking at adding hundreds or thousands of additional keystrokes as the names imported are very common. You'd sacrifice write-ability for what I'd consider negligible reading improvements. Cheers, Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
