[Doc-SIG] Undocumented modules
Christopher G. Petrilli
Wed, 24 Feb 1999 12:42:01 -0500
On Wed, Feb 24, 1999 at 12:31:23PM -0500, Guido van Rossum wrote:
> > colorsys DEPRECATE (very incomplete and possible
> > inacurate, use PIL)
> Hm... This incorporates quite a bit of arcane knowledge that was hard
> to come by when we wrote it. I'm not sure where it is incomplete or
Um, missing color systems like CMYK (which of course are nearly
impossible to do), but also is part of the concept of imaging a'la PIL
it seems, so awefully incomplete without the ability to do
transformations in the color system (histograms, etc).
> > mhlib DOCUMENT (has anyone tested this?)
> Yes, I use it a lot, and just today I received some patches from a
> mostly happy user in the newsgroup.
I noticed this myself, such timing :-)
> > mutex DOCUMENT
> Hmm, this is very shady and seems to predate threads!
It has some interesting capabilities though probably not thread-safe...
but threads don't work on every system unfortunately.
> > sched DOCUMENT
> Like mutex -- not clear how useful this is.
Same as mutex, might be useful for non-threading systems to use, and
might also be useful to throw into an individual thread to deal with
> > tty DEPRECATE (move to termios?)
> Document -- it's a higher-level thing that could be useful.
But should it go into termios?
> > tzparse DOCUMENT
> And someone should finish it!
Just what I wnated to work on, timezone parsing *gack*
> > caching things - has anyone actually tested these for performance? A
> > quick check on my FreeBSD 3.0 box says they're slower than not caching
> > because of (I assume) file system caching effeciency... Maybe that was
> > a fluke, at least with statcache ;-)
> Exactly how did you test it? This is needed especially when using
> NFS, since stat over NFS is slow and synchronous.
No I didn't do it over NFS, since I don't have NFS. Maybe the
documentation should mention that it's advantages are over NFS, not on
direct file systems?
> > As you've no doubt noticed, not much I don't say to document, BUT... I'm
> > worried about all this HYPER specific IRIX stuff... perhaps it should
> > be moved into it's own seperate documentation area, or even a seperate
> > distribution of sorts (a'la Mac)... there's a ton of junk that just
> > isn't useful for 99% of the users.
> Agreed. There is already an SGI specific chapter that could easily be
> lifeted out. Some of it is also very old and of questionable utility
> in modern SGI systems (even if SGI survives :-).
Oh SGI will survive, probably as a Microsoft vendor unfortunately. Sad
because IRIX was the best of the Unices in performance and amazing
feature sets (I still use the guaranteed filesystem bandwidth feature).
| Christopher Petrilli ``Television is bubble-gum for
| email@example.com the mind.''-Frank Lloyd Wright