Guido van Rossum wrote:
> In Python 3.10 we will no longer be burdened by the old parser (though 3rd
> party tooling needs to catch up).
> One thing that the PEG parser makes possible in about 20 lines of code is
> something not entirely different from the old print statement. I have a
> prototype:
> Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun 9 2020,
> 16:31:17)
> [Clang 11.0.0 (clang-1100.0.33.8)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> Cannot read termcap database;
> using dumb terminal settings.
> > print 2+2
> > 4
> > print "hello world"
> > hello world
> > print "hello", input("Name:")
> > Name:Guido
> > hello Guido
> > print 1, 2, 3, sep=", "
> > 1, 2, 3
> > But wait, there's more! The same syntax will make it possible to call
> any
> function:
> > len "abc"
> > 3
> > Or any method:
> > import sys
> > sys.getrefcount "abc"
> > 24
> > Really, any method:
> > class C:
> > ... def foo(self, arg): print arg
> > ...
> > C().foo 2+2
> > 4
> > There are downsides too, though. For example, you can't call a
> method
> without arguments:
> > print
> > <built-in function print>Worse, the first argument cannot start
> with a parenthesis or bracket:
> > print (1, 2, 3)
> > 1 2 3
> > C().foo (1, 2, 3)
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > TypeError: C.foo() takes 2 positional arguments but 4 were given
> > print (2+2), 42
> > 4
> > (None, 42)
> > C().foo [0]
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > TypeError: 'method' object is not subscriptable
> > No, it's not April 1st. I am seriously proposing this (but I'll
> withdraw it
> if the response is a resounding "boo, hiss"). After all, we currently have
> a bunch of complexity in the parser just to give a helpful error message to
> people used to Python 2's print statement:
> > print 1, 2, 3
> > File "<stdin>", line 1
> > print 1, 2, 3
> > ^
> > SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1,
> > 2, 3)?
> > And IIRC there have been a number of aborted attempts at syntactic
> hacks to
> allow people to call functions (like print) without parentheses, although
> (I think) none of them made it into a PEP. The PEG parser makes this much
> simpler, because it can simply backtrack -- by placing the grammar rule for
> this syntax (tentatively called "call statement") last in the list of
> alternatives for "small statement" we ensure that everything that's a valid
> expression statement (including print() calls) is still an expression
> statement with exactly the same meaning, while still allowing
> parameter-less function calls, without lexical hacks. (There is no code in
> my prototype that checks for a space after 'print' -- it just checks that
> there's a name, number or string following a name, which is never legal
> syntax.)
> One possible extension I didn't pursue (yet -- dare me!) is to allow
> parameter-less calls inside other expressions. For example, my prototype
> does not support things like this:
> > a = (len "abc")
> > File "<stdin>", line 1
> > a = (len "abc")
> > ^
> > SyntaxError: invalid syntax
> > I think that strikes a reasonable balance between usability and
> reduced
> detection of common errors.
> I could also dial it back a bit, e.g. maybe it's too much to allow 'C().foo
> x' and we should only allow dotted names (sufficient to access functions in
> imported modules and method calls on variables). Or maybe we should only
> allow simple names (allowing 'len x' but disallowing 'sys.getrefcount x'.
> Or maybe we should really only bring back print statements.
> I believe there are some other languages that support a similar grammar
> (Ruby? R? Raku?) but I haven't investigated.
> Thoughts?
One additional drawback ... if anytime sooner or later you would wanted to
introduce scoped variables like in `Rust` with keyword `var` or `let` it could
make some problems ...
```python
let x = 3 # Parser will think that it is the function let
```
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/YBJZDOW27R6V635BKXUWE2YWN2WHW6B2/
Code of Conduct: http://python.org/psf/codeofconduct/
