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
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 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
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 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
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 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
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, 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 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 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 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
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 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
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 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 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 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 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: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: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
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
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
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
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
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[:] =
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
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
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
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
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
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
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
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
34 matches
Mail list logo
