7 ms·

> 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 AP

by 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.
  - bunderbunder 14y ago
    I'd be so bold as to make a categorical statement: If your classes are invariably stateful, or if they can reasonably be described with the phrase "lots of layers", then you're doing it wrong. You're not doing object-oriented programming so much as the mongrel "class-oriented programming" style that rose to prominence among C++ programmers in the 1990s. Good well-modularized object-oriented code should not be an alternative to a collection of functions. It should be a technique for making your collections of functions more effective. It allows you to write a smaller, more concise collection of functions that can operate in a consistent manner on a whole plethora of datatypes. It accomplishes this because you can write your functions against a common set of mixins that your datatypes inherit rather than having to worry about specializing them for every datatype.
  - the_mitsuhiko 14y ago
    > 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. Functions hold state as well, they just encapsulate it. You can still break up your algorithm into a class with multiple template methods and then encapsulate it in a function if you're afraid of leaking state elsewhere. What I see instead is that people can't get rid of state and put it as global variables into Python modules. Case in point: pickle. It uses sys.modules and pickle.dispatch_table to store some of its state. > If you don't need to hold state, then a collection of functions will usually suffice. In Python, you can use modules for this. Classes have another advantage: virtual method calls. If one function in a module calls into another function in the module I can only do two things: a) copy/paste the library and change one of the functions or b) a monkeypatch which modifies a shared resource someone else might want to use with the old semantics. A class I can subclass and change the behavior for each method separately.
    - rlpb 14y ago
      > What I see instead is that people can't get rid of state and put it as global variables into Python modules. What I see is people writing classes that hold state in instances for far longer than is needed. Other code written around these classes then need to take this into account. This tends to the same place where global variables are. A tangled mess. > If one function in a module calls into another function in the module I can only do two things... 3) Adjust the function to include the behaviour that you need. In Python, default parameters often mean that you can do this without breaking backwards compatibility. If a function is deficient in some way, why not fix the function rather than working around it?
- loup-vaillant 14y ago
  The question is, what classes do that module systems don't? The answer is generally inheritance, and through it, class polymorphism. With first class function, you hardly need class polymorphism. Just pass the function as argument already, don't bother with writing a whole new class just to override one method. The other use for inheritance is plain code reuse. This is bad most of the time because it promotes thick interfaces, and function calls are great at code reuse anyway.
  - CodeMage 14y ago
    The question is, what classes do that module systems don't? Modules (at least in Python) are singletons.
    - loup-vaillant 14y ago
      Doesn't count. When you define a single data structure in a module, (along with functions to manipulate it) you can instantiate it just like you would a class.
      - CodeMage 14y ago
        Ugh. That's like saying that high-level programming languages "don't count" because you can do that stuff in assembler.
        loup-vaillant 14y ago
        I'm not arguing Turing completeness here. I'm arguing trivial one to one mapping. Syntax sugar. Compare: struct foo { int bar; float baz; }; int get_bar(foo); float get_baz(foo); Which would emulate this: class foo { public: int get_bar(); float get_baz(); private: int bar; float baz; }; If you're interested, I wrote more about that here: http://loup-vaillant.fr/articles/classes-as-syntactic-sugar http://loup-vaillant.fr/articles/classes-as-syntactic-sugar
  - nessus42 14y ago

by rlpb 14y ago

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.
- bunderbunder 14y ago
  I'd be so bold as to make a categorical statement: If your classes are invariably stateful, or if they can reasonably be described with the phrase "lots of layers", then you're doing it wrong. You're not doing object-oriented programming so much as the mongrel "class-oriented programming" style that rose to prominence among C++ programmers in the 1990s. Good well-modularized object-oriented code should not be an alternative to a collection of functions. It should be a technique for making your collections of functions more effective. It allows you to write a smaller, more concise collection of functions that can operate in a consistent manner on a whole plethora of datatypes. It accomplishes this because you can write your functions against a common set of mixins that your datatypes inherit rather than having to worry about specializing them for every datatype.
- the_mitsuhiko 14y ago
  > 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. Functions hold state as well, they just encapsulate it. You can still break up your algorithm into a class with multiple template methods and then encapsulate it in a function if you're afraid of leaking state elsewhere. What I see instead is that people can't get rid of state and put it as global variables into Python modules. Case in point: pickle. It uses sys.modules and pickle.dispatch_table to store some of its state. > If you don't need to hold state, then a collection of functions will usually suffice. In Python, you can use modules for this. Classes have another advantage: virtual method calls. If one function in a module calls into another function in the module I can only do two things: a) copy/paste the library and change one of the functions or b) a monkeypatch which modifies a shared resource someone else might want to use with the old semantics. A class I can subclass and change the behavior for each method separately.
  - rlpb 14y ago
    > What I see instead is that people can't get rid of state and put it as global variables into Python modules. What I see is people writing classes that hold state in instances for far longer than is needed. Other code written around these classes then need to take this into account. This tends to the same place where global variables are. A tangled mess. > If one function in a module calls into another function in the module I can only do two things... 3) Adjust the function to include the behaviour that you need. In Python, default parameters often mean that you can do this without breaking backwards compatibility. If a function is deficient in some way, why not fix the function rather than working around it?
loup-vaillant 14y ago
The question is, what classes do that module systems don't? The answer is generally inheritance, and through it, class polymorphism. With first class function, you hardly need class polymorphism. Just pass the function as argument already, don't bother with writing a whole new class just to override one method. The other use for inheritance is plain code reuse. This is bad most of the time because it promotes thick interfaces, and function calls are great at code reuse anyway.
- CodeMage 14y ago
  The question is, what classes do that module systems don't? Modules (at least in Python) are singletons.
  - loup-vaillant 14y ago
    Doesn't count. When you define a single data structure in a module, (along with functions to manipulate it) you can instantiate it just like you would a class.
    - CodeMage 14y ago
      Ugh. That's like saying that high-level programming languages "don't count" because you can do that stuff in assembler.
      - loup-vaillant 14y ago
        I'm not arguing Turing completeness here. I'm arguing trivial one to one mapping. Syntax sugar. Compare: struct foo { int bar; float baz; }; int get_bar(foo); float get_baz(foo); Which would emulate this: class foo { public: int get_bar(); float get_baz(); private: int bar; float baz; }; If you're interested, I wrote more about that here: http://loup-vaillant.fr/articles/classes-as-syntactic-sugar http://loup-vaillant.fr/articles/classes-as-syntactic-sugar
- nessus42 14y ago