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?

Here's a patch.

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

This patch currently causes test_pickle to fail (and test_random, but that 
failure is also pickle related).  Am investigating.

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.

If it breaks pickle it may also break user-defined data formats. I think
it is fine to continue support it.

Consider marking the 'L' code as deprecated and removing it in 3.1;
otherwise, this artifact may hang around forever.

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.

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.

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).

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.

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.

Thanks, Martin.

Fixed in py3k in r68814 and r68815, and merged to 3.0 release branch in 
r68818.

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.