RE: [Pythoncard-users] making components less restrictive about attributes

[Steve H. <sh...@ho...>]

[Kevin]
> 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.
>
Right. It's a nice catch to trap the assignment, though.

> 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.
>
By which I presume you wouldn't even want to define Background's
__slots__?

> 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.
>
"Simple is better than complex"

> 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,
>
I want to be clear I'm not arguing for the restrictions to remain. But I
can't help wondering if a little discipline might allow you to define a
testing (restrictive) framework and a production ( relaxed) one? If
there's no easy way to do so, just go ahead and ditch the restrictions.

regards
--
Steve Holden                                 http://www.holdenweb.com/
ReportLab Enterprise Publishing Solutions    http://www.reportlab.com/
Chairman, PyCON DC 2004                          http://www.pycon.org/
Telephone: +1-800 494 3119                        Fax: +1 703 278 8289