How many languages features are available for OO support?
Byron Hammond
I know it has [multiple] inheritance and polymorphism etc, but to what
extent does
the language accomodate this and other OO concepts?
Does Python support the notion of an abstract class or an interface through
the
use of language features?
I ask this because not only do I want certain design decisions to be clear
when
reading the code, but I also want to make debugging easier for myself.
I realize I can still implement the things I want to without the use of
keywords etc,
but for me, it is important I do what my design allows for, not what I want
to.
:-)
Thanks
Byron
Gerhard Häring
> To what extent does Python support OO?
>
> I know it has [multiple] inheritance and polymorphism etc, but to what
> extent does the language accomodate this and other OO concepts?
The language is described in the Python documentation. As you will see,
there are no abstract or interface keywords.
> Does Python support the notion of an abstract class or an interface
> through the use of language features?
No, not currently. Of course there are patters for newcomers from Java
to fake these features. But they're of little practical use, IMO.
Here's a quick shot from me:
class X:
def __init__(self, *args, **kwargs):
raise NotImplementedError, "This class is abstract :-P"
x = X()
> I ask this because not only do I want certain design decisions to be
> clear when reading the code, but I also want to make debugging easier
> for myself.
That's what comments and docstrings are for, like:
class X:
"""{short description here}
Don't use this class directly. Subclass it
and override the {methodname} method instead."""
Gerhard
--
This sig powered by Python!
Außentemperatur in München: 25.8 °C Wind: 3.5 m/s
Pedro B. Gomes Costa
> > Does Python support the notion of an abstract class or an interface
> > through the use of language features?
Here is a quote from the excelente book "Thinking in Python" from my
favourite C++/Java and now Python book writer, Bruce Eckel
(www.bruceeckel.com)
"Because Python is weakly typed, it doesn't really care about interfaces -
all it cares about is applying operations to objects (in fact, Java's
interface keyword would be wasted in Python). This means that inheritance in
Python is different from inheritance in C++ or Java, where you often inherit
simply to establish a common interface. In Python, the only reason you
inherit is to inherit an implementation - to re-use the code in the base
class."
Btw, you can download a electronic version of the book from the address
above.
Pedro Costa
----- Original Message -----
From: "Gerhard Häring" <gh_pyt...@gmx.de>
To: <pytho...@python.org>
Sent: Friday, May 17, 2002 12:40 PM
Subject: Re: How many languages features are available for OO support?
> * Byron Hammond <byr...@bigpond.net.au> [2002-05-17 11:02 +0000]:
> > To what extent does Python support OO?
> >
> > I know it has [multiple] inheritance and polymorphism etc, but to what
> > extent does the language accomodate this and other OO concepts?
>
> The language is described in the Python documentation. As you will see,
> there are no abstract or interface keywords.
>
> > Does Python support the notion of an abstract class or an interface
> > through the use of language features?
>
> No, not currently. Of course there are patters for newcomers from Java
> to fake these features. But they're of little practical use, IMO.
>
> Here's a quick shot from me:
>
> class X:
> def __init__(self, *args, **kwargs):
> raise NotImplementedError, "This class is abstract :-P"
>
> x = X()
>
> > I ask this because not only do I want certain design decisions to be
> > clear when reading the code, but I also want to make debugging easier
> > for myself.
>
> That's what comments and docstrings are for, like:
>
> class X:
> """{short description here}
> Don't use this class directly. Subclass it
> and override the {methodname} method instead."""
>
> Gerhard
> --
> This sig powered by Python!
> Außentemperatur in München: 25.8 °C Wind: 3.5 m/s
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Gonçalo Rodrigues
<pb...@ciberbit.pt> wrote:
>Hi
>
>> > Does Python support the notion of an abstract class or an interface
>> > through the use of language features?
>
>Here is a quote from the excelente book "Thinking in Python" from my
>favourite C++/Java and now Python book writer, Bruce Eckel
>(www.bruceeckel.com)
>
>"Because Python is weakly typed, it doesn't really care about interfaces -
>all it cares about is applying operations to objects (in fact, Java's
>interface keyword would be wasted in Python). This means that inheritance in
>Python is different from inheritance in C++ or Java, where you often inherit
>simply to establish a common interface. In Python, the only reason you
>inherit is to inherit an implementation - to re-use the code in the base
>class."
>
>Btw, you can download a electronic version of the book from the address
>above.
>
>Pedro Costa
>
I agree with what you say, but interfaces can serve another very
important purpose (VIP). Quoting from M. Pelletier interfaces PEP 245:
"There are many implied interfaces in Python, commonly referred to as
"protocols"."
"Currently determining those protocols is based on introspection, but
often that also fails. For example, defining __getitem__ implies both a
sequence and a mapping (the former with sequential, integer keys).
There is no way for the developer to be explict about which protocols
the object intends to implement."
"There is no unified model for determining if an object can be used in a
certain, valid way."
That is, an interface specification could (should) serve to declare a
protocol for a given object, e.g. if a class implemented interface
IIterable (the objects are iterable) then a method __iter__ must be
declared in the class and with the right signature.
If for a moment we take an extensional definition of interface (= a set
of classes) then prolly it could be implemented using metaclasses,
although I haven't figured out *exactly* how. Some syntactic sugar could
then be added on top of this (a la PEP 245).
Anyway, what I would like to stress is that in Python one mostly codes
for/against behaviour (protocol) and not type, and that some form of
behaviour declaration (interface) would be highly desirable, IMHO.
All the best,
Gonçalo Rodrigues
Jason Voegele
You can check out this page on my Web site. It may provide helpful information.
http://www.jvoegele.com/software/langcomp.html
--
Jason Voegele
"We believe that we invent symbols. The truth is that they invent us."
-- Gene Wolfe, The Book of the New Sun
Pedro B. Gomes Costa
2.2 Descriptors
In previous versions of Python, there was no consistent way to discover what attributes and methods were supported by an object. There were some informal conventions, such as defining __members__ and __methods__ attributes that were lists of names, but often the author of an extension type or a class wouldn't bother to define them. You could fall back on inspecting the __dict__ of an object, but when class inheritance or an arbitrary __getattr__ hook were in use this could still be inaccurate.
The one big idea underlying the new class model is that an API for describing the attributes of an object using descriptors has been formalized. Descriptors specify the value of an attribute, stating whether it's a method or a field. With the descriptor API, static methods and class methods become possible, as well as more exotic constructs.
8 PEP 232: Function Attributes
In Python 2.1, functions can now have arbitrary information attached to them.
People were often using docstrings to hold information about functions and
methods, because the __doc__ attribute was the only way of
attaching any information to a function. For example, in the Zope Web
application server, functions are marked as safe for public access by having a
docstring, and in John Aycock's SPARK parsing framework, docstrings hold parts
of the BNF grammar to be parsed. This overloading is unfortunate, since
docstrings are really intended to hold a function's documentation; for example,
it means you can't properly document functions intended for private use in Zope.
Arbitrary attributes can now be set and retrieved on functions using the regular Python syntax:
def f(): pass f.publish = 1 f.secure = 1 f.grammar = "A ::= B (C D)*"
The dictionary containing attributes can be accessed as the function's __dict__. Unlike the __dict__ attribute of class instances, in functions you can actually assign a new dictionary to __dict__, though the new value is restricted to a regular Python dictionary; you can't be tricky and set it to a UserDict instance, or any other random object that behaves like a mapping.
Regards,
Pedro Costa
"Gonçalo Rodrigues" <op7...@mail.telepac.pt> wrote in message news:ip5aeu4c4p9ab7q4k...@4ax.com...
> >> > through the use of language features?
> >
John Hunter
Byron> Does Python support the notion of an abstract class or an
Byron> interface through the use of language features?
Zope, a nearly pure python web server, is moving to a
Components/Interface design, and provides some base classes to support
interfaces in python
http://www.zope.org/Documentation/ZDG/ComponentsAndInterfaces.stx
John Hunter
Martijn Faassen
> To what extent does Python support OO?
> I know it has [multiple] inheritance and polymorphism etc, but to what
> extent does the language accomodate this and other OO concepts?
It does multiple inheritance and polymorphism very well. Python 2.2
changed the multiple inheritance rules for new style objects and added
a nicer way to call specific superclasses, but earlier versions have
always worked fine with multiple inheritance.
> Does Python support the notion of an abstract class
As others wrote, generally this is implemented by writing something like:
class Foo:
def abstractMethod(self):
raise NotImplementedError
which will definitely give you the intended effect if you try to use
the method directly. Of course only during runtime, but that's Python
for you (the runtime nature of Python can be very nice). Write unit tests.
> or an interface through the use of language features?
Python interfaces are always already there, but not explicitly unless
you make them explicit by just writing a class to document them (possibly
also an abstract one as above you can mix in).
In larger frameworks the implicitness of interfaces starts to hurt.
Zope, one of Python's largest frameworks, has grown a solution for this,
now religiously applied in Zope 3, the next generation of Zope now
under development. The notion is slowly spreading into other frameworks
now (notably Twisted).
The Interface package, unfortunately not nicely packaged yet and lacking
documentation, can be found here in Zope3 CVS (you can download a
tarball and experiment; I hope it doesn't have too many dependencies):
http://cvs.zope.org/Zope3/lib/python/Interface/?only_with_tag=Zope-3x-branch
It deserves packaging and documentation.
[snip]
Regards,
Martijn
--
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?