Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Ricky Teachey]

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")
super().__setitem__(k, v)

locals_dict = SafeDict()
globals_dict = SafeDict()

exec("d=1", locals_dict, globals_dict)  # Exception: 'd' key not allowed

You can do all sorts of things using that technique, including the way
assignment to variables is handled.

Beyond that, I declare my competence in this matter to have been hereby
exceeded, since I really don't follow or understand the HDL paradigm you
are working in. Maybe others might be able to help.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Yanghao Hua]

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
> that?  int @ int-expression is currently invalid, so defining it will
> not interfere with other int operations.  What am I not understanding?

I am not sure if I understood this. The intention is to e.g. assign a
signal with a value in a nature way, e.g. signal <== 5, are you saying
to replace <== with @? I guess that should work (signal @ 5), not
really intuitive though. I really really would like either a equal
sign or something like an arrow ... I know I am a bit picky ...
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Yanghao Hua]

On Fri, May 24, 2019 at 3:45 PM Ricky Teachey  wrote:
>
> Another idea if you really want to be able to do `foo = 5` and have it behave 
> the way you want:
>
> Create a custom dictionary type to hold locals() (and perhaps globals() if 
> needed). Unless I'm wrong, that dict type can pretty much do whatever you 
> want, including overriding assignment behavior. Then just run the code using 
> exec(), passing the custom hdl_locals().
>
> You could package up a custom python interpreter for hardware programming 
> which simply execs() the python code using this customized assignment 
> behavior provided by hdl_locals(). Such a customized namespace is a very 
> pythonic approach, and if I understand correctly, most regular non hdl python 
> would probably be able to run.

I am not sure I understand this ... could you give me a short example?
The thing is, it need to work at arbitrary closures, not just the
__main__, and you would like to import a hardware module just like you
import a python module. If there is a one single thing that is not
really python native, I feel it kind of defeated the purpose of
creating a Python HDL in the first place. (and execs() are scary too
...)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Yanghao Hua]

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 behavior. You will need to pretty concretely demonstrate 
> why the special handling of signals in assignment (no matter which operator 
> is the operator of choice) is something the language at large really needs, 
> and why descriptors aren't sufficient.

Just a quick example, suppose you have a class A and class B
representing two circuit blocks, where in class C you want instantiate
A() and B() and connecting them together. Please do let me know if you
could have a more reasonable way of representation to make it working.
class A:
def __init__(self, output):
self.output = output
def process(self):
self.output = 5 # !!! this does not work for descriptors passed in
# self.c_self.signal = 5 # this might work, but what the heck really?!

class C:
signal = Signal()
def __init__(self):
a = A(output=self.signal)
# a = A(output=self) # it is only possible for signal to work
if you pass C's self into a ...
b = B(input=self.signal)
# !!! This does not work !!!

Instead, a much more natural way of doing it is:
class A:
def __init__(self, output):
self.output = output
def process(self):
self.output <== 5 # this always works!

class C:
def __init__(self):
signal = Signal()
a = A(output=signal)
b = B(input=signal) # this feels much better, isn't it?

> And to be honest, working with a SignalDescriptor class seems like the most 
> explicit and readable approach anyway, given that your stated first 
> preference is to customize/"overload" the assignment operator. Python already 
> provides nearly the exact syntax you want, you are just limited to confining 
> it to your own Signal and SignalDescriptor objects.

If one thing PEP465 ever taught me is that readability really matters
a lot. Having a identical python object structure mapping to the
hardware structure, with proper localized values as it is in HDL, here
is an example in verilog instantiating 3 flip-flops, one outputs
connect the next input, it is really reflecting how engineers are
thinking in hardware description. If you could tell me a way to
implement something as elegant as below of cause I'd be happy and just
use it. It doesn't make sense to create a new HDL which is even less
intuitive and more difficult to use and understand ...

// D flip-flop
module dff(
input wire d,
input wire clk,
output reg q,
output reg q_bar
);

/*
input d, clk;
output q, q_bar;

wire d, clk;
reg q, q_bar;
*/
wire qx, qbx;

