A few words about Python interfaces
Alex Shindich
alex at shindich.com
Sun Apr 15 03:46:11 EDT 2001
Carlos Ribeiro wrote:
>
> At 01:03 14/04/01 -0700, Alex Shindich wrote:
> >If I understood you correctly, you propose to check interface meta-data
> >at run time. While this might be acceptable for may applications, some
> >applications may not be able to wait for it. The interface documentation
> >in my mind is meant for the developers rather than programs. Although
> >XML was meant to be read by programs.. Go figure ;)
>
> PEP 245 does not specify any means to check interfaces, either at compile
> or run time. PEPE246 does it, by means of adapters. The problem is that
> adapters may turn out to be a very popular idiom, and one that is not very
> efficient, given the way the check is going to be done - by means of
> (sometimes extensive) run time analysis of the objects given as parameters.
>
> >I do not think that code that uses explicit interfaces is going to look
> >worse then code that makes use of implicit interfaces. My fear is that
> >addition of explicit interfaces is going to introduce many Java-like
> >idioms into Python.
>
> So we share a very similar fear :-) I have nothing against Java-like
> idioms, except by the fact that adapters are going to be evaluated at run
> time, and the cost of this operation may be prohibitive.
I agree. I think that bi-directional adapters are wonderful when they
are not being pushed down everyone's throat.
> >(...) Although I still do not understand WHY
> >Python needs to deal with any of that?
>
> The interfaces proposal (PEP245) is being lead by Digital Creations. I see
> the reason behind their commitment, as they have to deal with a much more
> complex environment than other software developers. Zope is a very flexible
> framework, and keeps being extended by its users. Having some way to use
> interfaces (instead of relying on inheritance) is a big win for frameworks
> like Zope. It adds flexibility while keeping some control at Digital
> Creations, as they may specify formal interfaces for their framework. Zope
> users will only need to follow the interface specification, without any
> need to derive objects out of Zope base classes.
Zope can come with documentation on what methods should be implemented
for Zope-compatible components, and users would be able to create such
components even today. Also, Zope can provide a bunch of classes like:
class MyZopeInterface:
""""""
def myZopeMethod (self, a, b, c):
"""The docs go here..."""
raise MyZopeException, "Method 'MyZopeMethod' is not implemented"
...
What's the big deal if users had to inherit from those classes?
Regards,
Alex Shindich
mailto:alex at shindich.com
Visit http://www.shindich.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alex.vcf
Type: text/x-vcard
Size: 194 bytes
Desc: Card for Alex Shindich
URL: <http://mail.python.org/pipermail/python-list/attachments/20010415/ab6d9d67/attachment.vcf>
More information about the Python-list
mailing list