[Patches] [ python-Patches-941881 ] PEP309 Partial implementation

[SourceForge.net]

Patches item #941881, was opened at 2004-04-25 12:05
Message generated for change (Comment added) made by bediviere
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470

Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Hye-Shik Chang (perky)
Assigned to: Nobody/Anonymous (nobody)
Summary: PEP309 Partial implementation

Initial Comment:
This patch implements functional module which is
introduced by PEP309. It has only 'partial' function as
its member in this stage.

Unittest code is copied and modified slightly from
Patch #931010 by Peter Harris.

----------------------------------------------------------------------

Comment By: Steven Bethard (bediviere)
Date: 2005-02-19 13:38

Message:
Logged In: YES 
user_id=945502

It might be nice if partial objects were usable as
instancemethods, like functions are.  Note the following
behavior with the current patch:

>>> import functional
>>> class C(object):
...     pass
...
>>> def func(self, arg):
...     return arg
...
>>> for item in ['a', 'b', 'c']:
...     setattr(C, item, functional.partial(func, item))
...
>>> C().a()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: func() takes exactly 2 arguments (1 given)

If functional.partial was instead defined like:

class partial(object):
    def __init__(*args, **kwargs):
        self = args[0]
        try:
            self.func = args[1]
        except IndexError:
            raise TypeError('expected 2 or more arguments,
got ' %
                            len(args))
        self.obj = ()
        self.args = args[2:]
        self.kwargs = kwargs
    def __call__(self, *args, **kwargs):
        if kwargs and self.kwargs:
            d = self.kwargs.copy()
            d.update(kwargs)
        else:
            d = kwargs or self.kwargs
        return self.func(*(self.obj + self.args + args), **d)
    def __get__(self, obj, type=None):
        if obj is None:
            return self
        result = partial(self.func, *self.args, **self.kwargs)
        result.obj = (obj,)
        return result

where an appropriate __get__ method is provided, then
partial objects behave properly when set as attributes to a
class:

py> def test():
...     class C(object):
...         pass
...     def func(self, arg):
...         return arg
...     for item in ['a', 'b', 'c']:
...         setattr(C, item, functional.partial(func, item))
...     c = C()
...     return c.a(), c.b(), c.c()
... 
py> test()
('a', 'b', 'c')

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-08-10 18:11

Message:
Logged In: YES 
user_id=1038590

I have tested this patch on Windows, and it passes its own
test suite, without affecting any other tests.

However, PCBuild\pythoncore.vcproj & PC\config.c require
modification to allow Python to pick up the new module
correctly.

Patch #1006948 created with the needed changes (also removes
unneeded ODBC references from pythoncore.vcproj as I am
using the free MS toolkits to build here)

My patch definitely needs to be checked by someone with a
copy of Vis Studio 2003!

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-08-03 14:23

Message:
Logged In: YES 
user_id=113328

OK, a real need beats my theoretical worries :-) Consider me
convinced.

----------------------------------------------------------------------

Comment By: Bob Ippolito (etrepum)
Date: 2004-05-17 22:05

Message:
Logged In: YES 
user_id=139309

I would use partial in situations where speed can matter (imap, 
commonly used event handlers, etc.), so a fast C implementation would 
be nice to have.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-04-27 02:03

Message:
Logged In: YES 
user_id=113328

Yes, that looks like a significant speed improvement :-) I was 
basing my assumptions on the comments made in the PEP. 
Sorry.

But I still wonder if having the implementation in Python 
wouldn't be better from a maintenance point of view. (As well 
as all the arguments about usefulness as sample code, ability 
to backport, etc etc, that have come up on python-dev 
regarding moving other Python library modules into C...).

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-04-26 20:05

Message:
Logged In: YES 
user_id=55188

Python-version (function) ...   1.19    2.69
Python-version (class) ...      2.61    2.38
C-version ...   0.50    0.37
(former value is for 100000 instanciations and latter is for
100000 calls.)

And, C version have a facility that changing attributes after
the instantiation that is supported by class version only.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-04-26 13:30

Message:
Logged In: YES 
user_id=113328

Why implement this in C? I can't imagine that the
performance improvement will be that significant. A pure
Python module in the standard library seems to me to be a
far better idea. As the PEP says, "the case for a built-in
coded in C is not very strong". And a Python module is good
self-documentation.

I prefer the function version suggested in the PEP (credited
to Carl Banks) over the class-based one. You need to take a
little care to avoid capturing argument names:

    def partial(*args, **kwds):
        def callit(*moreargs, **morekwds):
            kw = kwds.copy()
            kw.update(morekwds)
            return args[0](*(args[1:]+moreargs), **kw)
        return callit

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=941881&group_id=5470