IndentationError when pasting code in Python 3 interpreter mode Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) 2019 Community Moderator Election Results Why I closed the “Why is Kali so hard” questionPython in GNOME code baseUse tabs for indentation in Python modeVim :fold of python code not different to C/C++ codecan something besides the shebang set the interpreter?Specifying a generic interpreter for a program like expect?how to write python code to change display colorThe python command starts the the wrong version of the python interpreterRun python script without declare it interpreterWhat's the purpose of having “env [shell]” as an interpreter?Cant change python interpreter in Visual Studio Code on Mac

Why are there no cargo aircraft with "flying wing" design?

Is a manifold-with-boundary with given interior and non-empty boundary essentially unique?

Can Pao de Queijo, and similar foods, be kosher for Passover?

Letter Boxed validator

How to recreate this effect in Photoshop?

Why is "Captain Marvel" translated as male in Portugal?

Is high blood pressure ever a symptom attributable solely to dehydration?

Did Xerox really develop the first LAN?

What causes the vertical darker bands in my photo?

What is the longest distance a 13th-level monk can jump while attacking on the same turn?

Should I call the interviewer directly, if HR aren't responding?

Doubts about chords

Using et al. for a last / senior author rather than for a first author

How to motivate offshore teams and trust them to deliver?

Is the Standard Deduction better than Itemized when both are the same amount?

How to deal with a team lead who never gives me credit?

What would be the ideal power source for a cybernetic eye?

Is there a documented rationale why the House Ways and Means chairman can demand tax info?

How can I make names more distinctive without making them longer?

Does surprise arrest existing movement?

What is this single-engine low-wing propeller plane?

Why did the IBM 650 use bi-quinary?

Is there a "higher Segal conjecture"?

How to bypass password on Windows XP account?



IndentationError when pasting code in Python 3 interpreter mode



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)
2019 Community Moderator Election Results
Why I closed the “Why is Kali so hard” questionPython in GNOME code baseUse tabs for indentation in Python modeVim :fold of python code not different to C/C++ codecan something besides the shebang set the interpreter?Specifying a generic interpreter for a program like expect?how to write python code to change display colorThe python command starts the the wrong version of the python interpreterRun python script without declare it interpreterWhat's the purpose of having “env [shell]” as an interpreter?Cant change python interpreter in Visual Studio Code on Mac



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








2















When I was running the following code, which has blank lines (no space) inside functions, I got different behavior from Python 3.6.5 when running the code line by line in interpreter mode and python3 split.py:



# File split.py

def find(s, start, predictor):
for i in range(start, len(s)):
if predictor(s[i]):
return i
return -1

def find_all(s, sep=" tn"):
beg_of_nonsep = 0
while beg_of_nonsep < len(s):
beg_of_nonsep = find(s, beg_of_nonsep, lambda ch, sep_chs=sep: ch not in sep_chs)
if beg_of_nonsep == -1:
break

end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
if end_of_nonsep == -1:
end_of_nonsep = len(s)

yield (beg_of_nonsep, end_of_nonsep)

beg_of_nonsep = end_of_nonsep + 1

split = lambda s: [s[beg: end] for (beg, end) in find_all(s)]

print(split(""))
print(split(" tn"))
print(split(" tssssn"))


When running the code line by line in interpreter mode, python3 gave me nasty errors:



Type "help", "copyright", "credits" or "license" for more information.
>>> def find(s, start, predictor):
... for i in range(start, len(s)):
... if predictor(s[i]):
... return i
... return -1
...
>>> def find_all(s, sep=" tn"):
... beg_of_nonsep = 0
... while beg_of_nonsep < len(s):
... beg_of_nonsep = find(s, beg_of_nonsep, lambda ch, sep_chs=sep: ch not in sep_chs)
... if beg_of_nonsep == -1:
... break
...
>>> end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
File "<stdin>", line 1
end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
^
IndentationError: unexpected indent
>>> if end_of_nonsep == -1:
File "<stdin>", line 1
if end_of_nonsep == -1:
^
IndentationError: unexpected indent
>>> end_of_nonsep = len(s)
File "<stdin>", line 1
end_of_nonsep = len(s)
^
IndentationError: unexpected indent
>>>
>>> yield (beg_of_nonsep, end_of_nonsep)
File "<stdin>", line 1
yield (beg_of_nonsep, end_of_nonsep)
^
IndentationError: unexpected indent
>>>
>>> beg_of_nonsep = end_of_nonsep + 1
File "<stdin>", line 1
beg_of_nonsep = end_of_nonsep + 1
^
IndentationError: unexpected indent
>>>
>>> split = lambda s: [s[beg: end] for (beg, end) in find_all(s)]
>>>
>>> print(split(""))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in <lambda>
TypeError: 'NoneType' object is not iterable
>>> print(split(" tn"))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 1, in <lambda>
TypeError: 'NoneType' object is not iterable
>>> print(split(" tssssn"))





