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
On Sat, Mar 09, 2019 at 11:39:39AM -0800, Stephan Hoyer wrote:
> Would __iadd__ and __isub__ be added to collections.abc.MutableMapping?
No, that will not be part of the PEP. The proposal is only to change
dict itself. If people want to add this to MutableMapping, that could be
considered
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
You can do :
I suggest this syntax:
> >>> map(.upper(), ['a', 'b', 'c'])
>
map(dot('upper'), 'a b c'.split())
map(dot('replace', 'x', 'y'), 'xo do ox'.split())
def dot(name, *args, **kwargs):
return lambda self: getattr(self, name)(*args, **kwargs)
> This would also work for attributes:
>
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,
Would __iadd__ and __isub__ be added to collections.abc.MutableMapping?
This would be consistent with other infix operations on mutable ABCs, but
could potentially break backwards compatibility for anyone who has defined
a MutableMapping subclass that implements __add__ but not __iadd__.
On Sat,
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
Thanks to everyone who has contributed to the discussion, I have been
reading all the comments even if I haven't responded.
I'm currently working on an update to the PEP which will, I hope,
improve some of the failings of the current draft.
--
Steven
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
08.03.19 23:16, Martin Bammer пише:
what about the idea that the interpreter preallocates and preinitializes the
tuples and dicts for function calls where possible when loading a module?
Before calling a function then the interpreter would just need to update the
items which are dynamic and
09.03.19 03:02, Greg Ewing пише:
Martin Bammer wrote:
what about the idea that the interpreter preallocates and
preinitializes the tuples and dicts for function calls where possible
when loading a module?
This would not be thread-safe. Locking would be needed around uses
of the preallocated
Ok right. There are some details which need to modify the idea:
- Thread safety:
Instead of locking the thread id could be saved in the object and then
checked when the object is used. If the thread id is wrong then a new
object must be created.
I think there is no additional locking necessary
Thread safety is not a problem here because of the GIL.
Am Sa., 9. März 2019 um 02:03 Uhr schrieb Greg Ewing <
greg.ew...@canterbury.ac.nz>:
> Martin Bammer wrote:
>
> > what about the idea that the interpreter preallocates and preinitializes
> > the tuples and dicts for function calls where
32 matches
Mail list logo
