People need to write better titles. When someone wrote "stop writing classes" the talk exactly when to write them. When you have an object with two methods and one of them is init. This whole discussion is absolutely wonderful and is what is great about the python community. Write classes when they facilitate code reuse - don't write taxonomies for the sake of it.
Write More Classes
81–90 of 150 posts
Re: Write More Classes
#82Earlier quoted context omitted.
It is perfectly acceptable to design a library with a simplified, restricted interface that covers the majority of use cases, but not all. e.g. requests vs urllib2 For me, that's a win for common sense. I have never even considered streaming JSON. The lack of streaming support should be a clue that the OP needs to look at whether what he's attempting is even sensible or could be better served by a different transport…
JSON supports streaming. You not having considered it is not an argument.
Firstly:
http://www.ietf.org/rfc/rfc4627.txt
"An implementation may set limits on the size of texts that it accepts. " - How does that "support" streaming?
My argument is that most people don't need it most of the time (I can't prove this). It's also NOT a protocol designed for streaming. As regards API design, it's a matter of taste but my preference and that of many others who use python, as we can see with the popularity of requests, Flask, is that an API should be designed for simplicity for the common use cases rather than for absolute completeness. I'm not saying don't expose a low-level API full of BufferedReaders, JSONParserCursors, but don't force it on me to parse a tiny JSON document of known length.
Re: Write More Classes
#83Write no classes! Joe Armstrong: "I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle . If you have referentially transparent code, if you have pure func…
Two points:
1. When OO was on the brink of becoming mainstream, let's say early 90's, there was an awful lot of the most idiotic rubbish talked about reusability. For example I recall one magazine article that, with a completely straight face, told readers that you would be able to buy an "Aeroplane" class that you could slot into pretty much any application that dealt with aeroplanes. So Joe has a point here.
2. This is not an argument for not using classes within a single codebase. And indeed when I see Erlang functions pushing all the relevant state around as parameters in a big mess of tuples and lists like a crazy baglady with all her possessions in a shopping cart, the benefits of encapsulating it all become clear.
Re: Write More Classes
#84I think the real point the author is trying to make is: use modular, layered designs of composable components, instead of monolithic APIs that only have a single entry point. The single-entry-point model imposes costs and decisions onto the application that are hard to work around. I think this is a good point. I think that it's hard to get from there to "more classes are always better" though. More classes don't alw…
Quoting from the end of the article: "And our solution to monolithic code in Python are classes." So, I guess the question I ask as someone who doesn't write a ton of python code is: Is that true? And if so, why? Is it not possible to compose a layered API that doesn't rely on inheritance / classes in Python?
You can do pretty much anything with default arguments, rather than overridable class methods. First class functions make this very flexible.
Sometimes this is a little inconvenient. I think the sign you really need a class is when you are sending in something called "object_type", and a dict of "object_type -> function".
Re: Write More Classes
#85Earlier quoted context omitted.
When you are trying to parse extremely large documents or you only care about a small subset of a document, needing to load the entire parsed file into memory is problematic. Simplejson doesn't provide an API that allows for any other option. This is in contrast to something like an XML sax parser, that allows you to register for events like "a foobar element was loaded". You get the foobar element while all the othe…
> The complaint is that, somewhere, under the hood, simplejson is doing that token parsing, but because of their API, a user can't plug into it. I read it exactly the other way around: simplejson skips an internal tokenization step, so even if you fork the library it is pretty much impossible to make it streaming, because there's no token stream to handle stream state.
That's more or less right, masklinn. To the above writers, look at the Python source (I can't vouch for how the C implementation does things). It's not beautiful, but it's also not hard to understand.
The effective work is all done inside a big function. To customize it, you'd have to split that function into pieces and then glue it back together using a class or your own function coordinating the parts.
Re: Write More Classes
#86The Java would have been prettier if he had used the new try-with-resources from Java 7.
Re: Write More Classes
#87Earlier quoted context omitted.
JSON supports streaming. You not having considered it is not an argument.
Firstly: http://www.ietf.org/rfc/rfc4627.txt "An implementation may set limits on the size of texts that it accepts. " - How does that "support" streaming? My argument is that most people don't need it most of the time (I can't prove this). It's also NOT a protocol designed for streaming. As regards API design, it's a matter of taste but my preference and that of many others who use python, as we can see with the pop…
The protocol can support streaming very well. How easy it is or if it's possible at all is an implementation issue.
With the Go standard library's json implementation, for example, you can decode JSON streams very easily: http://golang.org/pkg/encoding/json/#example_Decoder
Re: Write More Classes
#88IMO, the Flask example is pushing it - considering how large a job rendering a template is, the number of customization points is probably appropriate, but at some point you're going to get lost in a rabbit hole of wrapper functions that call wrapper functions and end up with three equally appropriate levels you might hook into because the code was written to keep you from having to duplicate a single line of code fr…
> IMO, the Flask example is pushing it - considering how large a job rendering a template is, the number of customization points is probably appropriate, but at some point you're going to get lost in a rabbit hole of wrapper functions that call wrapper functions
The actual implementations do a bit more. I have pretty much overriden every single part of that at one point, if for no other reason than debugging. Some of those hooks were added later because people requested them.
Re: Write More Classes
#89I think the original video this is a response to, was really just saying 'A class should not be one method, that's a function'
Re: Write More Classes
#90Earlier quoted context omitted.
Extensive experience? About Java: "I tried Java" About C++: "I saw C++ coming and read the book - or at least tried to read the book - there's a dent in the wall behind my piano, where the book hit the wall" About Smalltalk: "I learnt (with various degrees of proficiency) [...] smalltalk [...] and became proficient in Prolog (aggghhh - the beauty ....)" About the others: " I also (later) tried Python (ok), Ruby (ok)"…
So you are saying that you are a better language expert, and know better than him?
Why can't he say that?
Several people in HN should know more about OO than Armstrong.
There are academics that have taught and worked for decades on OO systems and concepts among the crowd, unlike Joe.
In general, popular language creators are hardly the more knowledgable of the various PL concepts and issues. Simon Peyton Jones probably knows hundred times more about such stuff than Matz or Guido do, for example.