design question: no new attributes

[Bruno Desthuilliers]

Alan Isaac a écrit :
> The security application seems to call for roles.

Considering that a role is a set of permissions in a context. The 
application doesn't want to say "you need this role", but "you need to 
have a role that has this permission" (nb : this is based on Zope's 
security model).

> I'll have to think about the schema example.
> But in any case, my question was poorly stated.
> I started out wanting to trap was the dynamic
> addition of attributes to class instances after
> initialization.

 From withing methods of the class, or from the outside world ? In the 
first case, pylint is what you're looking for.

> While you responded to my later question
> as asked, the response does not I think take this context
> into account.

Of course - this was not what I was answering to !-)

Now, in the above context, I still don't think your solution is the best 
option.

> 
>>As a side note :  in Python, *all* attributes are "dynamically created".
>>... Writing methods
>>within the class statement body makes things clearer, but is by no mean
>>mandatory:
> 
> 
> Point taken.  And I understand it means that my talk of
> "after initialization" above contains some ambiguity.

Indeed !-)

> One last point. While I remain interested in examples of how
> "late" addition of attributes to class instances is useful,

Then read the sources of packages / frameworks like SQLAlchemy, 
SQLObject, FormEncode, CherryPy, TurboGears, Django, etc - and probably 
a lot of other.

Heck, FWIW, modules are objects too - instances of class 'module', and 
all the top-level names of a module are de facto examples of "late 
addition of attributes to a class instance" !-)

> I must note that everyone who responded agreed that it
> has been a source of bugs.

Yes, of course - typos happens. But I've seen much more bugs introduced 
by all the boilerplate and complexities needed to work around arbitrary 
restrictions imposed by some well-known mainstream languages.

My experience with Python is that typos, type errors and all this class 
of programmer error are usually *very* quickly noticed (ie : within 
minutes).

> This seems to argue against a
> general ban on "locking" objects in some way, in some
> circumstances.

I'd rather go for better (well... pylint is already a pretty nice tool) 
code checkers.

My 2 cents...