Guido van Rossum wrote:
> On 4/8/06, Talin <[EMAIL PROTECTED]> wrote:
>
>>You know, on the one hand, I've been reading this thread, and I'm
>>excited about the possibility of generic functions (dynamic dispatch,
>>duckaplex-typing, whatever you want to call it), but at the same time
>>I kind of wo
On 4/8/06, Talin <[EMAIL PROTECTED]> wrote:
> You know, on the one hand, I've been reading this thread, and I'm
> excited about the possibility of generic functions (dynamic dispatch,
> duckaplex-typing, whatever you want to call it), but at the same time
> I kind of wonder about the eventual effec
Guido van Rossum python.org> writes:
> Before we worry about the implementation overhead, we need to make
> sure that the resulting paradigm shift isn't going to destroy Python
> as we know it. We already have well-established and well-understood
> machinery for method lookup in a class hierarchy
On Sat, Apr 08, 2006, Phillip J. Eby wrote:
>
> I suspect that the perspective of people like Alex, Jim, and myself is
> distorted by our being in consulting organizations (like Strakt, my
> group at Verio, and Zope corp.) where the focus is on having a toolkit
> that can be used to produce *multip
At 03:26 PM 4/8/2006 -0700, Guido van Rossum wrote:
>On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Those are mostly libraries, not frameworks, and for the most part you're
> > not *integrating* them. You're not trying to make Perforce store
> > information in your database, or to put a
On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Those are mostly libraries, not frameworks, and for the most part you're
> not *integrating* them. You're not trying to make Perforce store
> information in your database, or to put a database API over Perforce, for
> example.
OK -- then I fe
At 01:39 PM 4/8/2006 -0700, Guido van Rossum wrote:
>On 4/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Mostly just the API docs:
> > http://peak.telecommunity.com/protocol_ref/module-protocols.html
>
>I just finally found this too. PJE's website is really a confusing
>maze; the only *source* f
At 01:39 PM 4/8/2006 -0700, Guido van Rossum wrote:
>For example, what if one library overloads bool(str) so
>that bool("False") == False, while another library assumes the
>traditional meaning (non-zero string => True)?
Presumably, the author of that code would be taken out and shot. :)
I suspe
On 4/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mostly just the API docs:
> http://peak.telecommunity.com/protocol_ref/module-protocols.html
I just finally found this too. PJE's website is really a confusing
maze; the only *source* for PyProtocols I've found so far is a CVS
repository that se
At 02:21 PM 4/8/2006 +1000, Nick Coghlan wrote:
>>>Further, if all builtin function
>>>objects (including C function descriptors and method wrappers) were
>>>potentially generic,
>>This seems a rather extreme anticipation. I don't think anybody has
>>assumed this is where we might be going.
>
>Ther
Nick Coghlan wrote:
> With a change in type.__call__() to check the class extension registry
> before calling cls.__new__(), the above would put us well on the way to
> making
> all types extensible. For example, we could make a class of our own behave
> like a dictionary, returning its keys
Guido van Rossum wrote:
> On 4/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> I've been stealing liberally from PyProtocols all along, usually trying to
>> grasp ways to take *concepts* from it that I liked, and turn them into
>> something that seemed *usable* (with aesthetics playing a large par
On 4/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I've been stealing liberally from PyProtocols all along, usually trying to
> grasp ways to take *concepts* from it that I liked, and turn them into
> something that seemed *usable* (with aesthetics playing a large part in that).
Perhaps you coul
Phillip J. Eby wrote:
> At 02:15 PM 4/6/2006, Guido van Rossum wrote:
>> On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> > I don't want to discourage people from working out their own ideas,
>> > but a lot of the stuff that's being discussed here about protocol
>> > adaptation is already im
At 02:15 PM 4/6/2006, Guido van Rossum wrote:
>On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > I don't want to discourage people from working out their own ideas,
> > but a lot of the stuff that's being discussed here about protocol
> > adaptation is already implemented in PyProtocols.
>
>
On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I don't want to discourage people from working out their own ideas,
> but a lot of the stuff that's being discussed here about protocol
> adaptation is already implemented in PyProtocols.
That's great. I believe that if we derive things from f
Nick Coghlan wrote:
> One issue with generic functions and adaptation as currently being discussed
> (and something Tim mentioned a while back), it that it is very focused on
> dispatching based solely on obj.__class__.__mro__.
>
> That's all well and good, but (to use an example of Tim's), supp
> But I figured it was something worth throwing out there :)
>
> Cheers,
> Nick.
I'm finding most of this discussion very interesting although the fine
details haven't clicked for me just yet.
This reminds me of Guido's multi-method blog entry a while back. In
both the cases being discuss
Phillip J. Eby wrote:
> At 08:51 AM 4/6/2006, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>> So... in theory you could register strings, and thus implement
>> RuleDispatches behavior (where those strings represent expressions).
>> Or, ideally, py3k will have something better than strings to represent
At 08:51 AM 4/6/2006, Ian Bicking <[EMAIL PROTECTED]> wrote:
>So... in theory you could register strings, and thus implement
>RuleDispatches behavior (where those strings represent expressions).
>Or, ideally, py3k will have something better than strings to represent
>unevaluated expressions. Thoug
At 08:51 AM 4/6/2006, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>There is, however, an alternative, which would be to include a mechanism for
>telling a protocol about other equivalent protocols, and updating the
>registration mechanism to distribute any registration updates to the
>equivalent protoc
Nick Coghlan wrote:
> One issue with generic functions and adaptation as currently being discussed
> (and something Tim mentioned a while back), it that it is very focused on
> dispatching based solely on obj.__class__.__mro__.
RuleDispatch allows any function to be used in selecting an
impleme
22 matches
Mail list logo