Ezio Melotti added the comment: > Do we like how these look? Is the bare star notation too obscure? > > inspect.Signature.replace(*[, parameters][, return_annotation]) > inspect.Parameter.replace(*[, name][, kind][, default][, annotation])
Note that if possible, it's better to avoid using the [] and put the default values. However, in these cases the default value seems to be a _void placeholder. The star notation is OK, since it's valid Python. > I was curious what the preferred way to display the following is, > since I don't think any comma/bracket placement will work: > > ArgumentParser([description][, epilog][, prog][, usage][, add_help][, > argument_default][, parents][, prefix_chars][, conflict_handler][, > formatter_class]) If the default values are known you could use them, otherwise this signature looks OK to me. > (unless perhaps we use the construction "ArgumentParser(*[, > description][, epilog]....") This is OK too, as long as all the arguments (including 'description') are keyword-only. > I'm not sure how we want to handle this one using multiple signatures: > > multiprocessing.Process([group[, target[, name[, args[, kwargs]]]]], *, > daemon=None) This is OK too. > I also noticed these more unusual signatures: > > urllib.request.urlopen(url, data=None[, timeout], *, cafile=None, > capath=None, cadefault=True) > http.client.HTTPSConnection(host, port=None, key_file=None, cert_file=None[, > strict[, timeout[, source_address]]], *, context=None, check_hostname=None) Here the args between [] probably have a placeholder default, or are obtained from somewhere else (e.g. from socket.getdefaulttimeout()). These signature, albeit a bit weird, are understandable IMHO, so, unless you find a better way to write them, I would leave them as they are. > By the way, is the * really necessary in these examples? If the args on the right of the * are keyword-only and the one on the left aren't, then yes. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15831> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
