My reading of the PEP did not include making the structure members public. This complicates and slows the implementation. The notion of introducing mutable state to the PFA is at odds with the driving forces behind functional programming (i.e. statelessness).
Notice that the C code is (or atleast is meant as) a faithful implementation of the "Example Implementation" in the PEP, including the literal spelling of the class attributes. Now, it is not clear what is meant as normative in the PEP; I would agree that these member names are not meant to be exposed.
If necessary for introspection, the structure members can be made read-only.
This issue is not discussed in the PEP. If exposed, I think I would prefer different names. Starting all names with p_, might be appropriate, and I would rename "fn" to "func" (following method objects). Not sure what names would be appropriate for arguments and keywords.
Notice that the proposed documentation says this:
"""Partial objects are callable objects that are created, and mostly
behave, like the functions created by \function{partial}. The main
difference is that because they are Python objects, they have attributes
that can be inspected or modified."""So it was atleast the intention of the PEP author that partial functions are mutable.
Also, there may be room to improve the implementation by building on the passed-in dictionary rather than creating a copy of the one in the partial object.
Couldn't this cause the modifications be passed to the caller? This would not be acceptable, but I could not figure out whether CALL_FUNCTION* will always create a new kwdict, or whether it might pass through a dict from the original caller.
The current choice may be the correct one because it has the outer call override the defaults in the event of a keyword conflict -- if so, that should be documented.
Notice that the "Example Implementation" specifies this:
if kw and self.kw:
d = self.kw.copy()
d.update(kw)
else:
d = kw or self.kwIn any case - the fine points of the semantics primarily need to go into the documentation, which currently says
"""and keyword arguments override those provided when the new function was created."""
Overall, I have no major objections to the PEP or the patch. Before it goes in on auto-pilot, it would be darned nice if the proponents said that they've found it helpful in real code and that they are satisfied with the timings.
I guess "darned nice" is the best you can hope for. Not sure if Peter Harris is still around.
Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
