On Thu, 13 Jan 2005 01:04:01 -0500, Phillip J. Eby
[EMAIL PROTECTED] wrote:
At 12:01 AM 1/13/05 -0500, Michael Walter wrote:
What am I missing?
The fact that this is a type-declaration issue, and has nothing to do with
*how* types are checked.
I was talking about how you declare such types,
Michael Walter wrote:
Yepyep, but *how* you declare types now? Can you quickly type the function
def f(x): x.read()? without needing an interface interface x_of_f: def
read(): pass or a decorator like @foo(x.read)? I've no idea what you
mean, really :o)
Why would something like
def f(x):
At 08:50 AM 1/13/05 +0100, Alex Martelli wrote:
Your proposals are novel and interesting. They also go WAY deeper into a
critical reappraisal of the whole object model of Python, which has always
been quite reasonably close to the above-mentioned canon and indeed has
been getting _more_ so,
At 11:26 PM 1/12/05 -0500, Clark C. Evans wrote:
Regardless,
getting back to the main goal I had when writing PEP 246 -- your
alternative proposal still doesn't seem to provide a mechanism for
component developers to have a dialogue with one another to connect
components without involving the
instead interfaces can be defined in terms of individual operations, and
those operations can be initially defined by an abstract base, concrete
class, or an interface object.
I think this is quite problematic in the sense that it will force many
dummy interfaces to be created. At least
At 09:57 PM 1/12/05 -0500, Phillip J. Eby wrote:
class StringIO:
def read(self, bytes) implements file.read:
# etc...
could be used to indicate the simple case where you are conforming to an
existing operation definition. A third-party definition, of the same
thing might
At 12:01 AM 1/13/05 -0500, Michael Walter wrote:
What am I missing?
The fact that this is a type-declaration issue, and has nothing to do with
*how* types are checked.
Note that I'm only proposing:
1) a possible replacement for PEP 246 that leaves 'adapt()' as a function,
but uses a different
