OO in Python? ^^
Hi, sorry for my ignorance, but after reading the Python tutorial on python.org, I'm sort of, well surprised about the lack of OOP capabilities in python. Honestly, I don't even see the point at all of how OO actually works in Python. For one, is there any good reason why I should ever inherit from a class? ^^ There is no functionality to check if a subclass correctly implements an inherited interface and polymorphism seems to be missing in Python as well. I kind of can't imagine in which circumstances inheritance in Python helps. For example: class Base: def foo(self): # I'd like to say that children must implement foo pass class Child(Base): pass # works Does inheritance in Python boil down to a mere code sharing? And how do I formulate polymorphism in Python? Example: class D1(Base): def foo(self): print "D1" class D2(Base): def foo(self): print "D2" obj = Base() # I want a base class reference which is polymorphic if (): obj = D1() else: obj = D2() I could as well leave the whole inheritance stuff out and the program would still work (?). Please give me hope that Python is still worth learning :-/ Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Heiko Wundram wrote:
> Brian Beck wrote:
>
>>>class D1(Base):
>>> def foo(self):
>>> print "D1"
>>>
>>>class D2(Base):
>>> def foo(self):
>>> print "D2"
>>>obj = Base() # I want a base class reference which is polymorphic
>>>if ():
>>> obj = D1()
>>>else:
>>> obj = D2()
>>
>>I have no idea what you're trying to do here and how it relates to
>>polymorphism.
>>
>
>
> He's translating C++ code directly to Python. obj = Base() creates a
> variable of type Base(), to which you can assign different object types (D
> (), D2()) which implement the Base interface (are derived from Base).
> Err... At least I think it's what this code is supposed to mean...
>
> In C++ you'd do:
>
> Base *baseob;
>
> if( ) {
> baseob = (Base*)new D1();
> } else {
> baseob = (Base*)new D2();
> }
>
> baseob->foo();
>
> (should, if foo is declared virtual in Base, produce "d1" for D1, and "d2"
> for D2)
>
> At least IIRC, it's been quite some time since I programmed C++... ;-)
> *shudder*
Yes, that's what I tried to express (the cast to Base* is redundant here
by the way, since D1/D2 are also of type Base; you can always hold a
base class pointer to derived types without type conversion).
I have also read the other answers to my question, and I am really sorry
if I have sounded ignorant in my post, but it's harder than I thought to
move to a language where all these techniques one had learned in years
of hard work suddenly become redundant :)
I'm so used to statically typed languages that the shift is very
confusing. Looks as if it isn't as easy to learn Python afterall, for
the mere reason of unlearning rules which don't apply in the world of
Python anymore (which seem to be quite a lot!).
Regards,
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
Brian Beck wrote:
> def foo(self):
> raise NotImplementedError("Subclasses must implement foo")
That's actually a good idea, though not as nice as a check at
"compile-time" (jesus, I'm probably talking in C++ speech again, is
there such a thing as compile-time in Python at all?!)
Another thing which is really bugging me about this whole dynamically
typing thing is that it seems very error prone to me:
foo = "some string!"
# ...
if (something_fubar):
fo = "another string"
Oops, the last 'o' slipped, now we have a different object and the
interpreter will happily continue executing the flawed program.
I really see issues with this, can anyone comment on this who has been
working with Python more than just a day (like me)?
Regards,
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
That was quite insightful Martin, thanks. Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
gene tani wrote: > http://naeblis.cx/rtomayko/2004/12/15/the-static-method-thing > http://dirtsimple.org/2004/12/java-is-not-python-either.html > http://dirtsimple.org/2004/12/python-is-not-java.html > > http://idevnews.com/PrintVersion_CaseStudies.asp?Search3=web+services&Go2=Go&ID=118 > http://www.idevnews.com/PrintVersion_TipsTricks.asp?ID=107 > http://www.eros-os.org/pipermail/e-lang/2001-June/005337.html First of all, thanks everybody for posting all these answers and links, much appreciated. What Bruce Eckel wrote about dynamic typing was quite convincing and reasonable. I stumbled over this paragraph in "Python is not Java", can anyone elaborate on it: "In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters." Why would I want to use an attribute in Python, where I would use getters and setters in Java? I know that encapsulation is actually just a hack in Python (common, "hiding" an implementation detail by prefixing it with the classname so you can't access it by its name anymore? Gimme a break...), but is that a reason to only write white box classes? ^^ - Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: OO in Python? ^^
[EMAIL PROTECTED] wrote: > Just follow the links. I'll try ;-) -- http://mail.python.org/mailman/listinfo/python-list
PyXML: SAX vs. DOM
Hi, I have to say I am confused about the documentation on pyxml.sf.net. When I want to use DOM, I effectively am using a class called Sax2? ^^ I also have to catch SAXExceptions, which reside in xml.sax._exceptions. I thought DOM and SAX are two completely different things. Why is PyXML mixing them up like this? Thanks, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: PyXML: SAX vs. DOM
Oh and: Where can I find an API reference for PyXML? Am I supposed to /guess/ which methods and attributes e.g. Sax2 supplies? :D Thanks again, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: PyXML: SAX vs. DOM
Steven Bethard wrote: > I don't have an answer to your real question, but if you're not > committed to a particular XML package yet, you might consider ElementTree: > http://effbot.org/zone/element-index.htm > > The API is much simpler, and the package has a much more sane > organization. ;) Plus, it will be part of the Python standard library > in Python 2.5. That sounds great, thanks. Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: PyXML: SAX vs. DOM
Ivan Herman wrote: > I know this is not the ideal answer, but maybe it helps... It does, thanks Ivan. Regards, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Cross-module imports?
Hi, I am getting strange errors when I am importing modules cross-wise, like this: # module A import B var1 = "x" B.var2 = "y" # module B import A var2 = "z" print A.var1 The error messages are not even sane, for example the interpreter complains about not finding 'var1' in module A. Is there a solution to this problem which doesn't involve introducing a new module holding the shared objects? Thanks, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: Cross-module imports?
Ant wrote: > If you have to trick the compiler like this though, I'd take a good > look at *why* you want to couple the modules so tightly in the first > place! Yeah, you're right. I think loosening up the coupling by introducing a module which holds common shared data is probably a good idea anyway. Thanks for clearing up, Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: wxPython or wxWidgets
Marc 'BlackJack' Rintsch wrote: > wxPython are the Python bindings to wxWidgets which is a C++ library. Don't want to hijack the thread, but since it's answered already: Has wxWidgets finally arrived at migrating to GTK2? ^^ If so, I might consider using wxPython instead of pygtk for that small application I am currently writing. This would help portability a lot (since IIRC, wxWidgets has been designed to work on Windows, too). The last time I checked, wxWidgets was GTK1, although GTK2 has had been long around already. Because of this, and the nasty feeling that I was programming MFC when working with the wxWidgets somewhat drove me away from it with a big "Yuck!", but if it's based on GTK2 now I might risk another glimpse. Thanks, Matthias -- http://mail.python.org/mailman/listinfo/python-list
