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 <la...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
