[issue15373] copy.copy() does not properly copy os.environment

Eryk Sun added the comment: In bpo-28824, I suggested preserving the case of environment variables in Windows by using a case-insensitive subclass of str in the encodekey() function. This is self-contained by the use of the encodekey() and decodekey() functions in the mapping methods such

[issue15373] copy.copy() does not properly copy os.environment

Max Katsev added the comment: Note that deepcopy doesn't work either, even though it looks like it does at the first glance (which is arguably worse since it's harder to notice): Python 3.8.6 (default, Jun 4 2021, 05:16:01) >>> import copy, os, subprocess >>> env_copy =

Re: copy.copy

Le 22/11/2021 à 16:02, Jon Ribbens a écrit : On 2021-11-22, ast wrote: For immutable types, copy(foo) just returns foo. ok, thx -- https://mail.python.org/mailman/listinfo/python-list

Re: copy.copy

On 2021-11-22, ast wrote: > Hi, > > >>> a = 6 > >>> b = 6 > >>> a is b > True > > ok, we all know that Python creates a sole instance > with small integers, but: > > >>> import copy > >>> b = copy.copy(a) > &

copy.copy

Hi, >>> a = 6 >>> b = 6 >>> a is b True ok, we all know that Python creates a sole instance with small integers, but: >>> import copy >>> b = copy.copy(a) >>> a is b True I was expecting False -- https://mail.python.org/mailman/listinfo/python-list

[issue15373] copy.copy() does not properly copy os.environment

Andrei Kulakov added the comment: I guess the easy way to test it would be to modify the copy and check os.environ, but still there would be some uncertainty if it's consistent across platforms and python versions, if it's expected to still work in future python versions, etc. asdict()

[issue15373] copy.copy() does not properly copy os.environment

Change by Anton Barkovsky : -- nosy: -anton.barkovsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15373] copy.copy() does not properly copy os.environment

Andrei Kulakov added the comment: I think the advantage of asdict() method is it's more discoverable and it doesn't leave any uncertainty of whether returned value will update environment or not. If a user sees `dict(os.environ)` in code, they may wonder if it does or does not; and there's

[issue15373] copy.copy() does not properly copy os.environment

Change by Ryan Mast (nightlark) : -- nosy: +rmast ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15373] copy.copy() does not properly copy os.environment

rs in favour of the removal. Removing the copy is a breaking change so it should be done on several releases. Are you interested by a PR which adds DeprecationWarning when copy.copy(os.environ) or os.environ.copy() are called? It seems to be the first step to implement. -- nosy: +sblondon ver

[issue15373] copy.copy() does not properly copy os.environment

Andrei Kulakov added the comment: I think it may be good to deprecate and discourage use of `os.environ.copy()`, and add a new method `os.environ.asdict()`. And possibly have `__copy__` raise an error pointing users to `os.environ.asdict()`. I'm not sure what to do about pickling.

[issue15373] copy.copy() does not properly copy os.environment

Change by Kamil Turek : -- nosy: +kamilturek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15373] copy.copy() does not properly copy os.environment

Josh Rosenberg added the comment: Would we remove the functionality of os.environ.copy()? It seems very odd for types to have a .copy() method that works, while not supporting copy.copy, especially when there is zero documentation, on the web or the docstring, to even hint at the difference

[issue15373] copy.copy() does not properly copy os.environment

Change by Irit Katriel : -- components: +Library (Lib) versions: +Python 3.10 -Python 3.7 ___ Python tracker ___ ___

[issue34999] copy.copy and deepcopy do return same logger objects in 3.7

Vinay Sajip added the comment: Closing as per Serhiy's advice - assume that's OK. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue34999] copy.copy and deepcopy do return same logger objects in 3.7

Serhiy Storchaka added the comment: So that I think we can close this issue, since this is not a bug, but an intentional behavior. copy.copy() also consider functions and classes as atomic, although they are not immutable, and there are use cases for making a modified copy

[issue34999] copy.copy and deepcopy do return same logger objects in 3.7

