This greatly reminds me of zope.interface!
Python Programming for the Privileged Class
11–18 of 18 posts
Re: Python Programming for the Privileged Class
#12It 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.
Re: Python Programming for the Privileged Class
#13I 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.
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/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.
Re: Python Programming for the Privileged Class
#14I 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.
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/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.
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.
Re: Python Programming for the Privileged Class
#15One 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.
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.
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.
Re: Python Programming for the Privileged Class
#16Earlier quoted context omitted.
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/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.
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.
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.
Re: Python Programming for the Privileged Class
#17One 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.
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.
I would definitely prefer jmpeax's answer.
Although, there was a question/discussion similar to this here: https://www.youtube.com/watch?v=u-kkf76TDHE#t=2584
The gist was that, if the interface and the structs that are supposed to satisfy that interface belong to the same package, and then you want to prevent any outsider from implementing that interface, you can actually include an unexported method:
type HtmlStringer interface {
ToString() string
isHtmlStringer()
}
Re: Python Programming for the Privileged Class
#18Earlier quoted context omitted.
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.
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.
Have you seen https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...? It's a well-known parody, but one could also say it's "obviously written to a high standard", for some definitions of "standard".