How do I make functions "interact" with each other?

[Hudjefa]

def weight_stats():
    mean_total_weight = 8 * 68
    variance_total_weight = 8 * 25
    standard_deviation_total_weight = math.sqrt(variance_total_weight)
    return mean_total_weight and standard_deviation_total_weight

def failure_risk(max_weight):
    z_score = (max_weight - mean_total_weight)/standard_deviation_total_weight
    one_standard_deviation = standard_deviation_total_weight
    two_standard_deviation = 2 * standard_deviation_total_weight
    three_standard_deviation = 3 * standard_deviation_total_weight
    if z_score <= one_standard_deviation:
        print("Probability of failure >= " + str(16) + "%")
    elif z_score <= two_standard_deviation:
        print("Probability of failure >= " + str(2.5) + "%")
    elif z_score <= three_standard_deviation:
        print("Probability of failure >= " + str(0.15) + "%")
    else:
         print("Interesting!")

max_weight = float(input("Enter max weight for your elevator: "))

weight_stats()

failure_risk(max_weight)

As you can see I need the value of the variable mean_total_weight AND standard_deviation_total_weight (these I compute using the weight_stats() function) in the next function which is failure_risk(max_weight). It returns an error (undefined variables mean_total_weight and standard_deviation_total_weight).

How do carry the results of a computation in one function over to another function. They seem to be quite independent of each other. Why do we have this feature?

Gracias.

[deanhystad]

They seem to be quite independent of each other. Why do we have this feature?

To make it possible to write software.

What you are asking about is called "encapsulation". From Wikipedia:

In software systems, encapsulation refers to the bundling of data with the mechanisms or methods that operate on the data. It may also refer to the limiting of direct access to some of that data, such as an object's components.[1] Essentially, encapsulation prevents external code from being concerned with the internal workings of an object.

Encapsulation is a highly desirable attribute because it lets us write new software that uses existing software, only having to know a few details, the interface, of the old software. Imagine how long it would take for you to write anything if you needed to understand every detail about how the print statement generated character bitmaps from a font description, copied the bitmaps into display memory, and refreshed the display? And that is a ridiculously simplistic, and probably incorrect, description of what print does. I don't know the details of how print works. I don't know the details because I don't need to know the details. I only need to know the details of how print is used, so I can use print (old software) in my programs (new software).

This is how I would write your code if I was forced to use a function to get the weight stats and another to calculate and print failure risk:

def weight_stats():
    """Returns max total weight and standard deviation for elevator?"""
    weight = 8 * 68
    variance = 8 * 25
    return weight, variance ** 0.5


def failure_risk(max_weight, mean_total_weight, standard_deviation):
    z_score = (max_weight - mean_total_weight) / standard_deviation
    if z_score <= standard_deviation:
        print("Probability of failure >= 16%")
    elif z_score <= 2 * standard_deviation:
        print("Probability of failure >= 2.5%")
    elif z_score <= 3 * standard_deviation:
        print("Probability of failure >= 0.15%")
    else:
        print("Interesting!")


max_weight = float(input("Enter max weight for your elevator: "))
total_weight, stdev = weight_stats()
failure_risk(max_weight, total_weight, stdev)

Or I might write weight_stats() like this:

def weight_stats():
    """Returns max total weight and standard deviation for elevator?"""
    return 554, 200**0.5

Or I could write the function to lookup the information from a table or retrieve the information from a database. The details do not matter at all to the code, which only cares that the function returns max total weight and standard deviation values.

[Pedroski55]

Look up Python LEGB, which has nothing to do with any kind of sexuality!

Locale: Variables created inside a function belong to the local scope corresponding to that function — and are not available outside.
Enclosing: a function within another function has access to the variables of the enclosing function.
Global: variables declared outside of functions
Built-in Scope: The built-in scope is the widest scope, and contains all built-in keywords, which you can use anywhere in your code without importing or defining them.

L: gone when a functions ends
E: gone when the enclosing function ends
G: gone when the programme ends
B: Always available when Python starts

Probably, there are some exceptions, somewhere!

[deanhystad]

Encapsulation is inexorably tied to another important software concept called "modularity", so much so that it is difficult to distinguish between them. Modularity has more to do with breaking up big software tasks into several smaller tasks. Breaking up big software into smaller pieces is only possible because of encapsulation.

Your program could be written like this:

mean_total_weight = 8 * 68
standard_deviation_total_weight = (8 * 25) ** 0.5
max_weight = float(input("Enter max weight for your elevator: "))

z_score = (max_weight - mean_total_weight) / standard_deviation_total_weight
if z_score <= standard_deviation_total_weight:
    print("Probability of failure >= " + str(16) + "%")
elif z_score <= 2 * standard_deviation_total_weight:
    print("Probability of failure >= " + str(2.5) + "%")
elif z_score <= 3 * standard_deviation_total_weight:
    print("Probability of failure >= " + str(0.15) + "%")
else:
    print("Interesting!")

For a program this short, this is perfectly acceptable coding, though it could do with some comments that describe what the program does and how it is used. But what if the code to perform the calculations was 1000 lines, or 100,000 lines? That would be difficult to read in a text editor. Even scrolling through such a file would be painful. It would also be difficult (nearly impossible) to make any changes, because any change might affect other parts of the code, and the only way to identify what code is affected is by checking every line of code.

This is where modularity becomes beneficial. Some savvy programmer reorganizes the 1000 lines of code into 20 functions, each with a well-defined interface and purpose that dan be described in a sentence or two. Now you only need to understand how the 20 functions work together instead of how the 1000 lines of code interact. The programmer identifies a lot of repeated code, and the new functions not only reorganize the code into something easier to understand, but significantly reduce the number of lines of code. I've reworked a lot of old software and I commonly see a 50% reduction in overall code size.

