[Python-Dev] PEP 246: lossless and stateless

[Guido van Rossum]

[Phillip]
> Quick demo (strawman syntax) of declaring adapters...
> 
> First, a type declaring that its 'read' method has the semantics of
> 'file.read':
> 
>      class SomeKindOfStream:
>          def read(self, byteCount) like file.read:
>              ...
[and more like this]

Sorry, this is dead in the water. I have no desire to add syntax
complexities like this to satisfy some kind of theoretically nice
property.

> Second, third-party code adapting a string iterator to a readable file:

We need to pick a better example; I like Armin's hypothesis that
adapting strings to more specific things is abuse of the adapter
concept (paraphrased).

> >Are there real-life uses of stateful adapters that would be thrown out
> >by this requirement?
> 
> Think about this:
[...]

No, I asked for a real-life example. Just provided one, and I'm
satisfied that stateful adapters can be useful.

["proof" omitted] 
> Thus, stateful adapters *must* be explicitly adapted by the code that needs
> to manage the state.

This doesn't prove it at all to me.

> This is why I say that PEP 246 is fine, but type declarations need a more
> restrictive version.  PEP 246 provides a nice way to *find* stateful
> adapters, it just shouldn't do it for function arguments.

You haven't proven that for me. The example quoted earlier involving
print_next_line() does nothing to prove it, since it's a bad use of
adaptation for a different reason: string -> file adaptation is abuse.

> >But the solution IMO is not to weigh down adapt(), but to agree, as a
> >user community, not to create such "bad" adapters, period.
> 
> Maybe.  The thing that inspired me to come up with a new approach is that
> "bad" adapters are just *sooo* tempting; many of the adapters that we're
> just beginning to realize are "bad", were ones that Alex and I both
> initially thought were okay.

One of my hesitations about adding adapt() and interfaces to the core
language has always been that it would change the "flavor" of much of
the Python programming we do and that we'd have to relearn how to
write good code. There are other places in Python where it can be
tempting to use its features in a way that can easily cause trouble
(the extremely dynamic nature of the language is always tempting); we
tend not to invent new syntax to fix this but instead develop idioms
that avoid the issues.

IOW, I don't want to make it syntactically impossible to write bad
adapters, but we'll have to develop a set of guidelines for writing
good adapters. I don't believe for a second that all stateful adapters
are bad, even though I expect that stateless lossless adapters are
always good.

I like Armin's hypothesis better.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)