globals should accept parenteses for extending beyond 1 line
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
You can just write global foo, bar global baz, bletch On Mon, Jan 23, 2017 at 10:43 AM, João Matos <jcrmatos@gmail.com> 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)
Hello, To me that makes no sense. If for the import statement the rule is to use the parentheses and not repeating the import statement, why should it be different with global? Best regards, JM On 23-01-2017 19:14, Guido van Rossum wrote:
You can just write global foo, bar global baz, bletch
On Mon, Jan 23, 2017 at 10:43 AM, João Matos <jcrmatos@gmail.com <mailto:jcrmatos@gmail.com>> 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 <mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas <https://mail.python.org/mailman/listinfo/python-ideas> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>
-- --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
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
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
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" <jcrmatos@gmail.com>:
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/
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@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
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@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@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 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
On 23-01-2017 19:25, Terry Reedy wrote: 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/
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@python.org <mailto:brett@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@gmail.com <mailto:jcrmatos@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 >
On 23 January 2017 at 22:29, MRAB <python@mrabarnett.plus.com> 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 "<stdin>", line 1, in <module> 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 | ncoghlan@gmail.com | Brisbane, Australia
On 2017-01-26 16:02, Nick Coghlan wrote:
On 23 January 2017 at 22:29, MRAB <python@mrabarnett.plus.com> 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 "<stdin>", line 1, in <module> 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.
Just because the 'with' is followed by a '(', It doesn't necessarily mean that it's a tuple. The 'as' is preceded by an expression, which could start with '('. OTOH, I can't remember ever seeing the expression start with '('; it's usually the name of a callable.
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 <jcrmatos@gmail.com <mailto:jcrmatos@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@python.org <mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
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!
On Tue, 24 Jan 2017 at 01:42 Petr Viktorin <encukou@gmail.com> 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
On Tue, Jan 24, 2017 at 6:37 AM, João Matos <jcrmatos@gmail.com> 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
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 <jcrmatos@gmail.com> 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/
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~
On Mon, Jan 23, 2017 at 09:18:54PM +0000, 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
participants (12)
-
Brett Cannon -
Chris Angelico -
Ethan Furman -
Guido van Rossum -
João Matos -
MRAB -
Nick Coghlan -
Nick Timkovich -
Petr Viktorin -
Stephan Houben -
Steven D'Aprano -
Terry Reedy