always @ (posedge clk)
begin
q <= d;
q_bar <= !d;
end

endmodule

module dff_tb();
// skipped signal stimuli part ...
reg d, clk, test;
wire q0, q0_bar,q1,q1_bar,q2,q2_bar;

dff d1(d, clk, q0, q0_bar);
dff d2(q0, clk, q1, q1_bar);
dff d3(q1, clk, q2, q2_bar);

endmodule

> Comparing this idea to adding a matrix operator: in the latter case, even if 
> you created a Matrix class and customized __mul__ behavior, there were still 
> two competing definitions for how multiplication can occur. So that couldn't 
> be solved through customized classes. In this current case, the problem CAN 
> be solved by pairing a customized Signal and SignalDescriptor. Unless you can 
> demonstrate exactly why that this isn't a workable solution, I think you can 
> expect it to be very difficult to get the buy-in you need.

I think the above example self-explains the situation. Do let me know
if you think otherwise.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Making code objects filename an absolute path.

[Joao S. O. Bueno]

On Fri, 24 May 2019 at 16:49, 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.
>


It is also not reasonable to suppose that "since python 4 is looming in the
horizon we can schedule a lot
of breaking changes for that".  The incompatible changes that took place
on 2->3 won't happen again.

If the absolute path for __file__ is needed and you can demonstrate it, it
is safer
to create another  property like __abs_file__
(this has happened with __qualname__ for example)



> > And so you need to justify *why* you think that's acceptable
> I dont know it is acceptable or not, i saw this issue triaged to stage
> "patch required". AFAIK it means someone needs to write a patch for this
> issue and i wrote. I'm posting it here because i need to know do i have to
> write a pep or just give bpo link to __future__ page.
>
> On Fri, May 24, 2019 at 10:34 PM Brett Cannon  wrote:
>
>>
>>
>> On Fri, May 24, 2019 at 11:52 AM Batuhan Taskaya 
>> wrote:
>>
>>> The bpo i referenced can explain it better. An example;
>>>
>>>def foo(): pass
>>>assert foo.__code__.co_filename = 
>>> os.path.abspath(foo.__code__.co_filename)
>>>
>>>
>> Do realize there's a reason that issue has been open for well over five
>> years: changing this will probably break code. And so you need to justify
>> *why* you think that's acceptable since Python has existed with these
>> semantics on code objects for decades as this point.
>>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Making code objects filename an absolute path.

[Batuhan Taskaya]

> 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, i saw this issue triaged to stage
"patch required". AFAIK it means someone needs to write a patch for this
issue and i wrote. I'm posting it here because i need to know do i have to
write a pep or just give bpo link to __future__ page.

On Fri, May 24, 2019 at 10:34 PM Brett Cannon  wrote:

>
>
> On Fri, May 24, 2019 at 11:52 AM Batuhan Taskaya 
> wrote:
>
>> The bpo i referenced can explain it better. An example;
>>
>>def foo(): pass
>>assert foo.__code__.co_filename = 
>> os.path.abspath(foo.__code__.co_filename)
>>
>>
> Do realize there's a reason that issue has been open for well over five
> years: changing this will probably break code. And so you need to justify
> *why* you think that's acceptable since Python has existed with these
> semantics on code objects for decades as this point.
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Making code objects filename an absolute path.

[Brett Cannon]

On Fri, May 24, 2019 at 11:52 AM Batuhan Taskaya 
wrote:

> The bpo i referenced can explain it better. An example;
>
>def foo(): pass
>assert foo.__code__.co_filename = os.path.abspath(foo.__code__.co_filename)
>
>
Do realize there's a reason that issue has been open for well over five
years: changing this will probably break code. And so you need to justify
*why* you think that's acceptable since Python has existed with these
semantics on code objects for decades as this point.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Making code objects filename an absolute path.

[Batuhan Taskaya]

The bpo i referenced can explain it better. An example;

   def foo(): pass
   assert foo.__code__.co_filename = os.path.abspath(foo.__code__.co_filename)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Making code objects filename an absolute path.

[Rhodri James]

On 24/05/2019 17:35, Batuhan Taskaya wrote:

