[Python-ideas] globals should accept parenteses for extending beyond 1 line

[MRAB]

On 2017-01-23 20:09, Nick Timkovich wrote:
> Related and probably more common is the need for the line-continuation
> operator for long/multiple context managers with "with". I assume that's
> come up before, but was it also just a low priority rather than any
> technical reason?
>
It has come up before, and there is a technical reason, namely the 
syntactic ambiguity when parsing. Not impossible to fix, but probably 
not worth the added complexity.

> On Mon, Jan 23, 2017 at 1:53 PM, Brett Cannon <brett at python.org
> <mailto:brett at python.org>> wrote:
>
>     Actually multi-line import doesn't work:
>
>     File ".\Untitled.py", line 1
>         import (tokenize,
>                ^
>     SyntaxError: invalid syntax
>
>     I think you're getting this mixed up with parentheses being allowed
>     in `from ... import (...)` syntax. So unless there is another
>     single-word keyword that allows multi-line arguments using
>     parentheses I don't think there's an inconsistency here.
>
>     Plus, as Guido pointed out, the current syntax isn't preventing you
>     from doing something you can already do. So if you want to add
>     parentheses support to global, nonlocal, and import, you can propose
>     a patch, but it's not a priority to solve without someone providing
>     a solution since it doesn't open up anything new for something
>     people don't use on a regular basis.
>
>
>     On Mon, 23 Jan 2017 at 11:39 João Matos <jcrmatos at gmail.com
>     <mailto:jcrmatos at gmail.com>> wrote:
>
>         Hello,
>
>         You are correct, my mistake. I should have written global and
>         not globals.
>
>         The purpose of using parentheses on the import statement is not
>         (in my
>         view) for operational efficiency but for appearance/cleaness.
>         The same applies to using it to global.
>
>         One does not need to have 10 global vars. It may have to do with var
>         name length and the 79 max line length.
>
>         This is an example from my one of my programs:
>         global existing_graph, expected_duration_in_sec, file_size, \
>              file_mtime, no_change_counter
>
>         Anyway, the use of global being rare is of no concern. The point
>         of my
>         suggestion is standardization.
>         My opinion is that a standard language is easier to learn (and
>         teach)
>         than one that has different syntax for the same issue, depending
>         on the
>         statement.
>
>         In short, if the recommended multi-line use for import is
>
>         import (a, b,
>              c)
>
>         instead of
>
>         import a, b, \
>              c
>
>         Then the same should apply to global.
>
>
>         Best regards,
>
>         JM
>
>
>
>
>         On 23-01-2017 19:25, Terry Reedy wrote:
>         > On 1/23/2017 1:43 PM, João Matos wrote:
>         >> Hello,
>         >>
>         >> I would like to suggest that globals should follow the
>         existing rule
>         >> (followed by the import statement, the if statement and in
>         other places)
>         >> for extending beyond 1 line using parentheses.
>         >> Like this:
>         >> globals (var_1, var_2,
>         >>     var_3)
>         >>
>         >> instead of what must be done now, which is:
>         >> globals var_1, var_2 \
>         >>     var_3
>         >
>         > The declaration keyword is 'global'; 'globals' is the built-in
>         > function.  In any case
>         >
>         > global var_1, var_2
>         > global var_3
>         >
>         > works fine.  There is no connection between the names and,
>         unlike with
>         > import, no operational efficiency is gained by mashing the
>         statements
>         > together.
>         >
>         > This issue should be rare.  The global statement is only
>         needed when
>         > one is rebinding global names within a function*.  If a function
>         > rebinds 10 different global names, the design should probably be
>         > re-examined.
>         >
>         > * 'global' at class scope seems useless.
>         >
>         > a = 0
>         > class C:
>         >     a = 1
>         >
>         > has the same effect as
>         > a = 0
>         > a = 1
>         > class C: pass
>         >