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 wrote:
> On 4/4/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > I was going to comment about this one "check it in, we'll add to it
>> > later", but then I realized it's not 100% clear whether this is a
>> > feature PEP or a meta-PEP? It focuses on featu
Guido van Rossum wrote:
> On 4/4/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> [...]
>> def __init__(self, name, doc=''):
>> self.name = name
>> self.registry = {}
>> self.__doc__ = doc
>> self.all_protocols.add(self)
>> def __repr__(self):
>> retur
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
>
Walter Dörwald wrote:
> But if adapting is done via __call__() we have a problem: Sequence
> already provides a __call__, the constructor. Of course if this worked
>
> print Sequence([1,2,3]).len()
>
> would look much better than
>
> print Sequence.adapt([1,2,3]).len()
>
> but I'm not sure if
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
Nick Coghlan wrote:
> [...]
> So your example would become:
>
> class MetaInterface(type):
> def __new__(mcl, name, bases, dict):
> # Give each class it's own registry
> cls = type.__new__(mcl, name, bases, dict)
> cls.registry = {}
> return cls
>
>
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:
> 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:
> [...]
> 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
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.
[Greg Ewing]
> I'm more interested in long-term readability
> and maintainability than in pandering to one-off
> impressions when coming from another language.
[Ian Bicking]
> $-based substitution is very common. Like most languages, Python uses
> () for calling functions, it uses keywords like "
On Wed, 5 Apr 2006, Greg Ewing wrote:
[...]
> There are other problems with the $ syntax too.
> The lack of an explicit closing marker causes
> problems when the parameter is immediately
> followed in the string by an alphanumeric
> character. You end up having to allow some
> kind of bracketing as
On Tue, 4 Apr 2006, Barry Warsaw wrote:
[...]
> Yes, I think this is where we differ. $thing in it's most common
> form is more readable to me than {thing}, and while the former is
> equivalent to ${thing} with string.Template's defaults, I find it's
> very rarely used.
Regardless of readability,
Greg Ewing canterbury.ac.nz> writes:
> I'm also not all that keen on $, either inside
> or outside the string. It seems to me that
> something like
>
>"User {user} has printed {n} pages"
FWIW, this is very similar to the syntax used in the .Net function String.Format
(I think Java uses a si
Ian Bicking wrote:
> Alex Martelli wrote:
>
>>As for the % operator, I never liked it -- either a builtin function,
>>or even better a method of string objects, is going to be much more
>>readable (and my preference would be to have it take optional
>>positional arguments, corresponding to {
Tim Hochberg wrote:
> Ian Bicking wrote:
>> Alex Martelli wrote:
>>> As for the % operator, I never liked it -- either a builtin
>>> function, or even better a method of string objects, is going to be
>>> much more readable (and my preference would be to have it take
>>> optional positional a
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
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
Guido van Rossum wrote:
> Fascinating ideas in this thread!
It's certainly been interesting to see convergence coming from both
directions independently.
> I spent some time blogging about this on artima:
> http://www.artima.com/weblogs/viewpost.jsp?thread=155123
>
> I have to write my slides f
On 4/5/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > 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 better that's imminent!
>
> Is PEP 245 ("Python Interfac
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
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 mea
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
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
> 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
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
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:
>> [...]
>
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
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/4/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > As for the % operator, I never liked it -- either a builtin function,
> > or even better a method of string objects, is going to be much more
> > readable (and my preference would be to have it take optional
> > positional
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
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
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
Alex Martelli wrote:
>
> and my preference would be to have it take optional
> positional arguments, corresponding to {1}, {2}, etc, and optional
> named arguments, corresponding to {name} &c).
Yes, certainly.
--
Greg
___
Python-3000 mailing list
P
Ian Bicking wrote:
> Note that if it takes keyword arguments, but doesn't take a single
> dictionary-like object (like % and string.Template.substitute do), then
> you lose any ability to use clever or interesting dictionary-like
> objects for substitution.
If you subclass your clever object f
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
Ian Bicking wrote:
> Clever and interesting would include my quoting, evaluating, and
> formatting wrappers. It might also include special gettext expressions,
> case insensitivity, or other interesting wrappers.
Hmmm, *that* degree of cleverness would be better
served by a different interface
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
Ian Bicking wrote:
> ** can't be changed
> in this way, either -- it really has to enumerate all the keys in the
> thing passed to it,
In Py3k this could perhaps be different in the case where
you're calling a function defined like
def f(*args, **kwds):
...
In that case there are no n
Greg Ewing wrote:
> Ian Bicking wrote:
>
>> Clever and interesting would include my quoting, evaluating, and
>> formatting wrappers. It might also include special gettext
>> expressions, case insensitivity, or other interesting wrappers.
>
> Hmmm, *that* degree of cleverness would be better
>
Greg Ewing wrote:
> Ian Bicking wrote:
>
>> ** can't be changed in this way, either -- it really has to enumerate
>> all the keys in the thing passed to it,
>
> In Py3k this could perhaps be different in the case where
> you're calling a function defined like
>
> def f(*args, **kwds):
> .
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.
Ian Bicking wrote:
> Why? The wrappers looked pretty darn simple to me. I suppose they'd be
> slightly simpler if you replaced __getitem__ with __call__.
What I meant was that another method or function
could be provided that takes a mapping object as
a direct argument, rather than trying to s
On 4/5/06, John J Lee <[EMAIL PROTECTED]> wrote:
But how about putting them at the start, after the $? That way, theformat character can't get mixed up with the text following it. Forexample, $r{foo} would mean the same as the current %(foo)r.
This is somewhat tangental, but hopefully an $r forma
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
47 matches
Mail list logo
