Introduction to Object Oriented Programming in Python(stackabuse.com)
stackabuse.com
Introduction to Object Oriented Programming in Python
https://stackabuse.com/introduction-to-object-oriented-programming-in-python/
35 comments
How about {list|dict|set} comprehensions? I don't know if they are considered part of functional programming (and the definition of FP seems to be somewhat loose anyway, AFAICT - correct me if I'm wrong, anyone), but they can be nice to use. They can even be nested (never gone beyond 2 levels myself) and if/else clauses can be in them too. E.g.:
>>> def odd(n): return n % 2 == 1
...
>>> [ i if odd(i) else -i for i in range(1, 11) ]
[1, -2, 3, -4, 5, -6, 7, -8, 9, -10]
>>> def odd(n): return n % 2 == 1
...
>>> [ i if odd(i) else -i for i in range(1, 11) ]
[1, -2, 3, -4, 5, -6, 7, -8, 9, -10]
Comprehensions are a key part of functional programming in Python. Python lambdas are fairly awkward to use. Comprehensions provide a better syntax for transforming data in many cases.
Yes, lambas don't allow statements in them, only an expression.
In [8]: f = lambda x: x * 2
In [9]: f(2)
Out[9]: 4
In [10]: g = lambda x: if x % 2 == 0: x * 2 else x * 3
In [8]: f = lambda x: x * 2
In [9]: f(2)
Out[9]: 4
In [10]: g = lambda x: if x % 2 == 0: x * 2 else x * 3
File "<ipython-input-10-f7248669b8fd>", line 1
g = lambda x: if x % 2 == 0: x * 2 else x * 3
^Can you point to any good tutorials for replacing OOP with functional patterns in Python? I often use OOP to semantically group functionality and "manage" state e.g. avoiding methods with multiple variables or cases where I have to pass one (not changing) variable to multiple functions.
Sounds like you discovered that OOP and Functional are the same thing. Closures are the poor-person's objects. Objects are the poor person's Closures. If you never mutate the internals of an Object, or mutate with copy, isn't just a coherent closure?
Checkout http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent
Checkout http://wiki.c2.com/?ClosuresAndObjectsAreEquivalent
If they are the same thing, why does the parent commenter prefer Functional?
Personal choice. Some people like the idea of splitting the data from the functions that operate on it. Others don't like mutability and presume that OOP requires it. Scala and other languages make it easy to have immutability and OOP. Look at Clojure. The interfaces look a lot like Object definitions.
Would you mind sharing some code (or tutorials)? I'm intrigued!
Why not just use Haskell? Python has OOP baked into the language. Also, your responding to an article on introducing OOP with how not to use OOP, which seems tangental and deserving of it's own thread.
+1. When GP leaves a job and a "Python Programmer" is hired to replace him/her, their life will be hell. At that point one can only hope that GPs next gig is at a Haskell shop where every single function returns an IO action :)
In my experience what matters is the quality of the code regardless of the paradigm used. A well written piece of functional Python with comments and documentation will be much easier to understand than poorly written OOP.
FP is also quite idiomatic. Pythons list comprehensions are quite powerful, and the libraries I mentioned in my previous comment are all part of the standard library. There are third party libraries that attempt to make Python even more functional.
FP is also quite idiomatic. Pythons list comprehensions are quite powerful, and the libraries I mentioned in my previous comment are all part of the standard library. There are third party libraries that attempt to make Python even more functional.
Well written code is obviously better than badly written code. But why assume the functional-style is better written than the idiomatic Python? I think a good developer understand the context they work in rather than try to fit a square peg in a round hole.
I wouldn't like to maintain Haskell code written by someone who thinks everything should look like Python. And vice-versa.
I wouldn't like to maintain Haskell code written by someone who thinks everything should look like Python. And vice-versa.
Python code doesn't have to be OOP to be idiomatic. That said, functional code that uses lambdas, map, etc. is generally not idiomatic Python. I've seen a lot get done just with functions, list comprehensions, and Python-specific magic without using OOP, though. Guess that's mostly just imperative on steroids, though.
> square peg in a round hole
Python is a multi-paradigm language. I have not found Python to be better at OOP versus imperative or functional styles of programming.
For me, functional programming provides a closer to model to how I think about problems. This is true for many people. One should choose the style that provides the easiest translation of thought to code.
Python is a multi-paradigm language. I have not found Python to be better at OOP versus imperative or functional styles of programming.
For me, functional programming provides a closer to model to how I think about problems. This is true for many people. One should choose the style that provides the easiest translation of thought to code.
If you only write code which you yourself will read and maintain, then you should definitely do whatever you feel works best for you and matches your way of thinking.
Python's lambda is very intentionally limited precisely to steer people away from overly functional code. Don't write Haskell in Python, and equally don't write Java in Python.
I’m currently working on a large C++ project... which has layers and layers of indirections...
It’s so hard to even check where the actual implementation is....
There are no comments in code, no documentation whatsoever...
It’s so hard to even check where the actual implementation is....
There are no comments in code, no documentation whatsoever...
Using a programming language idiomatically is better than using it to match one's preferred paradigm. If the paradigm is more important, then use the right tool for the job. My understanding is that Guido and the community never intended Python to be a functional PL.
IMHO, Python has enough functional goodies to accomplish a lot with just functions and provided datastructures. I only use OOP as a technique to address specific issues, rather than treat it as something fundamental as writing functions.
As a Python developer, I'd much rather maintain a system written in a functional style, over one written in a Java-like OO style.
Refential transparency and simple data structures makes code much simpler to understand, and leads to fewer surprises when the code is being modified.
Refential transparency and simple data structures makes code much simpler to understand, and leads to fewer surprises when the code is being modified.
Python is one of the most popular languages in the world, it’s quite common to encounter it when you join a new buisness. It’s also the language many people learn to program with (I did).
Anyone who learns Python will necessarily learn OOP as it’s the de facto style. The post is a resource for that. My comment is meant to encourage people to consider the alternative ways you can approach problems in Python.
Anyone who learns Python will necessarily learn OOP as it’s the de facto style. The post is a resource for that. My comment is meant to encourage people to consider the alternative ways you can approach problems in Python.
In python, everything is an object ;)
You can't write python 'without OOP'. Almost everything you do requires instantiating some class, or called a method on a class. Unless you write everything globally with no mutation.
You can write python in a functional style, but you're still going to use OOP constructs.
You can write python in a functional style, but you're still going to use OOP constructs.
We’re talking about style here, not the technicality of whether something is implemented as an object or not.
I wonder how you manage to do such a feat, given that all Python data types are objects.
> from inspect import type
> type([])
=> <class 'list'>
> type(lambda x : x)
=> <class 'function'>
> type(1)
=> <class 'int'>
> type([x * x for x in [1,2,3]])
=> <class 'list'>
> type((x * x for x in [1,2,3]))
=> <class 'generator'>
> ...We’re talking about style here, not the technical details of the implementation.
[deleted]
Can you guys please share tutorials you like for getting started with functional programming in Python?
> Object-Oriented Programming (OOP) is a programming paradigm where different components of a computer program are modeled after real-world objects.
This is a common, but dangerous way to introduce the object-oriented paradigm. While it is true that many object-oriented systems end up having a few classes that represent entities of its problem domain (such as, perhaps, bus stations in a public transport app), most of them do not. These other classes are abstract entities like data repositories, factories, controllers etc. that are meant to split software into understandable pieces with clear responsibilities that work together to make things happen.
The point is that this collaboration happens solely by these pieces sending each other messages (calling methods) that describe their intent, without needing to know how exactly the message is being processed. This style of communication is the key characteristic of object orientation, and even an introduction should probably put their focus on this aspect rather than „modeling the real world“, which isn‘t really something that is done this way in practice.
All this being said, I do see the appeal of the real-world rhetoric in that it seems much more approachable than ralking about little communicating abstract things. I wonder how to balance this.
This is a common, but dangerous way to introduce the object-oriented paradigm. While it is true that many object-oriented systems end up having a few classes that represent entities of its problem domain (such as, perhaps, bus stations in a public transport app), most of them do not. These other classes are abstract entities like data repositories, factories, controllers etc. that are meant to split software into understandable pieces with clear responsibilities that work together to make things happen.
The point is that this collaboration happens solely by these pieces sending each other messages (calling methods) that describe their intent, without needing to know how exactly the message is being processed. This style of communication is the key characteristic of object orientation, and even an introduction should probably put their focus on this aspect rather than „modeling the real world“, which isn‘t really something that is done this way in practice.
All this being said, I do see the appeal of the real-world rhetoric in that it seems much more approachable than ralking about little communicating abstract things. I wonder how to balance this.
I believe it started as a way to model real-world object. Simula was designed for simulations. But OO turned out to be useful for much more. The simulation use case mostly live on in tutorial and examples, spreading confusion to beginners.
But I also think the "message passing" metaphor has outlived its usefulness the same way. A caller does not need to know how the callee is implemented. Sure, but this is the same in any language with functions/procedure, this is not something specific for OO. The idea of message passing is a bit deeper, for example that the client does not even know it is calling a method. It sends a message, and the object answers, even if it is just by throwing an error that the message is not supported. This is how Smalltalk and (I think) Ruby works, but not at all how a statically types language like C# works. And it is not how Python works either. In Python you obtain a method reference from an object and then invoke it. So if you apply the message passing metaphor, your are actually passing the message to the method rather than the object itself. Which I think is just a confusing way to describe a method call.
But I also think the "message passing" metaphor has outlived its usefulness the same way. A caller does not need to know how the callee is implemented. Sure, but this is the same in any language with functions/procedure, this is not something specific for OO. The idea of message passing is a bit deeper, for example that the client does not even know it is calling a method. It sends a message, and the object answers, even if it is just by throwing an error that the message is not supported. This is how Smalltalk and (I think) Ruby works, but not at all how a statically types language like C# works. And it is not how Python works either. In Python you obtain a method reference from an object and then invoke it. So if you apply the message passing metaphor, your are actually passing the message to the method rather than the object itself. Which I think is just a confusing way to describe a method call.
I can approach writing Python essentially the same way I’d write Haskell using the above strategy. I think it looks really nice.
I’ve turned a few people away from the dark path of OOP by writing in this style as well. They’re usually turned when they see how easy it is to test just regular functions with no need for magic mocks and the like.