* Russ P. (Mon, 2 Feb 2009 13:51:11 -0800 (PST)) > On Feb 2, 9:02 am, thmpsn....@gmail.com wrote: > Several participants here keep repeating that the leading-underscore > convention is perfectly adequate. Aside from the aesthetic problem of > littering code with leading underscores, let me try to explain the > problem with leading underscores.
A leading underscore is not an aesthetic problem - while I would agree that /multiple/ leading or trailing underscores are. > Suppose a library developer (or a module developer on a large team) > uses leading underscores. Now suppose that, for whatever reason > (pressure from the users, perhaps), the library developer decides to > change a "private" attribute to public. Now all occurrences of the > identifier need to be changed. If an assignment to the previously > "private" attribute is missed, no warning will be issued (because > Python allows new attributes to be added anywhere, even completely > outside the class definition itself). And if the library is widely > used, the probability of such bugs occurring is very high. > > If a "private" keyword (or equivalent) were available, then the change > would need to be made in only one location rather than at every > occurrence off the identifier. That is much less error prone. Sure, > you can argue (as I'm sure someone will) that the users of the library > should be more careful. Yes they should, but why not let the language > help with such low-level details. That's what high-level languages are > for. This scenario is highly "supposing" and doesn't look like a real-world- case to me. But anyway: the obvious solution in my humble opinion would be to do something like "public_attribute = _private_attribute". But that would be too simple, too "unjavaesque", right?! Thorsten -- http://mail.python.org/mailman/listinfo/python-list
