Bug on Python2.3.4 [FreeBSD]?

[Terry Reedy]

"Donn Cave" <donn at u.washington.edu> wrote in message 
news:donn-AD45A7.10101015082005 at gnus01.u.washington.edu...
> In article <mailman.3053.1123936311.10512.python-list at python.org>,
> "Terry Reedy" <tjreedy at udel.edu> wrote:
> ...
>> If there is a hole in the standard, 'innovation' is required.
>
> I hope this perspective is a rarity.

I think you over interpreted.  The ''s were intentional.  Let me reword. 
If one if implementing a standard and it is *silent* on an initial 
condition then one must *choose* something (or let it be complete accident, 
and even possibly invalid).

If there is one accessible and known existing 'standard' practice that is 
at least as reasonable as anything else, and the hole seems to be an 
accident rather than intentional, then I too would want to be that choice 
made.  But if there are two existing 'standard' practices, then there is a 
real choice to be made.  (But either would be better than a third.)

 > In the present case, so far I see a strong Berkeley vs. everyone
> else pattern, so GNU C probably wasn't the culprit after all.
> Along with already documented FreeBSD, I find MacOS X, NetBSD 2
> and Ultrix 4.2 position the read stream to EOF.  Linux, AIX and
> DEC/OSF1 (or whatever it's called these days) position it to 0.

The person I responded to gave almost none of this detail.  With this info, 
and the knowledge that Berkeley got Unix from Bell Labs about 1975, I 
speculate that the hole of not specifying the initial read position was 
intentional due to divergent well-established prior arts that neither group 
wanted to give up.  And yes, I also wish that someone had.  I even wish the 
committee had at least specified 'either 0 or EOF' to preclude a Solomonic 
compromise like EOF//2.

Terry J. Reedy