Inheritance and name clashes
arnodel at gmail.com
Mon Oct 4 00:23:46 CEST 2010
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
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.
More information about the Python-list