signum() not in math?

[Dinu Gherman]

Tim Peters wrote:
> 
> > 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.

As others have also pointed out at length, it wouldn't blow up any-
thing. And as you try to point out, it might not be *exactly* as 
trivial as one might think.

> > 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.
> [...]
> 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.

Well, even great decissions of the past benefit from an occasional
reality-check, don't they? And the matters about trust and floating 
point issues don't seem to apply, do they? The former not in these
brainwashing days and the latter not in this case...

> > 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>.

Well, I have *some* doubts that people using Roman numerals
will find them useful in cases where the % operator throws a 
ValueException for anything below I or greater than MMMM (if 
these were really implemented sticking to the, errm, specs...) 
which is for almost all integers... ;-)

To prevent some folks from getting me wrong: I *do* like Py-
thon and 2.2 will be likely the best Python there ever was, 
but I fail to understand why people don't care to make a damn 
jolly good product even better? 

All it takes in this case is to undust a few corners of the 
standard library and give it back some of the "ease-of-use"/
"battery-inluded" philosophy that it used to be advocated 
with.

Now,-that-would-certainly-deserve-a-PEP'ly,

Dinu

-- 
Dinu C. Gherman
ReportLab Consultant - http://www.reportlab.com
................................................................
"The world becomes a better place as a result of the refusal
to bend to authority and doctrine." (Noam Chomsky)