The new code is much easier to maintain. Because each function has a well-defined purpose and interface, changes to a function should have little to no effect on any other function. Breaking the code into functions also makes it possible to write other code to test the functions. This code can be run automatically to verify that any software changes don't cause any of the function tests to fail.

[Hudjefa]

Encapsulation is inexorably tied to another important software concept called "modularity", so much so that it is difficult to distinguish between them. Modularity has more to do with breaking up big software tasks into several smaller tasks. Breaking up big software into smaller pieces is only possible because of encapsulation.

I learned that in coding 101. Are Python functions like subroutines in other programs? The only other language I learned was Microsoft Small Basic and in Small Basic, we can link subroutines i.e. the value returned (output) by one subroutine can be used as an argument (input) for another subroutine and this can be achieved by simply calling one subroutine after the other (the values stored in a variable are not lost when the subroutine ends). Another difference is a Small Basic subroutine can be defined anywhere in the program. It doesn't have to be written before it's called; quite different from Python functions, which must appear before they're called.

So one way of accessing the output (what the function returns) of a Python function would be to nest it inside another subroutine, like so: cost(amount_paint_required(compute_area(length, width)))?

Gracias.

[Hudjefa]

Look up Python LEGB, which has nothing to do with any kind of sexuality!

Locale: Variables created inside a function belong to the local scope corresponding to that function — and are not available outside.
Enclosing: a function within another function has access to the variables of the enclosing function.
Global: variables declared outside of functions
Built-in Scope: The built-in scope is the widest scope, and contains all built-in keywords, which you can use anywhere in your code without importing or defining them.

L: gone when a functions ends
E: gone when the enclosing function ends
G: gone when the programme ends
B: Always available when Python starts

Probably, there are some exceptions, somewhere!

Most helpful! Arigato gozaimus.

[addictivecoder]

I've never thought it can be done like that. so excellent. link removed

[deanhystad]

So one way of accessing the output (what the function returns) of a Python function would be to nest it inside another subroutine, like so: cost(amount_paint_required(compute_area(length, width)))?

Maybe. compute_area needs to return a value appropriate as the one argument passed to compute_area, and compute_area must return a value that can be used by cost.

Personally, I don't like code written that way. Embedding one level of function calls, fine, but two or more begins to get difficult to read. It also seems like a lot of functions doing the work of one function.

[Hudjefa]

So one way of accessing the output (what the function returns) of a Python function would be to nest it inside another subroutine, like so: cost(amount_paint_required(compute_area(length, width)))?

Maybe. compute_area needs to return a value appropriate as the one argument passed to compute_area, and compute_area must return a value that can be used by cost.

Personally, I don't like code written that way. Embedding one level of function calls, fine, but two or more begins to get difficult to read. It also seems like a lot of functions doing the work of one function.

True, but Python's structure is such, no? The value of the variables are lost (LOCAL) if not used in this one of many other ways. It would depend on the situation and that's probably what you mean.

[deanhystad]

True, but Python's structure is such, no?

No, python does not do what you claim. Variables are not "lost".

I think you may be confused about scope.

A variable in a function only exists within the scope of the function. You cannot access the variable from outside the function. Remember Pedroski55 mentioning LEGB? L (local) can see EGB, but EGB cannot see into L. For example:

def counter(end):
    start = 0
    while start < end:
        yield start
        start += 1

iter = counter(10)
print(next(iter))
try:
    print(start)
except NameError as ex:
    print(ex)
try:
    print(counter.start)
except AttributeError as ex:
    print(ex)
print(next(iter))

Output:
0
name 'start' is not defined
'function' object has no attribute 'start'       
1

When I try to use the variable "start" from outside the counter() function, python tells me that there is not a variable named "start". This does not mean there is no variable named "start", it means that there is no variable named "start" in any scope that is visible to my print statements. There is obviously a variable named "start" inside the counter() function, and that variable obviously still exists somewhere, because when I ask for the next value from counter() it returns 1. counter() remembers "start", and "start" still exists. We just can't see "start" from outside counter().

Someone ignorant of how scope works might try to get access to "start" inside of counter() like this:

start = None

def counter(end):
    start = 0
    while start < end:
        yield start
        start += 1

iter = counter(10)
print(next(iter))
print(start)
print(next(iter))
print(start)
print(next(iter))

Output:
0
None
1   
None
2

Now we have two variables named "start": one in the scope of the module and one in the scope of the function. The variables have the same name, but are not related in any way. This is a desirable outcome because it provides encapsulation. You can change the name of the variables inside counter() without any concern of that affecting code outside of counter(). Encapsulation is a good thing, remember? We really don't want to look at variables inside a function because code that does that is dependent on the implementation of the function, not just the interface. Any change to the function would require searching all code for any references to function internals.

To get a variable value from a function, the function uses return or yield. return returns a value and exits the function. yield returns a value but does not exit the function. Functions that use yield are called "generators". counter() is a generator.

def counter(end):
    start = 0
    while start < end:
        yield start
        start += 1


iter = counter(10)
a = next(iter)
b = next(iter)
c = next(iter)
print(a, b, c)

Output:
0 1 2

variables in the module scope, a, b and c, are used to reference the value returned by the counter function/generator. Notice that the values are not "lost". Things are only "lost" when they are not referenced anywhere in the program. If there are no references to something you cannot use it, so Python deletes the object and recycles the memory.