On Fri, Jun 13, 2003 at 12:50:53AM -0400, Raymond Hettinger wrote:
| PEP 246 is a higher level protocol for seeking and applying
| pre-existing wrappers.
Right.
| > The primary audience of PEP 246 are component/library developres
| > who wish for their components to interoperate between frameworks.
|
| This is why I don't think adapt() should be a builtin.
| adapt.adapt() is not any harder to call than random.random()
| or glob.glob().
Make sense, although it would be nice if it was in the standard
library so that people could start using it. There really doesn't
seem to be any challengers; and without it in the standard library
it will be harder to facilitate adoption. For example, Twisted
relys upon code in Twisted in Python, and no other third party
modules save pyOpenSSL. While PyProtocols may be out there, it
may be harder to encourage Twisted to include it as part of their
library without assigning copyright to Glyph. (Or am I mistaken)
| Yep. All it takes is one user to contribute code to support a protocol.
| My expectation is that the adapter code will (for the most part) be
| contributed by a sophisticated component user rather than the original
| supplier of the component. After all, if the supplier thought the
| foreign protocol was important, they would have supplied it in
| the first place.
Perhaps. Although I think people in Twisted would include adapters
for Zope or Webware and vice versa.
| The nice thing about 246 is that the adapter code
| can be contributed without altering the original component code
| (OCP: open for extension, closed for modification).
Exactly.
| I don't see any significant downside to 246. The code is simple
| enough. It is useful in at least some cases and provides some
| support for interoperability. I don't think it makes writing
| adapters any easier -- it does nothing to mitigate the problem
| of widely differing protocols with different underlying assumptions.
| Getting complete, bug free general purpose adoption will still
| remain a hard problem. Cie le vie.
Yes.
| So, my questions is whether there is any reason not to adopt 246
| right away? AFAICT, there is no competing proposal and nothing
| that would be harmed by adoption. What's all the fuss about?
On Fri, Jun 13, 2003 at 08:19:59AM -0400, Phillip J. Eby wrote:
| Guido has said (and I agree) that if Python includes adapt(), then the
| Python standard library should use it.
When adapt() emerged, iterators were being formulated, and what
motivated me to write up the PEP is that I thought that the
function iter() provides (adapting an object to an iterator
protocol) needed to be more generic. There are plenty of
places within Python where it could be applied.
| PyProtocols was my attempt to show that a PEP 246 mechanism can
| actually be pretty agnostic about what kind of interface objects
| are used, just like the '+' operator is agnostic about what
| object types it's used with.
Yes, but it also removes some requirements on an interface mechanism.
For instance, most of the interface strategies involve some sort
of list of interfaces, which could be changed easily without
altering the inheritance hierarchy. This is needed to be more
'dynamic' than what inheritance could tell you.
With adapt(), this requirement is less important, since someone
could always implement __conform__ or __adapt__ to get the dynamic
behavior they want. The risk of these other, non-inheritance
mechanisms is that while they may be more dynamic, they may be
brittle (or ugly, IMHO).
| Ah well. :) On the bright side, I think PyProtocols can alleviate
| *one* of his concerns, which was that having a Python-included interface
| type would make other interface types (e.g. Zope interfaces) "second-class
| citizens". That is, I've demonstrated that it is possible to have a
| "protocol protocol", thus allowing different protocol or interface
| types to exist, even if they have no implementation in common (e.g.
| Twisted, Zope, and PyProtocols).
Guido could start with a 'common demoninator' between what Twisted and
Zope do. That is, he could define a protocol as a class/object which
uses inheritance, but not specify other mechanisms in which one
implements the interface, leaving this out in the open.
For example, he could create an interfaces.py which looks like...
# inside interfaces.py
class Iterable(object):
def next():
""" returns the next value in the iteration, or
raises StopIteration to finish up
"""
Clearly someone could inherit from interfaces.Iterable to signal
that their object is iterable. However, they could also use other
mechanism to signal that they are iterable, namely a __iter__
method... and in this case,
def iter(obj):
return adapt(Iterable, obj)
Best,
Clark
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4