[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/) _______________________________________________ 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