And the last print here never quit until I used ctrlc to stop it.



Thus, I thought there were many bugs with my code.



However, when I ran the code with python3 split.py, none of this happened:



[]
[]
['ssss']


This is rather confusing to me.



To be clear, I was actually using vimcmdline on Debian 9.8 with vim 8.1.



I am also using pylint through pymode, which split any trailing space, of which it considered superfluous.



This problem happened when I tried to use its builtin keybinding to send split.py to the python3 in the tmux split it opened.



I have already filled an issue, but I can't help wonder why python3 behaves like this.










share|improve this question






























    2















    When I was running the following code, which has blank lines (no space) inside functions, I got different behavior from Python 3.6.5 when running the code line by line in interpreter mode and python3 split.py:



    # File split.py

    def find(s, start, predictor):
    for i in range(start, len(s)):
    if predictor(s[i]):
    return i
    return -1

    def find_all(s, sep=" tn"):
    beg_of_nonsep = 0
    while beg_of_nonsep < len(s):
    beg_of_nonsep = find(s, beg_of_nonsep, lambda ch, sep_chs=sep: ch not in sep_chs)
    if beg_of_nonsep == -1:
    break

    end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
    if end_of_nonsep == -1:
    end_of_nonsep = len(s)

    yield (beg_of_nonsep, end_of_nonsep)

    beg_of_nonsep = end_of_nonsep + 1

    split = lambda s: [s[beg: end] for (beg, end) in find_all(s)]

    print(split(""))
    print(split(" tn"))
    print(split(" tssssn"))


    When running the code line by line in interpreter mode, python3 gave me nasty errors:



    Type "help", "copyright", "credits" or "license" for more information.
    >>> def find(s, start, predictor):
    ... for i in range(start, len(s)):
    ... if predictor(s[i]):
    ... return i
    ... return -1
    ...
    >>> def find_all(s, sep=" tn"):
    ... beg_of_nonsep = 0
    ... while beg_of_nonsep < len(s):
    ... beg_of_nonsep = find(s, beg_of_nonsep, lambda ch, sep_chs=sep: ch not in sep_chs)
    ... if beg_of_nonsep == -1:
    ... break
    ...
    >>> end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
    File "<stdin>", line 1
    end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
    ^
    IndentationError: unexpected indent
    >>> if end_of_nonsep == -1:
    File "<stdin>", line 1
    if end_of_nonsep == -1:
    ^
    IndentationError: unexpected indent
    >>> end_of_nonsep = len(s)
    File "<stdin>", line 1
    end_of_nonsep = len(s)
    ^
    IndentationError: unexpected indent
    >>>
    >>> yield (beg_of_nonsep, end_of_nonsep)
    File "<stdin>", line 1
    yield (beg_of_nonsep, end_of_nonsep)
    ^
    IndentationError: unexpected indent
    >>>
    >>> beg_of_nonsep = end_of_nonsep + 1
    File "<stdin>", line 1
    beg_of_nonsep = end_of_nonsep + 1
    ^
    IndentationError: unexpected indent
    >>>
    >>> split = lambda s: [s[beg: end] for (beg, end) in find_all(s)]
    >>>
    >>> print(split(""))
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "<stdin>", line 1, in <lambda>
    TypeError: 'NoneType' object is not iterable
    >>> print(split(" tn"))
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "<stdin>", line 1, in <lambda>
    TypeError: 'NoneType' object is not iterable
    >>> print(split(" tssssn"))





    And the last print here never quit until I used ctrlc to stop it.



    Thus, I thought there were many bugs with my code.



    However, when I ran the code with python3 split.py, none of this happened:



    []
    []
    ['ssss']


    This is rather confusing to me.



    To be clear, I was actually using vimcmdline on Debian 9.8 with vim 8.1.



    I am also using pylint through pymode, which split any trailing space, of which it considered superfluous.



    This problem happened when I tried to use its builtin keybinding to send split.py to the python3 in the tmux split it opened.



    I have already filled an issue, but I can't help wonder why python3 behaves like this.










    share|improve this question


























      2












      2








      2








      When I was running the following code, which has blank lines (no space) inside functions, I got different behavior from Python 3.6.5 when running the code line by line in interpreter mode and python3 split.py:



      # File split.py

      def find(s, start, predictor):
      for i in range(start, len(s)):
      if predictor(s[i]):
      return i
      return -1

      def find_all(s, sep=" tn"):
      beg_of_nonsep = 0
      while beg_of_nonsep < len(s):
      beg_of_nonsep = find(s, beg_of_nonsep, lambda ch, sep_chs=sep: ch not in sep_chs)
      if beg_of_nonsep == -1:
      break

      end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
      if end_of_nonsep == -1:
      end_of_nonsep = len(s)

      yield (beg_of_nonsep, end_of_nonsep)

      beg_of_nonsep = end_of_nonsep + 1

      split = lambda s: [s[beg: end] for (beg, end) in find_all(s)]

      print(split(""))
      print(split(" tn"))
      print(split(" tssssn"))


      When running the code line by line in interpreter mode, python3 gave me nasty errors:



      Type "help", "copyright", "credits" or "license" for more information.
      >>> def find(s, start, predictor):
      ... for i in range(start, len(s)):
      ... if predictor(s[i]):
      ... return i
      ... return -1
      ...
      >>> def find_all(s, sep=" tn"):
      ... beg_of_nonsep = 0
      ... while beg_of_nonsep < len(s):
      ... beg_of_nonsep = find(s, beg_of_nonsep, lambda ch, sep_chs=sep: ch not in sep_chs)
      ... if beg_of_nonsep == -1:
      ... break
      ...
      >>> end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
      File "<stdin>", line 1
      end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
      ^
      IndentationError: unexpected indent
      >>> if end_of_nonsep == -1:
      File "<stdin>", line 1
      if end_of_nonsep == -1:
      ^
      IndentationError: unexpected indent
      >>> end_of_nonsep = len(s)
      File "<stdin>", line 1
      end_of_nonsep = len(s)
      ^
      IndentationError: unexpected indent
      >>>
      >>> yield (beg_of_nonsep, end_of_nonsep)
      File "<stdin>", line 1
      yield (beg_of_nonsep, end_of_nonsep)
      ^
      IndentationError: unexpected indent
      >>>
      >>> beg_of_nonsep = end_of_nonsep + 1
      File "<stdin>", line 1
      beg_of_nonsep = end_of_nonsep + 1
      ^
      IndentationError: unexpected indent
      >>>
      >>> split = lambda s: [s[beg: end] for (beg, end) in find_all(s)]
      >>>
      >>> print(split(""))
      Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 1, in <lambda>
      TypeError: 'NoneType' object is not iterable
      >>> print(split(" tn"))
      Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 1, in <lambda>
      TypeError: 'NoneType' object is not iterable
      >>> print(split(" tssssn"))





      And the last print here never quit until I used ctrlc to stop it.



      Thus, I thought there were many bugs with my code.



      However, when I ran the code with python3 split.py, none of this happened:



      []
      []
      ['ssss']


      This is rather confusing to me.



      To be clear, I was actually using vimcmdline on Debian 9.8 with vim 8.1.



      I am also using pylint through pymode, which split any trailing space, of which it considered superfluous.



      This problem happened when I tried to use its builtin keybinding to send split.py to the python3 in the tmux split it opened.



      I have already filled an issue, but I can't help wonder why python3 behaves like this.










      share|improve this question
















      When I was running the following code, which has blank lines (no space) inside functions, I got different behavior from Python 3.6.5 when running the code line by line in interpreter mode and python3 split.py:



      # File split.py

      def find(s, start, predictor):
      for i in range(start, len(s)):
      if predictor(s[i]):
      return i
      return -1

      def find_all(s, sep=" tn"):
      beg_of_nonsep = 0
      while beg_of_nonsep < len(s):
      beg_of_nonsep = find(s, beg_of_nonsep, lambda ch, sep_chs=sep: ch not in sep_chs)
      if beg_of_nonsep == -1:
      break

      end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
      if end_of_nonsep == -1:
      end_of_nonsep = len(s)

      yield (beg_of_nonsep, end_of_nonsep)

      beg_of_nonsep = end_of_nonsep + 1

      split = lambda s: [s[beg: end] for (beg, end) in find_all(s)]

      print(split(""))
      print(split(" tn"))
      print(split(" tssssn"))


      When running the code line by line in interpreter mode, python3 gave me nasty errors:



      Type "help", "copyright", "credits" or "license" for more information.
      >>> def find(s, start, predictor):
      ... for i in range(start, len(s)):
      ... if predictor(s[i]):
      ... return i
      ... return -1
      ...
      >>> def find_all(s, sep=" tn"):
      ... beg_of_nonsep = 0
      ... while beg_of_nonsep < len(s):
      ... beg_of_nonsep = find(s, beg_of_nonsep, lambda ch, sep_chs=sep: ch not in sep_chs)
      ... if beg_of_nonsep == -1:
      ... break
      ...
      >>> end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
      File "<stdin>", line 1
      end_of_nonsep = find(s, beg_of_nonsep + 1, lambda ch, sep_chs=sep: ch in sep_chs)
      ^
      IndentationError: unexpected indent
      >>> if end_of_nonsep == -1:
      File "<stdin>", line 1
      if end_of_nonsep == -1:
      ^
      IndentationError: unexpected indent
      >>> end_of_nonsep = len(s)
      File "<stdin>", line 1
      end_of_nonsep = len(s)
      ^
      IndentationError: unexpected indent
      >>>
      >>> yield (beg_of_nonsep, end_of_nonsep)
      File "<stdin>", line 1
      yield (beg_of_nonsep, end_of_nonsep)
      ^
      IndentationError: unexpected indent
      >>>
      >>> beg_of_nonsep = end_of_nonsep + 1
      File "<stdin>", line 1
      beg_of_nonsep = end_of_nonsep + 1
      ^
      IndentationError: unexpected indent
      >>>
      >>> split = lambda s: [s[beg: end] for (beg, end) in find_all(s)]
      >>>
      >>> print(split(""))
      Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 1, in <lambda>
      TypeError: 'NoneType' object is not iterable
      >>> print(split(" tn"))
      Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<stdin>", line 1, in <lambda>
      TypeError: 'NoneType' object is not iterable
      >>> print(split(" tssssn"))





      And the last print here never quit until I used ctrlc to stop it.



      Thus, I thought there were many bugs with my code.



      However, when I ran the code with python3 split.py, none of this happened:



      []
      []
      ['ssss']


      This is rather confusing to me.



      To be clear, I was actually using vimcmdline on Debian 9.8 with vim 8.1.



      I am also using pylint through pymode, which split any trailing space, of which it considered superfluous.



      This problem happened when I tried to use its builtin keybinding to send split.py to the python3 in the tmux split it opened.



      I have already filled an issue, but I can't help wonder why python3 behaves like this.







      python interpreter






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 4 hours ago









      200_success

      3,96711629




      3,96711629










      asked 16 hours ago









      JiaHao XuJiaHao Xu

      1374




      1374




















          1 Answer
          1






          active

          oldest

          votes


















          17














          This behaviour doesn't look surprising to me.



          Python uses indentation to determine the beginning and end of a code block. Logically indentation ends on the first line that isn't indented. When running scripts blank lines are ignored. And when running scripts this means that indentation ends either with an un-indented line or the end of file.



          But this behaviour cannot work in a command line mode because there is no end of file. Consider the following script file:



          from somewhere import bar, do_something

          for foo in bar:
          do_something(foo)


          In a script, the end of the file indicates that it should now run the for loop. It knows there is no more to execute. But in command line mode, the command line is still open, you can still write more. It has no idea whether or not your next line of code is going to be inside or outside the for loop. But the command line cannot just sit and wait for your next line of code... you want it to execute ... now!



          Therefore the command line operates with one specific difference. A blank line will also end a code block. So this is fine:



          from somewhere import bar, do_something, do_something_else

          for foo in bar:
          do_something(foo)
          do_something_else(foo)


          But this is an error:



          from somewhere import bar, do_something, do_something_else

          for foo in bar:
          do_something(foo)

          do_something_else(foo)


          Because you have already ended the for loop with a blank line and cannot add to it.






          share|improve this answer























          • This is a good explanation. It’s worth noting that the interpreter could have been designed such that it always waits for an unindented line, which effectively means that when you want it to “execute…now!” you should type an unindented pass. Presumably all this extra passing was deemed more annoying than the incompatibility with the actual language.

            – wchargin
            1 hour ago











          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f512535%2findentationerror-when-pasting-code-in-python-3-interpreter-mode%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          17














          This behaviour doesn't look surprising to me.



          Python uses indentation to determine the beginning and end of a code block. Logically indentation ends on the first line that isn't indented. When running scripts blank lines are ignored. And when running scripts this means that indentation ends either with an un-indented line or the end of file.



          But this behaviour cannot work in a command line mode because there is no end of file. Consider the following script file:



          from somewhere import bar, do_something

          for foo in bar:
          do_something(foo)


          In a script, the end of the file indicates that it should now run the for loop. It knows there is no more to execute. But in command line mode, the command line is still open, you can still write more. It has no idea whether or not your next line of code is going to be inside or outside the for loop. But the command line cannot just sit and wait for your next line of code... you want it to execute ... now!



          Therefore the command line operates with one specific difference. A blank line will also end a code block. So this is fine:



          from somewhere import bar, do_something, do_something_else

          for foo in bar:
          do_something(foo)
          do_something_else(foo)


          But this is an error:



          from somewhere import bar, do_something, do_something_else

          for foo in bar:
          do_something(foo)

          do_something_else(foo)


          Because you have already ended the for loop with a blank line and cannot add to it.






          share|improve this answer























          • This is a good explanation. It’s worth noting that the interpreter could have been designed such that it always waits for an unindented line, which effectively means that when you want it to “execute…now!” you should type an unindented pass. Presumably all this extra passing was deemed more annoying than the incompatibility with the actual language.

            – wchargin
            1 hour ago















          17














          This behaviour doesn't look surprising to me.



          Python uses indentation to determine the beginning and end of a code block. Logically indentation ends on the first line that isn't indented. When running scripts blank lines are ignored. And when running scripts this means that indentation ends either with an un-indented line or the end of file.



          But this behaviour cannot work in a command line mode because there is no end of file. Consider the following script file:



          from somewhere import bar, do_something

          for foo in bar:
          do_something(foo)


          In a script, the end of the file indicates that it should now run the for loop. It knows there is no more to execute. But in command line mode, the command line is still open, you can still write more. It has no idea whether or not your next line of code is going to be inside or outside the for loop. But the command line cannot just sit and wait for your next line of code... you want it to execute ... now!



          Therefore the command line operates with one specific difference. A blank line will also end a code block. So this is fine:



          from somewhere import bar, do_something, do_something_else

          for foo in bar:
          do_something(foo)
          do_something_else(foo)


          But this is an error:



          from somewhere import bar, do_something, do_something_else

          for foo in bar:
          do_something(foo)

          do_something_else(foo)


          Because you have already ended the for loop with a blank line and cannot add to it.






          share|improve this answer























          • This is a good explanation. It’s worth noting that the interpreter could have been designed such that it always waits for an unindented line, which effectively means that when you want it to “execute…now!” you should type an unindented pass. Presumably all this extra passing was deemed more annoying than the incompatibility with the actual language.

            – wchargin
            1 hour ago













          17












          17








          17







          This behaviour doesn't look surprising to me.



          Python uses indentation to determine the beginning and end of a code block. Logically indentation ends on the first line that isn't indented. When running scripts blank lines are ignored. And when running scripts this means that indentation ends either with an un-indented line or the end of file.



          But this behaviour cannot work in a command line mode because there is no end of file. Consider the following script file:



          from somewhere import bar, do_something

          for foo in bar:
          do_something(foo)


          In a script, the end of the file indicates that it should now run the for loop. It knows there is no more to execute. But in command line mode, the command line is still open, you can still write more. It has no idea whether or not your next line of code is going to be inside or outside the for loop. But the command line cannot just sit and wait for your next line of code... you want it to execute ... now!



          Therefore the command line operates with one specific difference. A blank line will also end a code block. So this is fine:



          from somewhere import bar, do_something, do_something_else

          for foo in bar:
          do_something(foo)
          do_something_else(foo)


          But this is an error:



          from somewhere import bar, do_something, do_something_else

          for foo in bar:
          do_something(foo)

          do_something_else(foo)


          Because you have already ended the for loop with a blank line and cannot add to it.






          share|improve this answer













          This behaviour doesn't look surprising to me.



          Python uses indentation to determine the beginning and end of a code block. Logically indentation ends on the first line that isn't indented. When running scripts blank lines are ignored. And when running scripts this means that indentation ends either with an un-indented line or the end of file.



          But this behaviour cannot work in a command line mode because there is no end of file. Consider the following script file:



          from somewhere import bar, do_something

          for foo in bar:
          do_something(foo)


          In a script, the end of the file indicates that it should now run the for loop. It knows there is no more to execute. But in command line mode, the command line is still open, you can still write more. It has no idea whether or not your next line of code is going to be inside or outside the for loop. But the command line cannot just sit and wait for your next line of code... you want it to execute ... now!



          Therefore the command line operates with one specific difference. A blank line will also end a code block. So this is fine:



          from somewhere import bar, do_something, do_something_else

          for foo in bar:
          do_something(foo)
          do_something_else(foo)


          But this is an error:



          from somewhere import bar, do_something, do_something_else

          for foo in bar:
          do_something(foo)

          do_something_else(foo)


          Because you have already ended the for loop with a blank line and cannot add to it.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 15 hours ago









          Philip CoulingPhilip Couling

          2,7641224




          2,7641224












          • This is a good explanation. It’s worth noting that the interpreter could have been designed such that it always waits for an unindented line, which effectively means that when you want it to “execute…now!” you should type an unindented pass. Presumably all this extra passing was deemed more annoying than the incompatibility with the actual language.

            – wchargin
            1 hour ago

















          • This is a good explanation. It’s worth noting that the interpreter could have been designed such that it always waits for an unindented line, which effectively means that when you want it to “execute…now!” you should type an unindented pass. Presumably all this extra passing was deemed more annoying than the incompatibility with the actual language.

            – wchargin
            1 hour ago
















          This is a good explanation. It’s worth noting that the interpreter could have been designed such that it always waits for an unindented line, which effectively means that when you want it to “execute…now!” you should type an unindented pass. Presumably all this extra passing was deemed more annoying than the incompatibility with the actual language.

          – wchargin
          1 hour ago





          This is a good explanation. It’s worth noting that the interpreter could have been designed such that it always waits for an unindented line, which effectively means that when you want it to “execute…now!” you should type an unindented pass. Presumably all this extra passing was deemed more annoying than the incompatibility with the actual language.

          – wchargin
          1 hour ago

















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f512535%2findentationerror-when-pasting-code-in-python-3-interpreter-mode%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Möglingen Índice Localización Historia Demografía Referencias Enlaces externos Menú de navegación48°53′18″N 9°07′45″E / 48.888333333333, 9.129166666666748°53′18″N 9°07′45″E / 48.888333333333, 9.1291666666667Sitio web oficial Mapa de Möglingen«Gemeinden in Deutschland nach Fläche, Bevölkerung und Postleitzahl am 30.09.2016»Möglingen

          Virtualbox - Configuration error: Querying “UUID” failed (VERR_CFGM_VALUE_NOT_FOUND)“VERR_SUPLIB_WORLD_WRITABLE” error when trying to installing OS in virtualboxVirtual Box Kernel errorFailed to open a seesion for the virtual machineFailed to open a session for the virtual machineUbuntu 14.04 LTS Virtualbox errorcan't use VM VirtualBoxusing virtualboxI can't run Linux-64 Bit on VirtualBoxUnable to insert the virtual optical disk (VBoxguestaddition) in virtual machine for ubuntu server in win 10VirtuaBox in Ubuntu 18.04 Issues with Win10.ISO Installation

          Torre de la Isleta Índice Véase también Referencias Bibliografía Enlaces externos Menú de navegación38°25′58″N 0°23′02″O / 38.43277778, -0.3838888938°25′58″N 0°23′02″O / 38.43277778, -0.38388889Torre de la Illeta de l’Horta o Torre Saleta. Base de datos de bienes inmuebles. Patrimonio Cultural. Secretaría de Estado de CulturaFicha BIC Torre de la Illeta de l’Horta. Dirección General de Patrimonio Cultural. Generalitat ValencianaLugares de interés. Ayuntamiento del CampelloTorre de la Isleta en CastillosNet.org