Redundant use of indexing
Since you only need value, not index, you could store current minimal value instead of its index. This would allow for for
loop, like
for item in sequence:
if item < current_minimum:
current_minimum = item
You both ditch overhead for array access, for tracking the index and - most important - code looks cleaner. (although that's subjective)
No support for generators
Generators provide items one at a time, instead of wasting memory on all of them at once. Your code would force generation of all items before first of them is processed. This is not really good.
Well, if you don't use indexing then you don't need len
and generators would work just fine, your if len(args) == 1:
clause is good in this regard.
Confusing behaviour with single argument
However, special treatment for a lone argument is not obvious from signature, that's not really good. If one does not know about this behaviour, one can easily use stuff like min_element = minimal(*some_list)
which would generally work but will do an unexpected thing if some_list
had only one element.
Yes, it seems extremely useful, but also confusing. Maybe limiting to one argument only and expecting users to do stuff like minimal((1,2))
? I'm really not sure. It seems useful enough that built-in min
works like that, but generally speaking decisions like this should not be taken lightly.
Also, take a closer look at what min
does - there's also an option of using a key function and providing default value.
min
? Or did you do it for the fun of it? In that case add the tag reinventing-the-wheel \$\endgroup\$min
, I'm just practicing for fun! \$\endgroup\$