4 ms·

> Many Python users rarely create classes. Creating classes isn’t an essential part of Python, though many types of programming require it. Huh. Okay.

jackbrookes 7y ago
Data scientists for example.
- chasedehan 7y ago
  Huh? Every data scientist I have worked with who writes production code uses classes.
emddudley 7y ago
It's really true. You can do a lot with data objects (dicts, lists) and stateless functions.
- civility 7y ago
  Rich Hickey has some nice talks about why separating the data from the methods is really beneficial.
  - corysama 7y ago
    There’s a great Python talk out there titled “Stop writing classes”. It has several great demonstrations of Python code getting shorter, simpler and faster by converting code to just use the built-in containers.
    - aaronchall 7y ago
      I did like that talk very much - and here was my response: > The Python Datamodel: When and how to write objects - https://www.youtube.com/watch?v=iGfggZqXmB0 https://www.youtube.com/watch?v=iGfggZqXmB0
civility 7y ago
Which part are you reacting to? I can't speak for "many" users, but all three parts you quoted apply to my usage of Python.
coldtea 7y ago
OK what? Both statements are objectively true.
analog31 7y ago
I spent many years with Visual Basic before learning Python. Some of the earlier versions of VB were object based, meaning that you could use pre-written objects (standard and third party), but you had to buy a special kit to create your own objects. This was quite useful for those of us who were bewildered by OOP. When I learned Python, I was comfortable enough with using objects, that I had no problem creating classes. So I think it's fair to say that creating classes is something that beginning Python programmers can put off. Since I introduced Python to my workplace, I get to watch some fairly neophyte programmers develop their skills. These are typically engineers doing scientific programming, not commercial software developers. There's a point where I get to say: "You could put that stuff in a class." And later on, "You're creating too many classes." ;-)
pfranz 7y ago
It totally depends on the kind of work you're doing. My first few years with Python I never defined a class. I (and imagine most people) were working on code get from a to b. There's a lot of that kind of work to be had. Only later when I started writing modules and libraries did I need to.
- dTal 7y ago
  I also spent years writing Python scripts without a single class. I didn't really understand the point of objects at all. I used them because they were part of library interfaces, but I never created them. The scripts didn't have to manage much state, so writing everything in a pure-functional style worked fine. Nobody could really explain to me what objects were all about - all the arguments seemed to apply equally to functional programming ("re-use", "encapsulation" etc). Then I had to write a piece of software that heavily interacted with various bits of physical hardware, each with masses of state (serial communication and so forth). Suddenly the need for isolating state became terribly obvious. After seeing how some libraries did it, I wrote a class for every bit of hardware that abstracted the state away and provided a functional interface. It all worked terribly well, and it was a real lightbulb moment for me.
  - grepgeek 7y ago
    You could have still kept the massive state in a dict or a list or a tuple and passed that dict around from one function to another, could you not? Why did it become necessary to implement classes?
    - hhjkjhkjhhlkj 7y ago
      I agree. To be sure classes have a place and can be really useful, but so many people just create classes when they add no benefits. Clear code always wins imho
    - dTal 7y ago
      Because I don't want to "pass around" the state - I want to hide it. Yes, of course it's possible to mingle the state in all the rest of the program, just like it's possible to scatter gotos everywhere instead of using structured control flow. But what I really want is to call EnablePowerSupply(), rapidly followed by SetVoltage(30), and have all the messy business of statefully talking over a serial port (and not having commands stomp on each other) neatly abstracted away. EnablePowerSupply and SetVoltage need to share state to do that. That could indeed be done by passing an extra parameter - EnablePowerSupply(blobOfState) and SetVoltage(blobOfState, 30) - but that's basically exactly what objects are syntactic sugar for in Python. Only blobOfState is more usually called "self". Oh, and of course there's not one, but half a dozen power supplies. You could pass around the blobs of state seperately of course, but now you have to manage their scope independently from the functions that operate on them - a useless decoupling that adds overhead. What I ended up with was something like: [psu.enable() for psu in psus] Which you can always do, whenever psus is within scope. Hard to get terser and more idiomatic than that.
rat87 7y ago
while python is object oriented in the sense that everything is an object it doesn't insist of doing everything via message passing. It's quite happy with basic data types and simple functions (plus decorators and context managers)

