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

Reply via email to