[Tutor] product of all arguments passed to function call

[Mats Wichmann]

On 5/31/21 8:21 AM, Manprit Singh wrote:
>   Dear sir,
> 
> Coming to the same question , of finding the product of all arguments
> passed to a function call . Actually I have seen so many times when getting
> replies from python mailing list, those replies other than from you are
> more focussed on using modules that are part of  python standard library.
> My question is, if i had to perform the same task (finding the product of
> argument in function call )  in a real world program, what should i choose
> ? a solution without using those modules or it will be better using those
> modules?
> 
> Solution without using module (as given by you in previous mail):
> def product(*x):
>      result = 1 if x else 0
>      for n in x:
>        result *= n
>      return result
> 
> Solution using python standard library modules :
> 
>>>> from functools import reduce
>>>> from operator import mul
>>>> def prod_num(*x):
>             if not x or 0 in x:
>                 return 0
>            else:
>                return reduce(mul, x)
> 
> I feel there are overheads while you are importing , so better avoid using
> this way...
> I raised this question because sometime back, i saw one of my friend using
> re module with string for very small problem that was even easy to handle
> with string methods, i suggested him not to use re module for it, later on
> he agreed. So what is the real picture ? what should i adopt ?

So as you probably suspect, there's not going to be one overriding answer.

When building complex systems, there's a lot to think about, and if a 
supported part of the Language (which the standard library is) can solve 
your problem, why not?  You get the benefit of code which has been 
developed, tested and maintained by experienced Python developers as 
solutions to common programming situations, and the odds are good that 
they've thought of corner cases that you might not at first.  You'll 
still have plenty to think about building your software, why spend even 
more cycles than you need to?

The overhead of an import is non-zero, but "avoiding imports" just for 
some perceived performance gains is a losing strategy.

Sometimes, though, you have a simple problem to solve and there's no 
reason to reach for a big tool when a few lines of code will do.  Your 
example is quite an apt one - reaching for a regex when one is not 
needed is a formula for frustration.  It's probably been quoted to you 
here already, but there are jokes about this - the famous one (I'm too 
lazy to search it out, hope I've remembered the wording correctly) 'Some 
people, when confronted with a problem, think "I know, I'll use regular 
expressions." Now they have two problems.'  I'd note that it's easier to 
get regular expressions right these ways with the presence of regex 
sites which can evaluate one you've written, and in some cases, help you 
construct one by clicking some buttons.

And of course, sometimes a standard library module doesn't hit close 
enough to the mark of what you're trying to achieve to be worth the 
effort to try and bend it to your need.

Using the right tool for a job is also a skill to develop.