Inheritance and name clashes

[Arnaud Delobelle]

Rock <rocco.rossi at gmail.com> writes:

>> Object-oriented designs are difficult to design in any programming
>> language, and it helps to have some sort of concrete problem to drive
>> the discussion.  Are you working on a particular design where you
>> think Python's philosophy will inhibit good design?  My take on Python
>> is that it focuses more on enabling good designs than preventing bad
>> designs.  I prefer this to Java, for example, which I feel inhibits me
>> from expressiveness at a higher cost than any supposed benefits
>> private/protected would give me.
>
> Thanks for the reply. No, I was just working with a normal library
> class which was supposed to be derived. So that's what I did, but in
> the process I found myself needing to create an instance variable and
> it dawned on me: "how do I know I'm not clobbering something
> here???" ... I'd have to look at the docs, right? But I still wasn't
> sure ... so, then I thought "let's look at the source", and then I
> found out. But! It took me some time to make sure, and I was puzzled
> as well. I mean, what if I have no source to look at? What if the
> library I'm using doesn't realase the source, or what if I just can't
> get my hands on it for some reason or another?
>
> That was a big disappointment with Python for sure. Somehow PHP makes
> me feel a little safer, in that respect at least.

I've been reading c.l.python for years (on and off) and I can't recall
anybody saying this has been a problem in practise.  There are many
queries about how to create private/protected attributes, but not as a
result of having had a problem, rather because people new to Python but
experienced in another language (C++, Java...) are used to those
concepts being central, whereas in Python they are deliberately being
pushed aside.

A much more common problem with naming is something like this: I
create a module (or simply a script) and calls it "foo.py".  In another
file in the same directory I create a script that imports module "bar".
However, module "bar" itself imports a module called "foo" of which I am
unaware.  But because "foo.py" is in the Python path, this gets loaded
instead, causing havoc.

-- 
Arnaud