> On 15 Jun 2017, at 04:45, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 15 June 2017 at 11:06, Nathaniel Smith <n...@pobox.com > <mailto:n...@pobox.com>> wrote: >> On Wed, Jun 14, 2017 at 1:54 PM, Barry Scott <ba...@barrys-emacs.org> wrote: >>>> On 13 Jun 2017, at 23:49, Chris Angelico <ros...@gmail.com> wrote: >>>> For that purpose, is it possible to use super().__dir__()? Are there >>>> any considerations where that would fail? >>> >>> Remember that I need to do this in the C API and I want default_dir of self >>> in C not python. >>> >>> super().__dir__ looks at the class above me that is typically object() and >>> so is not useful >>> as it does not list the member function from my class or __mro__ or other >>> stuff I may not be aware of >>> that is important to return. >> >> object.__dir__(your_class_instance) should generally return everything >> you would get if you didn't override __dir__ at all. Remember, that >> code doesn't mean "return the methods and attributes defined on the >> object class", it's "run the object class's __dir__ method with >> self=your_class_instance". >> >> I don't know off-hand if there's a nicer way to do this from C than to >> manually look up the "__dir__" attribute on PyBaseObject_Type. > > This is the kind of case where > https://docs.python.org/3/c-api/object.html#c.PyObject_CallMethod > <https://docs.python.org/3/c-api/object.html#c.PyObject_CallMethod> is > useful: > > dir_result = PyObject_CallMethod(base_type, "__dir__", "O", self); > /* Add any additional attributes to the dir_result list */ > return dir_result;
But I need the result of __dir__ for my object not its base. Then I need to add in the list of member attributes that are missing because python itself has no knowledge of them they are accessed via getattr(). Now I cannot call __dir__ for my object in the implementation of __dir__ for the obvious reason. Today all classes defined using PyCXX for python3 cannot return the list of member variables via dir(obj). Where as in python2 I can make dir() work. > Fully supporting multiple inheritance is more work (as your link > shows), and often not needed. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com <mailto:ncogh...@gmail.com> | > Brisbane, Australia
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
