On Thu, May 7, 2009 at 7:18 AM, P.J. Eby <p...@telecommunity.com> wrote: > At 08:28 PM 5/6/2009 +0200, Hanno Schlichting wrote: >> >> Doug Hellmann wrote: >> > On May 6, 2009, at 1:46 PM, P.J. Eby wrote: >> > >> >> At 10:59 AM 5/6/2009 -0400, Doug Hellmann wrote: >> >> >> >>> On May 5, 2009, at 10:50 PM, P.J. Eby wrote: >> >>> >> >>>> At 12:03 PM 5/6/2009 +1000, Ben Finney wrote: >> >>>>> I don't see any advantage, in the context of this discussion, to >> >>>>> having an additional, incompatible naming for full-path-to-a-class. >> >>>> >> >>>> Setuptools doesn't limit an entry point to being a class, function, >> >>>> or other top-level name within a module. It can be a method of a >> >>>> class, or an attribute of an attribute. The ':' removes any >> >>>> ambiguity as to which part of the name is the module, and which >> >>>> parts are attributes within that module. >> >>> >> >>> Is that level of complexity useful in practice? I can understand how >> >>> it came to be implemented, but is it actually used by any projects? >> >> >> >> I use it; I'm not sure who else does. >> >> >> >> The particular use case I have (and that's most likely to be shared) >> >> is that the calling app or framework wants a callable or function, but >> >> the providing app or library implements that callable as a classmethod >> >> for convenience. >> > >> > That's pretty much what I expected. It feels a little messy to have >> > plugins exposing "internals" like that but not so much so that I propose >> > we don't allow it. The ":" syntax seems like the right way to go. >> >> I'd be tempted to call this an edge-case. You should be able to expose >> the internal detail you'd need via a module scope alias for the >> particular case. That seems easier than providing a whole new notion. > > Ah, now you reminded me of a forgotten detail: the specific use case was > that I had a library with a Command class that was widely used as a base > class; simply adding a classmethod to that base class allowed all the > existing classes to be used as plugins without any change to their modules' > source code: the entry points just always reference the classmethod.
[slightly off topic] It seems like registration is the canonical use case for classmethods in Python no? Tarek has a good example in Expert Python Programming of this in his observer example. [/end] > > _______________________________________________ > Distutils-SIG maillist - distutils-...@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > -- Cheers, Noah _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
