Allow || and && as alternatives to "or" and "and"

Ideas
1

I would like to see || and && as alternatives to or and “and”. This has been touched on briefly before, but these often want a full change. I don’t wanna see it replacing, but rather a valid alternative for ease of use and transition. We already have the “;” as a statement terminator, a foreign concept in C-like language. So why not use || and && as a way of improving accessibility and allow effective ease of use. Coming as a dev in C and Python, it is a good idea

2

These days Python has become a wide spread language - and the more widely used something is, the more reason you need to change it.

This change would not only introduce nothing new, but also possibly block the usage of this syntax for other possible features in the future. These days you must have at least one very good or many good reasons to change or extend the syntax of Python.

And of course, remember the Zen of Python:
There should be one-- and preferably only one --obvious way to do it.

Also ; has good use cases that might otherwise not be possible to implement.

12 Likes
3

Its not syntax-breaking at all, but it shouldn’t be a SyntaxError. It should be a silent redirect. Yes the zen says use the accepted way, but thats more for not reinventing the wheel multiple times like trying to introduce switch-case when we have match-case. Your just redirecting the || and && to their “and” and “or”, its redirecting a incorrect method to the accepted counterpart. Thats in line with the Zen.

1 Like
4

I understand what you’re saying and respect your opinion, but I’m hard -1 on this.

For me, previously coming from C and Java, I prefer Python’s and and or and I don’t think that switching from a language with && and || to Python’s way of doing it is a big enough mental effort for new users to introduce such an alias.

Also, just redirecting the || and && to their “and” and “or” is simpler said than done. I think with the current syntax of the language it COULD be done and would not clash with other syntax, but again we want to reserve as much syntax for the future as possible.

Another point is that Python is designed to be very readable like plain english. This would give the people that switch from other languages use a different, less readable way of writing the same thing. Then even newer people would have to learn both syntaxes instead of just one, which already is very readable to a new coder.

7 Likes
5

There are many larger issues to keep in mind when moving from C to Python than the syntax of “and” and “or”. The good news is that the semantics of and and && are the same, so it’s only a syntax issue.

Python prefers not to have multiple ways to do the same thing (although of course due to history and improvements, there are many examples where this is not the case).

8 Likes
6

Just add

#define and &&
#define or ||

in your C code and use and and or in both Python and C. Was this your problem?

I remember some beginners added this, and also

#define begin {
#define end }
#define then

after transition from Pascal to C. It didn’t last long. The difference in semantics cannot be ignored.

4 Likes
7

Or ´#include <iso646.h>

10 Likes
8

Hard -1 on this. If you don’t like Python language, then don’t use it. It brings no benefits to the development of Python language and community and it only complicates already too complicated language.

2 Likes
9

Personally Im -1 on this, but perhaps you could code a simple ‘preprocesser’ that looks over the script and replaces each || and && with or and and should be possible to make. (Although, checking wether the &&/|| is in strings or comments (that don’t get eval’d) is harder).

Also, modifying CPython to allow for this should be quite simple too, perhaps forking it, and then using that version of CPython could work for you too.

2 Likes
10

A more robust implementation isn’t much harder since the tokenize module has already done the hard work for us. In this case, we can treat && as two consecutive & operator tokens and transform them into a single and name token, and likewise for ||:

from io import StringIO
from itertools import pairwise, chain
from tokenize import generate_tokens, untokenize, OP, NAME, ENDMARKER

def normalize_and_or(source):
    token_pairs = pairwise(chain(
        generate_tokens(StringIO(source).readline),
        [(ENDMARKER, '', (1, 0), (1, 0), '')] # dummy token to pair the end
    ))
    for (
        (last_toknum, last_tokval, (last_srow, last_scol), (last_erow, last_ecol), last_line),
        (toknum, tokval, (srow, scol), (erow, ecol), line)
    ) in token_pairs:
        if (last_toknum == toknum == OP and last_tokval == tokval in '&|' and
                last_erow == srow and last_ecol == scol):
            last_toknum = NAME
            last_tokval = 'and' if tokval == '&' else 'or'
            last_ecol = ecol
            next(token_pairs)
        yield last_toknum, last_tokval, (last_srow, last_scol), (last_erow, last_ecol), last_line

print(untokenize(normalize_and_or('''\
if True && False || True: # && means and, || means or
    print("True && False || True is true")
''')))

which outputs:

if True and False or True: # && means and, || means or
    print("True && False || True is true")
5 Likes
11

I completely agree with the approach of using custom preprocessors.

This resolves MANY syntax proposals, whether alternative or new.

They could be used as plugins integrated into a tool that manages and imports them, almost like the cookiecutter.

Everyone is happy:

  • The language remains intact and unambiguous
  • Anyone can choose the syntax they prefer

Perhaps only those who read third-party custom syntax will be unhappy, but the responsibility would lie entirely with the project maintainer.

On the other hand, it will also serve as an experiment to measure the success and failure of adapting to new syntaxes, and if it performs well, it can be incorporated into the language.

1 Like