'complex' function with string argument.

[Ian Kelly]

On Wed, Mar 19, 2014 at 4:53 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Ian Kelly <ian.g.kelly at gmail.com>:
>
>> On Wed, Mar 19, 2014 at 4:09 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>> So complex(a, b) is documented to produce a+bj when a and b are integers
>>> or floats. What's more natural than saying it produces a+bj when a and b
>>> are complex numbers? It's a straightforward generalization that in no
>>> way violates the more limited documentation.
>>
>> When is it ever useful though? [...] It would be better to raise an
>> exception in either of the cases above, in my opinion.
>
> I don't think it matters one way or another.
>
> Medieval mathematicians had to address an analogous issue when they had
> to decide if
>
>    x + 0
>
> was meaningful. After all, adding nothing doesn't make any sense and
> should raise a ValueError exception...

I wasn't aware that algebra had ValueErrors.  Describing an operation
as "undefined" isn't the same thing.  Anyway, if mathematicians
discover that the definitions of the past were flawed or incomplete,
then they redefine them.  Case in point, if we were still using
Brahmagupta's rules for zero, then 0/0 would be 0.

Python though has backward compatibility to worry about.  Because of
this, it is much simpler to add wanted behavior than to remove
unwanted behavior. If an operation can be generalized but the
generalization has no apparent use case, it *may* be better to
disallow it, with the possibility of adding it later when a user pops
up and says "Hey, this would actually be useful to me", than to allow
it from the beginning, and then have no option to remove it later when
it turns out to be merely a nuisance.

Compare for example the 2-argument int constructor.  Normally this is
meant to be called like int("42", 13), where it will interpret the
digits passed as base 13 and return 54.  We might generalize that and
say that if the user passes int(42, 13), it should also return 54,
seeing that the repr of 42 provides the digits "42".  It is more
likely though that this call merely indicates a bug in the user's
code, and fortunately in this case what Python actually does is to
raise a TypeError.

Anyway, curious though this tangent is, further discussion is unlikely
to produce any useful outcome, so I'll just leave it there.