On Wed, Jan 12, 2005 at 04:07:37PM -0600, Ian Bicking wrote:
| A two-step adaptation encodes specific intention that it seems transitive
| adaption would be blind to.
Exactly. Nice example Ian. To parrot your example a bit more
concretely, the problem happens when you get two different
adaptation paths.
String -> PathName -> File
String -> StringIO -> File
Originally, Python may ship with the String->StringIO and
StringIO->File adapters pre-loaded, and if my code was reliant upon
this transitive chain, the following will work just wonderfully,
def parse(file: File):
...
parse("helloworld")
by parsing "helloworld" content via a StringIO intermediate object. But
then, let's say a new component "pathutils" registers another adapter pair:
String->PathName and PathName->File
This ambiguity causes a few problems:
- How does one determine which adapter path to use?
- If a different path is picked, what sort of subtle bugs occur?
- If the default path isn't what you want, how do you specify
the other path?
I think Phillip's suggestion is the only resonable one here, ambiguous
cases are an error; ask the user to register the adapter they need, or
do a specific cast when calling parse().
| As I think these things through, I'm realizing that registered
| adaptators really should be 100% accurate (i.e., no information loss,
| complete substitutability), because a registered adapter that seems
| pragmatically useful in one place could mess up unrelated code, since
| registered adapters have global effects.
I think this isn't all that useful; it's unrealistic to assume that
adapters are always perfect. If transitive adaptation is even
permitted, it should be unambiguous. Demanding that adaption is
100% perfect is a matter of perspective. I think String->StringIO
and StringIO->File are perfectly pure.
| Perhaps transitivity seems dangerous because that has the potential to
| dramatically increase the global effects of those registered adapters.
I'd prefer,
1. adaptation to _not_ be transitive (be explicit)
2. a simple mechanism for a user to register an explicit
adaptation path from a source to a destination:
adapt.path(String,PathName,File)
to go from String->File, using PathName as an intermediate.
3. an error message, AdaptationError, to list all possible
adaptation paths:
Could not convert 'String' object to 'File' beacuse
there is not a suitable adapter. Please consider an
explicit conversion, or register a composite adapter
with one of the following paths:
adapt.path(String,PathName,File)
adapt.path(String,StringIO,File)
3. raise an exception when _registering_ a 'path' which would
conflict with any existing adapter:
"Could not complete adapt.path(String,PathName,File)
since an existing direct adapter from String to Path
already exists."
"Could not complete adapt.path(String,PathName,File)
since an existing path String->StringIO->File is
already registered".
I'd rather have the latter error occur when "importing" modules
rather than at run-time. This way, the exception is pinned on
the correct library developer.
Best,
Clark
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
