general question about PEP reasoning

Carlos Ribeiro cribeiro at mail.inet.com.br
Mon Feb 10 21:24:16 EST 2003


On Tuesday 11 February 2003 01:09, jerf at compy.attbi.com wrote:
> On Mon, 10 Feb 2003 21:42:57 +0000, Peter Harris wrote:
> > class closure(object):
> >      __slots__=('fn','args','kw')
> >      def __init__(self, fn, *args, **kw):
> >          self.fn, self.args, self.kw = (fn, args, kw)
> >
> >      def __call__(self, *args, **kw):
> >          d = self.kw.copy()
> >          d.update(kw)
> >          return self.fn(*(self.args + args), **d)
>
> A general question, and I mean no disrespect by it. Why propose a PEP that
> can be implemented today in 9 lines of Python? I've got two or three
> versions of this idea floating around in my code base already, thanks to
> the find curry writeup in the ASPN Cookbook. (In one hairy case I wanted
> to be able to curry on either the first or second argument independently.)

I'm not the PEP proponent, but I see two reasons:

1) As noted elsewhere (in a message regarding booleans), consistence is good. 
Having this class in the standard library buys it for you.

2) He's playing by the rules of the game. If you want something to be included 
in the standard library, then you have to write a PEP.

There is also a slight performance advantage in that he proposes to implement 
an optimized C version of the code shown above. It's overall a good proposal, 
but as Alex noted, the syntax change is not only not necessary, it's also 
distracting and will make this PEP an easy target.


-- 
Carlos Ribeiro
cribeiro at mail.inet.com.br





More information about the Python-list mailing list