[Pythoncard-users] making components less restrictive about attributes

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

PythonCard components in the past have been restrictive about 
attributes, that is an attribute had to be pre-defined, otherwise an 
AttributeError would be thrown at runtime if you tried to use an 
attribute that didn't already exist. For example, given a TextField 
named 'fld',

self.components.fld.txt = 'hello'

would generate a runtime error. If you make a typo (e.g. txt instead of 
text), then this can help uncover errors in your program, but it is 
also more restrictive than a normal Python class where attributes can 
be added on the fly. If field1 was a normal Python object, the code 
above would not generate an error. Note that unless fld.txt was defined 
earlier, then something like

print self.components.fld.txt

would still generate an error even without restrictive attributes since 
txt isn't defined.

Anyway, we've been pulling off the restrictive attributes through the 
use of __getattr__ and __setattr__; some or all of that behavior might 
be doable now with slots. Only Font, Widget (base class for 
components), and StatusBar in release 0.7.3.1 are restrictive. If we're 
going to continue this type of usage, then for consistency all the 
classes exposed to user code should probably be just as restrictive or 
perhaps only classes that are unlikely to be subclassed would be 
restrictive; having to pre-define attributes for Background would be a 
major pain.

I've argued back and forth with myself about the pros and cons and my 
recommendation is that we drop the use of __getattr__ and __setattr__ 
and have PythonCard classes work like any other Python class. User code 
will be able to make typos that lead to errors, but even the largest 
PythonCard program is unlikely to be more than a few thousand lines of 
code, so tracking down that kind of bug shouldn't be that hard. In 
fact, since we'll still have component specs and tools like PyChecker, 
source checking can probably be automated. The framework code will be 
much simpler, especially since we'll be using the built-in Python 
property() to define attributes. It should be much simpler to wrap 
wxPython controls and subclass existing components too.

I already changed statusbar.py in the PythonCard branch of cvs to see 
how this change would impact some real code and Rowland and I plan to 
change widget.py and font.py sometime tomorrow. However, since this is 
Open Source I like to give people a chance to voice opinions even if 
they aren't doing the coding <wink>, so if you would like to argue for 
keeping the restrictive access, please do so ASAP.

Thanks,

ka