6 ms·

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

by bhntr3 14y ago

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?

dbaupp 14y ago
One can write Python in a procedural manner, and even in a functional way, so one can use the same techniques as are used in those paradigms (OO is probably more natural for Python though).
- w0utert 14y ago
  You can also easily write component-based architectures in Python, for example using zope.interface/zope.component (ie: the modules only, not the full Zope CMS). For example the Trac bug tracker/wiki works like this, and for its purpose I think it's a perfect fit. It allows re-usable and pluggable components with declared, adaptable interfaces that are not restricted by some hierarchical taxonomy the framework designer came up with. At the end of the day there will always be different ways to build layered architectures using re-usable components, and classes are just one of them. I'm pretty sure the author of the article didn't intend it like that, but 'write more classes' doesn't sound like great advice for novice/inexperienced programmers.
firlefans 14y ago
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 protocol with built in streaming support.
- neeee 14y ago
  JSON supports streaming. You not having considered it is not an argument.
  - firlefans 14y ago
    Firstly: http://www.ietf.org/rfc/rfc4627.txt 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.
    - neeee 14y ago
      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 http://golang.org/pkg/encoding/json/#example_Decoder
deleted 14y ago
[deleted]
rlpb 14y ago
> So, I guess the question I ask as someone who doesn't write a ton of python code is: Is that true? I don't think it is. His objections to the json library API can be addressed without introducing a single class. He seems to want access to the internal implementation of converting bytes into a single Python object. That is probably just an internal function that can just be exposed. If he wants to override it from the top level, the library could permit that by just adding the function as a default parameter. He wants it to deal with streaming. Python generators can help with this. The library could be refactored into implementing a json.load_stream function instead, which takes a string generator and returns some kind of object stream generator. The original json.loads function could be replaced with a wrapper around it for backwards compatibility and for API users who don't want the additional complexity. None of this involves writing classes. A generator could be seen as a type of class instance, and one can implement a generator with classes, but generators have a well known and simple API which eliminates the need to define a new API, as the traditional writing of classes would do. It seems to me that the writer has little experience of not using classes, so wants to solve every problem he has with a class. The API problems he want to address are genuine, but he's blind to any solution that doesn't use classes.
- the_mitsuhiko 14y ago
  > It seems to me that the writer has little experience of not using classes, so wants to solve every problem he has with a class. That's a bold statement. Where is the trend to forcefully avoid classes here coming from? Classes are a perfectly valid tool in Python to solve problems. Someone sent me a mail this morning proposing a dictionary with callback functions in addition to a function as if that would solve anything.
  - rlpb 14y ago
    > Where is the trend to forcefully avoid classes here coming from? See the "Stop Writing Classes" video. Classes hold state. More state adds more complexity, and typical OO design add lots of layers of indirection which also add complexity. Most of the time, you don't need the flexibility that the extra indirection gives you. So you get complexity for little benefit. If you don't need to hold state, then a collection of functions will usually suffice. In Python, you can use modules for this. By all means use classes if they are the best way to solve a problem. But for those who know nothing else, how do they even know this? My problem with this article is that it says "I have a problem; I can solve it with classes; therefore everyone should use classes more". It fails to even consider anything else.
