On Fri, Jun 15, 2012 at 8:51 PM, Larry Hastings <la...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
