> - protocol means any object, usually a type or class or interface, > which guides the construction of an adapter
Then what do we call the abstract *concept* of a protocol? > - adaptee-class refers to the adaptee's class Please make it explicit that this is a.__class__, not type(a). > - factory refers to a function, f(adaptee) -> adapter, where > the resulting adapter complies with a given protocol Make this adapter factory -- factory by itself is too commonly used. > - First, the registry is checked for a suitable adapter How about checking whether adaptee.__class__ is equal to the protocol even before this? It would be perverse to declare an adapter from a protocol to itself that wasn't the identity adapter. > - PEP 246 will ask for a `adapt' module, with an `adapt' function. Please don't give both the same name. This practice has caused enough problems in the past. The module can be called adaptation, or adapting (cf. threading; but it doesn't feel right so I guess adaptation is better). > - At any stage of adaptation, if None is returned, the adaptation > continues to the next stage. Maybe use NotImplemented instead? I could imagine that occasionally None would be a valid adapter. (And what do we do when asked adapt None to a protocol? I think it should be left alone but not considered an error.) > - At any stage of adaption, if adapt.AdaptException(TypeError) is > raised, then the adaptation process stops, as if None had been > returned from each stage. Why are there two ways to signal an error? TOOWTDI! > - One can also register a None factory from A->B for the > purpose of marking it transitive. In this circumstance, > the composite adapter is built through __conform__ and > __adapt__. The None registration is just a place holder > to signal that a given path exists. Sounds overkill; the None feels too magical. An explicit adapter can't be too difficult to come up with? > There is a problem with the default isinstance() behavior when > someone derives a class from another to re-use implementation, > but with a different 'concept'. A mechanism to disable > isinstance() is needed for this particular case. Do we really have to care about this case? Has someone found that things go harebrained when this case is not handled? It sounds very much like a theoretical problem only. I don't mean that subclasses that reuse implementation without being substitutable are rare (I've seen and written plenty); I mean that I don't expect this to cause additional problems due to incorrect adaptation. > Guido would like his type declaration syntax (see blog entry) to > be equivalent to a call to adapt() without any additional > arguments. However, not all adapters should be created in the > context of a declaration -- some should be created more > explicitly. We propose a mechanism where an adapter factory can > register itself as not suitable for the declaration syntax. I'm considering a retraction of this proposal, given that adaptation appears to be so subtle and fraught with controversies and pitfalls; but more particularly given the possible requirement (which someone added in a response to a blog) that it should be possible to remove or ignore type declarations without changing the meaning of programs that run correctly (except for code that catches TypeError). > - adapt( , intrinsic_only = False) will enable both sorts of adapters, That's one ugly keyword parameter. If we really need this, I'd like to see something that defaults to False and can be switched on by passing mumble=True on the call. But if we could have only one kind that would be much more attractive. Adaptation looks like it is going to fail the KISS test. > There was discussion as to how to get back to the original > object from an adapter. Is this in scope of PEP 246? Seems too complex. Again, KISS. > Sticky adapters, that is, ones where there is only one instance > per adaptee is a common use case. Should the registry of PEP 246 > provide this feature? Ditto. If you really need this, __adapt__ and __conform__ could use a cache. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