nnq 14y ago
...indeed, the one thing I "hate" about Python is that somehow it pushes your mind away from functional solutions. You end up writing either OO or procedural code, although in a language with first class functions and immutable strings you's expect to slip more to the functional side. Anyone else had the feeling that although Python allows functional style, it somehow pushes your mind away from it?
- vaughan0 14y ago
  Personally I find myself avoiding writing in a functional style in Python because of it's lack of good anonymous function literals and poor handling of closures in nested functions. Edit: when I say "poor handling of closures in nested functions" I'm referring to having to use nonlocal in order to modify variables in the parent function's scope.
  - nnq 14y ago
    yeah, I think lack of real anonymous functions is a small annoyance that can get quite "big" from the yucky feeling you get when defining functions just to pass them on. But... what do you mean by "poor handling of closures in nested functions"? Edit: ok, I get what you mean now :) ...though I consider this "poor handling" a feature of Python - mutating outer scope variables is a side-effect and what it encourages is what I like to call "callback hell functions with data Javascript-style nightmare" :) (true, some people know to keep their sanity and write readable code even in this style, and if you enjoy it you're probably one of them few, but most don't...). By "functional style", I and some people refer to "functional as in mathematical functions", so only using side-effects when actually needed (yeah, some "extremist" languages like Haskell try to never do them, but...) and you get this by having immutable values and passing around anonymous functions (that don't modify their outer scope). ...and this is another part of the paradox: this "feature" of Python should encourage what I call functional style, but why oh why it doesn't? ...maybe Rich Hickey is on to something with Clojure and it's actually more about the data-structures than the language syntax or semantics?
- betterunix 14y ago
  Well it does not really help that Python lacks tail call elimination (last I checked), which is fairly important to (practical) functional programming.
wisty 14y ago
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".

by bhntr3 14y ago

dbaupp 14y ago

One can write Python in a procedural manner, and even in a functional way, so one can use the same techniques as are used in those paradigms (OO is probably more natural for Python though).

w0utert 14y ago
You can also easily write component-based architectures in Python, for example using zope.interface/zope.component (ie: the modules only, not the full Zope CMS). For example the Trac bug tracker/wiki works like this, and for its purpose I think it's a perfect fit. It allows re-usable and pluggable components with declared, adaptable interfaces that are not restricted by some hierarchical taxonomy the framework designer came up with. At the end of the day there will always be different ways to build layered architectures using re-usable components, and classes are just one of them. I'm pretty sure the author of the article didn't intend it like that, but 'write more classes' doesn't sound like great advice for novice/inexperienced programmers.

firlefans 14y ago

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 protocol with built in streaming support.

neeee 14y ago
JSON supports streaming. You not having considered it is not an argument.
- firlefans 14y ago
  Firstly: http://www.ietf.org/rfc/rfc4627.txt 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.
  - neeee 14y ago
    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 http://golang.org/pkg/encoding/json/#example_Decoder

deleted 14y ago

[deleted]

rlpb 14y ago

> So, I guess the question I ask as someone who doesn't write a ton of python code is: Is that true? I don't think it is. His objections to the json library API can be addressed without introducing a single class. He seems to want access to the internal implementation of converting bytes into a single Python object. That is probably just an internal function that can just be exposed. If he wants to override it from the top level, the library could permit that by just adding the function as a default parameter. He wants it to deal with streaming. Python generators can help with this. The library could be refactored into implementing a json.load_stream function instead, which takes a string generator and returns some kind of object stream generator. The original json.loads function could be replaced with a wrapper around it for backwards compatibility and for API users who don't want the additional complexity. None of this involves writing classes. A generator could be seen as a type of class instance, and one can implement a generator with classes, but generators have a well known and simple API which eliminates the need to define a new API, as the traditional writing of classes would do. It seems to me that the writer has little experience of not using classes, so wants to solve every problem he has with a class. The API problems he want to address are genuine, but he's blind to any solution that doesn't use classes.

the_mitsuhiko 14y ago
> It seems to me that the writer has little experience of not using classes, so wants to solve every problem he has with a class. That's a bold statement. Where is the trend to forcefully avoid classes here coming from? Classes are a perfectly valid tool in Python to solve problems. Someone sent me a mail this morning proposing a dictionary with callback functions in addition to a function as if that would solve anything.
- rlpb 14y ago
  > Where is the trend to forcefully avoid classes here coming from? See the "Stop Writing Classes" video. Classes hold state. More state adds more complexity, and typical OO design add lots of layers of indirection which also add complexity. Most of the time, you don't need the flexibility that the extra indirection gives you. So you get complexity for little benefit. If you don't need to hold state, then a collection of functions will usually suffice. In Python, you can use modules for this. By all means use classes if they are the best way to solve a problem. But for those who know nothing else, how do they even know this? My problem with this article is that it says "I have a problem; I can solve it with classes; therefore everyone should use classes more". It fails to even consider anything else.

nnq 14y ago

...indeed, the one thing I "hate" about Python is that somehow it pushes your mind away from functional solutions. You end up writing either OO or procedural code, although in a language with first class functions and immutable strings you's expect to slip more to the functional side. Anyone else had the feeling that although Python allows functional style, it somehow pushes your mind away from it?

vaughan0 14y ago
Personally I find myself avoiding writing in a functional style in Python because of it's lack of good anonymous function literals and poor handling of closures in nested functions. Edit: when I say "poor handling of closures in nested functions" I'm referring to having to use nonlocal in order to modify variables in the parent function's scope.
- nnq 14y ago
  yeah, I think lack of real anonymous functions is a small annoyance that can get quite "big" from the yucky feeling you get when defining functions just to pass them on. But... what do you mean by "poor handling of closures in nested functions"? Edit: ok, I get what you mean now :) ...though I consider this "poor handling" a feature of Python - mutating outer scope variables is a side-effect and what it encourages is what I like to call "callback hell functions with data Javascript-style nightmare" :) (true, some people know to keep their sanity and write readable code even in this style, and if you enjoy it you're probably one of them few, but most don't...). By "functional style", I and some people refer to "functional as in mathematical functions", so only using side-effects when actually needed (yeah, some "extremist" languages like Haskell try to never do them, but...) and you get this by having immutable values and passing around anonymous functions (that don't modify their outer scope). ...and this is another part of the paradox: this "feature" of Python should encourage what I call functional style, but why oh why it doesn't? ...maybe Rich Hickey is on to something with Clojure and it's actually more about the data-structures than the language syntax or semantics?
betterunix 14y ago
Well it does not really help that Python lacks tail call elimination (last I checked), which is fairly important to (practical) functional programming.

wisty 14y ago

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".