jackbrookes 7y ago

Data scientists for example.

chasedehan 7y ago
Huh? Every data scientist I have worked with who writes production code uses classes.

emddudley 7y ago

It's really true. You can do a lot with data objects (dicts, lists) and stateless functions.

civility 7y ago
Rich Hickey has some nice talks about why separating the data from the methods is really beneficial.
- corysama 7y ago
  There’s a great Python talk out there titled “Stop writing classes”. It has several great demonstrations of Python code getting shorter, simpler and faster by converting code to just use the built-in containers.
  - aaronchall 7y ago
    I did like that talk very much - and here was my response: > The Python Datamodel: When and how to write objects - https://www.youtube.com/watch?v=iGfggZqXmB0 https://www.youtube.com/watch?v=iGfggZqXmB0

civility 7y ago

Which part are you reacting to? I can't speak for "many" users, but all three parts you quoted apply to my usage of Python.

coldtea 7y ago

OK what? Both statements are objectively true.

analog31 7y ago

I spent many years with Visual Basic before learning Python. Some of the earlier versions of VB were object based, meaning that you could use pre-written objects (standard and third party), but you had to buy a special kit to create your own objects. This was quite useful for those of us who were bewildered by OOP. When I learned Python, I was comfortable enough with using objects, that I had no problem creating classes. So I think it's fair to say that creating classes is something that beginning Python programmers can put off. Since I introduced Python to my workplace, I get to watch some fairly neophyte programmers develop their skills. These are typically engineers doing scientific programming, not commercial software developers. There's a point where I get to say: "You could put that stuff in a class." And later on, "You're creating too many classes." ;-)

pfranz 7y ago

It totally depends on the kind of work you're doing. My first few years with Python I never defined a class. I (and imagine most people) were working on code get from a to b. There's a lot of that kind of work to be had. Only later when I started writing modules and libraries did I need to.

dTal 7y ago
I also spent years writing Python scripts without a single class. I didn't really understand the point of objects at all. I used them because they were part of library interfaces, but I never created them. The scripts didn't have to manage much state, so writing everything in a pure-functional style worked fine. Nobody could really explain to me what objects were all about - all the arguments seemed to apply equally to functional programming ("re-use", "encapsulation" etc). Then I had to write a piece of software that heavily interacted with various bits of physical hardware, each with masses of state (serial communication and so forth). Suddenly the need for isolating state became terribly obvious. After seeing how some libraries did it, I wrote a class for every bit of hardware that abstracted the state away and provided a functional interface. It all worked terribly well, and it was a real lightbulb moment for me.
- grepgeek 7y ago
  You could have still kept the massive state in a dict or a list or a tuple and passed that dict around from one function to another, could you not? Why did it become necessary to implement classes?
  - hhjkjhkjhhlkj 7y ago
    I agree. To be sure classes have a place and can be really useful, but so many people just create classes when they add no benefits. Clear code always wins imho
  - dTal 7y ago
    Because I don't want to "pass around" the state - I want to hide it. Yes, of course it's possible to mingle the state in all the rest of the program, just like it's possible to scatter gotos everywhere instead of using structured control flow. But what I really want is to call EnablePowerSupply(), rapidly followed by SetVoltage(30), and have all the messy business of statefully talking over a serial port (and not having commands stomp on each other) neatly abstracted away. EnablePowerSupply and SetVoltage need to share state to do that. That could indeed be done by passing an extra parameter - EnablePowerSupply(blobOfState) and SetVoltage(blobOfState, 30) - but that's basically exactly what objects are syntactic sugar for in Python. Only blobOfState is more usually called "self". Oh, and of course there's not one, but half a dozen power supplies. You could pass around the blobs of state seperately of course, but now you have to manage their scope independently from the functions that operate on them - a useless decoupling that adds overhead. What I ended up with was something like: [psu.enable() for psu in psus] Which you can always do, whenever psus is within scope. Hard to get terser and more idiomatic than that.

rat87 7y ago

while python is object oriented in the sense that everything is an object it doesn't insist of doing everything via message passing. It's quite happy with basic data types and simple functions (plus decorators and context managers)