more thoughts ... The motivations for moving to the 'properties style': ---------- * trans.request.fields['a'] is slightly easier to read and type than trans.request().fields()['a']
* it seems to require less code in the source files: i.e. we can get rid of most of the accessor methods * direct access is marginally faster than using accessor methods in cases where no calculations are needed The cons/risks as I see them: ------------- * this proposal requires extensive changes to existing code * the marginal speed benefits of direct access cannot be reaped without dropping some important docstrings * !!! replacing the obj.setFoo() methods with obj.foo = 1234 introduces a whole new class of bugs, in which someone might accidentally write obj.foa = 1234. This can be safeguarded against with the new __slots__ attribute, BUT __slots__ is new/immature and comes with lots of caveats (see http://www.python.org/2.2/descrintro.html). In particular, there is a strange dichotomy between __slots__ and __dict__. Furthermore, using __slots__ does not protect against this sort of error when using subclasses. IMHO, the implementation of __slots__ in Python 2.2 needs more work and using it is risky! With these things in mind I change my vote from +1 to 0 for the foo() accessor methods and -1 for the setFoo() methods. Tavis On Friday 18 January 2002 10:16, Chuck wrote: > Speed wasn't my motivation for properties. I just considered the > speed a bonus. > > My motiviation is getting rid of the vast majority of ()s and _s > and extraneous method declarations in Webware for something that is > faster to read and write as well as more Pythonic. > > You are right that doc strings are important though. I hope the > Python community provides a solution. > > > -Chuck On Friday 18 January 2002 11:01, Tavis Rudd wrote: > thinking some more about the 'properties style' proposal ... > > One of the motivations for making the switch to 'properties' is to > remove the performance costs associated with all the accessor > methods. In cases where no calculations are done, 2 methods and an > underscored attribute can be replaced with a single property. > However, these 'quasi-properties' WON'T have docstrings associated > with them! True 'properties' can have docstrings, but they require > 2 methods and an internal underscored attribute. Thus, there's a > conflict between speed and docstrings. > > Tavis > > _______________________________________________ > Webware-discuss mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/webware-discuss _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
