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

On Jun 18, 2019, at 12:43, nate lust wrote: > > I have been following this discussion for a long time, and coincidentally I > recently started working on a project that could make use of assignment > overloading. (As an aside it is a configuration system for a astronomical > data analysis

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

> And what I'm asking for is a justification for that. Python in > general has done fine without it for almost 3 decades. I believe you > that you have so far not found a way to make a pretty DSL without it, > and similarly for Yanghao's HDL. But it's far from obvious that none > exists that

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

I have been following this discussion for a long time, and coincidentally I recently started working on a project that could make use of assignment overloading. (As an aside it is a configuration system for a astronomical data analysis pipeline that makes heavy use of descriptors to work around

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

> python is not build for speed Yes, but it scales to speed, letting you speed up your code easily when you need it. Consider Cython and Nuitka. Consider GraalPython. Consider... consider that C dylibs can be loaded and used from within Python without any wrappers. You can create the <-

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

Caleb Donovick writes: > I don't really want to change the semantic of =. What Yanghao and > I are asking for is an in-place update/assign operator which isn't > burdened with numeric meaning. And what I'm asking for is a justification for that. Python in general has done fine without it

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

There is probably some existing python API you can hijack to make custom locals() and globals() work everywhere. Perhaps pdb and inspect.stack are good places to start; maybe there’s a PDB API to break on every new stack frame and maybe you can use inspect to do the proper assignment overrides.

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

Perhaps you should take a look at Dlang. Using opDispatch and a with statement and compile time code generation, you may be able to accomplish what you’re trying to do entirely in D. > On May 24, 2019, at 4:05 AM, Yanghao Hua wrote: > >> On Fri, May 24, 2019 at 1:59 AM Steven D'Aprano wrote:

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

> It's because Python doesn't actually have assignment to variables, it > has binding to names. So there's no "there" there to provide a > definition of assignment. In a class definition, the "local > variables" are actually attributes of the class object. That class > object provides the

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

Stephen J. Turnbull wrote: Note that signal matrices will almost certainly be a completely different type from signals, so as far as the compiler is concerned there's no conflict between "@=" for signal injection and "@=" for signal matrix multiplication. Except that if @= represents signal

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

Kyle Lahnakoski wrote: Here is a half baked idea: class A: def assign(self, other): # whatever this means setattr(A, "<==", A.assign) Some things that would need to be addressed to fully bake this idea: * What determines the precedence of these new operators? * How to

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

Kyle Lahnakoski writes: > Correct me if I am wrong: Yanghao would like an elegant way to build > graphs. Simply using << to declare the connections in the graph [1] is > not an option because << is already needed for legitimate left-shift > operation. This is his claim, yes. > The problem

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

Correct me if I am wrong: Yanghao would like an elegant way to build graphs. Simply using << to declare the connections in the graph [1] is not an option because << is already needed for legitimate left-shift operation.  The problem is not assignment; rather, Yanghao's HDL requires more operators

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

Caleb Donovick writes: > In class bodies it is easy to redefine what assignment means, in > every other context its very annoying, I don't see why that must be > the case. It's because Python doesn't actually have assignment to variables, it has binding to names. So there's no "there" there

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

On Thu, Jun 13, 2019 at 1:02 AM Andre Roberge wrote: > > > > On Wed, Jun 12, 2019 at 7:56 PM Yanghao Hua wrote: >> >> On Wed, Jun 12, 2019 at 11:27 PM Chris Angelico wrote: >> > Yes, you would need some sort of syntactic parser. There are a couple >> > of ways to go about it. One is to make use

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

On Wed, Jun 12, 2019 at 7:56 PM Yanghao Hua wrote: > On Wed, Jun 12, 2019 at 11:27 PM Chris Angelico wrote: > > Yes, you would need some sort of syntactic parser. There are a couple > > of ways to go about it. One is to make use of Python's own tools, like > > the ast module; the other is to

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

Barry the reason I use python and don't parse syntax directly as I want to have python as meta programming environment for my DSLs. I can mostly work within the python syntax (with some pretty heavy metaclasses) I rarely have to touch the AST. Their only two places where I ever have to touch the

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

On Thu, Jun 13, 2019 at 12:52 AM Yanghao Hua wrote: > > On Wed, Jun 12, 2019 at 11:27 PM Chris Angelico wrote: > > Yes, you would need some sort of syntactic parser. There are a couple > > of ways to go about it. One is to make use of Python's own tools, like > > the ast module; the other is to

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

On Wed, Jun 12, 2019 at 11:27 PM Chris Angelico wrote: > Yes, you would need some sort of syntactic parser. There are a couple > of ways to go about it. One is to make use of Python's own tools, like > the ast module; the other is to mandate that your specific syntax be > "tidier" than the rest

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

On Thu, Jun 13, 2019 at 6:51 AM Yanghao Hua wrote: > > On Wed, Jun 12, 2019 at 9:39 AM Chris Angelico wrote: > > If Python is really THAT close, then devise two syntaxes: an abstract > > syntax for your actual source code, and then a concrete syntax that > > can be executed. It's okay for things

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

On Wed, Jun 12, 2019 at 10:10 AM Greg Ewing wrote: > > Yanghao Hua wrote: > > You are absolutely right in that writing a new parser > > might not be a bad idea, but it is just s close for enabling > > Python to be used as the DSL language. > > You seem to be arguing for this as an enabler for

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

On Wed, Jun 12, 2019 at 9:39 AM Chris Angelico wrote: > If Python is really THAT close, then devise two syntaxes: an abstract > syntax for your actual source code, and then a concrete syntax that > can be executed. It's okay for things to be a little bit ugly (like > "signal[:] = 42") in the

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

Yanghao Hua wrote: You are absolutely right in that writing a new parser might not be a bad idea, but it is just s close for enabling Python to be used as the DSL language. You seem to be arguing for this as an enabler for using Python for DSLs in general, but you're really only talking

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

On Wed, Jun 12, 2019 at 5:26 PM Yanghao Hua wrote: > > On Tue, Jun 11, 2019 at 11:35 PM Barry Scott wrote: > > Some times a DSL is usable within the python syntax and that is great. > > I have use python for a number of DSL's. > > > > But when the DSL is beyond what python can help with directly

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

On Tue, Jun 11, 2019 at 11:35 PM Barry Scott wrote: > Some times a DSL is usable within the python syntax and that is great. > I have use python for a number of DSL's. > > But when the DSL is beyond what python can help with directly I'm wondering > why you do not parse the DSL with python and

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

> On 11 Jun 2019, at 09:50, Yanghao Hua wrote: > > On Mon, Jun 10, 2019 at 8:57 PM Caleb Donovick > wrote: >> >> First off, I have admittedly not read all of this thread. However, as >> designer of DSL's in python, I wanted to jump in on a couple of things

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

On Mon, Jun 10, 2019 at 8:57 PM Caleb Donovick wrote: > > First off, I have admittedly not read all of this thread. However, as > designer of DSL's in python, I wanted to jump in on a couple of things I have > seen suggested. Sorry If I am repeating comments already made. Over the > last

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

First off, I have admittedly not read all of this thread. However, as designer of DSL's in python, I wanted to jump in on a couple of things I have seen suggested. Sorry If I am repeating comments already made. Over the last few years I have thought about every suggestion I have seen in this

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

On Wed, Jun 5, 2019 at 11:31 AM Chris Angelico wrote: > Part of the reason you can't just treat the + operator as a method > call is that there are reflected methods. Consider: > > class Int(int): > def __radd__(self, other): > print("You're adding %s to me!" % other) > return

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

Regarding this operator proposal, I also think we can still do this comfortably with the existing Python syntax. The problem that I have is I don't really understand what the *problem* is that you're trying to solve. It would be helpful if you had some explanation on that front. I see there was

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

On Wed, Jun 5, 2019 at 6:08 PM Yanghao Hua wrote: > > On Wed, Jun 5, 2019 at 12:52 AM Greg Ewing > wrote: > > > > Yanghao Hua wrote: > > > Did Guido say "user defined syntax" or "user defined operator"? > > > ... for me defining new operator is different > > > > To my mind it's not that much

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

On Wed, 5 Jun 2019 at 09:06, Yanghao Hua wrote: > With my very limited understanding of cpython internals (at least when > I implement <==) it seems cpython is searching for an operator and > then translates it into a method call on the objects Not really. The valid operators are hard coded into

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

On Wed, Jun 5, 2019 at 12:52 AM Greg Ewing wrote: > > Yanghao Hua wrote: > > Did Guido say "user defined syntax" or "user defined operator"? > > ... for me defining new operator is different > > To my mind it's not that much different. A reader encountering an > unfamiliar operator is pretty