[Python-Dev] PEP 362 minor nits

[Yury Selivanov]

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

+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.co_varnames``).
> 
> 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.

-
Yury