Why would it know to stop reading after seven lines? Maybe you want three lines now, and read the rest later? Maybe you just paused, and want another two lines in a moment.
But you referred to “no more text to read”. That’s when python tries to read data and gets an ed-of-file indication from the OS. When reading from a regular file, that’s when you reach the sctual end if file. When reading from the terminal, you typically type Control-d to “close” the file.
The dot convention I recommended would tell longinput to stop reading for now, but leave standard input “open” to resume reading later. This is basically how input and readline already work, except it’s a newline character, not a dot, that tells the function to stop reading without consuming all available input.
A loop is a key language capability, not a workaround.
The suggested multiline input function is too narrow to be generally useful, and a generalized handle-all-cases multiline function would have a complicated API. Consider the possible use cases:
You might want to prompt for input until a predicate is met. (e.g. a valid integer is entered).
The response to a previous prompt might alter what the next input prompt should be.
Of course you CAN, but that’s not how people will generally expect Ctrl-C to behave. Take the Python REPL [1] as an example. If you type in def spam(): and hit Enter, Python prompts for more text. When you’re done, give it a blank line to signal the end of the function. But if you press Ctrl-C, Python aborts the input and gives you back a fresh prompt, without running what you just gave it. That’s what people expect. Sure, you CAN redefine Ctrl-C to actually run the block of code, but it’d confuse people.
Ctrl-D (or Ctrl-Z on Windows) is an understood “end” signal. Blank lines, where appropriate, can have that meaning. A dot on an otherwise-blank line has a long heritage in various protocols (most notably SMTP), although it’s perhaps less useful for end users who might not be familiar with that. Any of those would be better suited than Ctrl-C.
Though I have to admit that I’ve abused signals in various ways, such as hooking SIGQUIT as a command signal, since it’s easy to type as Ctrl-.
it wouldnt, youd have to type it all in one go. it’s not supposed to be something you input line by line, it’s a longinput. if you want to input line by line, i guess you could have an optional argument for it, for example a string longinput("tell me about yourself’, ‘END INPUT’)
again, youre thinking about longinput as if it was an input where you input over and over. i imagine it as you input one thing, that happens to be multiple lines. again, longinput could be bimodal, as in having a mode where you keep inputting or a mode where you input once but it recognises you inputted a paragraph in the terminal rather than just a sentence on one line
longinput is only looking for a single input, not multiple. you paste your text and it reads everything just inputted and stores it. if i copy and paste a long paragraph and input it, i am not inputting that line by line, im inputting as a paragraph and i want longinput to know that
This is sounding more and more like something specific to YOUR use-case, so it’s something for YOUR codebase. I don’t think you’re going to see this as a built-in, because even if one did exist, it’s unlikely to perfectly match your narrow requirements.
Side point: Please can you use some capital letters in your posts? They look sloppy and careless, leaving us assuming the same about your proposal too.
i feel like most of you read this and thought i meant: ‘i want to keep inputting lines over and over’, and then got confused on how it would know when i stopped. while thats a useful use case, my idea was literally just: ‘i want to copy and paste a paragraph instead of a single line, it is is literally just input but it recognises text beyond a single line. i need to copy and paste huge text blocks regularly from microsoft word (and other things) into my python terminal’
Well this is just a suggestion, nothing more. I just feel like it would be useful to be able to copy and paste blocks of text into the terminal and for Python to understand that.
I don’t think that’s true here, it would require inputting each line over and over. You can’t give python a block of text to my knowledge and have it be inputted as is in one copy and paste and enter.
Well, this is better defined now that Yat has clarified that they’re
thinking of copy/paste, not read-lines-from-a-terminal.
The difficulty of course is that terminals don’t know anything about
copy/paste as they emulate serial port attached teletypes. So as far as
Python-running-in-a-terminal is concerned the user’s done a lot of
typing in a short space of time.
That said, there are escape sequences used to indicate a “begin paste
mode” and “end paste mode” transition (I know this because I can paste
into vim in my iTerm, and a paste doesn’t trigger the autoindent stuff).
So I can imagine a mechanism which honours those escapes, and gathers
text to the end-of-patse marker, which would provide Yat’s function.
The terminal doesn’t distinguish between newlines in text that you paste
in and newlines produced by pressing the Enter key. Nor does it
distinguish between one text pasting and two consecutive text pastings.
You’re going to have to enter something to mark the end of the input
that you want to be considered as “one thing”.