[Python-Dev] PEP 309

["Martin v. Löwis"]

Raymond Hettinger wrote:
> 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.kw

In 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