On Tue, Jun 19, 2012 at 7:06 AM, Jim Jewett <[email protected]> wrote:
> Correct; it should be redundant. Signature.kwargsparameter should be
> the same object that occurs as the nth element of
> Signature.parameters.values(). It is just more convenient to retrieve
> the parameter directly than it is to iterate through a collection
> inspecting each element for the value of a specific attribute.
I suspect in 3.4 we will add the following additional convenience properties:
Signature.positional -> list[Parameter]
List of POSITIONAL_ONLY and KEYWORD_OR_POSITIONAL parameters
Signature.var_positional -> None or Parameter
Reference to the VAR_POSITIONAL parameter, if any
Signature.keyword -> dict{name:Parameter}
Mapping of all KEYWORD_ONLY and KEYWORD_OR_POSITIONAL parameters
Signature.var_keyword -> None or Parameter
Reference to the VAR_KEYWORD parameter, if any
However, I don't think we should add such convenience properties
*right now*. One step at a time.
> __eq__ can can an _eq_fields attribute to see which other attributes
> matter -- but it makes more sense for that to be (sub-) class
> property.
Only if you accept the premise that there are other possible parameter
binding behaviours beyond the five already defined.
Hypergeneralisation is a great way to make an API far more complex
than it needs to be.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
