[IronPython] bug with copy.copy of System.Int64?

[Dino Viehland]

This is because we don't define a custom __getnewargs__ for .NET data types.  Therefore when the copy module tries to create the new instance it has no arguments and creates the default value - you'll get the same behavior with any random value type that isn't also a type in Python's type system.  For other random .NET types you may or may not get a new instance (depending on whether or not the type has a parameterless constructor).  We of course do define this for types like int because our int is Python's int.

We could presumably support this with some value types: for example the primitive types such as Int64 (decimal, char, etc...) and types like enums where it's well-understood how to construct the value type.  But we couldn't support it on arbitrary types.  We could also even considering pushing this further and support any type which is serializable (at which point __reduce_ex__ would return a function which does the deserialization, and __getnewargs__ would return the serialized data).

I've opened a feature request on CodePlex (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13401) to track this.  If you (and anyone else who thinks this would be cool) would vote for the feature then it'll help us get the right priority on it.

Thanks for the report!

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ronnie Maor
Sent: Friday, October 19, 2007 2:38 PM
To: users at lists.ironpython.com
Subject: [IronPython] bug with copy.copy of System.Int64?

I stumbled across the following problem copying System.Int64:

C:\>ipy

IronPython 1.1 (1.1) on .NET 2.0.50727.832

Copyright (c) Microsoft Corporation. All rights reserved.

>>> import copy

>>> from System import Int64

>>> x = Int64(3)

>>> x

3L

>>> copy.copy(x)

0L

>>> copy.deepcopy(x)

0L


Has anyone else come across this problem? Are there other types that will produce wrong copies?

My current workaround is to convert the Int64 to a long.

Some more notes:
I'm using IronPython 1.1 with CPython 2.4 standard library.
Doesn't happen with Int32

thanks
Ronnie

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20071019/88a8554b/attachment.html>