signum() not in math?
Dinu Gherman
gherman at darwin.in-berlin.de
Tue Oct 16 11:17:41 EDT 2001
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)
More information about the Python-list
mailing list