On 11/30/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > so no offense in advance.
>
> Sure, no offense taken. I've seen comments like this before on this
> list (recently :-). I think both approaches (interface types and duck
> typing) are complicated in different ways.
Instinctively, I agree w
Steven Bethard schrieb:
> On 11/29/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> But the >>> prompt is Python's trademark! I always get a warm fuzzy
>> feeling when I see it, e.g. in a corner of a slide in a NASA
>> presentation.
>
> I was using ``py>`` for a while. That still gave me a wa
On 12/1/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 11/30/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > so no offense in advance.
> >
> > Sure, no offense taken. I've seen comments like this before on this
> > list (recently :-). I think both approaches (interface types and duck
> > typing
> Instinctively, I agree with Tomer on this issue. But I'm reasonably
> relaxed about the matter as long as it's optional. What I'm not sure
> about, is if that is the intention. For example,
>
> class MyMap:
> def __getitem__(self, key): ...
> def __setitem__(self, key, value)
Guido van Rossum wrote:
> On 12/1/06, Paul Moore <[EMAIL PROTECTED]> wrote:
>
>> On 11/30/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
>>
so no offense in advance.
>>> Sure, no offense taken. I've seen comments like this before on this
>>> list (recently :-). I think bot
[Bill]
> I agree. For instance, the
> [k] operation may be implemented by the Container interface generic
> implementation, in which case your type might have to have the
> Container interface
i would still like to understand how object proxying (e.g., weakrefs, RPyC),
could work when all/most fr
On Friday 01 December 2006 12:08, tomer filiba wrote:
> i would still like to understand how object proxying (e.g., weakrefs,
> RPyC), could work when all/most frameworks/libraries would be based on
> ABCs.
That's a realy problem. zope.interface works hard to deal with proxies, but
it probabl
On 12/1/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Friday 01 December 2006 12:08, tomer filiba wrote:
> > i would still like to understand how object proxying (e.g., weakrefs,
> > RPyC), could work when all/most frameworks/libraries would be based on
> > ABCs.
>
> That's a realy prob
At 10:19 AM 12/1/2006 -0800, Guido van Rossum wrote:
>On 12/1/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> > On Friday 01 December 2006 12:08, tomer filiba wrote:
> > > i would still like to understand how object proxying (e.g., weakrefs,
> > > RPyC), could work when all/most frameworks/li
On 12/1/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i would still like to understand how object proxying (e.g., weakrefs, RPyC),
> could work when all/most frameworks/libraries would be based on ABCs.
> again, the problem is, your proxy is an instance of ProxyType, that
> refers to another, "con
At 01:45 PM 12/1/2006 -0500, Jim Jewett wrote:
>Why can't your proxy be a derived class that claims to inherit
>from those same base classes, but just happens to override all the
>methods (and attributes).
Because that means you can't use generic proxy objects (e.g. zope.proxy or
ProxyTypes).
Lu
Samuele Pedroni writes:
> Also the built-in types are concrete types, which tend to maximize
> convenience. It's unclear
> that they are a good starting point to define interfaces, because of
> this maximality.
I agree with you on this, Samuele. I don't want to deep-end, and put
only one metho
> Because that means you can't use generic proxy objects (e.g. zope.proxy or
> ProxyTypes).
>
> Luckily, however, proxies can lie about their __class__ (since Python 2.3)
> and thereby fool isinstance().
My guess is that support for weakrefs and/or RPC proxies (something
with which I have a lot
On 12/1/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:19 AM 12/1/2006 -0800, Guido van Rossum wrote:
> >On 12/1/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> > > On Friday 01 December 2006 12:08, tomer filiba wrote:
> > > > i would still like to understand how object proxying (e.g.,
On 12/1/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i would still like to understand how object proxying (e.g., weakrefs, RPyC),
> could work when all/most frameworks/libraries would be based on ABCs.
I don't think that's what is being proposed, if I understand Guido's
response to my post. There
Paul Moore writes:
> There is no expectation that all/most (or even
> many!) libraries would be based on ABCs. Duck typing would remain the
> norm. Although I'm not clear what the value of all this is, if the
> resulting ABCs *don't* get used in real code.
I'm not sure what it means to base a libr
At 11:52 AM 12/1/2006 -0800, Bill Janssen wrote:
>Paul Moore writes:
> > There is no expectation that all/most (or even
> > many!) libraries would be based on ABCs. Duck typing would remain the
> > norm. Although I'm not clear what the value of all this is, if the
> > resulting ABCs *don't* get use
> I would actually hope that library implementors would shift to using
> generic functions, since then they can just document what the function(s)
> are supposed to do, and people can just add methods to those functions for
> any object types they like, without needing to subclass anything, or h
On 12/1/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:52 AM 12/1/2006 -0800, Bill Janssen wrote:
> >Paul Moore writes:
> > > There is no expectation that all/most (or even
> > > many!) libraries would be based on ABCs. Duck typing would remain the
> > > norm. Although I'm not clear what the
[Phillip]
> Luckily, however, proxies can lie about their __class__ (since Python 2.3)
> and thereby fool isinstance().
yes, well, you try to override __class__ when the real class is actually
in a different process :)
types compare by ID, so when a proxy is created for an object in another
proce
At 01:41 PM 12/1/2006 -0800, Bill Janssen wrote:
>And adding GFs does not give us a coherent ability to do type
>introspection, which I think would help. Again, I seem to need to
>look at values *returned* from calls as much as I worry about the type
>of parameters passed into my functions. GFs w
At 01:46 PM 12/1/2006 -0800, Guido van Rossum wrote:
>I'm not sure what you mean this. Are you proposing that a library
>function that might take a mapping would be rewritten as a generic
>library function with one implementation that takes a mapping? Or are
>you proposing that the library function
At 12:02 AM 12/2/2006 +0200, tomer filiba wrote:
>i'm +1 on that, but still, as Guido (and others) said, you need a way to
>differentiate a sequence from a mapping, or a list from a string. dispatching
>based on *concrete types*, i.e., isinstance(x, dict), is bad, as it means
>users *must derive* f
> Actually, to me the thing that's a stretch from current practice is the
> attempt to spell out in detail what a "mapping" is.
Good point :-). Of course, that's the problem I'd like to see fixed
-- not knowing what a mapping is, or whether a particular value is
one.
> I'm not saying there is n
Paul Moore wrote:
> There is no expectation that all/most (or even
> many!) libraries would be based on ABCs. Duck typing would remain the
> norm.
But even if there are only a few things that don't
honour duck typing, it will have an effect on everyone,
because there will always be some anxiety th
tomer filiba wrote:
> when a proxy is created for an object in another
> process, you can only set __class__ to a *proxy* to the remote type...
> so isinstance fails.
But the class being passed to isinstance() can only be
a proxy to the remote class as well, so as long as it's
the same proxy that
At 05:47 PM 12/1/2006 -0800, Bill Janssen wrote:
> > Actually, to me the thing that's a stretch from current practice is the
> > attempt to spell out in detail what a "mapping" is.
>
>Good point :-). Of course, that's the problem I'd like to see fixed
>-- not knowing what a mapping is, or whether
I'm not sure anyone would be interested in this or not. A few months
back, I wrote a generic function dispatcher based on the Chambers/Chen
paper for my embedded mini-language, Saga. It's written in C++, although
it makes fairly minimal use of C++ features.
This code is an independent creation
28 matches
Mail list logo
