Jean-Claude Wippler wrote: > > Marc-Andre, > > > BTW, would you want to miss relative file name paths ? > > Well, that thought did cross my mind while posting that reply... > > I'm not sure. Yes, they are convenient, but "current working directory" > is not always a pleasant concept (yet more global state - think of tree > walks and the inconvenience of having to get, alter, work, restore it - > when using chdir to implement this). I don't use .. as often as might > be expected. I use "cd ~/something" a lot more. While that may look > relative at another level, it really is not (as "echo ~" shows). It > does illustrate how nearly equivalent the two approaches are. > > DOS/Windows has always had a broken relative path: the current drive. > > And the "hash/bang" headers of Unix seem to always use absolute paths. ...and people have turned to /usr/bin/env to get around this necessity :-) > Some of this may seem to point to the need for relative paths. But I > think it hides a more fundamental issue: you need to find out context. > Once you do, relativeness no longer matters (obviously). A system which > has a current directory and ".." is equivalent to one which has no such > thing and passes a "starting directory" in the environment, say. > > I think a system with less global state is more modular -> preferable. Agreed. I would much prefer imputil.py to become a standard -- then I could add my hook into its chain and wouldn't have to argue for using relative imports ;-) But then, how would I tell if someone else already has integrated such a hook in the chain ? I sure wouldn't want to add another one just to make sure... If the standard mechanism already knows about '__' then I wouldn't have to worry. > Another angle: I have built many types of tree structures, still do. > Less and less of those contain a "parent" link. Instead of storing a > parent you can just as easily keep state while descending into children. > > - Unix file info does not maintain a parent directory, it's redundant. > - Directories do, and file system mount points are messy because of it. > - Afaik, it's considered bad style to use "../header.h" in C includes. > - Upward pointers can introduce cycles (no not here, as has been said). > - In C++, member objects rarely need pointers to the enclosing object. Note that my patch does exactly this: it resolves the __ while descending into the package structure -- without any explicit back reference stored in the modules. > It is not for a module to know where it "is" in a hierarchy, it is for a > parent to (sometimes) provide that reference when it uses the module. Right. > If you want want access to a module called mx, and there may be many of > them - then you ask another module to locate it for you. One which is > able to choose / decide for you. Proximity may be a good discriminator, > but the decision of proximity was not taken by you - and you won't know > what rule is best. So you ask an "importer" (which could well always be > the standard Python mechanism). Given the task to write such as beast, > I'd probably want to implement the following module search as default: > - look for the module first in the parent (i.e. as sibling) > - move one level up, look again, etc > - all the way to the top > That's just one way to do it - proximity is not *always* what you want. Now this is an interesting idea... looks like acquisition at the module import level. Right now the scheme is as follows: - look for the module in the import module's dir - look for the module on the PYTHONPATH You would just add a third lookup step in between the two... it would cause many more module lookups though. > So if Zope chooses a different packaging style, let it override import. > But please don't build ".." into your modules, it doesn't belong there. > > Sorry for all the handwaving generalities. The issues are the same IMO, > whether relativeness is provided or context, and therefore the outcome > of this discussion will never be conclusive - they both work. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 108 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