Hi Guido,
Excited about the possibilities of the new PEG parser !
Have there been any consideration to allow this new call syntax to
actually quote the expression given as parameter ? Or have a different
meaning than a normal call ?
In IPython/Jupyter we use the fact that this is not valid syntax
currently to provide magics/macros:
In [2]: timeit time.sleep(0.1)
103 ms ± 422 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
(the timeit "function" will here actually get a string but that's a detail).
In ambiguous case users can force the resolution with an extra % which
allows assignments.:
In [3]: res = %timeit -o time.sleep(0.1)
103 ms ± 549 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
In [4]: res
Out[4]: <TimeitResult : 103 ms ± 549 µs per loop (mean ± std. dev. of
7 runs, 10 loops each)>
We would be excited to have something similar available in core Python.
--
Matthias
On Tue, 9 Jun 2020 at 17:07, Guido van Rossum <gu...@python.org> 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?
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
> _______________________________________________
> 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/NCQX6ZIBREUTLS52VVG3DSZ43OEXJFTT/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
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/QOEZYQ6RPZ3TKP3NFBXRED2PDFYY7XK5/
Code of Conduct: http://python.org/psf/codeofconduct/
