Python 1.5.2 and large files (Solaris 7)

[Steve Clift]

Hrvoje Niksic wrote:
>Steve Clift <clift at mail.anacapa.net> writes:
>
>> I thought about making the return values switch types automatically
>> depending on their magnitude, but eventually decided that was a bit
>> on the weird side. The test suite ran OK with plain Python longs, so
>> I left it that way. Also, getting a long back is a clue that large
>> file support is enabled.
>
>The question you have to ask yourself is whether the programmer really
>needs such a clue.  I think it's a generally good idea to simply
>return the correct value.  If it fits in an Int, it should be an Int,
>if not, not.
>
>Or, do you think doing so would actually break something?  I'm not
>very familiar with Python's number system, but I know that Python is
>unable to promote Ints to Longs automatically -- for example,
>1+sys.maxint overflows, while 1L+sys.maxint doesn't.

I don't think it would break anything - longs and ints seem
to be interchangeable for most reasonable purposes (e.g. the
Python test suite is happy with either as file sizes/pointers).
I guess you can argue this either way. Given a choice between:

a) The interpreter looks indistinguishable from the
   non-large-file version under most circumstances, but
   your program has a fit when a large file leaps out
   of the shrubs and unexpectedly hands you a long.

b) Your program has a fit immediately because it always
   gets a long.

I prefer b) because it's not a time bomb. It also keeps the
C code a bit simpler, modulo the "stinking pile of ifdefs"
required to implement this stuff in the first place. That's
the rationale behind the current behaviour. However, I don't
feel that strongly about it. Anyone else?

>Speaking of configuration, I also think it would be great if you added 
>support for configure to do these things, so that the user can just
>write:
>
>    ./configure --enable-large-file
>
>...and that configure does the rest.

Agreed. Just when you hoped you were free, it's Autoconf Day again.

-Steve