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 much faced with a new piece of
syntax to learn. Its spelling gives l
Stephen J. Turnbull wrote:
There may
be matrices of signals that do want to support multiplication, but
that will be a different type, and presumably multiplication of signal
matrices will be supported by "*".
Then you lose the ability for '*' to represent elementwise
multiplication of signal a
Cody Piersall wrote:
As Yanghao mentioned, the likeliest to use
would be the in-place matmul operator (@=) but there are use cases
where matrix-multiplication of signals would actually be useful too.
My question on that is whether matrix multiplication of signals is
likely to be used so heavily
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 commu
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 syntax in Python.
Did Guido sa
Yanghao Hua writes:
> On Tue, Jun 4, 2019 at 10:11 AM Stephen J. Turnbull
> wrote:
> > The question is always "does the use case justify increasing
> > complexity for a couple hundred maintainers and a few hundred
> > million readers?"
>
> That's a valid question. and let's address the it
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 community faced
was that there are multiple "multiplication" operations that m
Chris Angelico writes:
> ## New "unless" construct for list displays and argument lists ##
>
> Inside a list/dict/set/tuple display, or inside an argument list,
> elements can be conditionally omitted by providing a predicate.
>
> lst = [f1(), f3() unless f2(), f4()]
Not a fan of this in
Jeroen Demeyer writes:
> When you think of it this way, it's not an unreasonable request. There
> would be at least one major use of this operator within CPython, for
> lists. With this proposal, the awkward syntax (there are 219 instances
> of this in the CPython sources)
>
>L[:] =
On 6/4/2019 6:47 AM, 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 arithmetic.
I believe that
On Tue, Jun 4, 2019 at 7:21 AM 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 words of argument you
> still h
Ok agreed on .update and .extend. Two operators (+= and <==) doing the
same thing is dumb. And for .append I agree "this thing is the same, just
add this thing" is a little at odds with "update this thing when i send
this other thing into it".
> my_gen.send
>
> Sure, this makes sense to me!
>
I
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 syntax in Python.
--
Greg
___
Python-ideas mailing
On 04/06/2019 13:38, Steven D'Aprano wrote:
(2) Because things which act different should look different, and things
which act similar should look similar. Yanghao Hua wants an operator
which suggests a kind of assignment. Out of the remaining set of
operators, which one do you think suggests ass
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 that does not
> >>> collide with all existing
On 04/06/2019 13:36, Yanghao Hua wrote:
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 words
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 implement such a thing. Python need t
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 that does not
collide with all existing number/matrix operators.
Why?
That's the question that in all your tho
On 2019-06-04 14:34, Ricky Teachey wrote:
"update an object with another" (dunder update)
Yes, that's essentially what I meant. To me, "assign an object in place"
and "update an object with another" mean the same thing.
A few come to mind:
my_dict.update
This is PEP 584, where += is used
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 that does not
> >collide with all existing number/matrix operators.
>
> Why?
>
> That's the question that in all your thousands of words of argument you
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 words of argument you
> still h
I agree this needs to be reframed but suggest that assignment in place
isn't the most useful mental model.
Instead, something like "generically apply a value to another" (dunder
apply) or "update an object with another" (dunder update) might have a
prayer of making sense. Perhaps there are other s
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 signal linkage as a method
> > > call or cl
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 implement such a thing. Python need to provide the
> >mechanism.
>
> It really doesn't. If the end us
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 words of argument you
still haven't answered beyond "because I want it."
--
Rhodri James *-* Ky
On Tue, 4 Jun 2019 at 12:47, Jeroen Demeyer wrote:
>
> On 2019-06-04 13:29, Steven D'Aprano wrote:> As far as I can tell, there
> is no difference between your proposal
> > and the OP's proposal except you have changed the name of the dunder
> > from __arrow__ to __iassign__.
>
> I never claimed t
On 2019-06-04 13:29, Steven D'Aprano wrote:> As far as I can tell, there
is no difference between your proposal
and the OP's proposal except you have changed the name of the dunder
from __arrow__ to __iassign__.
I never claimed that there was a difference. I just tried to clarify
what the orig
On Tue, Jun 04, 2019 at 12:47:30PM +0200, Jeroen Demeyer wrote:
> When you think of it this way, it's not an unreasonable request. There
> would be at least one major use of this operator within CPython, for
> lists. With this proposal, the awkward syntax (there are 219 instances
> of this in t
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 arithmetic.
When you think of it this way, it's not an unreasonable re
On Tue, Jun 4, 2019 at 8:07 PM Yanghao Hua wrote:
> I understand that after the assignment expression (:=) PEP572 people
> are already not happy with anything that could be slightly related to
> assignment overloading, I actually don't understand why people object
> PEP572 so hard, its practical u
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 Mon, Jun 03, 2019 at 09:24:03PM +, Steve Barnes wrote:
> One specific pain point with zipfile is that if you zip a directory
> that contains the target zip file you end up trying to add the target
> file to itself which leads to a rapidly growing archive.
If that is accurate, it probably
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 signal linkage as a method
> > call or class all of its own is not a significant extra burden.
> There are very
On Sat, Jun 1, 2019 at 4:10 PM Serhiy Storchaka wrote:
>
> Why do you need to replace a symlink atomically? This is a solution,
> what problem it solves?
>
There is another, more common / realistic usage of atomic symlink
replacing.
When deploy PHP application or static web contents to web serve
34 matches
Mail list logo
