Chaining function calls in main. Is it “Pythonic”? [closed]
Lately, some of my code has led me to a question about using outputs of functions as variables, then to use those same variables as parameters in other functions. All when defining main. I believe this can lead to errors when debugging and confusion when using a file as a module.
An example is below:
def add_two_numbers(x, y):
z = x + y
return z
def now_divide_two(z, s):
t = z / s
return t
First method:
def main():
added = add_two_numbers(5, 10)
final_output = now_divide_two(added, 3)
print(final_output)
Second method:
def main():
final_output = now_divide_two(add_two_numbers(5,10), 3)
print(final_output)
Style guides and good practice suggest the first method is superior to the second. Yet, I still feel that they are both "unpythonic". With that, let's assume functions become more complicated, but still require the principle of using each others outputs as the next one's parameters. What is the recommended methodology for running functions in main?
python
closed as primarily opinion-based by wwii, Mad Physicist, Stedy, Tomasz Mularczyk, EdChum Jan 1 at 13:51
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
Lately, some of my code has led me to a question about using outputs of functions as variables, then to use those same variables as parameters in other functions. All when defining main. I believe this can lead to errors when debugging and confusion when using a file as a module.
An example is below:
def add_two_numbers(x, y):
z = x + y
return z
def now_divide_two(z, s):
t = z / s
return t
First method:
def main():
added = add_two_numbers(5, 10)
final_output = now_divide_two(added, 3)
print(final_output)
Second method:
def main():
final_output = now_divide_two(add_two_numbers(5,10), 3)
print(final_output)
Style guides and good practice suggest the first method is superior to the second. Yet, I still feel that they are both "unpythonic". With that, let's assume functions become more complicated, but still require the principle of using each others outputs as the next one's parameters. What is the recommended methodology for running functions in main?
python
closed as primarily opinion-based by wwii, Mad Physicist, Stedy, Tomasz Mularczyk, EdChum Jan 1 at 13:51
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
3
Which style guide?
– juanpa.arrivillaga
Dec 31 '18 at 21:15
1
"All when defining main" Note, "main" doesn't have any special status in Python.
– juanpa.arrivillaga
Dec 31 '18 at 21:19
1
What this has to do withmain()
anyway? Usuallymain
is just for parsing command line arguments and setting up logging. First way is preferable regardless, just clearer to read and easier to step through in debuggers.
– wim
Dec 31 '18 at 21:20
Which do you like better?
– wwii
Dec 31 '18 at 21:20
add a comment |
Lately, some of my code has led me to a question about using outputs of functions as variables, then to use those same variables as parameters in other functions. All when defining main. I believe this can lead to errors when debugging and confusion when using a file as a module.
An example is below:
def add_two_numbers(x, y):
z = x + y
return z
def now_divide_two(z, s):
t = z / s
return t
First method:
def main():
added = add_two_numbers(5, 10)
final_output = now_divide_two(added, 3)
print(final_output)
Second method:
def main():
final_output = now_divide_two(add_two_numbers(5,10), 3)
print(final_output)
Style guides and good practice suggest the first method is superior to the second. Yet, I still feel that they are both "unpythonic". With that, let's assume functions become more complicated, but still require the principle of using each others outputs as the next one's parameters. What is the recommended methodology for running functions in main?
python
Lately, some of my code has led me to a question about using outputs of functions as variables, then to use those same variables as parameters in other functions. All when defining main. I believe this can lead to errors when debugging and confusion when using a file as a module.
An example is below:
def add_two_numbers(x, y):
z = x + y
return z
def now_divide_two(z, s):
t = z / s
return t
First method:
def main():
added = add_two_numbers(5, 10)
final_output = now_divide_two(added, 3)
print(final_output)
Second method:
def main():
final_output = now_divide_two(add_two_numbers(5,10), 3)
print(final_output)
Style guides and good practice suggest the first method is superior to the second. Yet, I still feel that they are both "unpythonic". With that, let's assume functions become more complicated, but still require the principle of using each others outputs as the next one's parameters. What is the recommended methodology for running functions in main?
python
python
edited Dec 31 '18 at 21:57
Mad Physicist
37.3k1673103
37.3k1673103
asked Dec 31 '18 at 21:15
ask39ask39
3619
3619
closed as primarily opinion-based by wwii, Mad Physicist, Stedy, Tomasz Mularczyk, EdChum Jan 1 at 13:51
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by wwii, Mad Physicist, Stedy, Tomasz Mularczyk, EdChum Jan 1 at 13:51
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
3
Which style guide?
– juanpa.arrivillaga
Dec 31 '18 at 21:15
1
"All when defining main" Note, "main" doesn't have any special status in Python.
– juanpa.arrivillaga
Dec 31 '18 at 21:19
1
What this has to do withmain()
anyway? Usuallymain
is just for parsing command line arguments and setting up logging. First way is preferable regardless, just clearer to read and easier to step through in debuggers.
– wim
Dec 31 '18 at 21:20
Which do you like better?
– wwii
Dec 31 '18 at 21:20
add a comment |
3
Which style guide?
– juanpa.arrivillaga
Dec 31 '18 at 21:15
1
"All when defining main" Note, "main" doesn't have any special status in Python.
– juanpa.arrivillaga
Dec 31 '18 at 21:19
1
What this has to do withmain()
anyway? Usuallymain
is just for parsing command line arguments and setting up logging. First way is preferable regardless, just clearer to read and easier to step through in debuggers.
– wim
Dec 31 '18 at 21:20
Which do you like better?
– wwii
Dec 31 '18 at 21:20
3
3
Which style guide?
– juanpa.arrivillaga
Dec 31 '18 at 21:15
Which style guide?
– juanpa.arrivillaga
Dec 31 '18 at 21:15
1
1
"All when defining main" Note, "main" doesn't have any special status in Python.
– juanpa.arrivillaga
Dec 31 '18 at 21:19
"All when defining main" Note, "main" doesn't have any special status in Python.
– juanpa.arrivillaga
Dec 31 '18 at 21:19
1
1
What this has to do with
main()
anyway? Usually main
is just for parsing command line arguments and setting up logging. First way is preferable regardless, just clearer to read and easier to step through in debuggers.– wim
Dec 31 '18 at 21:20
What this has to do with
main()
anyway? Usually main
is just for parsing command line arguments and setting up logging. First way is preferable regardless, just clearer to read and easier to step through in debuggers.– wim
Dec 31 '18 at 21:20
Which do you like better?
– wwii
Dec 31 '18 at 21:20
Which do you like better?
– wwii
Dec 31 '18 at 21:20
add a comment |
3 Answers
3
active
oldest
votes
There's nothing unpythonic about passing the results of a function to another function. It's often the best way of doing things.
The first style is better than the second style in terms of clarity because it's a lot easier to tell what the value being passed to now_divide_two
represents. In the second method, you aren't declaring the variable to be passed to now_divide_two
, so you have to guess what the value you're passing represents. In the first method, there is a variable with a name, so you know reasonably well what the variable means and why you are passing it to another function.
Sometimes, however, it's easy to assume what the arguments to functions mean (like str
for example), and in those cases it can be better to just pass the results of the function directly to the other function.
1
I would add that one way to get "the best of both worlds" is to use named function arguments when calling a function with a complex expression as an argument. This "simulates" using a local variable name, without actually using a local variable name.
– Daniel Pryden
Dec 31 '18 at 21:46
add a comment |
Functionally, both approaches are equivalent (barring minor differences such as temporary vs explicitly named variables), so neither is inherently "better" than the other.
"Better" is a matter of practical needs and circumstances. Some concrete considerations to help you decide in the cases you may encounter:
- The one line approach uses fewer lines of code. This is sometimes (very seldom) important.
- Using a temporary variable instead of a new namespace entry may, in some cases provide a very marginal performance boost. This is again neither a likely nor worthwhile optimization to pursue in most situations.
- If you want to log or otherwise process the intermediate values, you will have to use the multiline approach.
- Having more shorter lines is generally more readable. Readability is more useful than brevity, especially with a language like Python.
As you can tell, I personally tend to lean towards having intermediate assignments rather than monolithic one liners. However, that's usually a matter of taste. When possible, weigh the pros and cons of different approaches. Sometimes you have to recognize that it really doesn't matter, and just go with what seems nicer to you in the moment.
add a comment |
First method is imperative. Second is functional. Many people outside of academic contexts tend to use imperative style, citing readability as the reason. If you prefer the second style you may like Lisp or Clojure, where functional programming is dominant
2
This isn't true at all. Why would the first be "imperative" and the second "functional"?
– juanpa.arrivillaga
Dec 31 '18 at 21:25
in the first, you're creating mutable state variable "added". if you extend the nesting approach you will not produce any mutable state
– Danny
Dec 31 '18 at 21:30
You aren't avoiding "creating mutable state". That's almost impossible to avoid in Python. Python can never hope to be purely functional, but if you call one "functional", the other one doesn't actually mutate any state, so it is still "functional", and they are both equally so. I mean, you also create "mutable state" when you assign tofinal_output
... And anyway, what are you going to do? Use entirely anonymous functions, the whole way down, to avoid creating "mutable state" of the variables that reference your functions?
– juanpa.arrivillaga
Dec 31 '18 at 21:33
yes, i agree assigning tofinal_output
is also creating mutable state. however, i think what OP is asking is the nesting (chaining) where return value is not mutated. You can check Clojure for examples of purely functional code
– Danny
Dec 31 '18 at 21:41
They never mention mutation at all, and the intermediate variable is never mutated. Yes, I am aware of purely functional programming languages with immutable variables.
– juanpa.arrivillaga
Dec 31 '18 at 21:43
|
show 5 more comments
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
There's nothing unpythonic about passing the results of a function to another function. It's often the best way of doing things.
The first style is better than the second style in terms of clarity because it's a lot easier to tell what the value being passed to now_divide_two
represents. In the second method, you aren't declaring the variable to be passed to now_divide_two
, so you have to guess what the value you're passing represents. In the first method, there is a variable with a name, so you know reasonably well what the variable means and why you are passing it to another function.
Sometimes, however, it's easy to assume what the arguments to functions mean (like str
for example), and in those cases it can be better to just pass the results of the function directly to the other function.
1
I would add that one way to get "the best of both worlds" is to use named function arguments when calling a function with a complex expression as an argument. This "simulates" using a local variable name, without actually using a local variable name.
– Daniel Pryden
Dec 31 '18 at 21:46
add a comment |
There's nothing unpythonic about passing the results of a function to another function. It's often the best way of doing things.
The first style is better than the second style in terms of clarity because it's a lot easier to tell what the value being passed to now_divide_two
represents. In the second method, you aren't declaring the variable to be passed to now_divide_two
, so you have to guess what the value you're passing represents. In the first method, there is a variable with a name, so you know reasonably well what the variable means and why you are passing it to another function.
Sometimes, however, it's easy to assume what the arguments to functions mean (like str
for example), and in those cases it can be better to just pass the results of the function directly to the other function.
1
I would add that one way to get "the best of both worlds" is to use named function arguments when calling a function with a complex expression as an argument. This "simulates" using a local variable name, without actually using a local variable name.
– Daniel Pryden
Dec 31 '18 at 21:46
add a comment |
There's nothing unpythonic about passing the results of a function to another function. It's often the best way of doing things.
The first style is better than the second style in terms of clarity because it's a lot easier to tell what the value being passed to now_divide_two
represents. In the second method, you aren't declaring the variable to be passed to now_divide_two
, so you have to guess what the value you're passing represents. In the first method, there is a variable with a name, so you know reasonably well what the variable means and why you are passing it to another function.
Sometimes, however, it's easy to assume what the arguments to functions mean (like str
for example), and in those cases it can be better to just pass the results of the function directly to the other function.
There's nothing unpythonic about passing the results of a function to another function. It's often the best way of doing things.
The first style is better than the second style in terms of clarity because it's a lot easier to tell what the value being passed to now_divide_two
represents. In the second method, you aren't declaring the variable to be passed to now_divide_two
, so you have to guess what the value you're passing represents. In the first method, there is a variable with a name, so you know reasonably well what the variable means and why you are passing it to another function.
Sometimes, however, it's easy to assume what the arguments to functions mean (like str
for example), and in those cases it can be better to just pass the results of the function directly to the other function.
answered Dec 31 '18 at 21:22
Supa Mega Ducky Momo da WaffleSupa Mega Ducky Momo da Waffle
1
1
1
I would add that one way to get "the best of both worlds" is to use named function arguments when calling a function with a complex expression as an argument. This "simulates" using a local variable name, without actually using a local variable name.
– Daniel Pryden
Dec 31 '18 at 21:46
add a comment |
1
I would add that one way to get "the best of both worlds" is to use named function arguments when calling a function with a complex expression as an argument. This "simulates" using a local variable name, without actually using a local variable name.
– Daniel Pryden
Dec 31 '18 at 21:46
1
1
I would add that one way to get "the best of both worlds" is to use named function arguments when calling a function with a complex expression as an argument. This "simulates" using a local variable name, without actually using a local variable name.
– Daniel Pryden
Dec 31 '18 at 21:46
I would add that one way to get "the best of both worlds" is to use named function arguments when calling a function with a complex expression as an argument. This "simulates" using a local variable name, without actually using a local variable name.
– Daniel Pryden
Dec 31 '18 at 21:46
add a comment |
Functionally, both approaches are equivalent (barring minor differences such as temporary vs explicitly named variables), so neither is inherently "better" than the other.
"Better" is a matter of practical needs and circumstances. Some concrete considerations to help you decide in the cases you may encounter:
- The one line approach uses fewer lines of code. This is sometimes (very seldom) important.
- Using a temporary variable instead of a new namespace entry may, in some cases provide a very marginal performance boost. This is again neither a likely nor worthwhile optimization to pursue in most situations.
- If you want to log or otherwise process the intermediate values, you will have to use the multiline approach.
- Having more shorter lines is generally more readable. Readability is more useful than brevity, especially with a language like Python.
As you can tell, I personally tend to lean towards having intermediate assignments rather than monolithic one liners. However, that's usually a matter of taste. When possible, weigh the pros and cons of different approaches. Sometimes you have to recognize that it really doesn't matter, and just go with what seems nicer to you in the moment.
add a comment |
Functionally, both approaches are equivalent (barring minor differences such as temporary vs explicitly named variables), so neither is inherently "better" than the other.
"Better" is a matter of practical needs and circumstances. Some concrete considerations to help you decide in the cases you may encounter:
- The one line approach uses fewer lines of code. This is sometimes (very seldom) important.
- Using a temporary variable instead of a new namespace entry may, in some cases provide a very marginal performance boost. This is again neither a likely nor worthwhile optimization to pursue in most situations.
- If you want to log or otherwise process the intermediate values, you will have to use the multiline approach.
- Having more shorter lines is generally more readable. Readability is more useful than brevity, especially with a language like Python.
As you can tell, I personally tend to lean towards having intermediate assignments rather than monolithic one liners. However, that's usually a matter of taste. When possible, weigh the pros and cons of different approaches. Sometimes you have to recognize that it really doesn't matter, and just go with what seems nicer to you in the moment.
add a comment |
Functionally, both approaches are equivalent (barring minor differences such as temporary vs explicitly named variables), so neither is inherently "better" than the other.
"Better" is a matter of practical needs and circumstances. Some concrete considerations to help you decide in the cases you may encounter:
- The one line approach uses fewer lines of code. This is sometimes (very seldom) important.
- Using a temporary variable instead of a new namespace entry may, in some cases provide a very marginal performance boost. This is again neither a likely nor worthwhile optimization to pursue in most situations.
- If you want to log or otherwise process the intermediate values, you will have to use the multiline approach.
- Having more shorter lines is generally more readable. Readability is more useful than brevity, especially with a language like Python.
As you can tell, I personally tend to lean towards having intermediate assignments rather than monolithic one liners. However, that's usually a matter of taste. When possible, weigh the pros and cons of different approaches. Sometimes you have to recognize that it really doesn't matter, and just go with what seems nicer to you in the moment.
Functionally, both approaches are equivalent (barring minor differences such as temporary vs explicitly named variables), so neither is inherently "better" than the other.
"Better" is a matter of practical needs and circumstances. Some concrete considerations to help you decide in the cases you may encounter:
- The one line approach uses fewer lines of code. This is sometimes (very seldom) important.
- Using a temporary variable instead of a new namespace entry may, in some cases provide a very marginal performance boost. This is again neither a likely nor worthwhile optimization to pursue in most situations.
- If you want to log or otherwise process the intermediate values, you will have to use the multiline approach.
- Having more shorter lines is generally more readable. Readability is more useful than brevity, especially with a language like Python.
As you can tell, I personally tend to lean towards having intermediate assignments rather than monolithic one liners. However, that's usually a matter of taste. When possible, weigh the pros and cons of different approaches. Sometimes you have to recognize that it really doesn't matter, and just go with what seems nicer to you in the moment.
edited Dec 31 '18 at 22:29
answered Dec 31 '18 at 21:56
Mad PhysicistMad Physicist
37.3k1673103
37.3k1673103
add a comment |
add a comment |
First method is imperative. Second is functional. Many people outside of academic contexts tend to use imperative style, citing readability as the reason. If you prefer the second style you may like Lisp or Clojure, where functional programming is dominant
2
This isn't true at all. Why would the first be "imperative" and the second "functional"?
– juanpa.arrivillaga
Dec 31 '18 at 21:25
in the first, you're creating mutable state variable "added". if you extend the nesting approach you will not produce any mutable state
– Danny
Dec 31 '18 at 21:30
You aren't avoiding "creating mutable state". That's almost impossible to avoid in Python. Python can never hope to be purely functional, but if you call one "functional", the other one doesn't actually mutate any state, so it is still "functional", and they are both equally so. I mean, you also create "mutable state" when you assign tofinal_output
... And anyway, what are you going to do? Use entirely anonymous functions, the whole way down, to avoid creating "mutable state" of the variables that reference your functions?
– juanpa.arrivillaga
Dec 31 '18 at 21:33
yes, i agree assigning tofinal_output
is also creating mutable state. however, i think what OP is asking is the nesting (chaining) where return value is not mutated. You can check Clojure for examples of purely functional code
– Danny
Dec 31 '18 at 21:41
They never mention mutation at all, and the intermediate variable is never mutated. Yes, I am aware of purely functional programming languages with immutable variables.
– juanpa.arrivillaga
Dec 31 '18 at 21:43
|
show 5 more comments
First method is imperative. Second is functional. Many people outside of academic contexts tend to use imperative style, citing readability as the reason. If you prefer the second style you may like Lisp or Clojure, where functional programming is dominant
2
This isn't true at all. Why would the first be "imperative" and the second "functional"?
– juanpa.arrivillaga
Dec 31 '18 at 21:25
in the first, you're creating mutable state variable "added". if you extend the nesting approach you will not produce any mutable state
– Danny
Dec 31 '18 at 21:30
You aren't avoiding "creating mutable state". That's almost impossible to avoid in Python. Python can never hope to be purely functional, but if you call one "functional", the other one doesn't actually mutate any state, so it is still "functional", and they are both equally so. I mean, you also create "mutable state" when you assign tofinal_output
... And anyway, what are you going to do? Use entirely anonymous functions, the whole way down, to avoid creating "mutable state" of the variables that reference your functions?
– juanpa.arrivillaga
Dec 31 '18 at 21:33
yes, i agree assigning tofinal_output
is also creating mutable state. however, i think what OP is asking is the nesting (chaining) where return value is not mutated. You can check Clojure for examples of purely functional code
– Danny
Dec 31 '18 at 21:41
They never mention mutation at all, and the intermediate variable is never mutated. Yes, I am aware of purely functional programming languages with immutable variables.
– juanpa.arrivillaga
Dec 31 '18 at 21:43
|
show 5 more comments
First method is imperative. Second is functional. Many people outside of academic contexts tend to use imperative style, citing readability as the reason. If you prefer the second style you may like Lisp or Clojure, where functional programming is dominant
First method is imperative. Second is functional. Many people outside of academic contexts tend to use imperative style, citing readability as the reason. If you prefer the second style you may like Lisp or Clojure, where functional programming is dominant
edited Dec 31 '18 at 21:25
answered Dec 31 '18 at 21:24
DannyDanny
46110
46110
2
This isn't true at all. Why would the first be "imperative" and the second "functional"?
– juanpa.arrivillaga
Dec 31 '18 at 21:25
in the first, you're creating mutable state variable "added". if you extend the nesting approach you will not produce any mutable state
– Danny
Dec 31 '18 at 21:30
You aren't avoiding "creating mutable state". That's almost impossible to avoid in Python. Python can never hope to be purely functional, but if you call one "functional", the other one doesn't actually mutate any state, so it is still "functional", and they are both equally so. I mean, you also create "mutable state" when you assign tofinal_output
... And anyway, what are you going to do? Use entirely anonymous functions, the whole way down, to avoid creating "mutable state" of the variables that reference your functions?
– juanpa.arrivillaga
Dec 31 '18 at 21:33
yes, i agree assigning tofinal_output
is also creating mutable state. however, i think what OP is asking is the nesting (chaining) where return value is not mutated. You can check Clojure for examples of purely functional code
– Danny
Dec 31 '18 at 21:41
They never mention mutation at all, and the intermediate variable is never mutated. Yes, I am aware of purely functional programming languages with immutable variables.
– juanpa.arrivillaga
Dec 31 '18 at 21:43
|
show 5 more comments
2
This isn't true at all. Why would the first be "imperative" and the second "functional"?
– juanpa.arrivillaga
Dec 31 '18 at 21:25
in the first, you're creating mutable state variable "added". if you extend the nesting approach you will not produce any mutable state
– Danny
Dec 31 '18 at 21:30
You aren't avoiding "creating mutable state". That's almost impossible to avoid in Python. Python can never hope to be purely functional, but if you call one "functional", the other one doesn't actually mutate any state, so it is still "functional", and they are both equally so. I mean, you also create "mutable state" when you assign tofinal_output
... And anyway, what are you going to do? Use entirely anonymous functions, the whole way down, to avoid creating "mutable state" of the variables that reference your functions?
– juanpa.arrivillaga
Dec 31 '18 at 21:33
yes, i agree assigning tofinal_output
is also creating mutable state. however, i think what OP is asking is the nesting (chaining) where return value is not mutated. You can check Clojure for examples of purely functional code
– Danny
Dec 31 '18 at 21:41
They never mention mutation at all, and the intermediate variable is never mutated. Yes, I am aware of purely functional programming languages with immutable variables.
– juanpa.arrivillaga
Dec 31 '18 at 21:43
2
2
This isn't true at all. Why would the first be "imperative" and the second "functional"?
– juanpa.arrivillaga
Dec 31 '18 at 21:25
This isn't true at all. Why would the first be "imperative" and the second "functional"?
– juanpa.arrivillaga
Dec 31 '18 at 21:25
in the first, you're creating mutable state variable "added". if you extend the nesting approach you will not produce any mutable state
– Danny
Dec 31 '18 at 21:30
in the first, you're creating mutable state variable "added". if you extend the nesting approach you will not produce any mutable state
– Danny
Dec 31 '18 at 21:30
You aren't avoiding "creating mutable state". That's almost impossible to avoid in Python. Python can never hope to be purely functional, but if you call one "functional", the other one doesn't actually mutate any state, so it is still "functional", and they are both equally so. I mean, you also create "mutable state" when you assign to
final_output
... And anyway, what are you going to do? Use entirely anonymous functions, the whole way down, to avoid creating "mutable state" of the variables that reference your functions?– juanpa.arrivillaga
Dec 31 '18 at 21:33
You aren't avoiding "creating mutable state". That's almost impossible to avoid in Python. Python can never hope to be purely functional, but if you call one "functional", the other one doesn't actually mutate any state, so it is still "functional", and they are both equally so. I mean, you also create "mutable state" when you assign to
final_output
... And anyway, what are you going to do? Use entirely anonymous functions, the whole way down, to avoid creating "mutable state" of the variables that reference your functions?– juanpa.arrivillaga
Dec 31 '18 at 21:33
yes, i agree assigning to
final_output
is also creating mutable state. however, i think what OP is asking is the nesting (chaining) where return value is not mutated. You can check Clojure for examples of purely functional code– Danny
Dec 31 '18 at 21:41
yes, i agree assigning to
final_output
is also creating mutable state. however, i think what OP is asking is the nesting (chaining) where return value is not mutated. You can check Clojure for examples of purely functional code– Danny
Dec 31 '18 at 21:41
They never mention mutation at all, and the intermediate variable is never mutated. Yes, I am aware of purely functional programming languages with immutable variables.
– juanpa.arrivillaga
Dec 31 '18 at 21:43
They never mention mutation at all, and the intermediate variable is never mutated. Yes, I am aware of purely functional programming languages with immutable variables.
– juanpa.arrivillaga
Dec 31 '18 at 21:43
|
show 5 more comments
3
Which style guide?
– juanpa.arrivillaga
Dec 31 '18 at 21:15
1
"All when defining main" Note, "main" doesn't have any special status in Python.
– juanpa.arrivillaga
Dec 31 '18 at 21:19
1
What this has to do with
main()
anyway? Usuallymain
is just for parsing command line arguments and setting up logging. First way is preferable regardless, just clearer to read and easier to step through in debuggers.– wim
Dec 31 '18 at 21:20
Which do you like better?
– wwii
Dec 31 '18 at 21:20