On Fri, Aug 14, 2009 at 23:05, Johannes Janssen<[email protected]> wrote: > Gaetan de Menten schrieb: >> On Wed, Aug 12, 2009 at 00:52, Johannes Janssen<[email protected]> >> wrote:
[...] >>> They are by the >>> default real absolute path (that means they are relative to __main__). >>> Using "resolve_root" option you can change this. >> Good ideas. I didn't think of those. I was using an alternate resolve >> method to emulate your "resolve_root" option but since it's probably a >> common use case, it's a nice idea to have such an option. > I assume that you agree that having "resolve_root" on a per-entity basis > makes sense. Hmm no. Seems like I wasn't clear enough. I meant it as an option (ie argument to the constructor) on the EntityCollection class. What would a use case for what you suggest be? If you specify a specific resolve_root for *one* particular entity, you might as well use the absolute paths. That feature would only make sense if you have *lots* of relations to the same target module within the same entity *and* that target module is not the current module (or one close to it in the module hierarchy). This seems like a very unlikely combination and not worth a feature in the default distribution (you could still implement it as a custom collection if you wish). > There may be better names like "module_root" for that option. Indeed. >>> (What I said about module paths (not) starting with a dot is not quite >>> true. "..foo.bar" will still be an abs path and while "...foo.bar" is an >>> rel path. Got it? Have a look at the example!) >> Hmmm, I lost you there. The relative path idea seems good. Using a >> leading dot seems good but this ".. is a no-op" idea seems artificial >> and very different to how python's relative imports work, hence very >> confusing. Honestly, I don't understand what's the point. > Yeah, I totally don't understand how I came up with this, now. Perhaps > it was bit too late, when I did this. It is not how relative imports > work in python, but like paths in common OSes. Okay just ignore all the > ".." stuff. That leaves this: > > * absolute paths (must not start with a dot) > o they are "relative" to the resolve_root option > o you can't address classes living not within the module given > by resolve_root or any of it's submodules > o resolve_root defaults to __main__ module, making the paths > real absolute paths like in the current resolve method > * relative paths (must start with at least one dot) > o they are relative to the entity class passed to the resolve > function > o each additional dot at the beginning of the path has the > meaning of going up one module/package level > > [...] > > I append a new version of the resolve function implementing this > behavior (http://paste.pocoo.org/show/134345/). This new version makes sense to me. I've created ticket #93 to keep track of it. -- Gaëtan de Menten http://openhex.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SQLElixir" 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/sqlelixir?hl=en -~----------~----~----~----~------~----~------~--~---
