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

[Nick Coghlan]

On 23 January 2017 at 22:29, MRAB  wrote:
> 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.

Right, it's the fact parentheses are already allowed there, but mean
something quite different:

>>> with (1, 2, 3): pass
...
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: __enter__

These days, I'd personally be in favour of changing the parsing of
parentheses in that situation, as if we were going to add meaningful
context management behaviour to tuples we would have done it by now,
and having the name bindings next to their expressions is easier to
read than having them all at the end:

with (cm1() as a,
 cm2() as b,
 cm3() as c):
...

Relative to tuples-as-context-managers, such an approach would also
avoid reintroducing the old resource management problems that saw
contextlib.nested removed and replaced with contextlib.ExitStack.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

On Tue, 24 Jan 2017 at 01:42 Petr Viktorin  wrote:

> On 01/23/2017 10:22 PM, João Matos wrote:
> > Hello,
> >
> > I understand.
> > Python sources are very large. Any pointers to which file defines the
> > global statement syntax?
>
> Consider joining the core-mentorship list for questions like these:
> https://mail.python.org/mailman/listinfo/core-mentorship
>
> Anyway, Python's grammar is defined in the file Grammar/Grammar, and
> there's a mini-HOWTO at the top of that file. Good luck!
>

There's also https://cpython-devguide.readthedocs.io/en/latest/grammar.html
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Petr Viktorin]

On 01/23/2017 10:22 PM, João Matos wrote:

Hello,

I understand.
Python sources are very large. Any pointers to which file defines the
global statement syntax?


Consider joining the core-mentorship list for questions like these:
https://mail.python.org/mailman/listinfo/core-mentorship

Anyway, Python's grammar is defined in the file Grammar/Grammar, and 
there's a mini-HOWTO at the top of that file. Good luck!


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Mon, Jan 23, 2017 at 09:18:54PM +, João Matos wrote:

> Why should I repeat global if I can use the line separation character \ 
> (like I mentioned on my 1st email) or parentheses as I suggested?

That's the wrong question.

The right question is, why should the Python language be made larger, 
more complicated, with more lines of code, to support parentheses in 
global declarations, when there are already two perfectly good 
alternatives?

global spam
global eggs


global spam, \
   eggs


Even if it only adds one extra line of code to the Python interpreter, 
that's still a cost. But it will add more than that: it will require the 
implementation, tests and documentation. And all other Python 
interpretations will need to do the same: IronPython, Jython, PyPy, µPy, 
Stackless, Nuitka and possibly more. And it is a new feature that people 
have to learn.

Every new feature has a cost. Even if the cost is tiny, the question 
is, will the benefit be greater than the cost?

Supporting parentheses in from...import statements has major benefit:

from deep.package.name import (spam,
eggs, cheese, foo, bar, baz,
fe, fi, fo, fum)

is a big improvement over:

from deep.package.name import spam, eggs, cheese
from deep.package.name import foo, bar, baz
from deep.package.name import fe, fi, fo, fum

for at least two reasons: better efficiency, and DRY (Don't Repeat 
Yourself) with the package name.

But for globals, neither reason applies: global statements are a 
compile-time declaration, not an executable statement, so efficiency 
isn't relevant, and there is no significant DRY issue with repeating the 
keyword global itself.

So the question here is not "why shouldn't we allow parentheses?" but 
"why should we allow parentheses?"

If your answer is just "I think it looks nicer", you probably won't find 
a lot of people who agree, and even fewer people who agree enough to 
actually do the work of writing the patch, the tests and the 
documentation.

So that comes down to the most important question of all:

- are you volunteering to do the work yourself?

If there are no strong objections to adding this feature, it might be 
easier to get a core developer to offer to review your work and check it 
in, than to get a core developer to add the feature themselves.

I don't dislike this proposed feature. Nor do I like it. I would 
probably never use it: it is very rare for me to use global at all, and 
even rarer to use more than one or two globals. But if somebody else did 
the work, I wouldn't strongly object to it.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

On 01/23/2017 01:18 PM, João Matos wrote:


Why should I repeat global if I can use the line separation character \
 (like I mentioned on my 1st email) or parentheses as I suggested?


Because prefixing each line with global is more readable than either \ or ( )?  
At least to me.  ;)

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [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 > 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 > 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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[João Matos]

Hello,

The subject of this topic is a suggestion about the language and not the 
programming paradigm/style.


Why should I repeat global if I can use the line separation character \ 
(like I mentioned on my 1st email) or parentheses as I suggested?


"global existing_graph, expected_duration # "in_sec" is unnecessary"
No it is not unnecessary unless sec is the only unit you use (in this 
case we have several units of duration and thus it is necessary).


Best regards,

JM



On 23-01-2017 20:24, Chris Angelico wrote:

On Tue, Jan 24, 2017 at 6:37 AM, João Matos  wrote:

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


I think you're already running into serious design concerns here. Why
are file_size and file_mtime global? Perhaps a better design would
involve a class, where this function would become a method, and those
globals become "self.file_size" and "self.file_mtime". Then you can
have a single global instance of that class for now, but if ever you
need two of them, it's trivially easy. You encapsulate all of this
global state into a coherent package.

But if you MUST use globals, I would split the lines according to purpose:

global existing_graph, expected_duration # "in_sec" is unnecessary
global file_size, file_mtime
global no_change_counter # also probably needs a new name

That way, you're unlikely to run into the 80-char limit.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[João Matos]

Hello,

I understand.
Python sources are very large. Any pointers to which file defines the 
global statement syntax?


Best regards,

JM


On 23-01-2017 19:53, Brett Cannon 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 > 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@python.org 
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Tue, Jan 24, 2017 at 6:37 AM, João Matos  wrote:
> 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
>

I think you're already running into serious design concerns here. Why
are file_size and file_mtime global? Perhaps a better design would
involve a class, where this function would become a method, and those
globals become "self.file_size" and "self.file_mtime". Then you can
have a single global instance of that class for now, but if ever you
need two of them, it's trivially easy. You encapsulate all of this
global state into a coherent package.

But if you MUST use globals, I would split the lines according to purpose:

global existing_graph, expected_duration # "in_sec" is unnecessary
global file_size, file_mtime
global no_change_counter # also probably needs a new name

That way, you're unlikely to run into the 80-char limit.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Nick Timkovich]

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  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  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@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephan Houben]

For what it's worth, I normally just do:

global a
global b

But I've never needed more than two.
I think if you need more, then there is a serious style issue. That it
looks syntactically ugly is a feature.

Perhaps we should deprecate the comma in global ;-) .

Stephan

Op 23 jan. 2017 8:38 p.m. schreef "João Matos" :

> 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@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[João Matos]

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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Terry Reedy]

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

--
Terry Jan Reedy


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

You can just write
  global foo, bar
  global baz, bletch

On Mon, Jan 23, 2017 at 10:43 AM, 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
>
>
> Best regards,
>
> JM
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/