Python Forum

Full Version: two different doc strings
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
i have a case where two different functions for different purposes were re-factored in a way that they shared exactly identical code. so i am looking at making them share a single definition:
def foo(...arguments...):
    ...the code...
    return
bar = foo
the original two functions had docstrings that explained the different purposes of those two functions. what i would like to know is if there is a way to associate two different docstrings with the two different function names now that they share identical code.

for those who cannot understand how two different purposes can be handled by exactly the same code, it turns out that a common value somewhere had the proper value in both cases and these functions used that value to carry out their purposes in the new version.
I don't think a docstring should describe the purpose of function. It should describe what it does and how it is used. What it is used for should direct the design, but the more your code can be used for multiple purposes the better.
that project has many functions that are similar. i may end up with more duplications like that. i agree with your statement about the functions. if i leave foo() and bar() as separate definitions, i can give each function its own docstring that describes what it does and how it is used. but i don't think it is good to have these two functions implemented with exactly the same code.

maybe, that is a wrong idea. it could be implementation versus expression that i need to consider.

do i need to focus more or less on efficiency, the efficiency of saving a function definition that is about 5 lines. my long term habitual practice has been for efficiency. but in Python, i am try to move away from that although there are cases where the code can do less if i have things work a different way. so i still do enough optimizing to avoid wasteful expressions.

this thinking comes from my decades of programming in assembly and C (no C++) and little bit of PLC and Pike.