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