Martin v. Löwis mar...@v.loewis.de 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
Mark Dickinson dicki...@gmail.com 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
STINNER Victor victor.stin...@haypocalc.com 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
Mark Dickinson dicki...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue4842
Mark Dickinson dicki...@gmail.com 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.
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I would call this a bug. Guido, do you concur?
--
assignee: - gvanrossum
nosy: +gvanrossum, rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4842
Raymond Hettinger rhettin...@users.sourceforge.net 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 rep...@bugs.python.org
New submission from Mark Dickinson dicki...@gmail.com:
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:
Guido van Rossum gu...@python.org 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
Mark Dickinson dicki...@gmail.com added the comment:
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file12592/issue4842.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4842
Antoine Pitrou pit...@free.fr 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 rep...@bugs.python.org
http://bugs.python.org/issue4842
Mark Dickinson dicki...@gmail.com 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
Changes by Guido van Rossum gu...@python.org:
--
nosy: -gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4842
___
___
Python-bugs-list
13 matches
Mail list logo
