On Fri, 10 Mar 2023 at 09:20, Grant Edwards <grant.b.edwa...@gmail.com> wrote:
>
> On 2023-03-09, Cameron Simpson <c...@cskk.id.au> wrote:
>
> > [...]
> >>It finally dawned on me after seeing an example I found elsewhere that
> >>you don't call some module method to fetch the next user-entered line.
> >>
> >>You call the input() built-in.
> >
> > Ah. That's not overtly stated? [...reads...] Ah, there it is in the last
> > sentence of the opening paragraph. Not quite as in-your-face as I'd have
> > liked it.
>
> What threw me off the track for a while was that the sentence to which
> you refer says it affects the "prompts offered by input()". In my head,
> that means it changes the string that's printed on stdout before stuff
> is read from stdin. That's different that affecting the handling of
> user input read by input().
>
> It doesn't actually change anything about the prompts provided by
> input(). It changes the handling of the user input by input().
>
> I guess I read it too literally. I must spend too much time with
> computers.
It does actually affect the prompts, although only in subtle ways.
import readline
print("Pseudo-prompt: ", end="")
msg1 = input()
msg2 = input("Actual prompt: ")
print(repr(msg1))
print(repr(msg2))
At each of the prompts, type a bit of text, then backspace it all the
way. The actual prompt will remain, but the pseudo-prompt will get
cleared off. There'll be other small differences too.
Maybe that could be mentioned somewhere too; but this is definitely
something to be more careful with locking in, since the behaviour may
not be quite the same if it's using libedit instead of GNU readline.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
