[Python-Dev] PEP 362 Third Revision (original) (raw)

Alexandre Zani alexandre.zani at gmail.com
Thu Jun 14 16:50:42 CEST 2012

On Thu, Jun 14, 2012 at 6:50 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:

On 2012-06-14, at 8:06 AM, Victor Stinner wrote:

Sorry if I'm asking dummy questions, I didn't follow the discussion.

* format(...) -> str  Formats the Signature object to a string.  Optional arguments allow  for custom render functions for parameter names,  annotations and default values, along with custom separators. Hum, what are these "custom render functions"? Can you give an example? That's how the function looks right now (I'm not sure we should load the PEP with this):  def format(self, *, formatname=str,  formatdefault=repr,  formatannotation=formatannotation,  formatargs=(lambda param: '*' + str(param)),  formatkwargs=(lambda param: '**' + str(param)),  tokenparamsseparator=', ',  tokenkwonlyseparator='*',  tokenleftparen='(',  tokenrightparen=')',  tokencolon=':',  tokeneq='=',  tokenreturnannotation=' -> '):  '''Format signature to a string.  Arguments (all optional):  * formatname : A function to format names of parameters.  Parameter  won't be rendered if None is returned.  * formatdefault : A function to format default values of parameters.  Default value won't be rendered if None is returned.  * formatannotation : A function to format parameter annotations.  Annotation won't be rendered if None is returned.  * formatargs : A function to render *args like parameters.  Parameter won't be rendered if None is returned.  * formatkwargs : A function to render **kwargs like parameters.  Parameter won't be rendered if None is returned.  * tokenparamsseparator : A separator for parameters.  Set to  ', ' by default.  * tokenkwonlyseparator : A separator for arguments and  keyword-only arguments.  Defaults to '*'.  * tokenleftparen : Left signature parenthesis, defaults to '('.  * tokenrightparen : Left signature parenthesis, defaults to ')'.  * tokencolon : Separates parameter from its annotation,  defaults to ':'.  * tokeneq : Separates parameter from its default value, set to  '=' by default.  * tokenreturnannotation : Function return annotation, defaults  to ' -> '.  ''' I've designed it in such a way, that everything is configurable, so you can render functions to color-term, HTML, or whatever else. * iskeywordonly : bool  True if the parameter is keyword-only, else False. * isargs : bool  True if the parameter accepts variable number of arguments  (*args-like), else False. * iskwargs : bool  True if the parameter accepts variable number of keyword  arguments (**kwargs-like), else False. Hum, why not using a attribute with a string value instead of 3 attribute? For example: * argtype: "index", "varargs", "keyword" or "keywordonly" It would avoid a possible inconsitency (ex: isargs=True and iskwargs=True). And it would help to implement something like a C switch/case using a dict: argtype => function for functions using signatures. Originally, I thought the the line: if parameters.isargs is better looking that: if parameters.kind == 'vararg' But, I like your arguments regarding inconsistency and dispatch through a dict (someone may find it useful).  Also, Larry gave another one - who knows if we add another type of arguments in the future. I guess if nobody really wants to keep 'isargs', we can alter the PEP. Let's consider replacement of 'Parameter.is*' set of attributes with a single 'Parameter.kind' attribute, which will have the following possible values: 'positional', 'vararg', 'keyword-only', 'varkwarg'. (I think 'positional' is more intuitive than 'index'?)

I disagree largely for readability reasons. As the PEP stands, I can look at a Parameter object and immediately understand what the different possible values are by just listing its attributes. The kind attribute makes that harder.

Comparing with strings is error prone. If I do param.is_varargs (adding an s at the end of the attribute name) I will see an attribute error and know what is going on. If I do the same mistake with the kind attribute param.kind == "varargs", the expression will just always be False without any explanation.

* isimplemented : bool  True if the parameter is implemented for use.  Some platforms  implement functions but can't support specific parameters  (e.g. "mode" for os.mkdir).  Passing in an unimplemented  parameter may result in the parameter being ignored,  or in NotImplementedError being raised.  It is intended that  all conditions where isimplemented may be False be  thoroughly documented.

I suppose that the value depends on the running platform? (For example, you may get a different value on Linux and Windows.) Correct. Implementation ==============

 - If the object has a _signature_ attribute and if it  is not None - return a deepcopy of it Oh, why copying the object? It may impact performances. If fhe caller knows that it will modify the signature, it can deepcopy the signature. There was a discussion on this topic earlier on python-dev. In short - as we usually create new signatures with each 'signature()' call, users will expect that they can modify those freely.  But if we have one defined in signature, without copying it, all its modifications will be persistent across 'signature()' calls.  So the deepcopy here is required more for the consistency reasons.  Besides, I don't think that 'signature()' will be used extensively in performance-critical types of code.  And even if it is - you can just cache it manually.  - If it is None and the object is an instance of  BuiltinFunction, raise a ValueError What about builtin functions (ex: len)? Do you plan to add a signature attribute? If yes, something created on demand or created at startup? Larry is going to add signatures to some 'os' module functions. But that would it for 3.3, I guess. It would be nice to have a C API to create Signature objects, maybe from the same format string than PyArgParse*() functions. But it can be implemented later. Then parameters will lack the 'name' attribute.  I think we need another approach here. Is it possible to build a Signature object from a string describing the prototype (ex: "def f(x, y): pass")? (I mean: do you plan to add such function?) There are no plans to add it now (no good reasons to include such functionality in 3.3 at least) Thank you, - Yury

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/alexandre.zani%40gmail.com

More information about the Python-Dev mailing list