> On May 28, 2019, at 5:22 PM, Yanghao Hua <yanghao...@gmail.com> wrote:
> 
>> On Tue, May 28, 2019 at 10:40 PM Eric V. Smith <e...@trueblade.com> wrote:
>> 
>>> On 5/28/2019 4:29 PM, Yanghao Hua wrote:
>>> 
>>> To repeat what the problem do I think I am solving? A variable, that
>>> behaves like an integer (e.g. all normal integer ops should just
>>> work), but has a different assignment behavior, such that it can be
>>> used to develop equally good hardware descriptions.
>> 
>> This is the part that you're not explaining: what does "a different
>> assignment behavior" mean? We all understand what Python means by
>> assignment (name binding), but we don't understand what you would like
>> it to be instead.
> 
> a different assignment behavior in HDL is your assignment does not
> take effect until a delta cycle of zero virtual time has passed. (did
> you really looked at the previous postings? :)

Yes, I’ve read every one of the emails in this thread, many of them multiple 
times. 

Python does not know what “a delta cycle of zero virtual time has passed” 
means, so there’s no way of implementing this feature. If indeed you’re serious 
about this feature, you would do yourself a favor by explaining it in terms of 
Python, not in terms of HDL.

> 
>> It seems that you want these two statements to work differently:
>> 
>> x = something()    # bind a name for the first time
>>                    #  ("create a variable", if you will)
>> x = 4              # do something different when x already exists
>>                    #  and is of some special type
>> 
>> Is that true? What is the "something different"?
> 
> x = 4 should be something like x <== 4 or x := 4 (the latter has been
> taken by the assignment expressions though ...). Such that variable
> initialization (=) and utilization (<==) can be differentiated.

I take this as an answer of “yes” to my question of the two assignments being 
different. If that’s so, then I’m positive this feature will not be 
implemented. 

> 
>> I've got to be honest with you: I don't see Python changing in this regard.
> 
> Sad to see that's the case from you when it seems you barely even read
> all of the postings in this thread.

It’s true that I’ve tried and failed to understand what behavior you’re 
suggesting be added to Python. Good luck going forward, but I’m dropping t out 
of the conversation. 

Eric
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to