How many languages features are available for OO support?

Fri May 17 15:07:48 EDT 2002

Hi,

I also agree with you, but i think that maybe function atributtes were included in Python 2.1 (PEP 232) and  "descriptors" were included in Python 2.2 to serve that purpose.
>From "Whats new in Python 2.2" (http://www.amk.ca/python/2.2/) :
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" <op73418 at mail.telepac.pt> wrote in message news:ip5aeu4c4p9ab7q4k5uf09dj94r1sjfr0t at 4ax.com...

> On Fri, 17 May 2002 13:41:00 +0100, "Pedro B. Gomes Costa"
> <pbeck at 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
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20020517/df245e39/attachment.html>