[Python-Dev] PEP 362 minor nits

[Jim Jewett]

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

    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