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

[Mark Dickinson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 simplest thing is to continue to let int('3L') be valid.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I would call this a bug.  Guido, do you concur?

--
assignee:  -> gvanrossum
nosy: +gvanrossum, rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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') still valid in Python 3.0
type: behavior
versions: Python 3.0, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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') as well.

--
assignee: gvanrossum -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

Mark Dickinson  added the comment:

Here's a patch.

--
keywords: +patch
Added file: http://bugs.python.org/file12592/issue4842.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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:

 - an 'L' is always appended on output, and
 - an 'L' is permitted, but not required, on input

This keeps compatibility both with 2.x and with 3.0.0.

issue4842_pickle.patch should be applied before issue4842.patch.

--
priority:  -> release blocker
stage:  -> patch review
Added file: http://bugs.python.org/file12610/issue4842_pickle.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

Changes by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 using the LONG opcode (pickle 
protocol 0).  The options are:

- append an 'L' on output in 3.x; accept input with and without trailing
  'L'.  This is what the patch does.  The only downside is the
  continuing presence of the 'L' in 3.x, which some might object to.

- don't append an 'L' on output in 3.x; accept input with and without
  trailing 'L'.  This would retain compatilbiity, but would mean that
  we can get different output *for the same opcode* with 2.x and 3.x.
  I don't think there's a precedent for this, but I can't see why it
  would be harmful.  Still, it seems safer not to do it.

- don't append an 'L' on output in 3.x, and reject input with a trailing
  'L' in 3.x.  This would make 3.x and 2.x pickles incompatible with
  each other, and breaks some tests.  Seems like a bad idea all around to
  me.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Martin v. Löwis]

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 "ascii
decimal digits, followed by L".

The patches look fine to me, please apply.

A further change might be that on pickling a long in text mode, the I
code could be used if the value is in range(-2**31,2**31). However, this
is independent of the issue at hand.

--
assignee:  -> marketdickinson
nosy: +loewis
resolution:  -> accepted

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Dickinson]

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 documentation for the pickletools module itself would be an 
appropriate place, if there were also a link from the pickle 
documentation.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com