On 4/20/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> With the ambiguity of sys.path, it's hard to statically determine if you
> have all the requirements.
[And, as you said elsewhere, whether it is the version you expected,
and whether it will actually load or get skipped because of an earlier
import]
Would you like the ability to specify precisely which file a requested
module gets loaded from, and to load your own copy if the
already-imported version has the wrong __file__ attribute?
> If you need to resolve a problem in a non-global manner, you can do so
> with alternate installation locations and sys.path manipulation.
If you need to resolve it in a non-global manner, doesn't that
indicate that you're working with a specific application, which can
safely run in (and modify the sys.path of) its own process?
> Mostly the ability to set up a localized environment disassociated from
> the global installation (except the stdlib).
Are you saying that you would like to lock the global environment, so
that you won't see anything except the original stdlib without an
explicit change to your own application?
If so, is the problem just that so many existing applications put
themselves on the global path, and [in a hosting situation] these may
be installed by someone else, without your knowledge?
In theory, the import path could be controlled directly by each
importing module, but in practice, I think that would lead to a bigger
mess as soon as there were conflicts (= as soon as it starts to
matter).
> I'm just noting that I think relative imports will
> be used by people who want to avoid the current distutil process,
Absolutely!
They also protect against version skew, which can be particularly
important if you're relying on a patched version.
> even though relative imports are not a good solution.
Why not? You won't get the benefit of automatic upgrades to
components you rely upon, but you won't get the risk either.
> it's not like zope.interface is
> magically more modular and elegant than zopeinterface.
One of the objections to the python documentation is that it can be
hard to find things if you don't already know where to look. The
module index is an obvious starting point, but is way too long,
because it lists every module instead of just packages and independent
modules.
Having to group on zope* rather than zope.* is a step backwards.
Looking at just the stdlib, are mailbox and mailcap related? operator
and optparse? I don't need to know anything about Carbon.* to know
that they're all related; if I have a summary of the Carbon package
("Mac only system bindings") I get to skip the whole batch.
-jJ
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
