Russ P. a écrit :
(snip)
I think the issue here is the distinction between hacking and software
engineering. I may be misusing the term "hacking," but I do not mean
it in a pejoritive sense. I just mean getting things done fast without
a lot of concern for safety, security, and long-term maintainability
and scalability.

I do feel concerned by these issues.

I'm not a computer scientist, but it seems to me that
Python is great for hacking and good for software engineering, but it
is not ideal for software engineering.

What Paul is suggesting, I think, is that Python should move in the
direction of software engineering. Whether that can be done without
compromising its hacking versatility is certainly a valid question,
but if it can be done, then why not do it?

Certainly one basic principle of software engineering is data
encapsulation. Tacking new attributes onto class instances all over
the place

There's a clear distinction between "making wise use of dynamicity" and "tacking new attributes onto class instances all over the place".

may be convenient and useful in many cases, but it is not
consistent with good software engineering.

simplicity is "good software engineering". Accidental complexity is not. Dynamism _can_ greatly reduce accidental complexity.


If the programmer could
somehow disallow it in certain classes,

Already possible - you just have to provide your own implementation of __setattr__.

that could be useful,
providing that those who wish to continue doing it would be free to do
so. If class attributes could somehow be declared private,

The important point is to make implementation distinct from interface - which we already know how to do -, and sometimes to prevent _accidental_ overriding of some critical implementation attributes - which is also already implemented. Enforcing access restriction is, from experience, just pointless.

"""
patient : doctor, when I do this, it hurts
doctor : well, don't do it, then.
"""
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to