signum() not in math?

[Tim Peters]

[Dinu Gherman]
> ...
> The more fundamental question behind these issues is:

I doubt that wrapping a request for a specific function inside a Grand
Generalization is going to help sell it.  At best it will bury the request
under an avalanche of "me too, but!"s for 50 other functions you don't care
about.  Then, if history is a trustworthy guide, nobody will care enough to
implement any of them.

> Can someone expect from the Python standard library, too, 'only'
> those 90% of functionality needed by 'the crowd' and be treated
> with regret when not belonging to it, especially when the matter
> is so trivial?

I've used a lot of languages over the endlessly tiring <wink> years, but
have never seen another language community so keen to avoid writing two-line
functions themselves.  When a function you want is indeed trivial to code in
Python, that's a strong argument against bloating the core C code with it.

> The reason for people not complaining about the absence of the
> sign() function need not necessarily be that they use something
> like tanh() more often (I doubt so), but simply because they
> can write sign() with far less difficulty than tanh().

I don't believe that -- overall, people just aren't shy about asking for new
stuff.

> One can argue if this is a good thing. Newbies might learn some-
> thing by writing sign() themselves, but will probably wonder why
> they *have* to? (While nobody expects to find the Riemann Zeta
> function in the math module, that you get in Mathematica...)

Then they can ask, and get an unsatisfying answer <wink>.

> In math textbooks sign() is typically introduced just before or
> after abs(), which raises the question why Python has chosen to
> implement only abs() and not only sign(),

As I explained last time, and as it says right at the top of the math module
docs:

    It [the math module] provides access to the mathematical functions
    defined by the C standard.

That's all it was designed to do, and all it does.  If people want a fancier
math module, fine by me, but then (A) it needs a PEP; and, (B) it needs
volunteers to design, document, code, port and test the new stuff.

> especially as they can be expressed in terms of each other?

I expect you severely underestimate the arguments there *would* be over "the
correct" signum function:  what to do about a 0 argument; which types it
should accept; which type(s?) it should return; if signum(0.0) returns a
float 0, whether the sign of 0 needs to be preserved or erased, or whether
that's undefined; if signum(0.0) returns a 1, ditto for reflecting the sign
of the input; what to do about NaN arguments; and whether subclasses of
numeric types and/or new numeric types need a way to override the base type
signum implementation (since you brought up the parallel, note that numeric
types *can* override __abs__, and that requires a whole slew of machinery in
the class and type implementations, and adding new slots for numeric types
at the C level creates cross-release binary compatibility headaches too).

> Orthogonal design? Ok, but the same is true for sin() and cos() and
> still, both are there in the math module!

    It provides access to the mathematical functions defined by
    the C standard.

That was Guido's practical way of letting some other committee argue for
years (literally) about which functions are of most use, and exactly what
they should do.  Trust me when I tell you there's nothing easy about math
library definition, design, or implementation, and especially not
floating-point math libraries.

> As the ActiveState Python cookbook comes closer to being printed
> it would be sort of embarassing to see a recipe therein for wri-
> ting a signum function, simply because you need it, wouldn't it?

I won't find it embarrassing, no; it's more embarrassing that we haven't
invented a % format code to convert integers to Roman numerals, which is a
more frequent topic on the newsgroup, and wrt support for which Python
severely lags behind Common Lisp <wink>.

> Expecting-the-Spanish-Inquisition'ly,

if-the-spanish-inquisition-doesn't-write-peps-or-code-i-expect-it-too-ly
    y'rs  - tim