[Patches] [ python-Patches-1544909 ] Implementation of PEP 362

[SourceForge.net]

Patches item #1544909, was opened at 2006-08-22 17:36
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
Assigned to: Brett Cannon (bcannon)
Summary: Implementation of PEP 362

Initial Comment:
This patch holds the current implementation of PEP 362
(Signature objects).

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-24 13:37

Message:
Logged In: YES 
user_id=764593

(2)  I agree that the current-binding information shouldn't 
be cached; I just think it should be available through the 
Parameter if it does exist.  On the other hand, I do see 
that it might cause confusion to have a property that is 
normally unavailable.

(3)  I think the reason it bugs me is that the same 
expression is used for both test and true, and so I keep 
expecting it to be a guard clause of some sort.  Something 
like

    argspec[1] if (argspec[1] is not None) else ""

would also clear up my concerns.

(4)  That makes sense, except that you don't catch 
TypeError.  So if you just changed it to a TypeError in 
__tuple_bind_OK raise and stopped catching IndexError, it 
would have the same effect.

(5)  I'll try to deal with separately.

(7)  My thought is that it should always be OK to call 
inspect.getsignature, even if the callable happens to be a 
write-only proxy.  I'm not saying you shouldn't cache the 
Signature; I just don't think that a failure to cache 
should raise an exception if everything else worked.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-08-24 13:14

Message:
Logged In: YES 
user_id=357491

In response to Jim:

(1) Yes.

(2) I don't want to cache it.  Remember this is not meant to
be used on a per-call basis, but for introspection before
calling the functin.

(3) Felt like using the new 'if' expression and I never
liked using the short-circuit of 'or' for assignment.  I can
change it to an 'if' statement if it really bugs you.

(4) Because I didn't want a TypeError that was caused
because of an error in the code to act as an accidental
signal that the check won't work.  I added a comment about that.

(5) I don't quite follow what your problem is here.  Can you
give me an example function def and call that you think is a
problem?

(6) No, that will be added when function
annotations/tags/whatever get added.  No need to prematurely
optimize.

(7) If it fails it should raise an exception, just like it
does now.  If you don't want it stored on the object, call
Signature's constructor directly.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-23 19:58

Message:
Logged In: YES 
user_id=764593

(1) Shouldn't classmethod Parameter.__tuple2param use cls 
rather than self?

(2) Should Parameter objects have an (optional, but 
standardizing a name) current_value attribute, so that they 
can be used to describe an execution frame as well as 
function objects?  (Or does the desire not to cache this 
information mean that bindings is is the best available 
API?)

(3) Why 
>>> self.var_args = argspec[1] if argspec[1] else ''

instead of just 
>>> self.var_args = argspec[1] or ''

(I keep expecting the if argspec[1] to be if argspec[1:] 
verifying that something is there.)

(4) Why does (private) __tuple_bind_OK raise IndexError 
just so that its only caller (private __positional_bind) 
can catch and raise TypeError instead?

(5) Why does bind insist that non-default arguments be 
passed as positionally (parts of *args) rather than by name 
(part of **kwargs)?  Is this safe because of how/when it 
gets called?

(6) Should signature objects have a returns attribute for 
the (parameter object representing the) return value, just 
to standardize the name?

(7) Can getsignature assume that it can create a new 
attribute on func (or im_func)?  Or should it use a temp 
variable, and wrap the caching inside a try-except?



----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-08-23 18:14

Message:
Logged In: YES 
user_id=357491

Add methods to Signature and Parameter.  It implements
__str__() on both and Signature.bind().

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-08-22 18:10

Message:
Logged In: YES 
user_id=357491

Change implementation of Signature.name so as to not try to
be fully qualified.  It's not possible with methods when
passed to a decorator since there is not back-reference to
the class it is being defined in.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2006-08-22 17:44

Message:
Logged In: YES 
user_id=357491

Changed getsignature() to attach the object to the im_func
object for methods instead of the method itself since
decorators will work with the function object directly and
not the method attribute.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470