Progress on missing features?

[John Roth]

I'd definitely like to see the interfaces. Class methods I can
take a pass on; from a pragmatic viewpoint, I just put them
in the module, and it works fine.

Pep 245 is missing several things that I suspect are needed.

First, it doesn't say anything about the aliasing problem. It
assumes that the method name in the class is the same as
the method name in the interface. This doesn't work in general.
To extend his Fish Market example to a Grocery Market and
a Hardware Store, how do you handle the hasNuts() method?
In one case, it should report on peanuts and cashews, in the
other on hex nuts and similar stuff.
Use those two interfaces on a CountryGeneralStore object,
and you might not get what you're looking for.

Requiring them to be unique doesn't hack it - it won't handle
adding interfaces where you don't own either the interface or
the class (i.e. add someone else's interface to an existing class.)
Even if you have the freedom to design both of them together,
you're introducing bad naming habits and undesirable
coupling.

Second, how do I instantiate an object with a particular
interface? Calling the interface isn't sufficient - I need the
class name also. Likewise, calling the class is not only
insufficient because I need the interface I want, but it will
also break code because there is no way of telling whether
I want an interface or access to the entire class.

In the same vein, assuming I have an existing instance of a class,
how do I call it through an interface? Is there a dynamically
created proxy class? If so, can I add another interface to an
existing instance of the instantiating class?

In summary, I'd love to see the feature, but only if it works
nicely.

John Roth



"Dinu Gherman" <dinu at reportlab.com> wrote in message
news:3b794800.115888839 at news.t-online.de...
> Hi,
>
> given the recent burst of new features in Python I do wonder
> what happend to those that are missing from Python for a
> long while now? I'm listing here only these:
>
>   - interfaces
>   - class methods
>   - type indicators (opt.)
>
> Being aware of the class/type unification announced for
> before Python 3000, I'm not listing this one above.
>
> The first two could be considered quite important for ma-
> king the language more complete in terms of object orien-
> tation. (Better information hiding might be another topic,
> but it seems like this is broadly considered non-Pythonic
> in the Python community.)
>
> I'm just curious if there has been any progress on any of
> these as I'm not following all SIGs that might be dealing
> with them or not, but notice a peak of activites in other
> domains of language development.
>
> Regards,
>
> Dinu
>
>
> --
> Dinu C. Gherman
> dinu at reportlab dot com
> http://www.reportlab.com
> ................................................................
> "The only possible values [for quality] are 'excellent' and 'in-
> sanely excellent', depending on whether lives are at stake or
> not. Otherwise you don't enjoy your work, you don't work well,
> and the project goes down the drain."
>                     (Kent Beck, "Extreme Programming Explained")