Mailing List Archive

Second round: arbitrary function and method attributes
Here's the second go at adding arbitrary attribute support to function
and method objects. Note that this time it's illegal (TypeError) to
set an attribute on a bound method object; getting an attribute on a
bound method object returns the value on the underlying function
object. First the diffs, then the test case and test output.

Enjoy,
-Barry
Re: Second round: arbitrary function and method attributes [ In reply to ]
On Tue, 11 Apr 2000, Barry A. Warsaw wrote:
> Here's the second go at adding arbitrary attribute support to function
> and method objects. Note that this time it's illegal (TypeError) to
> set an attribute on a bound method object; getting an attribute on a
> bound method object returns the value on the underlying function
> object. First the diffs, then the test case and test output.

In the instancemethod_setattro function, it might be nice to do the speed
optimization and test for sname[0] == 'i' before hitting the strcmp()
calls.

Oh: policy question: I would think that these attributes *should* be
available in restricted mode. They aren't "sneaky" like the builtin
attributes.

Rather than PyMapping_Get/SetItemString()... PyObject_Get/SetItem() should
be used. They apply to mappings and will be faster. Note that (internally)
the PyMapping_Get/SetItemString use the latter forms (after constructing a
string object(!)).
... whoops. I see that the function object doesn't use the ?etattro()
variants. hrm.

The stuff is looking really good!

Cheers,
-g

--
Greg Stein, http://www.lyra.org/
Re: Second round: arbitrary function and method attributes [ In reply to ]
>>>>> "GS" == Greg Stein <gstein@lyra.org> writes:

GS> In the instancemethod_setattro function, it might be nice to
GS> do the speed optimization and test for sname[0] == 'i' before
GS> hitting the strcmp() calls.

Yeah, you could do that, but it complicates the code and the win seems
negligable.

GS> Oh: policy question: I would think that these attributes
GS> *should* be available in restricted mode. They aren't "sneaky"
GS> like the builtin attributes.

Hmm, good point. That does simplify the code too. I wonder if the
__dict__ itself should be restricted, but that doesn't seem like it
would buy you much. We don't need to restrict them in classobject
anyway, because they are already restricted in funcobject (which ends
up getting the call anyway). It might be reasonable to relax that for
arbitrary func attrs.

GS> Rather than
GS> PyMapping_Get/SetItemString()... PyObject_Get/SetItem() should
GS> be used. They apply to mappings and will be faster. Note that
GS> (internally) the PyMapping_Get/SetItemString use the latter
GS> forms (after constructing a string object(!)). ... whoops. I
GS> see that the function object doesn't use the ?etattro()
GS> variants. hrm.

Okay cool. Made these changes and `attro'd 'em too.

GS> The stuff is looking really good!

Thanks!
-Barry