Re: [myhdl-list] Constant ints in interfaces

[Henry G. <he...@ca...>]

On 16/03/15 12:50, SHEN Chen wrote:
> On 2015-03-16 20:09, Henry Gomersall wrote:
>
>> >On 16/03/15 12:01, SHEN Chen wrote:
>> >
>>> >>For instance, do you think it's a good idea to have a Interface base
>>> >>class, and requires all interface to derive from the base class?
>> >
>> >This would seriously limit future potential, and restricts one's
>> >ability
>> >to use 3rd party classes - e.g. which I keep banging on about,
>> >IntEnum.
>> >
>> >All objects are interfaces!
>> >
> I guess by the last statement you meant that all objects that has
> attributes derived from _Signal are interfaces.
> Obviously there are also list of signals.
> How about dict of signals?
> How about nesting, i.e. objects' attributes that are objects?
> I hope there is a spec on supported features.

No, what I mean is that by imposing an additional restriction that 
Signals need to be part of some special object type, that also creates a 
significant and permanent point of divergence between the capabilities 
of Python and what is convertible.

One of the fundamental tenets of Python is that everything is an object 
(which is just a collection of other objects). That's what interfaces 
should be - don't limit future opportunity by what is possible now.

At its heart, the current situation is that all MyHDL objects represent 
a useful aspect of an HDL design, mostly with a one-to-one mapping to V* 
(coincidence?), with the control inferred from totally generic python 
code (albeit, that often doesn't convert). Special casing interfaces 
would mean that now there is a structure that is special only because it 
limits what can be done in MyHDL for the benefit of making the 
conversion easier, which IMO is backwards.

This does however, raise the bigger question of how should things be 
converted in general. I'd love to see a far more dynamic conversion 
process, whereby signals need only be identified through a running 
convertible object, as opposed to the current static approach, which I 
would suggest is the source of many frustrations (given Python's 
inherently dynamic nature).

> Btw, starting from Python2.2, new-style classes (derived from object)
> are just like built-in python types.
> So you really need to scan everything of everything in an object to
> extract all possible symbols.
> The Interface base-class idea was meant to simplify the scan. Of
> course, I only spent very little time on this, not sure if it's good or
> crappy idea.

Well, one can say at the moment Interfaces are defined only by 
attributes that live in an instance's `__dict__`. This is clean and well 
defined and supports most current usage, without limiting future scope. 
I imagine something like this _is_ how it is currently defined.

Given that, I think there is good grounds for defining precisely what 
constitutes an interface in the current implementation of the code.

>
> Sorry I didn't catch the discussion on IntEnum. Any pointer to previous
> discussions in the mail archive?

http://comments.gmane.org/gmane.comp.python.myhdl/3738

Cheers,

Henry