[issue4842] int('3L') still valid in Python 3.0

Mark Dickinson added the comment: Re: specification of the pickle formats. There's a fairly detailed description of all the opcodes already in the pickletools module, so the main task would be to extract those descriptions and put them into the documentation somewhere. Perhaps the documenta

[issue4842] int('3L') still valid in Python 3.0

Mark Dickinson added the comment: Thanks, Martin. Fixed in py3k in r68814 and r68815, and merged to 3.0 release branch in r68818. -- status: open -> closed ___ Python tracker _

[issue4842] int('3L') still valid in Python 3.0

Martin v. Löwis added the comment: We should really start maintaining a specification of the pickle format(s). Pickle is designed to be independent of the Python version, although protocol extensions may be added over time. In such a specification, it would say that the format of the L code is "

[issue4842] int('3L') still valid in Python 3.0

Mark Dickinson added the comment: Does anyone have time to review these patches? I think the first is straightforward, and I'm reasonably sure of the correctness of the second patch. I'm less sure that it's the right thing to do. The question is what should happen when pickling an integer

[issue4842] int('3L') still valid in Python 3.0

STINNER Victor added the comment: I like the new patches: break int("3L") but keep pickle compatibility. I already noticed the "L" suffix problem when I was hacking the long type in Python 3.x (eg. by using GMP instead of builtin library). -- nosy: +haypo

[issue4842] int('3L') still valid in Python 3.0

Changes by Guido van Rossum : -- nosy: -gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue4842] int('3L') still valid in Python 3.0

Mark Dickinson added the comment: I guess that makes this a release blocker for 3.0.1, then. Here's a second patch, complementary to the first, that fixes pickling of longs so that pickle protocol 0 in Python 3.0.1 and later behaves identically to pickle protocol 0 in Python 2.x. Namely: -

[issue4842] int('3L') still valid in Python 3.0

Guido van Rossum added the comment: After reading all that I still think we should fix this now, and fix pickle so that it can read (and write?) 2.x pickles. This is much less visible than cmp() still being present in 3.0, and we've already decided to kill that in 3.0.1, so we can kill int('3L'

[issue4842] int('3L') still valid in Python 3.0

Raymond Hettinger added the comment: Consider marking the 'L' code as deprecated and removing it in 3.1; otherwise, this artifact may hang around forever. ___ Python tracker ___ _

[issue4842] int('3L') still valid in Python 3.0

Antoine Pitrou added the comment: If it breaks pickle it may also break user-defined data formats. I think it is fine to continue support it. -- nosy: +pitrou ___ Python tracker

[issue4842] int('3L') still valid in Python 3.0

Mark Dickinson added the comment: Here's the issue with pickle: with this patch, the pickle of a long using pickle protocol 0 under 2.x can't be read by Python 3.x, because (1) the pickled long includes a trailing L, and (2) unpickling goes via a call to PyLong_FromString. Maybe the simples

[issue4842] int('3L') still valid in Python 3.0

Mark Dickinson added the comment: This patch currently causes test_pickle to fail (and test_random, but that failure is also pickle related). Am investigating. ___ Python tracker ___ __

[issue4842] int('3L') still valid in Python 3.0

Raymond Hettinger added the comment: I would call this a bug. Guido, do you concur? -- assignee: -> gvanrossum nosy: +gvanrossum, rhettinger ___ Python tracker ___

[issue4842] int('3L') still valid in Python 3.0

Mark Dickinson added the comment: Here's a patch. -- keywords: +patch Added file: http://bugs.python.org/file12592/issue4842.patch ___ Python tracker ___

[issue4842] int('3L') still valid in Python 3.0

New submission from Mark Dickinson : int('3L') is still valid in Python 3.x. Presumably this is unintentional. Is there any possibility of changing this for 3.0.1 or 3.1? -- components: Interpreter Core messages: 79121 nosy: marketdickinson severity: normal status: open title: int('3L