PJ Eby <pje <at> telecommunity.com> writes: > > In pkg_resources, entry points are references to any importable > object. They don't have to be callables. > > Note, however, that if you load an entry point which is a module, then > of course the module code will be executed as a side-effect, so > technically, a module still meets the "start of some executable code" > standard.
Yes, I acknowledged this in my response to Lennart's post. > In any case, the name was chosen for the primary use case of > designating executable entry points in Python code, often callables. > However, given the nature of Python, there was absolutely no reason to > restrict them to referring *only* to callables. (In fact, the > feature's name and implementation was inspired by Eclipse's "extension > points" architecture, where the advertised objects usually implement > interfaces with more than one method.) Right, they're just objects of one sort or another. > > If the name *must* be changed, I'd suggest using "exports", for > symmetry with "imports". Entry points are always the name of an > importable object, and they are basically being advertised so that > other code knows what is available to be imported, and the loading API > allows one to handle other details such as updating sys.path as > necessary, and doing the actual import. As you say, entry points don't have to be actual entry points, and I didn't want to slavishly follow pkg_resources nomenclature; though it reflects the most common use case, it's not the only one. Your suggestion of "exports" seems very reasonable as a replacement for "registry", which I agree is too generic. > I understand that right now you're not supporting those other features > in distlib, but I feel I should mention as a reminder that many of > these pkg_resources features were created to support application > platforms with plugins, such as Trac, Zope, Chandler, etc., and to > prevent the need for wheel-reinvention between different Python plugin > systems. For this type of platform, it's often an important core > feature to be able to dynamically add plugins and their requirements > to sys.path on an as-needed basis when the entry points are actually > *used*, because early loading or additions to sys.path can > dramatically affect application startup times. I understand, and appreciate your pointing these things out. As I see it, the specific way that some of those features were implemented is what some people object to. In distlib, importing is still lazy, but sys.path is not updated before attempting imports. Clearly, distlib can't do things exactly the way they're done in pkg_resources and setuptools, since those are not considered suitable to go into the stdlib, whereas distlib hopes to provide (some of) the useful features provided in those packages in a (hopefully) non-contentious way, with perhaps part of it going into the stdlib at some future date if there's a consensus about that. ISTM that the "exports" feature in distlib allows applications to cooperate in the same way as pkg_resources' entry points do, except for the fact that sys.path is not manipulated at all, meaning that all such cooperating applications are assumed to be installed on the path. Actual importing is delayed until needed; scanning of distribution metadata for exports also happens on demand. Do you feel that this is insufficient to meet the performance concerns you mentioned? Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
