On Wed, May 29, 2019 at 9:34 PM Ricky Teachey <ri...@teachey.org> wrote:
> Seems to me that namespace collisions are a possibility no matter what
> namespace you are working in, right? If you are in the global (module)
> namespace, and use up a, b, and c, that doesn't seem any different to me than
> using up ns.a, ns.b, and ns.c.
I am talking about each function definition, which when using this
approach, effectively has to have its own namespace. e.g. at each of
the function start:
def process(self):
ns = HDL()
ns.x = 3
ns.y = 4
def another_process(self):
ns = HDL()
ns.x = 5
ns.y = 6
Compare with this:
def process(self):
x = Signal(width=32, value=0)
y = Signal(width=16, value=0)
def another_process(self):
x = Signal(w=32,v=0)
y = Signal(w=8,v=0xFF)
Where should the signal attributes go for the namespace case? hmmm ...
or maybe one namespace for each and every signal like this:
def process(self):
x = HDL(w=32,v=0)
x.signal = 5 # only one signal or one type of signal allowed for
each name space!
y = HDL(w=8,v=0xFF)
y.signal = 6 # ...
You see, eventually this is not better than just arbitrary object and
use obj.next = 5 ...
I really think the separation of declaration and use ... is sometimes
important (you don't have to be forced to use it, but you'd better be
able to use it).
> In fact, you could say it expands your namespace. You can have multiple HDL
> namespaces and interact between them without any problems:
>
> # these will be descriptors that store Signal instances
> ns1.x = 1
> ns2.x = 2
> # you can combine them into another namespace
> ns3.x = ns1.x+ns2.x
> # or into an existing namespace
> ns1.y = ns1.x+ns2.x
> # or put them into a data structure
> x = [ns1.x, ns2.x, ns3.x]
> # and pull them back out again:
> ns4.a, ns4.b, ns4.c = x
>
> Behavior is preserved in all cases.
>
see above.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
