Guido van Rossum <guido@python.org> writes:
>> I considered these two options:
>>
>> option 1:
>> introduce a separate metaclass for every wrapped class so that we
>> have a place to stick a property object.
>>
>> option 1a:
>> only do this if the user supplies a special extra template
>> parameter to the class_<...> declaration
>>
>> option 2:
>> Implement a special property type which allows us to easily
>> identify property attributes which correspond to Boost.Python static
>> data members
>>
>> Implement a special __setattr__ in the Boost.Python metaclass which
>> looks up the attribute on the class to see if it has this special
>> type; if so, it is called, and otherwise the default __setattr__
>> behavior takes effect.
>>
>> I was going to go with option 1. Are you suggesting option 2?
>
> It would seem to be less work than having a separate metaclass for
> each class that has a static data item. But it's really up to you.
My reasoning was:
it favors speed and code size over data size. The only downside I
can see is that an extra object (the metaclass object) is created
for every wrapped class. It's also simpler to implement.
However, I think it might also cost an extra property object per
wrapped class, unless I can find a way to get the class and its
instance to share the property. Hmm, feels a bit hack-ish to me now
that you mention it. Maybe option 2 is better after all. But then,
do I want to implement tp_getattr or tp_getattro? I don't recall the
differences.
>> Yes, but type is always non-None, it seems.
>
> Yes, that's what I said.
>
>> Look at descrintro.html again. It says:
>>
>> Example: coding super in Python.
>>
>> As an illustration of the power of the new system, here's a fully
>> functional implementation of the super() built-in class in pure
>> Python. This may also help clarify the semantics of super() by
>> spelling out the search in ample detail. The print statement at the
>> bottom of the following code prints "DCBA".
>>
>> class Super(object):
>> def __init__(self, type, obj=None):
>> self.__type__ = type
>> self.__obj__ = obj
>> def __get__(self, obj, type=None):
>> ^^^^^^^^^
>> if self.__obj__ is None and obj is not None:
>> return Super(self.__type__, obj)
>> else:
>> return self
>>
>> Also, PEP 252 says:
>>
>> - __get__(): a function callable with one or two arguments that
>> retrieves the attribute value from an object.
>>
>> What's that about? Does __get__ ever get called with just one
>> argument (excluding self)? If so, when?
>
> When you call it yourself (rather than when it is called as a result
> of __getattribute__).
When do you call it yourself?
> I suppose this is a bit redundant.
I guess; I don't know. I'm trying to understand whether "callable
with one or two arguments" is really part of the requirements for use
as a property method, or just something that got thrown in there.
>> >> 3. Is there documentation for __delete__ anywhere?
>> >
>> > Apparently not, but it's easy to guess what it does if you know
>> > __getattr__, __setattr__ and __delattr__. It's __delete__ and not
>> > __del__ because __del__ is already taken. In an early alpha release
>> > it was actually __del__, but that didn't work very well. :-)
>>
>> It's easy enough to guess what it does by instrumenting it, too.
>> However, it's been out in a released Python for several versions now
>> and I get tired of guessing every time I have to write a new one of
>> these ;-). I think it's time there were some official docs.
>
> So volunteer some.
I'm anxious to, and I will -- just as soon as I can get a clear
picture of what I should say. Gee, I guess "someone" should document
__getattribute__ while I'm in there. Are there any other obvious
omissions in that neighborhood?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4