Changing calling sequence

[dn]

On 15/05/2022 11.34, 2QdxY4RzWzUUiLuE at potatochowder.com wrote:
> On 2022-05-15 at 10:22:15 +1200,
> dn <PythonList at 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