On 30 June 2000, M.-A. Lemburg said:
> > But I vote -1 on this one anyway -- it's too much code and almost by
> > its very nature not something that belongs in a "standard" library.
> > Plus, I don't want to be responsible for maintaining it. Sorry,
>
> You don't have to maintain it... I will anyway since it's part
> of mxCGIPython.
>
> Anyway, perhaps Greg Ward can find some use for it in
> distutils.
I looked at platform.py once briefly, and my impression was similar to
Guido's: too big! All I want(ed) is "osname-cpu" -- linux-i386,
solaris-sparc, whatever. osversion is optional.
But, consider that that the Distutils might want to know if it should
generate RPMs or Debian packages... then the stuff about grokking which
Linux distribution it's running on is relevant. Argh!
Anyways, I'm already taking static about too much code in the Distutils,
and I partly agree. (I agree there's a *lot* of code, I know there are
bits that can be refactored and reduced, but I'm not sure it's too
much.) So I'll stick with sys.platform for now -- it's good enough.
Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange / CNRI voice: +1-703-262-5376
Reston, Virginia, USA fax: +1-703-262-5367
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4