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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4