These are good points.
I would suggest the unary - creates serious readability concerns and
should only be valid as 0 x -; ~ and unary + raise other
considerations. The ~ operator is extremely useful in bitshift and
bitmask operations, and has an ugly ~x representation as 0 1 - x ^ in
the same way as unary -x is 0 x - (which is elegant).
Unary can't be assumed from 0 x +, and it seems inelegant to use
things like ~x -x +x (i.e. without white space)
On Fri, Apr 2, 2021 at 12:09 PM MRAB
On 2021-04-02 16:55, Richard Damon wrote:
I think python only has 3 unary operations, + - and ~ and only + and - can also be binary operations.
unary + has less uses, since it normally just passes its argument, if valid, unchanged, but can be used to validate that its argument has the right type. I am not sure if a type could define its own unary+ to do something special, but I thought it could.
The Counter class from the collections module has a special use for unary +.
On 4/2/21 11:19 AM, John wrote:
True. It gets ambiguous when doing n*(-(x + y)) i.e. n x y + - * (fail). The simplest solution is n 0 x y + - *
I can't actually think of any other unary operators.
On Fri, Apr 2, 2021 at 10:54 AM Richard Damon
wrote: One problem with trying to mix RPN with in-fix is that some operators, like - can be either a unary or binary operation in the in-fix notations, distinguished by context. In RPN you have lost that context.
is x y - - the same as -(x-y) or is it x-(-y) ? or is it waiting for another operator and be x ?? (-(-y)) or is it expecting a previous operand and is ?? - (x-y)
(same with +)
Typical RPN systems get around this by having unary - be a different symbol/key that binary -
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TOLSXC... Code of Conduct: http://python.org/psf/codeofconduct/