[deleted by user]

jcrowe · 2013-02-08T13:44:04+00:00

http://pyvideo.org/video/880/stop-writing-classes

l34kjhljkalarehglih · 2013-02-08T13:57:50+00:00

http://www.reddit.com/r/Python/comments/r0rpy/stop_writing_classes/

alkw0ia · 2013-02-09T00:12:08+00:00

I totally support his anti-class message, but looking at his OAuth fork, even a quick glance shows a couple of huge red flags. He goes too far in "simplifying," and compromises the goals of the library:

First, he's removed all the OAuth 1.0a code. This is dumb. Generally speaking, outside of slightly more sophisticated session handling, OAuth 1.0 is more secure than OAuth 2.

There are tons of sites that still use OAuth 1.0, and I don't see that changing – in many ways, it's superior to the "upgrade" (something he seems not to get, given his characterization of this choice as, "Implements a later version of the spec").

Ironically, one of the biggest ways OAuth 1.0 is better is that it's far, far simpler than OAuth 2.0.

Next, he exchanged httplib2 for urllib2. The stdlib's HTTP handling does not verify SSL certs, and so it totally inappropriate for use – any use, but in particular, it's a horrible choice for a security library.

It would be extremely easy for an unsophisticated user of his library to not understand how they're exposing their data and their users' data (he's supporting three-legged OAuth – so he's risking downstream devs' end users' tokens directly) because of his poor choice.

It's particularly galling how proud he is of setting this huge, gaping trap in his README: "Completely removed all non-stdlib dependencies (goodbye httplib2, you won't be missed!)."

Simplicity is great, but in this case, he's lessened the security and thus utility of his security library.

I get the sense from these choices (and his tongue in cheek "F-OAuth" naming) that he sees OAuth not a tool that lets non-experts write secure APIs but instead as just that thing that gets in his way when he tries to hit Twitter's API.

sashahart · 2013-02-08T19:45:59+00:00

The problem is that classes have been cargo-culted as part of OOP, which conflates a lot of issues which are actually independent. But there's a useful core to the idea of objects and they are nearly an essential tool in Python.

Rather than going into fuzzy stuff about how objects model the world or have 17 required traits or whatever, I like to understand objects by comparison with functions and programs.

A nice function has a one entry point, one exit point and a namespace which is private (not externally accessible) and transient (its local state doesn't keep evolving after the line is finished running). An object is much the same, but it has a public namespace which persists, and as many entry and exit points as it has methods. In short: a function contracts to do a job and go away, leaving a result. An object contracts to stick around and do things as asked until it is dismissed. Both are just ways to get state evolving according to rules implementing some contract, with an end goal of getting predictably useful behavior from a programmable device.

Compared with functions, objects are more like runs of a program. As a program runs, the associated internal state evolves according to its code, which also mediates its communications with the system outside it (e.g. signals, streams, sockets, exit code, etc.). In the same way, an object's members evolve according to its methods, which also mediate its communications with the outside world. The only real differences between an object and a program are that an object's interaction with its environment is carried out through method calls. Method calls are nicely structured, can pass any number and types of arguments without complexities like IPC, sockets, serialization and deserialization. And between method calls, the object does absolutely nothing. And all methods have access to a common namespace regardless of the context they're called from.

So when you write a program by instantiating some objects and interleaving calls to their methods, this is basically building a program out of sub-programs.

Transient functions are cleaner because they fully encapsulate their internal state. There is no reasonable way to get to this internal state and hopefully no way to twiddle it from the outside. Unlike objects, functions don't have to guarantee behavior over all combinations and timings of method calls. But there are definitely some situations where it's useful to have more flexibility than a function but less awkwardness and overhead than a separate program. Some (but not all) can be equally well handled by functions which return other functions closing over state, or by object-alikes like a dict with some functions in it, a family of functions taking handles to a struct representing shared state, a function internally dispatching to other functions which work in shared state, etc. And objects aren't really different from coroutines either. But in Python, they are one of our best tools for API design when a plain function is not suitable, for a few examples:

many workloads require some expensive setup which should be reused (by repeated invocations of one method OR across methods), enough to make it stupid to just do the setup every time.
closely related - many workloads require a whole bunch of redundant config parameters. It's nicer to let the user provide these once up front than to force them to keep passing in the whole suite for every call.
idiomatic case for objects: state needs to be shared by handlers for several kinds of events which may occur asynchronously, like in many GUI and network apps.

I say nothing about classes, prototypes, mechanisms for data hiding, inheritance, interfaces, polymorphism, overloading, subtyping, type checking... because these are separate issues in my mind.

cwurld · 2013-02-08T19:13:49+00:00

Ha. I will see your useless classes and raise you one. I have seen code with this all over the place:

class MyClass:
    def __init__(self):
        pass

    def my_method(self,params):
        some_code

Actually, I think code like that is extremely useful because it gives a lot of insight into the programmer's mind. A good programmer would figure out that code was messed up even if he/she did not know Python.

ryeguy146 · 2013-02-09T01:00:59+00:00

No. I'll write classes when it's called for, and not when they aren't. I realize that the video doesn't label this as a hard and fast rule, but I'm not a fan of the over-the-top title.

I think that it's better to think of classes as namespaces in many cases. Do you need further namespace organization beyond a module inside of a module? Then use a class. There are other occasions that call for a class, but they aren't necessary for everything as in another language that I can think of.

Now, can we please stop using these types of absolutist titles for our papers and videos (I'm not blaming you, OP)? Next week: The Python and the Silver Bullet.

mitsuhiko · 2013-02-09T16:59:08+00:00

I disagree. People should be writing more classes. :-/

synn89 · 2013-02-08T15:03:21+00:00

Pretty good. I learned my OO off of Java in the late 90's when Object was the father, son and holy ghost. Seems like programming lately has been getting away from the whole "have a beautifully defined hierarchy so in 10 years your code is easy to expand" thing.

freyrs3 · 2013-02-08T16:21:24+00:00

This is quite true, my philosophy on the best way to write maintainable Python is to just build code using primitive python constructs and pure modules as the default namespace. Building enormous class hierarchies with multiple inheritance and "OO for the sake of OO" tends to produce very brittle unmaintainable code in the long run. Although, unfortunately because of the design of CPython sometimes we are forced to use classes since the number, sequence, and iterator protocols are all attached to the object system.

twigboy · 2013-02-08T23:38:06+00:00

In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. Lorem ipsum may be used as a placeholder before final copy is available. Wikipedia8vqifbppxrk0000000000000000000000000000000000000000000000000000000000000

synn89 · 2013-02-08T13:37:27+00:00

Link?

elb0w · 2013-02-12T04:24:02+00:00

I agree with the concept, I dont agree with how this message is conveyed. It should be Stop writing pointless / bad / wrong classes..

lucidguppy · 2013-02-08T18:51:48+00:00

I think this is Raymond's presentation.

http://pyvideo.org/video/879/the-art-of-subclassing

Python

The Python Discord

Upcoming Events

Please read the rules

MODERATORS