This is a horrible idea.
I proposed to Mr. Fine earlier that we adopt a << operator.
d1 << d2 merges d2 into a copy of d1 and returns it, with keys from d2
overriding keys from d2.
On Sat, Mar 9, 2019 at 4:50 PM Jonathan Fine wrote:
> A good starting point for discussing the main idea is:
>
Are you all REALY=LU proposing more operators?
Adding @ made sense because there was an important use case for which there
was no existing operator to use.
But in this case, we have + and | available, both of which are pretty good
options.
Finally, which dicts are a very important ue ase, do we
Maybe it's just the C++ IO piping that makes me like it, but these actually
seem intuitive to me, whereas `+` or even `|` leaves me queasy.
On Sat, Mar 9, 2019 at 7:40 PM Ian Foote wrote:
> > It might also be worth considering YAML's own dict merge operator, the
> > "<<" operator, as in
On Sat, Mar 9, 2019 at 4:14 PM Greg Ewing wrote:
>
> A large part of the reason that common operations are written
> using infix operators is that the operator symbols used are very
> compact. That benefit disappears if your operator is an entire
> word.
I suppose people bring up Haskell too
> It might also be worth considering YAML's own dict merge operator, the
> "<<" operator, as in https://yaml.org/type/merge.html as this is the
> existing Python's shift operator added to dict and will require no
> change to the synatx::
>
> a = a << b
I really like this suggestion. It
Jonathan Fine wrote:
It not me, but Chris and Steve who
want to bind dict.update to an operator, namely '+'. I'm suggested
that if you do that, why not call the operator 'update'.
One reason would be that '+' is short, whereas 'update' is long.
A large part of the reason that common
A good starting point for discussing the main idea is:
PEP 465 -- A dedicated infix operator for matrix multiplication
https://www.python.org/dev/peps/pep-0465
Matrix multiplication is one of many special binary mathematical
operators. PEP 465 successfully argues the merits of introducing a
I'm adopting an idea suggested by Anders and Chris.
To allow us better to focus on the main idea and purpose, I've
replaced '@' by '$' in the initial suggestion. And if the main idea is
accepted, we can if needed have an secondary discussion regarding the
details of the syntax.
Here's the
On Sun, Mar 10, 2019 at 6:07 AM Jonathan Fine wrote:
> He then correctly says that in my proposal the lack of whitespace
> after an operator can cause the operator to absorb a following
> identifier.
>
> However, something similar ALREADY happens in Python.
> >>> a = nota = True
> >>> not
Why are you continuing to insist on using the symbol "@" after all these
problems have been pointed out I wonder? Just suggest $ or something else that
is a syntax error today and we can move on with discussing the merits of the
underlying idea itself?
/ Anders
> On 9 Mar 2019, at 20:03,
SUMMARY
Acknowledgement of an error, and clarification of behaviour of '@b' vs
'@ b'. I claim that once '@b' is accepted as an operator, the
behaviour is perfectly natural and obvious.
AN ERROR
In a previous post, I mispoke. I should have written
a@b+1
is valid Python before and after, but
It might also be worth considering YAML's own dict merge operator, the
"<<" operator, as in https://yaml.org/type/merge.html as this is the
existing Python's shift operator added to dict and will require no
change to the synatx::
a = a << b
Meitham
On 03/10, Chris Angelico wrote:
> On Sun,
On Sat, 9 Mar 2019 at 18:22, Jonathan Fine wrote:
>
> I'm suggesting that the grammar allow us, if we wish, to write
>c = a @cup b
> for the union of two sets. And
>len(A @cup B) == len(A) + len(B) - len(A @cap B)
You can use the infix module for that, which allows you to write
- a
On Sun, Mar 10, 2019 at 4:22 AM Jonathan Fine wrote:
>
> Steven D'Aprano wrote
>
> > The last thing we're going to do is repeat Ruby's design mistake of
> > making code dependent on spaces around operators.
>
> I'd say that Ruby's mistake was encouraging programmers to write code
> that was hard
Steven D'Aprano wrote
> The last thing we're going to do is repeat Ruby's design mistake of
> making code dependent on spaces around operators.
I'd say that Ruby's mistake was encouraging programmers to write code
that was hard for human beings to read accurately and quickly. As we
say in
On Sun, Mar 10, 2019 at 3:46 AM Jonathan Fine wrote:
>
> Chris Angelico suggested that
> a = a.update_with(b)
> would be better than
> a @update= b
>
> One of the key points of += is that
> parent.child['toy'].wheel[3].speed += 1
> increases the speed that that wheel by 1, without
> Thus, 'b' would be unchanged, and 'a' would be the same dictionary as
> before, but updated with 'b'.
>
> I hope this helps.
It didn't. I feel just as confused as before. What does "iat" mean? Is "update"
an arbitrary symbol (if so then you could have used "foo" instead of "update"
to make
On Sat, Mar 09, 2019 at 04:34:01PM +, Jonathan Fine wrote:
> There are (many) numbers between 1 and infinity. If a programmer
> defines __at_python__ on type(guido) then guido@python will have
> semantics.
It already has meaning: it calls the @ operator with operands "guido"
and "python".
Chris Angelico suggested that
a = a.update_with(b)
would be better than
a @update= b
One of the key points of += is that
parent.child['toy'].wheel[3].speed += 1
increases the speed that that wheel by 1, without having to write
parent.child['toy'].wheel[3].speed =
On Sun, Mar 10, 2019 at 3:37 AM Jonathan Fine wrote:
> I'd like to see some real-world examples of code that would be broken.
> As I recall, most or all of the code examples in the python-ideas
> thread on the '@' operator actually write ' @ '. So they would be
> good.
>
Steven D'Aprano asked me to explain the difference between
> a@update=b
> a@update b
It is the same as the difference between
a += b
a + b
The one uses a._iadd__(b), a.__add__(b) and so on. For the other,
replace 'add' by 'at_update', and '+' by '@update'.
By the way, the
On Sun, Mar 10, 2019 at 3:16 AM Jonathan Fine wrote:
>
> Anders Hovmöller wrote:
>
> > I don't understand what you mean. Can you provide examples that show the
> > state of the dicts before and after and what the syntax would be the
> > equivalent of in current python?
>
> If a.__radd__
Anders Hovmöller wrote:
> I don't understand what you mean. Can you provide examples that show the
> state of the dicts before and after and what the syntax would be the
> equivalent of in current python?
If a.__radd__ exists, then
a += b
is equivalent to
a = a.__radd__(b)
Similarly,
On Sat, Mar 09, 2019 at 03:33:25PM +, Jonathan Fine wrote:
> I've been thinking that it might be easier, in the long term, to make
> a big step and allow
> >>> a @update= b
> as valid Python. What do you think? (I hope it will look nicer once
> syntax highlighted.)
Are we supposed to know
I don't understand what you mean. Can you provide examples that show the state
of the dicts before and after and what the syntax would be the equivalent of in
current python?
> On 9 Mar 2019, at 16:33, Jonathan Fine wrote:
>
> I've been thinking that it might be easier, in the long term, to
I've been thinking that it might be easier, in the long term, to make
a big step and allow
>>> a @update= b
as valid Python. What do you think? (I hope it will look nicer once
syntax highlighted.)
For clarity, this would proceed via a.__iat_update__(b), and (a
@update b) would be similarly
26 matches
Mail list logo
