bugpyFormex - Bugs: bug #43940, Cannot deepcopy PropertyDB

 
 

bug #43940: Cannot deepcopy PropertyDB

Submitted by:  francesco <francio>
Submitted on:  Mon 05 Jan 2015 05:52:09 PM UTC  
 
Category: CoreSeverity: 3 - Normal
Item Group: Functionality errorStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Open

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Thu 08 Jan 2015 03:43:00 PM UTC, comment #5:

The original message states that the problem is in the Dict class. After inspection, I doubt this. The Dict implements its own _deepcopy_ which seems to work well.

I have a problem with the PropertyDB _deepcopy_ though: it overrides the Dict's _deepcopy_ and does not set the default attribute as required by the Dict class.

Further, as I mentioned in comment https://savannah.nongnu.org/bugs/?43940#comment3, the initialization of a PropertyDB includes a side effect: a session global materials and section database is created. Should this be done when doing a deepcopy or not, should these databases be PropertyDB owned or not? I would think so.

Benedict Verhegghe <bverheg>
Project Administrator
Thu 08 Jan 2015 02:49:44 PM UTC, comment #4:

So you want the fix in the Dict class? I did not touch it as
I thought you meant it like that.
It is something you should do or give suggestions on how you want to deal with it.

The rest about the PropertyDB I did not really understand what you mean.

francesco <francio>
Project Member
Wed 07 Jan 2015 06:39:55 PM UTC, comment #3:

Since the problem is in Dict, it should be fixed there.

The PropertyDB class was conceived as a single database for the non-geometrical model data. If you have a use for multiple PropertyDB instances, you should probably think about how you would like to handle the current side effects with the single module level variables for the material and section databases. These should probably become class attributes.

Benedict Verhegghe <bverheg>
Project Administrator
Tue 06 Jan 2015 12:34:24 PM UTC, comment #2:

Benedict
I was investigating a bit more. this problem will actually occur in all the inheritances of Dict without the 'default' key in the _init_. Shall we look for a general solution?

francesco <francio>
Project Member
Tue 06 Jan 2015 01:29:34 AM UTC, comment #1:

in commit 876b825 I overrode the _deepcopy_ method in the PropertyDB class to overcome the issue.

The error in the previous comment was not complete. here I report it again.

Traceback (most recent call last):
File "/home/Francesco/Desktop/postdoc/peterbif/simulationsAngles/606060_3045/postdilation/stentinsertionCatheterTestwithstentenlarg1LipWithImport1.py", line 69, in <module>
P1=copy.deepcopy(P)
File "/usr/lib/python2.7/copy.py", line 174, in deepcopy
y = copier(memo)
File "/home/Francesco/pyformex/pyformex/mydict.py", line 251, in _deepcopy_
newdict = self.__class__(default=self._default_)
TypeError: _init_() got an unexpected keyword argument 'default'

francesco <francio>
Project Member
Mon 05 Jan 2015 05:52:09 PM UTC, original submission:

The problem is in the Dict class
if I have a PropertyDB class P and I try

P1=copy.deepcopy(P)

I get this error

File "/home/Francesco/pyformex/pyformex/mydict.py", line 251, in _deepcopy_
newdict = self.__class__(default=self._default_)

I cannot find a way to solve this

francesco <francio>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bverheg (Posted a comment)
  • -unavailable- added by francio (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 06 Jan 2015 01:29:34 AM UTCfrancioStatusNone=>Fixed

    Back to the top


    Powered by Savane 3.1-cleanup1