On Sat, 26 Jun 2010 10:17:45 pm Payal wrote:
> Hi,
> Some questions about which I am a bit confused.
>
> 1. I know there is a difference between mro of classic and new style
> classes. but I do not get why we need the new mro, the old one is
> easy to predict and understand?
The old MRO (Method Resolution Order) is broken for classes using
multiple inheritance with a diamond shape inheritance diagram. Not a
little bit broken, but horribly, horribly broken.
If you have something like this class hierarchy:
class A:
pass
class B(A):
pass
class C(A):
pass
class D(B, C):
pass
(only with actual methods, of course) then inheritance with old-style
classes cannot work correctly in some circumstances. Fortunately this
sort of inheritance diagram:
A
/ \
B C
\ /
D
is rare for old-style classes. But for new-style classes, *all* multiple
inheritance is diamond-shaped, because all classes inherit back to
object at the top of the diagram:
object
/ \
list str
\ /
myclass
So in order to allow people to inherit from built-ins, we had a choice:
(1) Keep the old MRO and a bug which used to be rare would become
common;
(2) Keep the old MRO but prohibit multiple inheritance and mixins (which
would mean breaking a lot of existing code); or
(3) Change the MRO to one which doesn't have the bug.
The Python developers choose 3. Well, actually, that's not quite true:
nobody noticed that the MRO was broken until *after* new-style classes
were added in version 2.2, and so the new MRO was added in version 2.3.
http://www.python.org/download/releases/2.3/mro/
> 2. A friend of mine told me that in C++ abstract classes are classes
> which can not be instatiated. Is she right, do we have them in
> python, if yes can someone give a simple example?
Python doesn't have a special "abstract class" type, but it is easy to
make one with just two lines of boilerplate:
class AbstractThing:
def __init__(self):
# Next two lines are boilerplate.
if type(self) is Abstract:
raise TypeError("abstract class, you must subclass this")
# init code for non-abstract Thing classes goes here
> 3. In http://www.alan-g.me.uk/tutor/index.htm , Alan has given an
> example in "User Defined Exceptions",
>
> >>> class BrokenError(Exception): pass
>
> Even after reading the section a few times over, I fail to get
> utility of such a class. Can someone please explain with better
> example? Alan can you please cleanup that section, maybe make it
> broader and put the stuff about "SystemExit" elsewhere.
The utility of user-defined exceptions is simply to allow your code to
distinguish between *your* exceptions and other exceptions. Different
people have different policies. Some people prefer this:
def func(x):
if x <= 0:
raise ValueError('x must be positive')
return sqrt(x) + x**2
Other people prefer this:
class DomainError(ValueError):
"""Used for mathematics domain errors."""
pass
def func(x):
if x <= 0:
raise DomainError('x must be positive')
return math.sqrt(x) + math.asin(x**2)
Then when you catch an error:
try:
print func(y)
except DomainError:
# only catches my own error
except ValueError:
# catches any other ValueError
But both solutions are equally good. Normally you don't want fifty
different exception classes in a module, nor do you want every
exception to be the same generic class. How finely you divide the error
classes is up to you.
--
Steven D'Aprano
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