sebix added the comment: > I suggest as a workaround that a context manager approach could be used to > save and restore part of the logging configuration around various operations > (at least levels and handlers), as outlined here: >

[issue34999] copy.copy and deepcopy do return same logger objects in 3.7

Vinay Sajip added the comment: Loggers are singletons, so the pickling operation just pickles the name. Unpickling just leads to getting the pickled name and calling getLogger(name), which will return the same object that was pickled (I'd forgotten about issue30520). I suggest as a

[issue34999] copy.copy and deepcopy do return same logger objects in 3.7

sebix added the comment: Oh, that's something different than I initially thought. Using copy.deepcopy gives the same result as with copy.copy. -- title: Different behavior of copied loggers in 3.7 -> copy.copy and deepcopy do return same logger objects in 3.7 type: -> be

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Raymond Hettinger added the comment: > Perhaps all this deserves a PEP. If Serhiy and Kristján are on a course of action, that will suffice. Copying iterators is an esoteric endeavor of interest to very few users (no one has even noticed until now). --

[issue29897] itertools.chain behaves strangly when copied with copy.copy

. This is a behavior change. What if any code depends on the current behavior? This is silly, copy(filter) and copy(map) could just return the original iterator if this is a desirable behavior. 2. Depending on the copy module in the method of the builtin type looks doubtful. Should we implement copy.copy() in C

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Kristján Valur Jónsson added the comment: It is a tricky issue. How deep do you go?what if you are chaining several of the itertools? Seems like we're entering a semantic sinkhole here. Deepcopy would be too deep... The original copy support in these objects stems from the desire to support

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Raymond Hettinger added the comment: Serhiy, feel free to take this in whatever direction you think is best. -- assignee: -> serhiy.storchaka ___ Python tracker

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Serhiy Storchaka added the comment: Just for example there is a patch that implements in Python deeper copying for itertools.chain objects. I doesn't mean pushing it, it is too complicated. I have wrote also slightly simpler implementation, but it doesn't work due to the behavior of copied

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Michael Seifert added the comment: Just an update what doesn't work: just overriding the `__copy__` method. I tried it but it somewhat breaks `itertools.tee` because if the passed iterable has a `__copy__` method `tee` rather copies the iterator (=> resulting in a lot of unnecessary memory

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Serhiy Storchaka added the comment: This issue is related to the behavior of other composite iterators. >>> from copy import copy >>> it = map(ord, 'abc') >>> list(copy(it)) [97, 98, 99] >>> list(copy(it)) [] >>> it = filter(None, 'abc') >>> list(copy(it)) ['a', 'b', 'c'] >>> list(copy(it)) []

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Changes by Raymond Hettinger : -- assignee: rhettinger -> ___ Python tracker ___

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Serhiy Storchaka added the comment: chain(x) is a shortcut for chain.from_iterable(iter(x)). Neither copy.copy() nor __reduce__ don't have particular relation to this. Consider following example: >>> from itertools import chain >>> i = iter([[1, 2, 3], [4, 5, 6]]) >>&

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Raymond Hettinger added the comment: Humph, that is definitely not the expected result. The itertools copy/reduce support has been a never-ending source of bugs and headaches. It looks like the problem is that __reduce__ is returning the existing tuple iterator rather than a new one: >>> a

[issue29897] itertools.chain behaves strangly when copied with copy.copy

Changes by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___

[issue29897] itertools.chain behaves strangly when copied with copy.copy

New submission from Michael Seifert: When using `copy.copy` to copy an `itertools.chain` instance the results can be weird. For example >>> from itertools import chain >>> from copy import copy >>> a = chain([1,2,3], [4,5,6]) >>> b = copy(a) >>>

[issue15373] copy.copy() does not properly copy os.environment

INADA Naoki added the comment: I agree. os.environ is not dict, it's a proxy of "current" environment which is not copyable. So I agree to copy.copy() shouldn't copy os.environ implicitly. -- ___ Python tracker <rep...@bugs.pyth

[issue15373] copy.copy() does not properly copy os.environment

Raymond Hettinger added the comment: That patch would be fine except that I really agree with Antoine that an error should be raised. -- ___ Python tracker

[issue15373] copy.copy() does not properly copy os.environment

INADA Naoki added the comment: patch looks OK. But I prefer `__deepcopy__ = __copy__ = copy`. I don't know how to support pickling. (should unpickled object reference os.environ, or copied dict?) I feel it is different issue. -- nosy: +inada.naoki

[issue15373] copy.copy() does not properly copy os.environment

Raymond Hettinger added the comment: [Antoine] > I agree with David that copy(os.environ) is rather ambiguous. > I think the preferred idiom should be to call dict(os.environ). > As for __copy__, I don't know what it should do: perhaps > simply raise an error when copying is attempted? FWIW, I

[issue15373] copy.copy() does not properly copy os.environment

Serhiy Storchaka added the comment: If add support for the copy protocol, consider also adding support for deepcopying and pickling. -- nosy: +serhiy.storchaka ___ Python tracker

[issue15373] copy.copy() does not properly copy os.environment

Changes by Gregory P. Smith : -- keywords: +needs review nosy: +gregory.p.smith stage: -> patch review versions: +Python 3.7 -Python 3.4 ___ Python tracker

[issue28967] copy.copy fails on threading.local subclass

Ned Deily added the comment: Thanks for raising the issue, Jelle. And thanks for the analysis, Serhiy. It doesn't sound like a release blocker for 3.6.0. Is it worth addressing at all? -- assignee: ned.deily -> priority: release blocker -> normal versions: +Python 3.7

[issue28967] copy.copy fails on threading.local subclass

Serhiy Storchaka added the comment: copy.copy() didn't work correctly with threading.local in 3.x. It just silently created an empty instance (even not properly initialized, since __init__ is bypassed). Now it correctly raises TypeError. copy.copy() looks working in 2.7 because it copied

[issue28967] copy.copy fails on threading.local subclass

Jelle Zijlstra added the comment: This might be due to issue22995. -- ___ Python tracker ___ ___

[issue28967] copy.copy fails on threading.local subclass

New submission from Jelle Zijlstra: Calling copy.copy on a threading.local subclass copies attributes over correctly in Python 2.7, but creates an empty object in Python 3.3-3.5 and fails with a pickle-related error in 3.6. Marking this as a release blocker and assigning to Ned because

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

Raymond Hettinger added the comment: Then go ahead with the patch as is. -- ___ Python tracker ___ ___

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

Serhiy Storchaka added the comment: > This looks nicer and should run faster by taking advantage of the LIST_APPEND > opcode. The difference is insignificantly (less than 1%) for large lists (list(range(1))), but it is 3-4% slower for small lists (list(range(10))) and 20-25% slower for

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

Raymond Hettinger added the comment: One suggestion: def _deepcopy_list(x, memo, deepcopy=deepcopy): y = [] memo[id(x)] = y y[:] = [deepcopy(a, memo) for a in x] return y This looks nicer and should run faster by taking advantage of the LIST_APPEND opcode.

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

Serhiy Storchaka added the comment: If there are no other comments, I'm going to commit the patch in short time. -- ___ Python tracker ___

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

Serhiy Storchaka added the comment: Oh, sorry. Here is a patch. -- keywords: +patch Added file: http://bugs.python.org/file41679/copy_speedup.patch ___ Python tracker

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

Josh Rosenberg added the comment: Good point. Though I don't see any attached patches... -- ___ Python tracker ___

[issue26167] Improve copy.copy speed for built-in types

New submission from Josh Rosenberg: copy.copy uses a relatively high overhead approach to copying list, set and dict, using: def _copy_with_constructor(x): return type(x)(x) This is despite the fact that all three types implement a .copy() method, and there is already a defined

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

Changes by Josh Rosenberg <shadowranger+pyt...@gmail.com>: -- title: Improve copy.copy speed for built-in types -> Improve copy.copy speed for built-in types (list/set/dict) ___ Python tracker <rep...@bugs.python.org> <http

[issue26167] Improve copy.copy speed for built-in types (list/set/dict)

Serhiy Storchaka added the comment: methodcaller is not needed. We can use just list.copy etc. Proposed patch speeds up copying list, dict, set, bytearray, slice, NotImplemented. It makes deepcopying list, tuple, dict a little faster. It makes the code for copying and deepcopying using

[issue20791] copy.copy(bytes) is slow

New submission from Frank Millman: 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

[issue20791] copy.copy(bytes) is slow

Peter Otten added the comment: Assuming that the current behaviour is by accident here's a patch that adds the bytes type to the _copy_dispatch registry. -- keywords: +patch nosy: +peter.otten Added file: http://bugs.python.org/file34244/copy_bytes.patch

[issue20791] copy.copy(bytes) is slow

STINNER Victor added the comment: bytes is immutable, I don't why we would duplicate it. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20791 ___

[issue20791] copy.copy(bytes) is slow

Changes by Yury Selivanov yselivanov...@gmail.com: -- nosy: +yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20791 ___ ___

[issue20791] copy.copy(bytes) is slow

R. David Murray added the comment: 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. -- nosy: +r.david.murray versions: +Python 3.4, Python 3.5 ___ Python

[issue20791] copy.copy(bytes) is slow

Antoine Pitrou added the comment: 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/ -- nosy: +pitrou stage: - patch review versions: -Python 3.3 ___

[issue20791] copy.copy(bytes) is slow

Peter Otten added the comment: I did sign today (and received the confirmation email). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20791 ___

[issue20791] copy.copy(bytes) is slow

Roundup Robot added the comment: New changeset c2523bca50d7 by Antoine Pitrou in branch 'default': Issue #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 -- nosy: +python-dev

[issue20791] copy.copy(bytes) is slow

Antoine Pitrou added the comment: Ok, thank you! This will be in 3.4.1 and 3.5. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20791

[issue20791] copy.copy(bytes) is slow

STINNER Victor added the comment: Why not fixing this bug in Python 3.3 too? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20791 ___ ___

[issue20791] copy.copy(bytes) is slow

Antoine Pitrou added the comment: Is Python 3.3 still allowing bug fixes? If yes, this is a good idea. Do you want to backport it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20791 ___

[issue20791] copy.copy(bytes) is slow

R. David Murray added the comment: 3.3 will get fixes until its final release, which will be some time after the release of 3.4.0. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20791 ___

[issue20791] copy.copy(bytes) is slow

Roundup Robot added the comment: New changeset b3fb7828b6fc by Antoine Pitrou in branch '3.3': Issue #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

[issue15373] copy.copy() does not properly copy os.environment

Antoine Pitrou pit...@free.fr added the comment: I agree with David that copy(os.environ) is rather ambiguous. I think the preferred idiom should be to call dict(os.environ). As for __copy__, I don't know what it should do: perhaps simply raise an error when copying is attempted? --

[issue15373] copy.copy() does not properly copy os.environment

R. David Murray rdmur...@bitdance.com added the comment: Well, I think the fact that os.environ.copy is explicitly supported (and does indeed do dict(os.environ)) is an argument in favor of giving that same meaning to copy(os.environ). I think that follows the principle of least surprise.

[issue15373] copy.copy() does not properly copy os.environment

New submission from Hartmut Goebel h.goe...@crazy-compilers.com: Wehn copying os.environ usinf copy.copy(), any manipulation on the copied object will change os.environment, too. $ python Python 2.7.3 (default, Apr 22 2012, 07:46:58) [GCC 4.6.3] on linux2 Type help, copyright, credits

[issue15373] copy.copy() does not properly copy os.environment

R. David Murray rdmur...@bitdance.com added the comment: os.environ is not a dictionary, so it isn't all that surprising that a shallow copy doesn't behave like a shallow copy of a dictionary. deepcopy does what you'd expect, as does os.environ.copy(). Perhaps it is worth improving this by

[issue15373] copy.copy() does not properly copy os.environment

Anton Barkovsky swarmer...@gmail.com added the comment: Here's a patch. -- keywords: +patch nosy: +anton.barkovsky Added file: http://bugs.python.org/file26403/environcopy.patch ___ Python tracker rep...@bugs.python.org

[issue15373] copy.copy() does not properly copy os.environment

Anton Barkovsky swarmer...@gmail.com added the comment: A new patch with tests. -- Added file: http://bugs.python.org/file26404/environcopy_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15373

[issue9021] no copy.copy problem description

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 0e050b38e92b by Senthil Kumaran in branch '2.7': Issue #9021: Add an introduction to the copy module. Doc changes suggested by Terry Reedy. http://hg.python.org/cpython/rev/0e050b38e92b -- nosy: +python-dev

[issue9021] no copy.copy problem description

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset a352e24b9907 by Senthil Kumaran in branch '3.2': Issue #9021 - Introduce copy module better. Doc changes suggested by Terry http://hg.python.org/cpython/rev/a352e24b9907 New changeset bf6f306ad5cf by Senthil Kumaran

[issue9021] no copy.copy problem description

Senthil Kumaran sent...@uthcode.com added the comment: Added suggested changes to the documentation. Thanks. -- resolution: - fixed stage: - committed/rejected status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org

[issue9021] no copy.copy problem description

anatoly techtonik techto...@gmail.com added the comment: Perfectionist in me says that now copy.copy theory should be diluted with examples for those who can't grasp the concept of binding of variables, but the patch perfectly covers the original user story. Thanks

[issue9021] no copy.copy problem description

Senthil Kumaran orsent...@gmail.com added the comment: I am +0 on this change. The existing introduction is fine and the discussion where shallow and deep copy is discussed is more important. It is okay to assume that the reader is aware of the assignment operation nature, i.e. it does not

[issue9021] no copy.copy problem description

anatoly techtonik techto...@gmail.com added the comment: The doc change suggested by Terry could be helpful in the tutorial where a copy module is mentioned. Can you post a link to this tutorial here? -- ___ Python tracker rep...@bugs.python.org

[issue9021] no copy.copy problem description

Senthil Kumaran orsent...@gmail.com added the comment: Can you post a link to this tutorial here? Section 9.1 and 9.2 of the docs.python.org/tutorial It may not be as explicit as you might want it to be, but it does sets up background that assignments do not copy the object. --

[issue9021] no copy.copy problem description

Terry J. Reedy tjre...@udel.edu added the comment: The intro paragraph currently (3.2a) consists of This module provides generic (shallow and deep) copying operations. This could be expanded to ''' Assignment statements create bindings between a target and an object. They never duplicate or

[issue9021] no copy.copy problem description

Terry J. Reedy tjre...@udel.edu added the comment: Shorter and better version. Assignment statements create bindings between a target and an object. They never duplicate or copy an existing object. For collections that are mutable or contain mutable items, a copy is sometimes needed so one

[issue9021] no copy.copy problem description

, techtonik priority: normal severity: normal status: open title: no copy.copy problem description versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9021

[issue9021] no copy.copy problem description

Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9021 ___ ___

[issue7848] copy.copy corrupts objects that return false value from __getstate__

Changes by Georg Brandl ge...@python.org: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7848 ___ ___ Python-bugs-list

[issue7848] copy.copy corrupts objects that return false value from __getstate__

Albertas Agejevas a...@pov.lt added the comment: This bug is a duplicate of issue6827, sorry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7848 ___

[issue7848] copy.copy corrupts objects that return false value from __getstate__

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +alexandre.vassalotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7848 ___ ___

[issue7848] copy.copy corrupts objects that return false value from __getstate__

Changes by R. David Murray rdmur...@bitdance.com: -- priority: - normal resolution: - duplicate stage: - committed/rejected superseder: - deepcopy erroneously doesn't call __setstate__ if __getstate__ returns empty dict ___ Python tracker

[issue7848] copy.copy corrupts objects that return false value from __getstate__

New submission from Albertas Agejevas a...@pov.lt: When copy.copy is used on an object whose __getstate__ returns 0, it can produce a corrupt copy of an object: import copy class Foo(object): ... def __init__(self): ...self.value = 0 ... def __getstate__(self

[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

Alexandre Vassalotti alexan...@peadrop.com added the comment: Committed in r77437. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7382 ___

[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

Changes by Alexandre Vassalotti alexan...@peadrop.com: -- resolution: - accepted stage: test needed - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7382

[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +alexandre.vassalotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7382 ___ ___

[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

New submission from Sebastian Hagen sh_pyb...@memespace.net: In either python 3.0, bytes instances cannot be copied, and (even trivial) bytes subclasses cannot be unpickled unless they explicitly override __getnewargs__() or __reduce_ex__(). Copy problem: import copy; copy.copy(b'foo

[issue7382] bytes.__getnewargs__ is broken; copy.copy() therefore doesn't work on bytes, and bytes subclasses can't be pickled by default

R. David Murray rdmur...@bitdance.com added the comment: Confirmed on py3k trunk. We no longer do bug fixes in 3.0, which is why I'm removing it from versions. -- keywords: +easy nosy: +r.david.murray priority: - high stage: - test needed versions: +Python 3.2 -Python 3.0

Re: Problem using copy.copy with my own class

this work is to define the special __copy__ method [1], specifying explicitly how to create a copy of a Test instance: Normally (i.e. for pure Python classes that don't subclass a builtin other than object) copy.copy() is smart enough to know how to create a copy without an explicit __copy__

Re: Problem using copy.copy with my own class

(cls, arg1) def __init__(self, arg1, arg2): self.arg2 = arg2 if __name__ == '__main__': t = Test(0, 0) t_copy = copy.copy(t) Traceback (most recent call last): File copytest.py, line 12, in module t_copy = copy.copy(t) File /usr/lib/python2.5/copy.py, line 95, in copy

Re: Problem using copy.copy with my own class

): ^^^ The exception is saying that copy.copy is not providing this 3rd argument. I might be a bit dense, but what would arg2 be for? Isn't arg1 supposed to be the object instance you are copying from? If so, arg2 is superfluous. -- http://mail.python.org/mailman

Re: Problem using copy.copy with my own class

knows. Here it is: import copy class Test(int): def __new__(cls, arg1, arg2): ^^^ The exception is saying that copy.copy is not providing this 3rd argument. I might be a bit dense, but what would arg2 be for? Isn't arg1 supposed to be the object instance you

Re: Problem using copy.copy with my own class

En Thu, 24 Apr 2008 01:21:15 -0300, Gabriel Genellina [EMAIL PROTECTED] escribió: I agree. In case arg2 were really meaningful, use __getnewargs__ (see ) I forget to include the link: http://docs.python.org/lib/pickle-inst.html -- Gabriel Genellina --

Re: Problem using copy.copy with my own class

)     t_copy = copy.copy(t) First off, inheriting from a basic builtin type such as int and changing its constructor's signature is not typical; you should rethink your design unless you know what you're doing. One way to make this work is to define the special __copy__ method [1], specifying

Problem using copy.copy with my own class

(Pdb) myclass MyClass( 0, 0, 'A string', 123.45) (Pdb) copy.copy(myclass) *** TypeError: TypeError('__new__() takes at least 4 arguments (2 given)',) I see 4 arguments (actually, 5 because Python is passing cls invisibly to __new__). Does anyone have an idea what is going on here? I have

Re: Problem using copy.copy with my own class

On Tue, 22 Apr 2008 11:13:43 -0600, Jeffrey Barish wrote: By the way, I have simplified somewhat the code in the explanation. Please simplify the code to a minimal example that still has the problem and *show it to us*. It's hard to spot errors in code that nobody except you knows. --