I was working on bpo20443  but then i
realized it changes behavior of the compiler and some functions so i want
to propose this change to here and then write a pep. I have a draft pr, it
introduces a new future flag and as far as i can understand from the future
docs, i need a PEP.


Could you perhaps say what "this change" is, exactly?  And why it matters.

--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Making code objects filename an absolute path.

[Batuhan Taskaya]

I was working on bpo20443  but then i
realized it changes behavior of the compiler and some functions so i want
to propose this change to here and then write a pep. I have a draft pr, it
introduces a new future flag and as far as i can understand from the future
docs, i need a PEP.

Before writing to PEP, is there a core developer wants to sponsor my PEP?

Reference implementation: https://github.com/python/cpython/pull/13527
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Terry Reedy]

On 5/24/2019 8:50 AM, Yanghao Hua wrote:

for instance,


I explained already but here again: you will need to have "this_signal
<<= (that_signal << 4) + something, and next line you should be able
to write this_signal <<= 4 bit, where all arithmetic operation still
have to be kept. Otherwise it makes signal doesn't look like a value
... it needs to be looking like a integer but with a different
assignment behavior. In hardware design domain a signal is just a
value but with its own assignment behavior involving delta-cycles (a
virtual time step increase of the value zero ... I know it is a bit
confusing to SW developers). So the intention is to keep all
arithmetic ops like a int, but only changing how the assignment is
done.


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 
that?  int @ int-expression is currently invalid, so defining it will 
not interfere with other int operations.  What am I not understanding?


--
Terry Jan Reedy

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

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Ricky Teachey]

Another idea if you really want to be able to do `foo = 5` and have it
behave the way you want:

Create a custom dictionary type to hold locals() (and perhaps globals() if
needed). Unless I'm wrong, that dict type can pretty much do whatever you
want, including overriding assignment behavior. Then just run the code
using exec(), passing the custom hdl_locals().

You could package up a custom python interpreter for hardware programming
which simply execs() the python code using this customized assignment
behavior provided by hdl_locals(). Such a customized namespace is a very
pythonic approach, and if I understand correctly, most regular non hdl
python would probably be able to run.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Ricky Teachey]

>
> In structure design ... and especially when you design a hardware that
> is meant to be automatically converted into verilog or even logic
> gates, I personally would really want to have a one-to-one
> relationship of the python-objects vs the actual hardware structures.
> The granularity is at signal/bit level. This is why I really think
> giving a special assignment in python which users could override is
> really helpful, rather than having to have this kind of special case:
> if you do "self.abc = thing" descriptor mechanism is invoked, but the
> very next line if you do "abc = thing" ... nothing will happen. This
> special case can be completely removed and having a much better
> conceptual consistency if the "<==" assignment operator always behaves
> the same, doesn't matter if it is "self.abc <== thing" or "abc <==
> thing".
>

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 behavior. You will need to pretty concretely
demonstrate why the special handling of signals in assignment (no matter
which operator is the operator of choice) is something the language at
large really needs, and why descriptors aren't sufficient.

And to be honest, working with a SignalDescriptor class seems like the most
explicit and readable approach anyway, given that your stated first
preference is to customize/"overload" the assignment operator. Python
already provides nearly the exact syntax you want, you are just limited to
confining it to your own Signal and SignalDescriptor objects.

Comparing this idea to adding a matrix operator: in the latter case, even
if you created a Matrix class and customized __mul__ behavior, there were
still two competing definitions for how multiplication can occur. So that
couldn't be solved through customized classes. In this current case, the
problem CAN be solved by pairing a customized Signal and SignalDescriptor.
Unless you can demonstrate exactly why that this isn't a workable solution,
I think you can expect it to be very difficult to get the buy-in you need.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Yanghao Hua]

On Fri, May 24, 2019 at 10:30 AM Paul Moore  wrote:
> Personally, my understanding is that Python is not designed to make
> writing DSLs in Python easy (I'm a little sad about this fact myself,
> but I accept that trying to make a language good at everything is
> counter-productive). Features like the ability to call functions
> without parentheses, user-defined operators, user-defined syntax in
> general, are directly intended to make writing DSLs easier, and have
> been requested and rejected many times in the past.

