Best practise implementation for equal by value objects

[Slaunger]

On 7 Aug., 21:19, Terry Reedy <tjre... at udel.edu> wrote:
> Slaunger wrote:
> > On 6 Aug., 21:36, Terry Reedy <tjre... at udel.edu> 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...