RE: [PyCrust] Attribute list hook

[Kevin A. <al...@se...>]

Patrick and I started chatting on messenger and we ended up disagreeing on
implementation of Neil's idea, so I'm just copying the whole discussion
(with some minor edits) to the list.

ka
---
altis: i don't quite understand Neil's "code for PythonCard" and your own
hook. In order for Neil's stuff to work, PyCrust actually needs to call the
_getAttributes method when you build your list for a given object.

altis: i'll go ahead and add _getAttributes to the Background components if
I can understand what is going on

altis: can we make the call _getAttributes as Mark suggested?

pat_orbtech: I'm concerned that it isn't very generic. Another project might
implement it differently, or use that same call for something entirely
different.

altis: huh? the point of using the leading underscore is to indicate it is
private. your own getAttributes doesn't need the leading underscore, only
the one you're going to call for an object

pat_orbtech: Here is what I mean. In another project, say Boa for example,
_getAttributes might mean something entirely different than how PythonCard
defines it. Or, Boa may have a method with a different name that returns the
list of attributes. I'd like to have the flexibility to allow for these
situations, rather than hardcode in an attempt to do object._getAttributes.

pat_orbtech: Making the method private doesn't solve much.

altis: but you have to call the method, so you need to standardize on
something

pat_orbtech: No, I don't. I could call a function that was passed in as a
parameter and pass that function the object under investigation, like
getMorePlease(object). Since getMorePlease is a parameter, it could be a
reference to any function in PythonCard, or Boa, or whatever, that took an
object and returned a list of hidden, or magic, or whatever, attributes.

altis: yes, that is what i was just thinking, add the method name, not a
method object, to be passed in as part of the initialization

altis: that works for me

pat_orbtech: I just moved most of these functions we are talking about to a
new module called introspect, so if we want to get specific it would help to
be talking about the same thing.

pat_orbtech: In any case, the issue is having a function or method in
PythonCard that can take an object and return magic attributes. Then there
needs to be a way to tell PyCrust to use that method in its getAttributes
function.

altis: yes

altis: so, let's pass in the name at init getAttr='_getAttributes' would be
what I use assuming getAttr is the method parameter for init

altis: i added
    def _getAttributeNames(self):
        names = []
        for name in self.data.keys():
            names.append(name)
        return names

altis: to WidgetDict, so as soon as you check in a change so we can pass in
the method name i'll change the init in debug.py, check in my changes and we
can try it

altis: of course that's a list, do you need a dictionary? and if so, what is
the value supposed to be?

pat_orbtech: I don't think we are quite on the same page.

altis: i just implemented what Neil described. what i want to do is pass in
the '_getAttributeNames' method name as part of my shell initialization and
then for every object, your code is going to check whether that method
exists and if so, get the extra list of attributes

pat_orbtech: That's not quite what I was thinking.

altis: you already have all the stuff from __dict__ ..., you just need the
hidden stuff

pat_orbtech: I know. The part I'm struggling with is getting passed the
method name.

altis: the method name is no longer hard-coded, i made up my own which I
pass to your initialization

altis: i could call mine _cheezyPoofs

pat_orbtech: I'm not saying it can't be done. I was just thinking of
something slightly different.

pat_orbtech: Are you going to send me a sting? I guess you would have to,
right?

altis: such as? i can't pass you a method object

pat_orbtech: sting = string

altis: then you do a recursive search for that method name and if found
execute it to get back a list of additional names

pat_orbtech: You could pass me a function that took an object as a
parameter. Then I would call that function passing it the object. Inside
that function you would do object._cheezyPoofs.

altis: nope, doesn't work

pat_orbtech: I want you to control how this works, not PyCrust.

altis: the extra names would have to be the same for every class which it
won't be

pat_orbtech: Why wouldn't that work? I'm giving you the object?

altis: WidgetDict defines the extra attributes as keys in a dictionary, the
Widgets themselves define the extra attributes as items with get/set, and
yet another class will define it differently still

altis: you're also requiring that the method being passed in at
initialization will then have to be around the life of the program, that is
lame

altis: perhaps we should move this to the list

pat_orbtech: no more lame than any function defined in a module.

pat_orbtech: it shouldn't be a method, just a function.

pat_orbtech: Look at Neil's original example:
def attrList(d):
    try:
        print d.getAttributeNames()
    except AttributeError, x:
        print "Empty"

pat_orbtech: I'm saying pass me attrList and I will call it with the object
under inspection and it can find the magic attributes. That way the
functionality stays inside PythonCard where it belongs. PyCrust just gives
you a hook.
pat_orbtech: Of course, attrList needs to be changed to return a list, not
print stuff out.

altis: well, i guess we should copy this discussion to the list. that just
seems broken to me with every code piece that wants to use the shell having
to define their own method to do the searching when the functionality
belongs in the shell

altis: and i think that is what neil is describing

pat_orbtech: If we were talking standard Python I would agree it belongs in
the shell. But we aren't. We're talking about a PythonCard specific
technique. So I think a hook is appropriate. But I'm more than willing to
debate this on the list.

altis: no, it isn't a pythoncard thing neil was talking about a general
solution that all classes could implement if they want enhanced support in
PyCrust

pat_orbtech: I know that's what what suggested, but until everyone adopts it
it is a PythonCard thing. And I'm not as unhappy with my solution as you
are.

altis: copying to the list now....