[IronPython] expected behavior of the module copy with .net objects

Dino Viehland dinov at microsoft.com
Thu Oct 14 19:58:51 CEST 2010


Ahh, well if it's ASP.NET it's all multi-threaded because you're probably handling more than one request at a time.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pablo Dalmazzo
Sent: Thursday, October 14, 2010 4:49 AM
To: IronPython Mailing list
Subject: Re: [IronPython] expected behavior of the module copy with .net objects

thanks for the reply Dino, If I get any additional info  about it, I'll post it.

In one application (which triggered the error you mentioned it) Im using an asp.net timer. That runs in another thread, right?

Greetings, Pablo


________________________________
From: dinov at microsoft.com
To: users at lists.ironpython.com
Date: Wed, 13 Oct 2010 19:47:04 +0000
Subject: Re: [IronPython] expected behavior of the module copy with .net objects
I think as of now copy is certainly not suitable for all .NET objects.  For starters not all .NET objects are serializable/copyable.  There should probably be some effort to close the gaps where it makes sense.  For example something which implements ICloneable could have a __copy__ method added to it.  This is similar to how we add a __reduce_ex__ method for things which implement ISerializable.  But if something doesn't implement either of these interfaces then there's no standard way for us to copy these objects.

If you have specific object types which you know you need to copy I would suggest registering the type with copy_reg.  That should at least give you a solution for your specific scenarios.

You also mentioned the null reference exception ("object reference not set to object instance...").  That sounds like a bug - I would guess you're running in a multi-threaded environment?  If you could get a repro of this that'd be great as it looks like it could be an issue w/ our dictionary implementation not being thread safe.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Pablo Dalmazzo
Sent: Wednesday, October 13, 2010 11:51 AM
To: IronPython Mailing list
Subject: [IronPython] expected behavior of the module copy with .net objects

Hi guys,

Sorry for being annoying about this but I just want to know where I'm standing at :)

It would seem to me the copy module has some problems copying .net objects in general. I was wondering if I'm pretending too much for that module and it will never fully copy  objects instantiated from .net classes, or it's a goal  for it to do it someday, or I just happened to find a couple of errors, or Im not using it rightly for what it was meant to be. I dont know 5% of what you know so it's an honest question :)

Aside there are a couple of errors I cant reproduce, and that it didnt copy System.DBNull , now I see it loses property values when copying
a System.Data.SqlConnection object, properties such as "DataSource", "DataBase", etc. they get empty strings after being copied. Just in case
I tried with the original version of the module/file copy. I guess you have thousands of things to check but I just want to know, it's the module supposed to copy any object instantiated from .net classes or it's only supposed to fully work only for custom made classes?

Greetings, Pablo Dalmazzo

P.S: sorry about insisting again with this but I've also added another example where it seems to fail :)









_______________________________________________ Users mailing list Users at lists.ironpython.com<mailto:Users at lists.ironpython.com> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20101014/cc48b288/attachment.html>


More information about the Ironpython-users mailing list