[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Eric Snow
Eric Snow added the comment: > I don't see why a new pyc magic number should be necessary. Python > continues to support the existing files. Good point. -- ___ Python tracker __

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Martin v . Löwis
Martin v. Löwis added the comment: For the truncation, see ec7267fa8b84. I don't see why a new pyc magic number should be necessary. Python continues to support the existing files. -- ___ Python tracker __

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Eric Snow
Eric Snow added the comment: Looks like the Misc/NEWS entry got truncated. Also, does this change need a new PYC magic number (now in Lib/importlib/_bootstrap.py)? -- ___ Python tracker __

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Martin v . Löwis
Martin v. Löwis added the comment: I put the complete removal of TYPE_INT64 into issue15480 -- ___ Python tracker ___ ___ Python-bugs-

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Martin v . Löwis
Changes by Martin v. Löwis : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Amaury Forgeot d'Arc
Amaury Forgeot d'Arc added the comment: Removing TYPE_INT64 was indeed the most reasonable choice. -- ___ Python tracker ___ ___ Pytho

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Eric Snow
Changes by Eric Snow : -- versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Roundup Robot
Roundup Robot added the comment: New changeset 461e84fc8c60 by Martin v. Löwis in branch 'default': Issue #15466: Stop using TYPE_INT64 in marshal, http://hg.python.org/cpython/rev/461e84fc8c60 -- nosy: +python-dev ___ Python tracker

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Eric Snow
Eric Snow added the comment: > I suggest the opposite: never emit TYPE_INT64 at all. For > compatibility, we can still support reading it in 3.3 (and drop > that support in 3.4). +1 essentially we maintain the status quo -- nosy: +eric.snow ___ Pyth

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Amaury Forgeot d'Arc
Amaury Forgeot d'Arc added the comment: Are there really platforms which don't use two's complement? (If there are, I'm not sure to want to share binary data with them. Same for EBCDIC) -- ___ Python tracker

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Martin v . Löwis
Martin v. Löwis added the comment: Serhiy: this is safe to ignore. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Serhiy Storchaka
Changes by Serhiy Storchaka : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: I can see yet another problem under the hood. Marshalling will output different data on platforms with a different representation of negative numbers. Worse still, these data are non-portable, written on one platform will be read incorrectly on the other. M

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Amaury Forgeot d'Arc
Amaury Forgeot d'Arc added the comment: Here is a patch that write TYPE_INT64 on most platforms (where either long or long long is 64bit). It is admittedly much larger than Martin's... -- Added file: http://bugs.python.org/file26554/marshal_use_int64.patch

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Martin v . Löwis
Martin v. Löwis added the comment: Here is a patch to stop generating TYPE_INT64. Ok for 3.30b2? -- keywords: +patch priority: high -> release blocker Added file: http://bugs.python.org/file26553/marshal.diff ___ Python tracker

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-28 Thread Martin v . Löwis
Martin v. Löwis added the comment: I suggest the opposite: never emit TYPE_INT64 at all. For compatibility, we can still support reading it in 3.3 (and drop that support in 3.4). -- nosy: +loewis ___ Python tracker

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-27 Thread Brett Cannon
Changes by Brett Cannon : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-27 Thread Amaury Forgeot d'Arc
Amaury Forgeot d'Arc added the comment: My primary goal is to have a stable importlib.h, and currently all developer work on machines where PY_LONG_LONG is >64bit. So the restriction is OK. -- ___ Python tracker

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-27 Thread Antoine Pitrou
Antoine Pitrou added the comment: > I suggest to remove this distinction, and allow TYPE_INT64 on all > platforms. You have to find a 64-bit C int type that works on all platforms and for which a PyLongAsXXX() function exists, though. Or perhaps you want to restrict yourself to systems which

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-27 Thread Amaury Forgeot d'Arc
Amaury Forgeot d'Arc added the comment: I realize that uppercase I and lowercase L are easily confused: On first row, 'I' (=TYPE_INT64) followed by 0x on 8 bytes. On second row, 'l' (=TYPE_LONG) followed by 3 followed by 0x (in 3 chunks of 15 bits). -- ___

[issue15466] Python/importlib.h is different on 32bit and 64bit

2012-07-27 Thread Amaury Forgeot d'Arc
New submission from Amaury Forgeot d'Arc : As shown in a patch in issue15431, frozen.c does not output the same data on different platforms. The first difference looks like this (extracted from the patch): -101,73,255,255,255,255,0,0,0,0,40,10,0,0,0,117, +101,108,3,0,0,0,255,127,255,127