[Python-Dev] PEP 362 Third Revision

[Nick Coghlan]

On Fri, Jun 15, 2012 at 8:51 PM, Larry Hastings <larry at hastings.org> wrote:
> If I understand you correctly, you seem to be trying to apply
> "is_implemented" to the problem of predicting which specific inputs to a
> parameter would be valid.  I don't think that problem is tractable--it's way
> too context-specific.

Correct, but the more important point is that I don't think the
question you're proposing to ask is worth answering. I *don't care* if
there is some value that's supported on the current platform, I only
care if the value *I am about to pass* is supported.

Since I don't believe your proposed flag will answer any question that
actually matters in practice, I consider it useless noise that should
be dropped from the proposal. To go back to my simple buffering
parameter example:

1. A hypothetical platform supports line buffered and fixed chunk
buffered IO. Therefore, it sets the "is_implemented" flag for
"buffering" to True (under your proposed definition)
2. My LBYL program checks the flag, sees that it is implemented and
passes "buffering=0"
3. My program fails with NotImplementedError or
UnsupportedOperationError, since my LBYL check wasn't strict enough

A simple "is this parameter implemented?" does not provide enough
useful information to be justify being part of the standard signature
objects.

Now, what a function *could* do is set __signature__ to a Signature
subclass that provided an additional "validate()" method, or provided
arbitrary additional information about supported features. That's a
perfectly reasonable option.

But what we definitely *shouldn't* be doing is supporting a niche use
case directly on Parameter objects without allowing adequate time to
explore alternative solutions that may be better in the long run.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia