[Python-checkins] python/nondist/peps pep-0309.txt,1.3,1.4

[goodger at users.sourceforge.net]

Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22504

Modified Files:
	pep-0309.txt 
Log Message:
update from Peter Harris

Index: pep-0309.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0309.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** pep-0309.txt	11 Mar 2003 04:49:44 -0000	1.3
--- pep-0309.txt	21 Feb 2004 16:32:30 -0000	1.4
***************
*** 1,4 ****
  PEP: 309
! Title: Built-in Curry Type
  Version: $Revision$
  Last-Modified: $Date$
--- 1,4 ----
  PEP: 309
! Title: Function Currying
  Version: $Revision$
  Last-Modified: $Date$
***************
*** 15,25 ****
  ========
  
! This proposal is for a standard curry type for Python that
  allows a new callable to be constructed from a callable and a
  partial argument list (including positional and keyword arguments).
  
  Note: after feedback on comp.lang.python, I am persuaded that the most
! accurate term for this is a 'curry' rather than a 'closure', so the
! terminology has been amended since the first version of this PEP.
  
  I propose a standard library module called "functional", to hold useful
--- 15,25 ----
  ========
  
! This proposal is for a curry constructor for Python that
  allows a new callable to be constructed from a callable and a
  partial argument list (including positional and keyword arguments).
  
  Note: after feedback on comp.lang.python, I am persuaded that the most
! accurate term for this is a 'curry', so the terminology has been
! amended since the first version of this PEP.
  
  I propose a standard library module called "functional", to hold useful
***************
*** 41,49 ****
  thing when presented with a functor and less arguments than expected.
  
! Python has more flexible argument-passing, and so curries cannot be
! implicit in the same way.  Instead of using them, a Python programmer
  will probably either define another named function or use a lambda.
! But lambda syntax is horrible, especially when you want to do
! something complex.
  
  We need something better.
--- 41,48 ----
  thing when presented with a functor and less arguments than expected.
  
! Python has more flexible argument-passing, and so function currying cannot
! be implicit in the same way.  Instead, a Python programmer
  will probably either define another named function or use a lambda.
! But lambda syntax is not to everyone's taste, to say the least.
  
  We need something better.
***************
*** 53,72 ****
  =========
  
! Here is one way to do a curry in Python::
  
      class curry(object):
  
!         def __init__(self, fn, *args, **kw):
!             self.fn, self.args, self.kw = (fn, args, kw)
  
          def __call__(self, *args, **kw):
!             if self.kw:
                  d = self.kw.copy()
                  d.update(kw)
              else:
!                 d = kw
              return self.fn(*(self.args + args), **d)
  
! Note that when the curry is called, positional arguments are
  appended to those provided to the constructor, and keyword arguments
  override and augment those provided to the constructor.
--- 52,74 ----
  =========
  
! Here is one way to do a create a curried callable in Python. The
! implementation below is based on improvements provided by Scott David
! Daniels::
  
      class curry(object):
  
!         def __init__(*args, **kw):
!             self = args[0]
!             self.fn, self.args, self.kw = (args[1], args[2:], kw)
  
          def __call__(self, *args, **kw):
!             if kw and self.kw:
                  d = self.kw.copy()
                  d.update(kw)
              else:
!                 d = kw or self.kw
              return self.fn(*(self.args + args), **d)
  
! Note that when the curried function is called, positional arguments are
  appended to those provided to the constructor, and keyword arguments
  override and augment those provided to the constructor.
***************
*** 76,81 ****
  Label class, but with a blue foreground by default.
  
! I think a built-in type called ``curry``, that behaves the same way
! but maybe implemented more efficiently, would be very useful.
  
  Update: a recipe almost exactly like this has been in the Python
--- 78,83 ----
  Label class, but with a blue foreground by default.
  
! I think a built-in class called ``curry`` that behaves the same way
! would be very useful.
  
  Update: a recipe almost exactly like this has been in the Python
***************
*** 123,127 ****
      nextarg = sys.argv.pop@(0)
  
! It has not been well-received, so I am not pursuing this as a serious
  proposal.
  
--- 125,129 ----
      nextarg = sys.argv.pop@(0)
  
! It has not been well-received, so I withdraw this part of the
  proposal.
  
***************
*** 202,208 ****
  The performance gain in Pyrex is less than 100% over the nested function
  implementation, since to be fully general it has to operate by Python API
! calls.  Any C implementation will be unlikely to be much faster, so the
! case for a builtin coded in C is not very strong.
! 
  
  
--- 204,209 ----
  The performance gain in Pyrex is less than 100% over the nested function
  implementation, since to be fully general it has to operate by Python API
! calls.  For the same reason, a C implementation will be unlikely to be much
! faster, so the case for a built-in coded in C is not very strong.
  
  
***************
*** 210,226 ****
  =======
  
! I prefer that curry should be a built-in, with the semantics as
! described, whether as a function or a class. However, it should do its
! apprenticeship in the standard library first.
  
  The standard library module ``functional`` should contain ``curry`` and
  ``rightcurry`` classes, and any other higher-order functions the community
! want. These other functions fall outside this PEP though.
  
  The @ syntax proposal is withdrawn.
  
- Since this proposal is now much less ambitious, I'd like to aim for
- inclusion in Python 2.3.
- 
  
  Copyright
--- 211,224 ----
  =======
  
! I prefer that some means to curry functions should be a built-in, with the
! semantics as described, whether as a function or a callable class. However,
! it should do its apprenticeship in the standard library first.
  
  The standard library module ``functional`` should contain ``curry`` and
  ``rightcurry`` classes, and any other higher-order functions the community
! want. Other functions that might belong there fall outside this PEP though.
  
  The @ syntax proposal is withdrawn.
  
  
  Copyright