-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Append space after completed keywords #69396
Comments
Open parenthesis ('(') is appended after completed callable globals and attributes. I propose to add a space after completed keyword. In most cases a space is either required after the keyword, or recommended by PEP-8. Attached patch implements this. |
I agree with adding a space in some cases, but not others. E.g. "pass" would only need a space if you wanted to add a comment, "return" often takes no argument, "lambda" may need an immediate colon (lambda: x). See <https://github.com/vadmium/etc/blob/0f8d459/python/pythonstartup.py#L210\> for a whitelist of keywords that I thought should always have spaces, but beware this list may not be up to date (no “await” nor “async” for instance). BTW I don’t agree with the default of forcing an open bracket “(” for callables; consider decorators, subclassing, deferred function calls, etc, where that bracket may not be wanted. |
Good catch Martin. Indeed, "pass", "break" and "continue" don't need a space, and "True", "False" and "None" need a space only in rare cases like "None in collection". Some keywords ("else", "finally", "try") need a colon. But while "return" and "lambda" not always need a space, I think that needing a space is more common case, and in any case the redundant space doesn't make a harm. Here is revised patch that doesn't add a space in some cases and instead adds a colon in some cases. |
“Else” doesn’t always use a colon. Consider “1 if x else 2”. Again, if Python started adding unwanted spaces and colons I imagine users could be annoyed and think Python is being too smart and complicated for its own good. But maybe see what others say. |
I tested the patch. "wi<tab>" displays "with " (space)., but "fo<tab>" displays "for" (no space). I don't understand why. Well, it's not a big issue, anyway the patch looks good to me. IMHO you should apply it to Python 3.4-3.6 (not only 3.6). |
Victor, maybe because “for” also stands for “format”? |
Good catch Martin. Unfortunately the completer doesn't take context into account. "else" with a colon is a common case, but unwanted colon could be annoyed. I agree that it would be safe to not append a colon after "else". At least unless we make the completer context aware. However I don't think that unwanted space would be so annoyed. Here is updated patch. I see that your code does an autocompletion for module names in "import", Martin. This was my next idea. Do you want to provide a patch for including this in CPython?
Because there is "format(".
This is definitely a new feature. And there is a risk to break something (if standard completer is used programmatic). |
Ok, it's up to you. |
Yes I am interesting in making a patch for auto-completing module names. I’ll leave it on my to-do list, but don’t expect it overnight. :) My code does some rough parsing of Python syntax, but maybe that is not needed for “import x”, though it might be needed to support module attributes for “from x import y”. |
New changeset f64ec4aac935 by Serhiy Storchaka in branch 'default': |
Thank you for your review Martin. Hope to see your patch for completing import statement. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: