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

2019-05-24 Thread 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 =

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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.

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

2019-05-24 Thread 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 = ...

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

2019-05-24 Thread 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

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

2019-05-24 Thread 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