My two cents as well.
I also find the open parenthesis very annoying. For me, it's asymmetry
with PyCharm behavior, and inconsistency with bash.
PyCharm adds the parenthesis, but also adds the end parenthesis, so
the whole use of parentheses is consistent: the user has not to worry
about them.
Bash refuses to guess when it's ambiguous, and stops until you fill
the ambiguous part.
Right now, the REPL implements a mixed situation where it both assumes
your usage, and does not help you all the way through. Although we can
all agree that functions most of the time are invoked, rather than
used as is.
IMHO, either the parenthesis should not be added, or two parentheses
should be added and the cursor placed in the center (I am unsure about
the details of the REPL implementation, but I guess it's possible) at
least to have a consistent experience.
On Thu, 25 Apr 2019 at 14:24, Jonathan Fine <jfine2...@gmail.com> wrote:
>
> This is an interesting thread. Here's my two cents worth. (Colloquial US
> English for a low-value opinion.)
>
> I'm in favour of sensible defaults (of course). In this situation, perhaps
> this means defaults that work well for those who would find it difficult to
> select a different default. Put enough way, values that work well for Emacs
> users should not be the default (unless they also work well for beginners).
>
> Sometimes, when I'm using a module for the first time (or when I'm puzzled
> about Python's behaviour and online documentation), I find myself doing
> >>> help(something)
> quite often. And I find myself typing
> >>> help({})
> instead of
> >>> help(dict)
> to avoid the unwanted
> >>> help(dict(
>
> My preference, which might work well for a wide range of use cases, is
> 1. If the initial identifier is help, tab produces the opening paren (.
> 2. If the intial identifier is callable, tab produces the opening paren (.
> 3. After help(, tab does not produce opening paren (.
> 4. Otherwise, tab does produce opening paren (.
> 5. Perhaps, after something like
> >>> help(int
> have tab produce the CLOSING paren ).
>
> As I said, just my two cents worth. Your opinions may vary.
>
> --
> Jonathan
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
