Raymond Hettinger wrote:
I would like for the principal advocates to reach a consensus that the
proposed implementation is a winner.
That I cannot understand. Do you want the advocates to verify that the
implementation conforms to the specification? or that the implementation
of the PEP is faster than any other existing implementation of the PEP?
These two hold, I believe.
Ideally, that decision should be
informed by trying it out on their own, real code and seeing whether it
offers genuine improvements.
Performance-wise, or usability-wise? Because usability-wise, all
implementations of the PEP are identical, so all implementations
of the PEP should offer the precisely same improvements.
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 concern is that with Guido having approved the idea in abstract form,
the actual implementation has escaped scrutiny. Also, if the API is
different from the PEP, acceptance should not be automatic.
AFAICT, the proposed patch implements the behaviour of the PEP exactly.
If functional.partial() isn't a clear winner, it may be a reasonable to
ask that it be released in the wild and evolve before being solidified
in the standard library. My sense is that that the current
implementation is far from its highest state of evolution.
Again, this I cannot understand. 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.
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
