On 15/05/2022 11.34, 2qdxy4rzwzuui...@potatochowder.com wrote: > On 2022-05-15 at 10:22:15 +1200, > dn <pythonl...@danceswithmice.info> wrote: > >> That said, a function which starts with a list of ifs-buts-and-maybes* >> which are only there to ascertain which set of arguments have been >> provided by the calling-routine; obscures the purpose/responsibility >> of the function and decreases its readability (perhaps not by much, >> but varying by situation). > > Agreed. > >> Accordingly, if the function is actually a method, recommend following >> @Stefan's approach, ie multiple-constructors. Although, this too can >> result in lower readability. > > (Having proposed that approach myself (and having used it over the > decades for functions, methods, procedures, constructors, ...), I also > agree.) > > Assuming good names,¹ how can this lead to lower readability? I guess > if there's too many of them, or programmers have to start wondering > which one to use? Or is this in the same generally obfuscating category > as the ifs-buts-and-maybes at the start of a function? > > ¹ and properly invalidated caches
Allow me to extend the term "readability" to include "comprehension". Then add the statistical expectation that a class has only __init__(). Thus, assuming this is the first time (or, ... for a while) that the class is being employed, one has to read much further to realise that there are choices of constructor. Borrowing from the earlier example: > This would be quite pythonic. For example, "datetime.date" > has .fromtimestamp(timestamp), .fromordinal(ordinal), > .fromisoformat(date_string), ... Please remember that this is only relevant if the function is actually a module - which sense does not appear from the OP (IMHO). The alternatives' names are well differentiated and (apparently#) appropriately named*. * PEP-008 hobgoblins will quote: "Function names should be lowercase, with words separated by underscores as necessary to improve readability. Variable names follow the same convention as function names." - but this is a common observation/criticism of code that has been in the PSL for a long time. # could also criticise as not following the Software Craftsmanship/Clean Code ideal of 'programming to the interface rather than the implementation' - which we see in PEP-008 as "usage rather than implementation" (but please don't ask me how to differentiate between them, given that the only reason for the different interfaces is the function's/parameters' implementation!) NB usual caveats apply to PEP-008 quotations! So, I agree with you - it comes down to those pernicious 'ifs-buts-and-maybes'. If the interface/parameter-processing starts to obfuscate the function's actual purpose, maybe it can be 'farmed-out' to a helper-function. However, that would start to look very much like the same effort (and comprehension-challenge) as having a wrapper-function! Continuing the 'have to read further' criticism (above), it could equally-well be applied to my preference for keyword-arguments, in that I've suggested defining four parameters but the user will only call the function with either three or one argument(s). Could this be described as potentially-confusing? Given that the OP wouldn't want to have to redefine the existing interface, the next comment may not be applicable - but in the interests of completeness: anyone contemplating such architecture might like to consider "Single-dispatch generic functions" (https://peps.python.org/pep-0443/). At least the decorators signal that there are alternative-choices... -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
