Hello everyone. how to input this text in python
I like C
very
much
Do you mean you want the user to input multiple lines into a program using input()?
If this is the case you need to write a loop calling input() multiple times:
lines = []
while True:
try:
line = input()
except EOFError:
break
lines.append(line)
print(lines)
Note that here, you need to hit “ctrl+D” (or ctrl+Z on Windows) to signal that the input is “finished”. You may as well use another solution, like passing a special word “END” to end the input:
lines = []
while True:
line = input()
if line == 'END':
break
lines.append(line)
Thanks. But I want without “END” or enter or any commands, l input multiline strings and python convert this string to list. For example:
I like C
very
much
[“I”, “like”, “C”, “very”, “much”]
If you are using an interactive input, this is not possible, because you need to tell your program that you are finished inputting things, so it can process your lines.
What you can do is put your text into a file, then process that file.
Try to use the following as a starting point:
>>> lines = []
>>> while True:
... line = input()
... if not line:
... break
... lines.append(line)
...
I like
Python
more than C
>>> lines
['I like ', 'Python', 'more than C']
This is a contradiction, because, to get:
["I", "like", "C", "very", "much"]
… your multi line strings would be:
I
like
C
very
much
… in which case, all you need is lines = input().split()
I agree with this approach. Since @Teach does not want to use a special character/string to end the input, using the empty line is the most reasonable option.
In this case we must click enter for finish inputting.
In [1]: lines = []
In [2]: while line := input():
...: lines.append(line)
...:
here
are
some lines
In [3]: lines
Out[3]: ['here', 'are ', 'some lines']
I think we or you are finding your “finish” constraint confusing. You
want to end input text. For that text to be finite, Python needs to know
when it ends. How do you want to indicate when it ends?
Use a substitute for newline and then replace it with newline. Note that long input() response that wraps on the terminal is seen as one line of input.
>>> s = input().replace('\t', '\n')
I like C very much
>>> s
'I like C\nvery\nmuch'
>>> s2 = """I like C
... very
... much"""
>>> s2
'I like C\nvery\nmuch'
Python noob here.
Is
If not line:
break
the same as
If len(line)==0:
break
Python treats some things as ‘falsy’ (pretend it’s false) and everything else as ‘truthy’ (pretend it’s true).
Zero is falsy, as are empty collections (empty list, empty tuple, empty dict, etc) and empty (i.e. zero-length) strings.
Also related from PEP-8:
For sequences, (strings, lists, tuples), use the fact that empty sequences are false:
# Correct: if not seq: if seq: # Wrong: if len(seq): if not len(seq):
Technically speaking, not line is broader than not len(line) == len(line)==0 as the former applies to non-sizable falsy objects such as False. But if you know that you have a collection object that is False when empty, then I agree with PEP 8 and Brian.
fyi empty collections evaluate as True not False, unlike Lisp with NIL.
Python disagrees:
>>> bool([])
False
>>> bool({})
False
hmm… noob mistake on my half.
(bool(x) does not equal x == True)
>>> 0 == False
True
>>> [] == False
False
>>> () == False
False
>>> {} == False
False
I believe it’s in PHP or Javascript that something like [] == false returns true because it’s testing whether []is false-like. Yuck! 
Originally, Python didn’t have False and True, it used 0for false and 1 for true. Falseand Truewere added later, but remain equal to 0 and 1 for backwards compatibility.
The rule is that zero and empty collections are treated as false-like and everything else as true-like.
In python the concept of True or False does not really exist, it’s more of a truthy/falsey.
The operations use the __eq__ of the left type..That means that a == b will use a.__eq__(b). If that returns something truthy, the expression evaluates to True, similarly with returning False. If NotImplemented is returned, we use b.__eq__(a) (at least that’s how it’s with other dunders).
As you can see, there is a lot of room to make custom == functionality, so using is might have been better to demonstrate this with in the first place.
Generally though, just because something seems truthy in one context, doesn’t mean it’s so in all contexts. (Special Dunder methods might be involved).