Re: [myhdl-list] intbv wrap

[Ben <ben...@gm...>]

On Wed, May 4, 2011 at 10:00, Christopher Felton <chr...@gm...> wrote:
> At this point in time I am going to defer converting the wrap function
> as briefly discussed in other threads.  It is beyond my current
> capabilities.  But this doesn't change the approach.  It simply means
> the wrap can only be used as an attribute of the intbv object, thank you
> Tom Dillon for the pointer here.

Looks like a good idea. See my comments bellow.

>
> It also seemed appropriate to add a property for _val, see the following.
>
>     # val property
>     def _get_val(self):
>         return self._val
>
>     def _set_val(self, pval):
>
>         if self._wrap:
>             self._val = self.wrap(pval)

do both _wrap and wrap exists ?

>         else:
>             self._val = pval
>
>         self._checkBounds()
>
>     val = property(_get_val, _set_val)

I guess you'd better like to call the property _val and put its
internal value inside __val. This way you minimize your impact on the
rest of the code.

>
>
> This had been discussed in some older threads.  Are there any objections
> against this type of implementation?  The _checkBounds and wrap will be
> called only from the _set_val property function.
>
> Above self._wrap is a data member initialized in the constructor based
> on a parameter.
>
> def __init__(self, val=0, min=None, max=None, wrap=False, _nrbits=0):

My understanding is that in the constructor, if wrap is a boolean
(isinstance(wrap, boolean)), and equal to True, then do the regular
wrapping (modulo max), otherwise if set to False, don't do wrapping
(same as now), in a third case, one could give a function to use as
parameter like for instance one that throw an overflow exception when
it occurs:

def mywrapfunc(self, val):
    if val > self._max or val < self._min:
      raise OverflowException()
    self._val = val

this function would simply be given as parameter to the constructor
like intbv(wrap=mywrapfunc).

I can try to put together a real patch with tests this evening ...
can't promise it though.

@Tom: backward compatibility is a must there.

Regards,
Benoît