On 06/23/2009 06:27 AM, Sylvain Hellegouarch wrote: > Matt Hammond a écrit : > >>> So some questions arise: >>> 1. Good idea or not? >>> 2. Really? Could be viewed as bad mojo& messing about one step too >>> far. >>> 3. If OK, should it be static? ie the list of what gets imported and >>> handles what dealt with by a table lookup in Kamaelia/__init__.py ? >>> 4. Or should it go "OK, I was imported here, I'll rummage around in all >>> my >>> subdirectories, in this overall order" >>> 5. Do 3, then 4, if the name wasn't found in 3. >>> 6. The other way round ? >>> 7. Do we allow extra search paths for the case of 4 ? (think sys.path >>> for >>> modules) >>> 8. How about allowing extra lookup tables to be added in the case of 3? >>> 9. lots more possibilities. >>> >>> >> I can see it would be much less verbose and that is a *good* thing! If >> nothing else, from writing examples in documentation, where brevity is >> highly desireable, adding all those import statements can be tedious and >> ugly. >> >> > True and yet I welcome that verbosity. I did a bit of Ruby and the first > thing that annoyed me was that there was lots of magic going on in > module finding and since the language allows you to change things rather > dramatically at so many levels I ended up being lost and frustrated quickly. > > I appreciate the fact that the current verbosity means I know where > things are coming from and never worry about name clashing. > > - Sylvain > I have to admit, and I agree. I did something similar in PHP5 with autoloading (we had no choice, really, because of the limitations of PHP and it's internal global scoping). much magic was done, and it was convenient but confusing.
I think Python developers, whether they realize it or not, come to this language with the expectation of being given a superb tools to do their own magic. Dynamic module loading may cause great confusion. But a static solution is actually excellent, IMHO. It saves one the effort of discovering the import chain, but at the same time gives us the ability to change it as needed. Another possibility could be to provide virtualenv configs for people who choose to use them, where the setup.pth file contains the proper sys path, and all modules are pulled in, etc. This can be a beautiful solution, since I can set up different dev environments that won't conflict or get too heavy when compared to my others. People who want to purely DIY can avoid the virtualenv config altogether. What do you think? Gloria --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to kamaelia+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~----------~----~----~----~------~----~------~--~---
