

Python Programming for the Privileged Class - skfroi
https://github.com/kuujo/yuppy

======
jmpeax
One of the best type features of Go is the lack of need to do something like
this: "@implements(IEatable)". If a class implements all of the methods of the
interface, then it automatically implements that interface. Yuppy seems like a
step backwards in OO in this regard.

~~~
RHSeeger
Is it possible to indicate, in an interface, that it's not a structural type?
Ie, that classes need to specifically indicate they implement it to be
considered it's type?

For example, the HtmlString interface could require only "toString" as a
method, but not everything that has that method should be considered that
type.

~~~
jmpeax
The idea would be, in this case, to create a method called "toHtmlString". The
name "toString" suggests a generic String is created for the object, but
HtmlString represents a specially formatted String.

Rather than having a class implement HtmlString as a way to specify that its
"toString" method works differently to the usual or expected way for a method
of that signature, you can instead write a "toHtmlString" which is more clear.
Reading code as "myObject.toString()" vs "myObject.toHtmlString()" is better
than having to check the class signature for a special contract pertaining to
general-looking method names.

------
asdfologist
Perhaps this is an unpopular opinion, but I think the Duck typing philosophy
of Python is a feature, not a bug. Imposing the verbosity and rigidity of
Java-style OO onto Python seems like a step backwards to me.

------
siliconc0w
I feel like one of the merits of python is the looseness of classes and
multiple inheritance. You get the benefits of OO without some of the pitfalls.
Sure, you can go through the effort of defining an abstract class but it often
isn't needed since your object is often composed of a bunch of separate
objects - dealing with a formal contract to some 'abstract' version of your
object just adds boilerplate and ends up creating convoluted class
hierarchies.

------
dsymonds
I can't tell whether this is serious or it's a parody. I'm leaning towards the
latter given the title, but it's hard to tell.

~~~
Myrmornis
_but it 's hard to tell_

No, it isn't.

[https://github.com/kuujo/yuppy/blob/master/yuppy/core.py](https://github.com/kuujo/yuppy/blob/master/yuppy/core.py)

[https://github.com/kuujo/yuppy/blob/master/tests.py](https://github.com/kuujo/yuppy/blob/master/tests.py)

What you say is kind of funny, although rather an obvious sort of caustic
witticism. But I think the answer is in fact obvious to you.

~~~
dsymonds
Honestly, it's still hard for me to tell, and those two files don't make it
clearer. It's got tests, which is good and presumably counts for the serious
case, but I've seen similarly excessive testing done for obvious jokes (like
the enterprise Java FizzBuzz parody).

Are you saying it's obvious to you? That's great, but it's not obvious to me.

~~~
Myrmornis
I don't know, there seems something unpleasantly supercilious about taking a
software project that's obviously written to a high standard and saying you
think it's a joke. How do you know the author won't be unhappy to see someone
say that? It kind of seems like classic #shithnsays.

~~~
dsymonds
Have you seen
[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)?
It's a well-known parody, but one could also say it's "obviously written to a
high standard", for some definitions of "standard".

------
woadwarrior01
This is very reminiscent of zope.interface used in Twisted. I wouldn't want to
argue for or against it, but I've had times when something like this might
have been useful in large code bases.

[1]:
[http://docs.zope.org/zope.interface/](http://docs.zope.org/zope.interface/)
[2]:
[http://twistedmatrix.com/documents/14.0.0/core/howto/compone...](http://twistedmatrix.com/documents/14.0.0/core/howto/components.html)

------
Myrmornis
It would be very helpful to add to the README a section explaining what
problems this solves. So examples of conventional python classes exhibiting
weaknesses that are improved by using yuppy features.

------
TTPrograms
I love Python and I love interfaces, so this appeals to me.

~~~
aeflash
But either way, you're going to get a runtime error. Languages like Java or C#
that actually have real interfaces and abstract classes can detect these
problems at compile time. This seems only marginally better.

------
X-Istence
This greatly reminds me of zope.interface!

