[Python-Dev] PEP 246, Feedback Request (original) (raw)

Guido van Rossum gvanrossum at gmail.com
Mon Jan 17 06:42:33 CET 2005

- 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( , intrinsiconly = 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/)

More information about the Python-Dev mailing list