I am struggling with this myself as well ... but Python is arguably
one of the best language to represent ideas. When I wrote "if python
is going to support scala like operator constructions" I meant more to
ask "If someone out there already had this plan and working on it",
rather than advocating it myself too strong (I would really love it
though, but not the part that calls a function without parentheses).

> I believe Python is OK (I may even go as far as saying "pretty good")
> for defining simple DSLs, but it's not a core goal of the language,
> and you have to make your DSL fit with Python's syntax, not the other
> way round.

Python is great! I am in no way saying anything bad about python only
because it is missing one feature. But I do think it can still be
better and better. I guess in the past there is just not enough
interests from hardware people to use Python to design hardware. We
had MyHDL, cocotb, etc. as well as my own Python-Verilog co-simulator
... because SystemVerilog really makes me sick ... for a language that
has more than 250+ reserved keywords you can imagine it is even worse
than C++ and no two vendor could ever build a compiler for system
verilog behaves exactly the same (I don't even know if the spec itself
can be self-consistent ... just too many possibilities to go wrong)
... that's why I build the Python-Verilog co-simulator where I can
write much more powerful testbenches just in a few lines of Python.

> That's not to say that features useful for DSLs aren't ever going to
> be accepted, but they will need justification independent of their
> value in DSLs. The matrix @ operator that you quote wasn't accepted
> because "it reads well in a maths context", the proponents did a *lot*
> of research to demonstrate that the operator simplified existing code,
> and existing language features couldn't deliver the benefits. PEP 465
> is well worth a read to give an idea of the sorts of arguments needed
> to successfully introduce a new operator to Python.

Sure and will work on it. I am not sure if the argument can come as
strong as in PEP 465, as numpy community (which has almost the entire
machine-learning world) is considerably larger than python hardware
design community ... but I will try to see if I can convince some of
you guys.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Yanghao Hua]

On Fri, May 24, 2019 at 12:29 PM Greg Ewing  wrote:
>
> Yanghao Hua wrote:
> > I have explained the problem of use
> > descriptors in previous replies, where you cannot have a local signal,
> > e.g. obj.signal = thing # works, but local_signal = thing # doesn't
> > work.
>
> Maybe you could do something like:
>
> local = Signals()
> local.signal1 = ...
> local.signal2 = ...

In structure design ... and especially when you design a hardware that
is meant to be automatically converted into verilog or even logic
gates, I personally would really want to have a one-to-one
relationship of the python-objects vs the actual hardware structures.
The granularity is at signal/bit level. This is why I really think
giving a special assignment in python which users could override is
really helpful, rather than having to have this kind of special case:
if you do "self.abc = thing" descriptor mechanism is invoked, but the
very next line if you do "abc = thing" ... nothing will happen. This
special case can be completely removed and having a much better
conceptual consistency if the "<==" assignment operator always behaves
the same, doesn't matter if it is "self.abc <== thing" or "abc <==
thing".
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Yanghao Hua]

On Fri, May 24, 2019 at 11:47 AM Steven D'Aprano  wrote:

> PEP 465 had a concrete purpose for its new operator, and although no
> built-in object supported the @ operator, we understood why Numpy wanted
> it. But I do not understand why you want an arrow operator or what you
> will do with it.

OK, I see your point and will work on a more comprehensive example
with some investigations how it can simplify existing libraries
outside there.

> What should built-in types do with this new dunder?
>
> "Hello world!" <== "aardvark"
>
> 23.5 <== 1.25
>
> [1, 2, 3] <== 4

It will generate error: unsupported operand types(s) for: 'int' and
'int'. (or list and int etc.)

>
> Have you considered the __ilshift__ method?
>
> signal <<= 5

