One of the problems with Python's current approach to CPAN-like packagesis, to put it in a particularly blunt way, that it hasn't quite sunk inthat not everyone has root.

(I am aware that Python doesn't have an approach to packages as such;it's all done by distutils et al, although distutils is part of thestandard library. That's part of the overall problem.)

Oh, sure, you can use distutils to install packages in places besides

Dear software, I have a small and simple request, from a working systemadministrator:

Please stop pretending that \r\n and \n are the same thing.

That is, please stop pretending that MS-DOS line endings and Unix lineendings are the same thing, because they are not. Pretending that theyare is one of those collective hallucinations that only work if absolutely everyone is playing along. Sooner or later(usually sooner) you will run into a program that does not play along,and things

Reading a line from standard input, as the shell's read builtin does,certainly seems like it should be easy to implement or reimplement (ifone's shell is sufficiently primitive). However, it turns out that thereis a subtle problem that forces a pretty inefficient implementation, andmakes it basically impossible to duplicate read with any common Unixprogram.

I can neatly illustrate the problem with a little script:

(echo a; echo b) |   (echo `sed 1q`; echo `sed

When they are planning how to organize their IO , programs (and designers) normally assume thatrewriting (overwriting) an existing, already written file is the fastestsort of write operation possible and will not change the existing filelayout (for example, if it has been created to be sequential). Thisis because all of the data blocks have already been allocated and allof the metadata has been set up; if you write in block-aligned units,pretty much all the operating system has to do is shovel