Using copy.copy on a byte string returns a new copy instead of the original immutable object. Using copy.deepcopy returns the original, as expected. Testing with timeit, copy.copy is much slower than copy.deepcopy.

>>> import copy
>>>
>>> a = 'a'*1000  # string
>>> copy.copy(a) is a
True
>>> copy.deepcopy(a) is a
True
>>>
>>> b = b'b'*1000  # bytes
>>> copy.copy(b) is b
False
>>> copy.deepcopy(b) is b
True

Assuming that the current behaviour is by accident here's a patch that adds the bytes type to the _copy_dispatch registry.

bytes is immutable, I don't why we would duplicate it.

We probably just forgot to add it when the bytes type was added, and there was of course no test that would fail since it was a new type.

Thanks for the patch, Peter. Could you sign a contributor's agreement? You can do so online at http://www.python.org/psf/contrib/contrib-form/

I did sign today (and received the confirmation email).

New changeset c2523bca50d7 by Antoine Pitrou in branch 'default':
Issue bpo-20791: copy.copy() now doesn't make a copy when the input is a bytes object. Initial patch by Peter Otten.
http://hg.python.org/cpython/rev/c2523bca50d7

Ok, thank you! This will be in 3.4.1 and 3.5.

Why not fixing this bug in Python 3.3 too?

Is Python 3.3 still allowing bug fixes?
If yes, this is a good idea. Do you want to backport it?

3.3 will get fixes until its final release, which will be some time after the release of 3.4.0.

New changeset b3fb7828b6fc by Antoine Pitrou in branch '3.3':
Issue bpo-20791: copy.copy() now doesn't make a copy when the input is a bytes object. Initial patch by Peter Otten.
http://hg.python.org/cpython/rev/b3fb7828b6fc