[Python-Dev] PEP 246, redux (original) (raw)
Clark C. Evans cce at clarkevans.com
Thu Jan 13 18:46:43 CET 2005
- Previous message: [Python-Dev] PEP 246, redux
- Next message: [Python-Dev] PEP 246, redux
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Jan 12, 2005 at 01:15:20PM -0800, Guido van Rossum wrote: | [Clark] | > - add a flag to adapt, allowTransitive, which defaults to False || That wouldn't work very well when most adapt() calls are invoked | implicitly through signature declarations (per my blog's proposal).
Understood. This was a side-suggestion -- not the main thrust of my response. I'm writing to convince you that automatic "combined" adaptation, even as a last resort, is a bad idea. It should be manual, but we can provide easy mechanisms for application developers to specify combined adapters easily.
On Wed, Jan 12, 2005 at 02:57:11PM -0500, Clark C. Evans wrote: | On Wed, Jan 12, 2005 at 10:16:14AM -0800, Guido van Rossum wrote: | | But now, since I am still in favor of automatic "combined" adaptation | | as a last resort
A few problems with automatic "combined" adaptation:
Handling the case of multiple adaptation pathways is one issue; how do you choose? There isn't a good cost algorithem since the goodness of an adapter depends largely on the programmer's need.
Importing or commenting out the import of a module that may seem to have little bearing on a given chunk of code could cause subtle changes in behavior or adaptation errors, as a new path becomes available, or a previously working path is disabled.
The technique causes people to want to say what is and isn't an adapter -- when this choice should be soly up to the appropriate developers. I'd rather not have to standardize that FileName -> File is a bad adaption, but File -> String is a good adaption. Or whatever is in vogue that year.
It's overly complicated for what it does. I assert that this is a very minor use case. When transitive adaptation is needed, an explicit registration of an adapter can be made simple.
My current suggestion to make 'transitive adaption' easy for a application builder (one putting togeher components) has a few small parts:
If an adaptation is not found, raise an error, but list in the error message two additional things: (a) what possible adaptation paths exist, and (b) how to register one of these paths in their module.
A simple method to register an adaption path, the error message above can even give the exact line needed,
adapt.registerPath(from=A,to=C,via=B)
Make it an error to register more than one adapter from A to C, so that conflicts can be detected. Also, registrations could be 'module specific', or local, so that adapters used by a library need necessarly not be global.
In general, I think registries suffer all sorts of namespace and scoping issues, which is why I had proposed conform and adapt Extending registry mechanism with automatic 'transitive' adapters makes things even worse.
Cheers,
Clark
Clark C. Evans Prometheus Research, LLC. http://www.prometheusresearch.com/ o office: +1.203.777.2550 ~/ , mobile: +1.203.444.0557 // (( Prometheus Research: Transforming Data Into Knowledge \ , / - Research Exchange Database /\ - Survey & Assessment Technologies ` \ - Software Tools for Researchers ~ *
- Previous message: [Python-Dev] PEP 246, redux
- Next message: [Python-Dev] PEP 246, redux
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]