On 06/15/2012 12:18 AM, Nick Coghlan wrote:
Perhaps you meant "ill-concieved"?
No, I mean ill-defined. The criteria for when a particular platform
should flip that bit for an arbitrary parameter is highly unclear, as
whether or not a particular parameter is "implemented" or not depends
on the operation and the parameter.
I guess I really did do a poor job of explaining it then. Here's
another pass.
My working definition for "is_implemented" is "is this functionality
available at all?" Pressed to produce a stricter definition, I *would*
define "is_implemented" as:
True if it is possible to produce any valid inputs for the parameter
on the current platform, and False otherwise.
However, I don't think parameters should be added and removed from a
function's signature based on what functionality is available on the
local platform--that way lies madness. Instead I think it best to
define a no-op default value for every optional parameter, and always
accept that even when the functionality behind it isn't locally
available. Function signatures should be stable. Therefore I amend
the definition to:
True if it is possible to produce any valid non-default inputs for
the parameter on the current platform, and False otherwise.
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.
//arry/
_______________________________________________
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