I explained already but here again: you will need to have "this_signal
<<= (that_signal << 4) + something, and next line you should be able
to write this_signal <<= 4 bit, where all arithmetic operation still
have to be kept. Otherwise it makes signal doesn't look like a value
... it needs to be looking like a integer but with a different
assignment behavior. In hardware design domain a signal is just a
value but with its own assignment behavior involving delta-cycles (a
virtual time step increase of the value zero ... I know it is a bit
confusing to SW developers). So the intention is to keep all
arithmetic ops like a int, but only changing how the assignment is
done.

> Yes. You should study PEP 465. It is one of the best PEPs in Python's
> history. If you want your proposal to succeed, you should think "How can
> I write this to be more like PEP 465?"

I am writing just to see if I missed something significantly in this
field ... will come back with a comprehensive PEP.

> I am completely aware that we can't hook into assignment except with
> attribute or item assignment. But I still do not understand why you want
> to hook into assignment.

What is going to be hooked into the assignment is the pending update
of the value to the signal, which only happens until a delta cycle is
passed, such that you can have a deterministic behavior when using
software to mimic actual hardware behaviors.

> Perhaps I have missed something when reading your earlier posts, but I
> don't understand what you will do with this new operator. Perhaps you
> can show up your intended method?
>
>
> x <== y
>
> def __arrow__(self, other):
># what goes here?

For example:

def __larrow__(self, other):
self.next_value = other.value

And when increasing virtual time (e.g. a delta cycle):

for sig in all_signals:
sig.current_value = self.next_value


> I am not sure if I understand what you mean by "feeding 5 into this
> signal". But if it means what I think it means, then you can give signal
> a method:
>
> signal.feed(5)
>
> which is explicit and readable. Or you could use <<= as I mentioned
> above.

The intention is to make the signal looks like an integer, and yet to
change the assignment behavior. As I explained above that all normal
arithmetic ops still need to be kept.

> You also said:
>
> "[arrow operator] looks like kind of the non-blocking
> assignment operators in hardware description languages"
>
> What is "non-blocking assignment"?

non-blocking assignment is a terminology in HDL design, where the
assignment is not actually happening until a later time. In simple
words if the "virtual-time" is not increasing, then the assignment is
not happening. To allow all hardware threads seeing the same
consistent value at that particular virtual time.

I have the prototype working, let me implement a much more elaborated
example, and also look into how existing modules like MyHDL could
benefit out of it, and give you guys a written PEP.

>From this good discussion so far (Thanks everyone for your candid
responses!), I understood I have not missed anything significantly,
Python community has no intention to make Python supporting
operator-on-demand-definition like in scala, so the only possible way
forward is (for me): build the "<== and ==>" operator and write a PEP
to justify its usefulness. The general intention is to make HDL design
in python looks and feels at least as good as in verilog/vhdl, so once
I have my library complete I will explain in depth how it looks side
by side for Python vs Verilog, with and without the arrow operators.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Greg Ewing]

Yanghao Hua wrote:

I have explained the problem of use
descriptors in previous replies, where you cannot have a local signal,
e.g. obj.signal = thing # works, but local_signal = thing # doesn't
work.


Maybe you could do something like:

   local = Signals()
   local.signal1 = ...
   local.signal2 = ...

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

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Steven D'Aprano]

On Fri, May 24, 2019 at 10:05:17AM +0200, Yanghao Hua wrote:

> Well, if python is not envisioned to be able to represent almost
> everything elegantly maybe I should indeed walk away from this idea.

Python code is supposed to look like Python, not arbitrary languages. If 
you want a language where you can invent and use arbitrary syntax, 
Python is not the language for you.

Of course we could add a new dunder method __arrow__ and a new 
operator <== but *why*? What would it do? What types would support it?

PEP 465 had a concrete purpose for its new operator, and although no 
built-in object supported the @ operator, we understood why Numpy wanted 
it. But I do not understand why you want an arrow operator or what you 
will do with it.

What should built-in types do with this new dunder?

"Hello world!" <== "aardvark"

23.5 <== 1.25

[1, 2, 3] <== 4


Have you considered the __ilshift__ method?

signal <<= 5


Or perhaps a preprocessor, such as "Like Python" (a joke) or Coconut 
(serious)?

https://jon.how/likepython/

http://coconut-lang.org/

Perhaps something like that will solve your problem.


