> Guido van Rossum wrote:
> > What if, instead of adding registries mapping types to functions left
> > and right (in pickle, copy, pprint, who knows where else), we had a
> > convention of adding __foo_bar__ methods directly to the class dict?
> > This would require giving up the effective immutab
"Ian Bicking" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> Definitely wild. Reader beware. Now is the time to generate lots of
>> wild ideas and let them sink in. If it still seems a good idea 3
>> months from now we may select it for a code experiment (as opposed to
>> a though
At 10:34 AM 4/13/2006 -0500, Ian Bicking <[EMAIL PROTECTED]> wrote:
>And even if that wasn't a problem, it means mpz would be eagerly loaded
>along with NumPy even if it wasn't needed. Or if you had to manually
>import this operator.add-glue, then if you forget it is likely to be
>difficult to deb
Let me update my original thought experiment in a way that (I think)
preserves the current behaviour while also requiring strict dominance.
Let's imagine for a second that we have two new types at the top of the
hierarchy. I'll call them Ultimate and Penultimate. So the inheritance
tree goes l
[Guido]
>> ...
>> Definitely wild. Reader beware. Now is the time to generate lots of
>> wild ideas and let them sink in. If it still seems a good idea 3
>> months from now we may select it for a code experiment (as opposed to
>> a thought experiment). BTW I want to encourage lots of code
>> experi
Guido van Rossum wrote:
> Around the same time I also had this scary thought:
>
> What if, instead of adding registries mapping types to functions left
> and right (in pickle, copy, pprint, who knows where else), we had a
> convention of adding __foo_bar__ methods directly to the class dict?
> Thi
On 4/12/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/12/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> > What would happen if 'a+b' was just syntactic sugar for
> > 'operator.add(a,b)', where operator.add was a generic
> > function, instead of the current magic dance involvi
Michael Chermside wrote:
> But in a more realistic situation, the NumPy folks realize that
> many of their users are doing scientific work and a noticable
> number make use of mpz. (The mpz folks are just wrapping an
> external library so they don't think of these things, but that's
> OK since only
On 4/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Michael Chermside wrote:
> > my_x = my_mpz + my_array
> >
> > THIS then raises an exception because there is no one dominant
> > definition.
>
> Or, to make a long story short: there might not be a single next
> best candidate, but mul
Martin v. Löwis replies to my story:
> Or, to make a long story short: there might not be a single next
> best candidate, but multiple, which are mutually equally-good:
> both mpz+object and object+array would match, and neither is
> better than the other.
>
> This is because they only form a parti
> Guido writes:
>> the conventional way of treating __add__
>> etc. has a different need for resolving conflicts than Phillip Eby's
>> idea of requiring strict dominance of the selected solution over all
>> other candidates. So now that you mention it I wonder if the whole
>> strict dominance requi
Guido writes:
> the conventional way of treating __add__
> etc. has a different need for resolving conflicts than Phillip Eby's
> idea of requiring strict dominance of the selected solution over all
> other candidates. So now that you mention it I wonder if the whole
> strict dominance requirement
On 4/12/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> What would happen if 'a+b' was just syntactic sugar for
> 'operator.add(a,b)', where operator.add was a generic
> function, instead of the current magic dance involving
> __add__ and __radd__.
Funny, exactly the same thought
Here's a little thought experiment:
What would happen if 'a+b' was just syntactic sugar for
'operator.add(a,b)', where operator.add was a generic
function, instead of the current magic dance involving
__add__ and __radd__.
Neglecting the fact that it would break all Python co
This is just a little update on my rewrite of pprint. I've continued to
clean up and optimize this. If anyone wants to look at it, I've updated
the code here:
http://members.cox.net/~tim.hochberg/pprint2.py
[The changes are probably not signifigant enough to justify another
posting of t
Guido van Rossum wrote:
> On 4/9/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>
>>Rather than having you scroll all through this long message/file, I'll instead
>>place all the examples up here at the top. Assuming that you save this as
>>pprint2.py, you should be able to run the examples just by e
On 4/9/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Rather than having you scroll all through this long message/file, I'll instead
> place all the examples up here at the top. Assuming that you save this as
> pprint2.py, you should be able to run the examples just by executing the
> file.
Suggest
On 4/9/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>
> Let me add this cautionary note -- this primarily intended as for
> illustrative purposes. There's a good chance it has bugs. It does,
> however, pass
> test_pprint except for test_subclassing, which it can't really be
> expected to pass.
Py3k
"""This is my attempt to rewrite pprint.py to be based on protocols. Or
overloading or specialization or whatever they end up being called ;-). My
first attempt only touched about 20 lines of the original pprint and
probably
had 90% of the usability gain that this one does, but for some reason I
At 08:29 AM 4/8/2006 -0700, Guido van Rossum wrote:
>Of course, there are applications for more general predicates (like a
>dungeons&dragons game dispatcher) but to me they all seem a bit
>specialized to me.
Sure - but it would certainly be nice if RuleDispatch could tie into the
Python-supplied
At 08:01 AM 4/8/2006 -0700, Guido van Rossum wrote:
>Check out the accelerated version in time_overloading.py in the svn
>sandbox/overloading/. It's mostly faster than the manual version!
>
>Anyway, you seem to be confirming that it's the speed with which we
>can do a cache lookup. I'm not worried
At 07:58 AM 4/8/2006 -0700, Guido van Rossum wrote:
>On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > By the way, my rewrite of dominates() actually had a bug in it also, as did
> > your original. Yours used an 'is' to compare the tuple signatures where it
> > should've used ==, and mine c
On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Naturally, if your goals are more modest, dealing only with actual
> arguments, no expressions, no operators other than 'isinstance()', no
> ability to apply boolean logic to the conditions (e.g. "isinstance(arg1,A)
> and isinstance(arg1,B)", o
On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >Even with the cache I put in? The hairy algorithm doesn't get invoked
> >more than once per actual signature (type tuple).
>
> You've measured it now, but yes, my own measurements of similar techniques
> in RuleDispatch showed the same effect,
On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> By the way, my rewrite of dominates() actually had a bug in it also, as did
> your original. Yours used an 'is' to compare the tuple signatures where it
> should've used ==, and mine checked individual types with 'is' instead of
> comparing th
At 10:57 AM 4/7/2006 -0700, Guido van Rossum wrote:
>Here I'm not so sure. Are you sure those results are unexpected? It
>seems you are saying that if I have a class C deriving from A and B
>(in that order) where both A and B implement a method foo(), and C
>doesn't, the call C().foo() would be amb
On 4/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Even with the cache I put in? The hairy algorithm doesn't get invoked
> more than once per actual signature (type tuple).
OK, I timed this, and the @overloaded function (when it hits the
cache) is indeed 4-7 times slower than a handwritten d
On 4/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Guido wrote:
> > mros = tuple(t.__mro__ for t in types)
> > n = len(mros)
> > candidates = [sig for sig in self.registry
> > if len(sig) == n and
> > all(t in mro for t, mro
At 07:37 AM 4/7/2006, Jim Jewett wrote:
>On 4/7/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Guido wrote:
> > > mros = tuple(t.__mro__ for t in types)
> > > n = len(mros)
> > > candidates = [sig for sig in self.registry
> > > if len(sig) == n and
>
Guido wrote:
> mros = tuple(t.__mro__ for t in types)
> n = len(mros)
> candidates = [sig for sig in self.registry
> if len(sig) == n and
> all(t in mro for t, mro in zip(sig, mros))]
I believe this can be simplified to:
n
#!/usr/bin/env python2.5
# overloading.py
"""Here's another executable email.
This is an implementation of (dynamically, or run-time) overloaded
functions, formerly known as generic functions or multi-methods.
I actually blogged on Artima about multi-methods about a year ago; but
at the time I
Walter Dörwald wrote:
> Guido van Rossum wrote:
>
>
>>On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>
>>>The problem with this is that it looks in the base protocol only if the
>>>the class can't be found in the registry of the subprotocol. This mean
>>>that an adapter from the subprotoco
> What I'd like to see is how this changes if we use a generic functions
> (multiple dispatch) implementation instead of adaptation. Adaptation
> is pretty much isomorphic with a generic function of one argument (see
> my blog). But the register_for() method couldn't (shouldn't) interpret
> multipl
Guido van Rossum wrote:
> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> The problem with this is that it looks in the base protocol only if the
>> the class can't be found in the registry of the subprotocol. This mean
>> that an adapter from the subprotocol might be used, although the ba
Guido van Rossum wrote:
[TAHs simple pprint customization example snipped]
>>
>>Nice!
>>
>>I expect that with another dozen lines of code I could make custom
>>pretty printers possible, although the way the customization happens
>>might be a little kludgy. I'll look into it.
>
>
> Neat indeed.
On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> The problem with this is that it looks in the base protocol only if the
> the class can't be found in the registry of the subprotocol. This mean
> that an adapter from the subprotocol might be used, although the base
> protocol has a "better" a
On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> It seems like you can chain protocols like that simply by setting up an
> appropriate default_adapter method. For example, if we already had a
> pprinter protocol, we could define one that subclassed it and customized it:
>
> class CustomPPrintPr
Tim Hochberg wrote:
> Walter Dörwald wrote:
>
>> Guido van Rossum wrote:
>>
>>> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>>
Guido van Rossum wrote:
> On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>
>> I'm hoping that Walter can give some more realistic exam
Walter Dörwald wrote:
> Guido van Rossum wrote:
>
>> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>
>>> Guido van Rossum wrote:
>>>
On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> I'm hoping that Walter can give some more realistic examples since I
> don't have real
Guido wrote:
>Does anybody know if Phillip Eby's generic functions support this?
Yes, and yes, they do. :) At least, the multiple-dispatch ones
do. You can add a 'next_method' argument to the front of a method's
arguments, and it's automatically passed the next applicable
callable. (Which c
Guido van Rossum wrote:
> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>
>>> On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
I'm hoping that Walter can give some more realistic examples since I
don't have real-world experience here. The basic idea is
On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> >> I'm hoping that Walter can give some more realistic examples since I
> >> don't have real-world experience here. The basic idea is simply to let
> >> an adapt
Tim Hochberg wrote:
> Guido van Rossum wrote:
>
>> On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Walter Dörwald wrote:
>>>
>>>
What's still missing IMHO is a way for an adapter to defer to the next
adapter in the chain, i.e. something like:
>> [...]
>
Guido van Rossum wrote:
> On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>> I'm hoping that Walter can give some more realistic examples since I
>> don't have real-world experience here. The basic idea is simply to let
>> an adapter give up and let the protocol try the next adapter. This could
> Walter Dörwald wrote:
> > What's still missing IMHO is a way for an adapter
> > to defer to the next adapter in the chain
Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Why not simply raise a DeferToNextAdapter exception?
It sounds good at first, but it may be overengineered.
If that means "NotImpl
On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> I'm hoping that Walter can give some more realistic examples since I
> don't have real-world experience here. The basic idea is simply to let
> an adapter give up and let the protocol try the next adapter. This could
> happen in a generic functio
Guido van Rossum wrote:
>On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>
>
>>Walter Dörwald wrote:
>>
>>
>>>What's still missing IMHO is a way for an adapter to defer to the next
>>>adapter in the chain, i.e. something like:
>>>
>>>
>[...]
>
>
>>The concept seems good, but I fin
Walter Dörwald wrote:
> Guido van Rossum wrote:
>
>
>>Fascinating ideas in this thread!
>>
>>I spent some time blogging about this on artima:
>>http://www.artima.com/weblogs/viewpost.jsp?thread=155123
>>
>>I have to write my slides for a talk about Py3K later today, but I'll
>>be back. In the mea
On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Walter Dörwald wrote:
> > What's still missing IMHO is a way for an adapter to defer to the next
> > adapter in the chain, i.e. something like:
[...]
> The concept seems good, but I find the implementation baffling, OK, I
> finally figured it out
Walter Dörwald wrote:
> Guido van Rossum wrote:
>
>> Fascinating ideas in this thread!
>>
>> I spent some time blogging about this on artima:
>> http://www.artima.com/weblogs/viewpost.jsp?thread=155123
>>
>> I have to write my slides for a talk about Py3K later today, but I'll
>> be back. In the m
Guido van Rossum wrote:
> Fascinating ideas in this thread!
>
> I spent some time blogging about this on artima:
> http://www.artima.com/weblogs/viewpost.jsp?thread=155123
>
> I have to write my slides for a talk about Py3K later today, but I'll
> be back. In the mean time I've rejected PEPs 245
Fascinating ideas in this thread!
I spent some time blogging about this on artima:
http://www.artima.com/weblogs/viewpost.jsp?thread=155123
I have to write my slides for a talk about Py3K later today, but I'll
be back. In the mean time I've rejected PEPs 245 and 246 in
expectation of something be
Nick Coghlan wrote:
> Tim Hochberg wrote:
>
>>I like this version. The naming seems an improvement and the
>>default_adapter seems like a worthy addition. I do keep wondering if
>>there's some reason for a user of Protocol to call candidate_keys
>>directly or it's only an implementation detail.
Nick Coghlan wrote:
> [...]
> def default_adapter(self, *args):
> """Call result when no adapter was found"""
> raise TypeError("Can't adapt %s to %s" %
> (args[0].__class__.__name__, self.name))
+1 This makes it easy to add fallbacks:
class XReprP
Tim Hochberg wrote:
> I like this version. The naming seems an improvement and the
> default_adapter seems like a worthy addition. I do keep wondering if
> there's some reason for a user of Protocol to call candidate_keys
> directly or it's only an implementation detail. If the there is such a
Nick Coghlan wrote:
> Tim Hochberg wrote:
>
>>So after all of that, I think my conclusion is that I wouldn't refactor
>>this at all, at least not yet. I'd add support for multiple registration
>>and possibly spell adapt as __call__, otherwise I'd leave it alone. My
>>opinion may change after I
Tim Hochberg wrote:
> So after all of that, I think my conclusion is that I wouldn't refactor
> this at all, at least not yet. I'd add support for multiple registration
> and possibly spell adapt as __call__, otherwise I'd leave it alone. My
> opinion may change after I try ripping out keysof an
Guido van Rossum wrote:
> One followup. Alex mentioned that PyPy used to have its own
> implementation of multiple dispatch (which is really the same as
> generic functions) but ditched over a year ago. Would Armin or Samuele
> care to explain why? Do they no longer like multiple dispatch or was
>
Guido van Rossum wrote:
> #!/usr/bin/python2.4
>
> """An example of generic functions vs. adaptation.
>
> After some face-to-face discussions with Alex I'm presenting here two
> extremely simplified implementations of second-generation adaptation
> and generic functions, in order to contrast and
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> #!/usr/bin/python2.4
>
> """An example of generic functions vs. adaptation.
Nice.
For me, the idea of 'generic function' goes into my brain much more
smoothly than the idea of 'protocol adaptation' even though the
On 4/4/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Apr 4, 2006, at 5:29 PM, Guido van Rossum wrote:
> [excellent example, mostly snipped]
>
> Just for when this will be published/blogged (as it deserves to be!),
> tiny nit:
>
> > if hasattr(obj, "__iter__"):
> > return obj._
Alex Martelli wrote:
> On Apr 4, 2006, at 5:29 PM, Guido van Rossum wrote:
> [excellent example, mostly snipped]
>
> Just for when this will be published/blogged (as it deserves to be!),
> tiny nit:
>
>> if hasattr(obj, "__iter__"):
>> return obj.__iter__()
>> raise TypeErro
On Apr 4, 2006, at 5:29 PM, Guido van Rossum wrote:
[excellent example, mostly snipped]
Just for when this will be published/blogged (as it deserves to be!),
tiny nit:
> if hasattr(obj, "__iter__"):
> return obj.__iter__()
> raise TypeError("Can't iterate over a %s object"
One followup. Alex mentioned that PyPy used to have its own
implementation of multiple dispatch (which is really the same as
generic functions) but ditched over a year ago. Would Armin or Samuele
care to explain why? Do they no longer like multiple dispatch or was
the reason for the extraction spec
#!/usr/bin/python2.4
"""An example of generic functions vs. adaptation.
After some face-to-face discussions with Alex I'm presenting here two
extremely simplified implementations of second-generation adaptation
and generic functions, in order to contrast and compare.
As the running example, we u
65 matches
Mail list logo
