On Wed, Jun 26, 2019 at 11:24 PM nate lust wrote:
[...]
> Yanhao, I do not think you are doing this proposal any good. I appreciate you
> trying to go to bat for it, but there are many good concerns here that would
> be good to hear out and address rather than trying to dismiss them.
I was
On Wed, Jun 26, 2019 at 11:16 PM Chris Angelico wrote:
[...]
> Then I completely don't understand getself. Can you give an example of
> how it would be used? So far, it just seems like an utter total mess.
Sure, below is my code snippet for signal get/set, using "L[:] =
thing" syntax and
On Wed, Jun 26, 2019 at 11:00 PM Chris Angelico wrote:
>
> On Thu, Jun 27, 2019 at 6:50 AM Yanghao Hua wrote:
> >
> > On Wed, Jun 26, 2019 at 10:16 PM Chris Angelico wrote:
> > >
> > > Let's suppose that frob() returns something that has a __getself__
&g
On Wed, Jun 26, 2019 at 10:16 PM Chris Angelico wrote:
>
> On Thu, Jun 27, 2019 at 5:29 AM Yanghao Hua wrote:
> >
> > On Wed, Jun 26, 2019 at 4:47 PM Chris Angelico wrote:
> > [...]
> > > There are many things that can be implemented with dunders, yes, bu
On Wed, Jun 26, 2019 at 4:47 PM Chris Angelico wrote:
[...]
> There are many things that can be implemented with dunders, yes, but
> in Python, I would expect these two functions to behave identically:
>
> def f1(x):
> return frob(x).spam
>
> def f2(x):
> f = frob(x)
> s = f.spam
>
On Tue, Jun 25, 2019 at 11:01 PM nate lust wrote:
>
> This message is related to two previous threads, but was a sufficiently
> evolved to warrant a new topic.
>
> I am proposing that two new magic methods be added to python that will
> control assignment and loading of class
> instances. This
On Thu, Jun 20, 2019 at 10:28 PM nate lust wrote:
>
> There is nothing more humbling than sending nonsense out to an entire mailing
> list. It will teach me to stop an process my steam of consciousness
> critically instead of just firing off a message. You were right that I was
> not at all
On Sun, Jun 16, 2019 at 7:41 PM Steven D'Aprano wrote:
>
> On Sun, Jun 16, 2019 at 08:04:44AM -0700, Christopher Barker wrote:
> > On Sun, Jun 16, 2019 at 6:08 AM Franklin? Lee
> >
> > wrote:
> >
> > > The proposed feature is for expressing type relations, which only
> > > matters when you care
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
>> >
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
> > t
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
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
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
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
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
On Thu, Jun 6, 2019 at 11:10 AM Angus Hollands wrote:
>
> I'm not sure if you saw my reply earlier:
> https://mail.python.org/archives/list/python-ideas@python.org/thread/B7QPHTQSBVN4NFO3SEVR57AIGYPM3MUM/
>
> I proposed some alternative syntax already supported.
Yes, saw it ... not sure
On Thu, Jun 6, 2019 at 9:48 AM Chris Angelico wrote:
> They have a difference for the built-in list type in that slicing a
> list returns a new list with references to the same objects, thus "x =
> x[:]" is going to give you an equivalent but distinct list. That's an
> important point in some
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
On Thu, Jun 6, 2019 at 6:31 AM Ryan Gonzalez wrote:
>
> Think of it more like indexing a range. Say you have:
>
> L[:] = M[:]
>
> Which is the same as:
>
> L[0:len(L)] = M[0:len(M)]
>
> Which mentally you can think of like:
>
> L[0], L[1],...L[len(L)] = M[0],M[1],...M[len(M)]
>
> Slicing is just
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 enc
On Tue, Jun 4, 2019 at 12:47 PM Jeroen Demeyer wrote:
>
> I'd like to get rid of all the signal and HDL stuff (whatever that
> means) in this thread, so I think what the original poster really wants
> is an "assign in place" operator. Basically, something like += or *= but
> without the
On Tue, Jun 4, 2019 at 7:28 PM Stephen J. Turnbull
wrote:
>
> Cody Piersall writes:
>
> > would be the in-place matmul operator (@=) but there are use cases
> > where matrix-multiplication of signals would actually be useful
> > too.
>
> If I recall correctly, the problem that the numeric
On Tue, Jun 4, 2019 at 3:24 PM Greg Ewing wrote:
>
> Yanghao Hua wrote:
> > is Python visioned in a way to allow
> > users to define there own operators?
>
> No, it's not. Whenever the topic has come up, Guido has always said
> that he is against having user-defined s
On Tue, Jun 4, 2019 at 2:50 PM Eric V. Smith wrote:
>
> On 6/4/2019 8:38 AM, Steven D'Aprano wrote:
> > On Tue, Jun 04, 2019 at 01:20:14PM +0100, Rhodri James wrote:
> >> On 04/06/2019 11:06, Yanghao Hua wrote:
> >>> [...] what I needed is an operator tha
On Tue, Jun 4, 2019 at 2:28 PM Steven D'Aprano wrote:
>
> On Fri, May 31, 2019 at 02:48:24PM +0100, Rhodri James wrote:
> > On 29/05/2019 08:31, Yanghao Hua wrote:
>
> > >Python does not need to know this ... just hand it over to end user
> > >who knows how to im
On Tue, Jun 4, 2019 at 2:20 PM Rhodri James wrote:
>
> On 04/06/2019 11:06, Yanghao Hua wrote:
> > [...] what I needed is an operator that does not
> > collide with all existing number/matrix operators.
>
> Why?
>
> That's the question that in all your thousands of
On Tue, Jun 4, 2019 at 10:11 AM Stephen J. Turnbull
wrote:
>
> Yanghao Hua writes:
> > On Fri, May 31, 2019 at 3:48 PM Rhodri James wrote:
>
> > > It really doesn't. If the end user is going to implement the
> > > logic of this anyway, implementing signa
On Mon, Jun 3, 2019 at 8:01 PM Andrew Barnert wrote:
>
> I think it was a mistake to even mention assignment here (much less arbitrary
> operators). Most of the resistance you’re facing is because of that, and I
> think you’re missing a fundamental reason behind that resistance.
>
> Overloading
On Thu, May 30, 2019 at 12:56 PM Richard Damon wrote:
> As someone who does hardware design with HDLs, I would say that to think
> that it would be easy to recreate the abilities of them in a
> 'conventional' programming language doesn't really understand at least
> one of the languages, as there
On Thu, May 30, 2019 at 7:07 AM Stephen J. Turnbull
wrote:
>
> Steven D'Aprano writes:
>
> > You might be right, but then the first post in this thread talked
> > about it:
> >
> > I realize there is no way to overload the behavior of the
> > assignment operator in python
> >
> >
On Thu, May 30, 2019 at 1:02 AM Greg Ewing wrote:
>
> Steven D'Aprano wrote:
>
> > The obvious solution to customising assignment is to use a dotted
> > target:
> >
> > obj.x = value
>
> Another problem with this is that we don't want to customise *all*
> assignments. Sometimes we just want a
On Thu, May 30, 2019 at 12:50 AM Greg Ewing wrote:
>
> Steven D'Aprano wrote:
> > Yanghao Hua wants to customise the behaviour of assignment. I believe
> > that he wants to emulate the behaviour of some hardware description
> > languages, where the equals sign = doesn't me
On Wed, May 29, 2019 at 9:34 PM Ricky Teachey wrote:
> Seems to me that namespace collisions are a possibility no matter what
> namespace you are working in, right? If you are in the global (module)
> namespace, and use up a, b, and c, that doesn't seem any different to me than
> using up
On Wed, May 29, 2019 at 4:51 PM Ricky Teachey wrote:
>
> Another approach is to abandon the idea of HDL namespace parent class, and
> just create a HDL (or hdl) decorator:
>
> @hdl # decorator adds a custom __setattr__
> class C: ...
>
> The decorator would modify the __setatrr__ method of the
On Wed, May 29, 2019 at 4:43 PM Ricky Teachey wrote:
>
> Seems like this would do it (note: `in` can't actually be a variable):
>
> class A(HDL):
> # A is now an HDL namespace - all members have signal behavior
> def __init__(self, in, o1, o2):
> self.in = in # descriptor
>
On Wed, May 29, 2019 at 2:57 PM Ricky Teachey wrote:
> class HDL:
> """Every new member of this namespace has signal behavior"""
> def __setattr__(self, attr, value):
> # note: if attr existed already,
> # SignalBehavior.__set__ was called
>
> # add attr as signal
On Wed, May 29, 2019 at 3:47 PM Ricky Teachey wrote:
>
> I look forward to seeing the working example. Hopefully it's clear already,
> but: I don't think anybody is yet claiming the descriptor approach is the
> "correct" or "best" answer for you. But it will help a lot to demo what you
> want,
tainly
> > possible I simultaneously don't understand what you are really trying to do
> > in the code you wrote (I definitely don't claim to).
>
> Descriptors are, I think, a total red herring.
>
> Yanghao Hua wants to customise the behaviour of assignment. I believe
>
On Wed, May 29, 2019 at 2:57 PM Ricky Teachey wrote:
>
> For the understanding of all, it would help tremendously for you to implement
> a WORKING TOY example showing exactly the behavior you want in real (not
> theoretical) python, maybe something like this as a starting point:
>
> class
On Wed, May 29, 2019 at 9:46 AM Greg Ewing wrote:
>
> Yanghao Hua wrote:
> > If I use python to do
> > something and I have to type more chars it doesn't make sense for me.
>
> If you shorten it to "n" you get
>
>x.n = 4
>
> which is
On Wed, May 29, 2019 at 3:15 AM Eric V. Smith wrote:
> 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
>
On Wed, May 29, 2019 at 3:45 AM Greg Ewing wrote:
>
> Yanghao Hua wrote:
> > 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? :)
&g
On Tue, May 28, 2019 at 10:46 PM Ricky Teachey wrote:
>
> I don't want to pile on, but: you have also not given any actual reason why
> overloading the = operator using descriptors:
>
> stuff.a = 8
>
> ...is not sufficient, other than a general "well I don't like that". Come on,
> guy. If you
On Tue, May 28, 2019 at 10:38 PM Chris Angelico wrote:
>
> On Wed, May 29, 2019 at 6:30 AM Yanghao Hua wrote:
> >
> > > You do realise that repeatedly avoiding the question "what problem do
> > > you think you are solving?" does not convincingly mak
On Tue, May 28, 2019 at 10:40 PM Eric V. Smith 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 di
> You do realise that repeatedly avoiding the question "what problem do
> you think you are solving?" does not convincingly make the case that
> there is a problem to be solved, don't you?
It might be that I am not good enough yet to present it in a way for
some of you to better comprehend it.
On Sun, May 26, 2019 at 10:25 PM Chris Angelico wrote:
>
> On Mon, May 27, 2019 at 6:05 AM Yanghao Hua wrote:
> > Doesn't matter how it ends up, I
> > urge the python community do give it a second thought. (Don't you guys
> > think it is odd that Python can override
On Sun, May 26, 2019 at 9:34 PM Chris Angelico wrote:
> Irrelevant though. I've ridden in a car - does that make me a
> petrochemical engineer?
No of course not. But if you are able to build one faster from
scratch, you are. We all know building a house with chisels and
hammers is different from
On Sun, May 26, 2019 at 8:00 PM David Mertz wrote:
>
> On Sun, May 26, 2019, 1:12 PM Barry Scott wrote:
>>
>> You said this: "Well, depends on how we define narrow ... you are writing
>> probablythis email on a HDL designed machine ... and the entire world is
>> powered by HDL designed
On Sun, May 26, 2019 at 7:11 PM Barry Scott wrote:
> You said this: "Well, depends on how we define narrow ... you are writing
> probably
> this email on a HDL designed machine ... and the entire world is
> powered by HDL designed silicons. that is not small for me at all."
>
> Which I take to
On Sun, May 26, 2019 at 11:27 AM Barry Scott wrote:
> I think you are confusing the number of people that use HDL with the amount
> of product created.
I don't see how I did that but if you intercepted that way I must have
done that somehow.
> Also I was under the impression that HDL tools
On Sun, May 26, 2019 at 6:05 AM Terry Reedy wrote:
>
> 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
>
On Sun, May 26, 2019 at 12:04 AM David Mertz wrote:
>
> 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
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 oper
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 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")
>
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
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
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
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
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
> >
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.
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
>
On Thu, May 23, 2019 at 4:49 AM Ricky Teachey wrote:
>
> Can I offer an alternative suggestion?
>
> How about these arrow operators, which despite being 3 characters, look
> pretty nice, and are not currently valid python:
>
> a <== b <== c
> a ==> b ==> c
>
> Perhaps __larrow__ and __rarrow__
> I think the idea for using the left arrow is a non-starter, since it's
> already valid Python syntax to write
>
> x <- 3
>
> today. ("-" being a unary operator and all).
>
> That said, I would be really happy to have a clean way to write HDL in
> Python, so good luck! Time to check out MyHDL...
> You might also want to look at macropy
> https://github.com/lihaoyi/macropy/blob/master/readme.rst , although I don’t
> know if it supports new operators.
Thanks for the pointer, I am also not sure how to apply it after a
quick going through of its documentation.
So far the quickest thing to
> Perhaps you might be able to do what you want using an import hook. I have
> done some experiments with introducing some new operators that way:
> https://github.com/aroberge/experimental/blob/master/experimental/transformers/readme.md
Thanks for the link, it is a very interesting module.
I
> If you are proposing to add "<-" and "->" to the fundamental Python
> grammar, then it could work as PEP465 does. But if you are proposing
> that classes can define new lexical operators, it would have to work
> very very differently. You started with "operators as first class
> citizens," but
On Wed, May 22, 2019 at 2:54 PM Rhodri James wrote:
>
> On 22/05/2019 13:29, Yanghao Hua wrote:
> > Problem is python do not allow you to define new operators in the
> > language itself, except those pre-defined you can modify their
> > behavior. Even in case, if pyt
> > And this is something I have in mind for a Python DSL for HDL:
> >
> > def combinational_or_sequential_logic(in: Signal, out: Signal):
> > local_signal = Signal()
> > local_signal <- in << 10 # read as: local_signal <- (in << 10)
> > out <- local_signal + 5 # read as out <-
> Yes, it does make sense. Forgive my lack of Scala knowledge, but is it
> possible for 'b' in your example to be the one that handles the
> addition? Specific case:
>
> class Seven:
> def __add__(self, other): return other + 7
> def __radd__(self, other): return 7 + other
>
> seven =
I see python3.5 accepted PEP465 adding a new infix operator for matrix
(@, @=), which made matrix formula's much less painful to read in
Python. There are still more use cases like this in other areas.
While looking at Chisel (a hardware construction language build on top
of scala), where you can
72 matches
Mail list logo
