Issue1544909
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2006-08-22 21:36 by brett.cannon, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
pep_362_impl.patch | brett.cannon, 2006-08-23 22:14 | Add support for __str__() and Signature.bind() | ||
pep_362_w_Jim_comments.diff | brett.cannon, 2006-08-24 17:16 | Minor changes as suggested by Jim Jewett | ||
pep_362_fix_pos_as_kw.diff | brett.cannon, 2006-08-24 21:44 | Fix bug where having all kw for pos. args failed for bind() | ||
pep_362_BindError.diff | brett.cannon, 2006-08-26 06:36 | Add BindError |
Messages (13) | |||
---|---|---|---|
msg50962 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2006-08-22 21:36 | |
This patch holds the current implementation of PEP 362 (Signature objects). |
|||
msg50963 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2006-08-22 21:44 | |
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. |
|||
msg50964 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2006-08-22 22:10 | |
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. |
|||
msg50965 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2006-08-23 22:14 | |
Logged In: YES user_id=357491 Add methods to Signature and Parameter. It implements __str__() on both and Signature.bind(). |
|||
msg50966 - (view) | Author: Jim Jewett (jimjjewett) | Date: 2006-08-23 23:58 | |
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? |
|||
msg50967 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2006-08-24 17:14 | |
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. |
|||
msg50968 - (view) | Author: Jim Jewett (jimjjewett) | Date: 2006-08-24 17:37 | |
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. |
|||
msg50969 - (view) | Author: Jim Jewett (jimjjewett) | Date: 2006-08-24 17:49 | |
Logged In: YES user_id=764593 For question (5) def f(a): pass sig=inspect.getsignature(f) myargs=() mykwargs=dict(a=1) sig.bind(myargs, mykwargs) Parameter 'a' has been passed, but it is part of the keywords mapping, rather than part of the positional tuple. Right now, this would raise TypeError("too few positional arguments provided") I believe the python parser will normalize calls so that a typical call f(a=6) would would end up seeing args=(6) kwargs={} but I didn't see anything explaining that as a precondition. |
|||
msg50970 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2006-08-24 21:23 | |
Logged In: YES user_id=357491 (2) I don't want to do that because it isn't like you can't call bind() multiple times. I would hate to get a Parameter object with some suggested argument value, and then while I had it have that value change because in another thread someone called bind() on the Signature object again. (3) Fair enough. Changed to your suggestion in my version. (4) OK, I see what you are getting at. Changed in my version. I still wish there was a different exception that I could use to flag that the binding didn't fail but that the code couldn't figure out one without being destructive. (5) Yep, that's a bug. I have a test case for it now and will work on fixing it. (7) Fair enough. Code changed and docstring updated. I will work on fixing the bug I have that you reported. |
|||
msg50971 - (view) | Author: Jim Jewett (jimjjewett) | Date: 2006-08-24 21:34 | |
Logged In: YES user_id=764593 (4) Is there any reason you can't define a new exception type, perhaps as a subclass of TypeError? |
|||
msg50972 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2006-08-24 21:44 | |
Logged In: YES user_id=357491 OK, fixed the bug. Problem was that I had a bogus test that was testing for your example to fail. Oops. =) All fixed in the newest version. |
|||
msg50973 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2006-08-26 06:36 | |
Logged In: YES user_id=357491 I just like to try to reuse the built-in exceptions as much as possible. But you are right, a new exception is the right solution. I added a BindError exception that inherits from TypeError. |
|||
msg50974 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2007-03-06 19:30 | |
Code has moved into the sandbox in the pep362 directory. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:19 | admin | set | github: 43876 |
2006-08-22 21:36:21 | brett.cannon | create |