> (This is sad for me ... I have been saying and believing python is
> envisioned that way for more than 20 years now). Your argument could
> be applied on PEP465 as well, where the only justification is to make
> matrix operation prettier.

Yes. You should study PEP 465. It is one of the best PEPs in Python's 
history. If you want your proposal to succeed, you should think "How can 
I write this to be more like PEP 465?"



> I have explained the problem of use
> descriptors in previous replies, where you cannot have a local signal,
> e.g. obj.signal = thing # works, but local_signal = thing # doesn't
> work.

I am completely aware that we can't hook into assignment except with 
attribute or item assignment. But I still do not understand why you want 
to hook into assignment.

Perhaps I have missed something when reading your earlier posts, but I 
don't understand what you will do with this new operator. Perhaps you 
can show up your intended method?


x <== y

def __arrow__(self, other):
   # what goes here?



In your first post, you said:

"it [item assignment using descriptors] does not work if you 
want a local signal, where signal = 5 will always make signal 
to be 5, instead of feeding 5 into this signal."

I am not sure if I understand what you mean by "feeding 5 into this 
signal". But if it means what I think it means, then you can give signal 
a method:

signal.feed(5)

which is explicit and readable. Or you could use <<= as I mentioned 
above.

You also said:

"[arrow operator] looks like kind of the non-blocking 
assignment operators in hardware description languages"

What is "non-blocking assignment"?

Thank you,


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

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Paul Moore]

On Fri, 24 May 2019 at 09:06, Yanghao Hua  wrote:

> Well, if python is not envisioned to be able to represent almost
> everything elegantly maybe I should indeed walk away from this idea.
> (This is sad for me ... I have been saying and believing python is
> envisioned that way for more than 20 years now).

Personally, my understanding is that Python is not designed to make
writing DSLs in Python easy (I'm a little sad about this fact myself,
but I accept that trying to make a language good at everything is
counter-productive). Features like the ability to call functions
without parentheses, user-defined operators, user-defined syntax in
general, are directly intended to make writing DSLs easier, and have
been requested and rejected many times in the past.

I believe Python is OK (I may even go as far as saying "pretty good")
for defining simple DSLs, but it's not a core goal of the language,
and you have to make your DSL fit with Python's syntax, not the other
way round.

That's not to say that features useful for DSLs aren't ever going to
be accepted, but they will need justification independent of their
value in DSLs. The matrix @ operator that you quote wasn't accepted
because "it reads well in a maths context", the proponents did a *lot*
of research to demonstrate that the operator simplified existing code,
and existing language features couldn't deliver the benefits. PEP 465
is well worth a read to give an idea of the sorts of arguments needed
to successfully introduce a new operator to Python.

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

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Yanghao Hua]

On Fri, May 24, 2019 at 1:59 AM Steven D'Aprano  wrote:
>
> On Thu, May 23, 2019 at 06:23:31PM +0200, Yanghao Hua wrote:
>
> > Is this (<== and ==>) something can be made into CPython?
>
> If it goes into CPython, eventually every other Python needs to do the
> same.
>
> Of course it *could* be put into Python, but you haven't given
> sufficient justification for why it *should* be put into Python.
>
> Why does your DSL need a seperate assignment operator? How is it
> different from regular assignment?
>
> Could you use __setitem__ instead?
>
> Instead of this:
>
> variable <== thing  # magic happens here
>
> can you write this?
>
> obj.variable = thing  # magic happens here
>
>
> If your DSL is so different from Python that it needs new operators,
> perhaps you should write an interpreter for your language and run that
> seperately.
>
> code = """
> any syntax you like <- thing
> """
> result = interpret(code)

Well, if python is not envisioned to be able to represent almost
everything elegantly maybe I should indeed walk away from this idea.
(This is sad for me ... I have been saying and believing python is
envisioned that way for more than 20 years now). Your argument could
be applied on PEP465 as well, where the only justification is to make
matrix operation prettier. I have explained the problem of use
descriptors in previous replies, where you cannot have a local signal,
e.g. obj.signal = thing # works, but local_signal = thing # doesn't
work.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/