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

Nick Timkovich prometheus235 at gmail.com
Mon Jan 23 15:09:12 EST 2017


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?

On Mon, Jan 23, 2017 at 1:53 PM, Brett Cannon <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> 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
>> >
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170123/2625ad1c/attachment.html>


More information about the Python-ideas mailing list