Ahhh, there we go, so "file" is type you declare. All I was asking
for, I thought you were thinking in a different/"more sophisticated"
direction (because what "f" actually wants is not a file, but a "thing
which has a read() like file" -- I thought one would like to manifest
that in the type inste
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, r
At 10:18 PM 1/13/05 +1000, Nick Coghlan wrote:
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
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):
x.re
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
On 2005 Jan 13, at 03:57, Phillip J. Eby wrote:
Okay, I'm really out of time now. Hate to dump this in as a possible
spoiler on PEP 246, because I was just as excited as Alex about the
possibility of it going in. But this whole debate has made me even
less enamored of adaptation, and more inte
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 in
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
> 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 w
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 appli
Phillip,
In my mind, the driving use-case for PEP 246 was to allow causual
programmers to plug components together and have it 'just work'; it
does this by enabling the component vendors to carry on a discussion
via __adapt__ and __conform__ to work together. I was not picturing
that your average
This is a pretty long post; it starts out as discussion of educational
issues highlighted by Clark and Ian, but then it takes the motivation for
PEP 246 in an entirely new direction -- possibly one that could be more
intuitive than interfaces and adapters as they are currently viewed in
Zope/Tw
12 matches
Mail list logo
