On 5/25/2019 3:09 PM, Yanghao Hua wrote:
@= has all the same issues like <<= or >>=,
No, it does not
in that you are basically
sacrificing a well known number operation
because @= is not a number operation at all.
I admit this (@=) is a much rarer case,
It is a different case.
but
I don't really understand HDL/Verilog, but I've worked with people who do.
In fact, I even wrote a pre-processor that transformed the same DSL to
Python, C++, and Verilog.
In my mind, the HDL use case is FAR too narrow and specialized to warrant a
new arrow operator, let an entirely new parser
On Sat, May 25, 2019 at 8:28 PM Terry Reedy wrote:
>
> On 5/24/2019 4:25 PM, Yanghao Hua wrote:
> > On Fri, May 24, 2019 at 5:45 PM Terry Reedy wrote:
> >> What I understand is that you are doing discrete-time hardware
> >> simulation and that you need a operator that will schedule future
> >>
On 5/24/2019 4:25 PM, Yanghao Hua wrote:
On Fri, May 24, 2019 at 5:45 PM Terry Reedy wrote:
What I understand is that you are doing discrete-time hardware
simulation and that you need a operator that will schedule future
assigments to int-like objects. Have you considered using '@' to do
On Fri., May 24, 2019, 12:48 Batuhan Taskaya, wrote:
> > changing this will probably break code
> It is why i'm suggesting making the real transition at 4.0 and adding a
> future flag for now.
> > And so you need to justify *why* you think that's acceptable
> I dont know it is acceptable or not,
On Sat, May 25, 2019 at 11:24 AM Anders Hovmöller wrote:
> process() in A could look like:
>
> self.send(output=5)
>
> To me that looks OK, and scales nicely with multiple outputs:
>
> self.send(a=5, b=3)
>
> send() is implemented simply as
>
> def send(self, **kwargs):
> for k, v in
> On 24 May 2019, at 22:11, Yanghao Hua wrote:
>
>> On Fri, May 24, 2019 at 3:27 PM Ricky Teachey wrote:
>> This seems like a hurdle you're going to have trouble passing... especially
>> given that all the functionality that is required can be provided using
>> existing descriptor
On Fri, May 24, 2019 at 10:34 PM Ricky Teachey wrote:
>
> You can do things like this with exec():
>
> class SafeDict(dict):
> curated_keys = {"a", "b", "c"}
> def __setitem__(self, k, v):
> if k not i self.curated_keys:
> raise Exception(f"{k!r} key not allowed")
>
