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

[SourceForge.net]

Patches item #941881, was opened at 2004-04-26 04:05
Message generated for change (Comment added) made by ncoghlan
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: Nick Coghlan (ncoghlan)
Date: 2004-08-11 10: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-04 06: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-18 14: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 18: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-27 12: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-27 05: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