[Python-Dev] PEP 362 minor nits (original) (raw)

Yury Selivanov yselivanov.ml at gmail.com
Tue Jun 19 17:53:44 CEST 2012

Jim,

On 2012-06-19, at 11:33 AM, Jim Jewett wrote:

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 Tue, 19 Jun 2012 02:38:15 -0700 (3 hours ago) parents c1f693b39292 ================== 44 * returnannotation : 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).

+1.

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.covarnames).

Are you really sure you want to promise the keyword-only order in the PEP?

Well we can remove that sentence (it seems that at least for CPython we can guarantee so, as we work with 'code.co_varnames', but again, even for CPython there may be some opcode optimizer, that can screw up the order in some way)

[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.

+1.

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.

Correct, we push as much as possible to 'args'. Only var_keyword and keyword_only args go to 'kwargs'.

But the words "positional" and "keyword" more refer to what particularly *args and **kwargs do, disconnected from the Signature's parameters.

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?

Do you have a use-case? I think we should only support callable types, otherwise we may mask an error in the user code.

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.

It's actually not how it's implemented.

https://bitbucket.org/1st1/cpython/src/bf009eb6e1b4/Lib/inspect.py#cl-1262

We first check for (types.MethodType, classmethod), because they relay all attributes from the underlying function (including signature) But that's an implementation detail, the algorithm in the PEP just shows the big picture (is it OK?).

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?

What do you mean by "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.

I think it's too early for this type of mechanism. Maybe in 3.4 we have a new way of defining parameters on C level? I'd not rush this in 3.3.

More information about the Python-Dev mailing list