On 7 Aug., 21:19, Terry Reedy <[EMAIL PROTECTED]> wrote: > Slaunger wrote: > > On 6 Aug., 21:36, Terry Reedy <[EMAIL PROTECTED]> wrote: > > OK, the situation is more complicated than that then. In the case here > > though, > > the attributes would always be sinmple bulit-in types, where > > eval(repr(x))==x > > or, where the attribute is a user-defined equal-by-value class, that I > > have > > control over. > > I think most would agree that a more accurate and informative > representation is better than a general representation like Pythons > default. For instance, > >>> a=range(2,10,2) # 3.0 > >>> a > range(2, 10, 2) > > is nicer than <class 'range' object at ######>. > > So when the initializers for instances are all 'nice' (as for range), go > for it (as in 'Age(10)'). And test it as you are by eval'ing the rep. > Just accept that the eval will only work in contexts with the class name > bound to the class. For built-in like range, it always is, by default > -- unless masked by another assignment! > OK, i am encouraged to carry on my quest with the eval(repr)) for my 'nice' classes. I just revisited the documentation for eval and noticed that there are optional globals and locals name space variables, that one could specify:
http://docs.python.org/lib/built-in-funcs.html Quite frankly I do not understand how to make use of these parameters, but it is my feeling that if I enforce a convention of always specifying the globals/locals parameter in a specific manner: assert eval(repr(x), globals, locals) == x would work independent of how I have imported the module under test. Now, I just need to figure out if this is right and how to specify the globals and locals if that is not too cumbersome... or maybe I am just over-engineering... -- http://mail.python.org/mailman/listinfo/python-list
