[Patches] [ python-Patches-1544909 ] Implementation of PEP 362
SourceForge.net
noreply at sourceforge.net
Sat Aug 26 08:36:51 CEST 2006
Patches item #1544909, was opened at 2006-08-22 14:36
Message generated for change (Comment added) made by bcannon
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: Brett Cannon (bcannon)
Date: 2006-08-25 23:36
Message:
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.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2006-08-24 14:44
Message:
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.
----------------------------------------------------------------------
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-24 14:34
Message:
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?
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2006-08-24 14:23
Message:
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.
----------------------------------------------------------------------
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-24 10:49
Message:
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.
----------------------------------------------------------------------
Comment By: Jim Jewett (jimjjewett)
Date: 2006-08-24 10: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 10: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 16: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 15: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 15: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 14: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
More information about the Patches
mailing list