Am 24.10.2011 14:06, schrieb Victor Stinner:
> There are open issues related to plat-XXX.
>
> Le Lundi 24 Octobre 2011 00:03:42 Martin v. Löwis a écrit :
>> no, we make no changes to them unless a user actually requests a change
>
> Matthias Klose asked for socket SIO* constants in september 2006
There are open issues related to plat-XXX.
Le Lundi 24 Octobre 2011 00:03:42 Martin v. Löwis a écrit :
> no, we make no changes to them unless a user actually requests a change
Matthias Klose asked for socket SIO* constants in september 2006 (5 years
ago).
http://bugs.python.org/issue1565071
I
>> So why remove them?
>
> Not worrying whether we should maintain these files or not would be a
> reason. Not worrying whether we should document them (or provide a
> better way to access these facilities) is another.
Don't worry whether, I tell you :-) Yes, we maintain them, and no,
we make no
> -1. If they were broken, and somebody used them, a bug would be
> reported. That no bug is being reported means that they either
> work fine, or nobody uses them.
>
> In the former case, removing them will break somebody's code.
> In the latter case, nothing is gained by either keeping or remov
> I don't understand why we kept modules of the plat-* directories (e.g.
> Lib/plat-linux/CDROM.py).
Because they are useful. There is no reasonable other way at getting at
the information in the modules for a Python program that may need them.
> These modules are not regenerated when Python is
> 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.
-1. If they were broken, and somebody used them, a bug would be
reported. That no bug is bein
Le lundi 17 octobre 2011 23:27:09, Antoine Pitrou a écrit :
> On Mon, 17 Oct 2011 02:04:38 +0200
>
> Victor Stinner 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
On Mon, 17 Oct 2011 02:04:38 +0200
Victor Stinner 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 me
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,
