> > Along the way, they should assess whether
> > it is as applicable as expected, whether the existing limitations
are
> > problematic, and whether performance is an issue.
>
> Ah, so you question the specification, not the implementation of it.
My only issue with the PEP is that it seemed much more promising when
reading it than when looking for real code that could benefit from it. I
liked it much better until I tried to use it. My hope is that the
advocates will try it for themselves before pushing this one in on
faith.
> I do believe that there is no better
> way to implement the PEP. The PEP very explicitly defines what
precisely
> functional.partial is, and the implementation follows that
specification
> very closely.
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).
If necessary for introspection, the structure members can be made
read-only.
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. 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.
The test for callability is redundant and can be removed.
The traverse() function can be simplified with the PyVISIT macro.
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.
partial(str.__add__, 'Ray')('mond')
_______________________________________________
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
