RetroSearch Browse

Tue Oct 18 02:20:39 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-October/114122.html

Le lundi 17 octobre 2011 23:27:09, Antoine Pitrou a écrit :
> On Mon, 17 Oct 2011 02:04:38 +0200
> 
> Victor Stinner <victor.stinner at haypocalc.com> wrote:
> > Le lundi 17 octobre 2011 01:16:36, Victor Stinner a écrit :
> > > For example, IN.INT_MAX is 2147483647, whereas it should
> > > be 9223372036854775807 on my 64-bit Linux.
> > 
> > Oops, wrong example: INT_MAX is also 2147483647 on 64 bits. I mean
> > IN.LONG_MAX.
> > 
> > IN.LONG_MAX is always 9223372036854775807 on Linux, on 32 and 64 bits
> > systems.
> 
> Given the issues you are mentioning, and given they were never
> reported in years before, it seems unlikely anybody is using these
> files.
> 
> +1 to remove them, as they don't seem documented either.

Oh, there are other (new?) problems listed in last comments of the issue 
#12619. The Mac OS X issue is funny. Extracts:

"What do you do for platforms like OS X where we support one set of binary 
files that contain multi-architecture C-files that can run as Intel-64, Intel-32 
or PPC-32 on the same machine at user option at run time? (...) The static 
IN.py currently shipped in plat-darwin is misleading at best."

"-1 on auto-building. The header needed may not be available on the build 
platform, (...)"

"There is no reason to keep plat-xxx files if cannot be managed properly."

Victor

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-October/114122.html below:

[Python-Dev] Modules of plat-* directories