On Mon, Oct 8, 2012 at 5:14 PM, Vinay Sajip <[email protected]> wrote: > What do *you* mean by entry point? My understanding is that it represents the > start of some executable code. Wikipedia: > > "In computer programming, an entry point is a memory address, corresponding > to a > point in the code of a computer program which is intended as the destination > of a > long jump, be it internal or external." > > So, in the Python sphere, I would interpret an entry point to be a callable. > While that might be the most common usage of the feature, it's not the only > one. > For example, you could use name = value entries where value is not a callable, > but for example a name of a resource to use for something, or a configuration > option, or the name of a package or a module (which is not an entry point by > my > understanding of entry points being callables).
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. ;-) 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.) 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. 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. That's why I baked those features into entry points from the beginning - I was battling what was at the time an excruciating slow startup for the Chandler application platform, and I borrowed the architectural pattern of delayed loading of plugins from Eclipse. (I also remember that Ian Bicking was talking about some problem, maybe on the Web-SIG, and I remember that the problem he was talking about could be solved by something like entry points, at which point I then had a solution for both Ian's problem and Chandler's problem.) _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
