[Python-Dev] PEP 362 minor nits

Tue Jun 19 17:33:41 CEST 2012

I've limited this to minor issues, but kept python-dev in the loop
because some are questions, rather than merely editorial.
Based on: http://hg.python.org/peps/file/tip/pep-0362.txt
view pep-0362.txt @ 4466:659639095ace
Committing the latest changes to PEP 362 on behalf of Yury Selivanov.
author	Larry Hastings <larry at hastings.org>
date	2012年6月19日 02:38:15 -0700 (3 hours ago)
parents	c1f693b39292
=わ=わ=わ=わ=わ=わ=わ=わ=わ=わ=わ=わ=わ=わ=わ=わ=わ=わ
 44 * return_annotation : object
 45 The annotation for the return type of the function if specified.
 46 If the function has no annotation for its return type, this
 47 attribute is not set.
I don't think you need the "if specified", given the next line.
Similar comments around line 89 (Parameter.default) and 93
(Parameter.annotation).
 48 * parameters : OrderedDict
 49 An ordered mapping of parameters' names to the corresponding
 50 Parameter objects (keyword-only arguments are in the same order
 51 as listed in ``code.co_varnames``).
Are you really sure you want to promise the keyword-only order in the PEP?
[BoundArguments]
 139 * arguments : OrderedDict
 140 An ordered, mutable mapping of parameters' names to
arguments' values.
 141 Does not contain arguments' default values.
I think 141 should be reworded, but I'm not certain my wording doesn't
have similar problems, so I merely offer it:
arguments contains only explicitly bound parameters; parameters for
which the binding relied on a default value do not appear in
arguments.
 142 * args : tuple
 143 Tuple of positional arguments values. Dynamically computed from
 144 the 'arguments' attribute.
 145 * kwargs : dict
 146 Dict of keyword arguments values. Dynamically computed from
 147 the 'arguments' attribute.
Do you want to specify which will contain the normal parameters, that
could be called either way? My naive assumption would be that as much
as possible gets shoved into args, but once a positional parameter is
left to default, remaining parameters are stuck in kwargs.
 172 - If the object is not callable - raise a TypeError
 173
 174 - If the object has a ``__signature__`` attribute and if it
 175 is not ``None`` - return a shallow copy of it
Should these two be reversed?
 183 - If the object is a method or a classmethod, construct and return
 184 a new ``Signature`` object, with its first parameter (usually
 185 ``self`` or ``cls``) removed
 187 - If the object is a staticmethod, construct and return
 188 a new ``Signature`` object
I would reverse these two, to make it clear that a staticmethod is not
treated as a method.
 194 - If the object is a class or metaclass:
 195
 196 - If the object's type has a ``__call__`` method defined in
 197 its MRO, return a Signature for it
 198
 199 - If the object has a ``__new__`` method defined in its class,
 200 return a Signature object for it
 201
 202 - If the object has a ``__init__`` method defined in its class,
 203 return a Signature object for it
What happens if it inherits a __new__ or __init__ from something more
derived than object?
 207 Note, that
I would remove the comma.
 235 Some functions may not be introspectable
 236 ----------------------------------------
 237
 238 Some functions may not be introspectable in certain implementations of
 239 Python. For example, in CPython, builtin functions defined in C provide
 240 no metadata about their arguments. Adding support for them is out of
 241 scope for this PEP.
Ideally, it would at least be possible to manually construct a
signature, and register them in some central location. (Similar to
what is done with pickle or copy.) Checking that location would then
have to be an early step in the signature algorithm.
-jJ