Gordon McMillan wrote: > > [M.-A. Lemburg] > > The current lookup does the following if you want to import > > a module E from module A.B.C.D: > > > > 1. check A.B.C.E > > 2. check E > > 3. fail > > > > Now instead of failing we could add a lookup method that > > walks up the package structure: > > > > 3. check A.B.E > > 4. check A.E > > [5. check E -- already done] > > 6. fail > > > > so that the complete scheme looks like this: > > > > 1. check A.B.C.E > > 2. check E > > 3. check A.B.E > > 4. check A.E > > [5. check E -- already done] > > 6. fail > > > > That way I could leave intra-mx-package imports untouched and > > still have the convenience of achieving the goal of making my mx > > subpackages work in the mx context *plus* in the top-level > > context thus allowing a backward compatible and flexible setup > > for mx* users. > > Comment 1: You're just giving yourself headaches by allowing > your users to install mx in anything other than the prescribed > manner. Actually, I'm trying to provide them a way to smoothly switch from the old setup to the new one. This includes myself, of course ;-). > Comment 2: I generally like this scheme, but think (for > consistency and confusion-reduction) that it should go straight > up the tree, instead of checking the root second. That would probably break code because the search could find some other module having the same name as a top-level one. OTOH, perhaps that situation is not all the common to fear too much about it. Walking up all the way would certainly be easier to explain to a 12-year old ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 100 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4