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

IndentationError when pasting code in Python 3 interpreter mode

Is there a way in Ruby to make just any one out of many keyword arguments required?

Why did the IBM 650 use bi-quinary?

Is there a service that would inform me whenever a new direct route is scheduled from a given airport?

Right-skewed distribution with mean equals to mode?

Antler Helmet: Can it work?

Why was the term "discrete" used in discrete logarithm?

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

List *all* the tuples!

Disable hyphenation for an entire paragraph

When to stop saving and start investing?

How to assign captions for two tables in LaTeX?

What does the "x" in "x86" represent?

Is there a Spanish version of "dot your i's and cross your t's" that includes the letter 'ñ'?

How to bypass password on Windows XP account?

Did Xerox really develop the first LAN?

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

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

Withdrew £2800, but only £2000 shows as withdrawn on online banking; what are my obligations?

Is it true to say that an hosting provider's DNS server is what links the entire hosting environment to ICANN?

Is 1 ppb equal to 1 μg/kg?

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

Bonus calculation: Am I making a mountain out of a molehill?

Output the ŋarâþ crîþ alphabet song without using (m)any letters



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 3 hours ago









      200_success

      3,96711629




      3,96711629










      asked 14 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
            2 mins 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
            2 mins 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
            2 mins 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 14 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
            2 mins 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
            2 mins 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
          2 mins 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
          2 mins 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

          Францішак Багушэвіч Змест Сям'я | Біяграфія | Творчасць | Мова Багушэвіча | Ацэнкі дзейнасці | Цікавыя факты | Спадчына | Выбраная бібліяграфія | Ушанаванне памяці | У філатэліі | Зноскі | Літаратура | Спасылкі | НавігацыяЛяхоўскі У. Рупіўся дзеля Бога і людзей: Жыццёвы шлях Лявона Вітан-Дубейкаўскага // Вольскі і Памідораў з песняй пра немца Адвакат, паэт, народны заступнік Ашмянскі веснікВ Минске появится площадь Богушевича и улица Сырокомли, Белорусская деловая газета, 19 июля 2001 г.Айцец беларускай нацыянальнай ідэі паўстаў у бронзе Сяргей Аляксандравіч Адашкевіч (1918, Мінск). 80-я гады. Бюст «Францішак Багушэвіч».Яўген Мікалаевіч Ціхановіч. «Партрэт Францішка Багушэвіча»Мікола Мікалаевіч Купава. «Партрэт зачынальніка новай беларускай літаратуры Францішка Багушэвіча»Уладзімір Іванавіч Мелехаў. На помніку «Змагарам за родную мову» Барэльеф «Францішак Багушэвіч»Памяць пра Багушэвіча на Віленшчыне Страчаная сталіца. Беларускія шыльды на вуліцах Вільні«Krynica». Ideologia i przywódcy białoruskiego katolicyzmuФранцішак БагушэвічТворы на knihi.comТворы Францішка Багушэвіча на bellib.byСодаль Уладзімір. Францішак Багушэвіч на Лідчыне;Луцкевіч Антон. Жыцьцё і творчасьць Фр. Багушэвіча ў успамінах ягоных сучасьнікаў // Запісы Беларускага Навуковага таварыства. Вільня, 1938. Сшытак 1. С. 16-34.Большая российская1188761710000 0000 5537 633Xn9209310021619551927869394п

          Беларусь Змест Назва Гісторыя Геаграфія Сімволіка Дзяржаўны лад Палітычныя партыі Міжнароднае становішча і знешняя палітыка Адміністрацыйны падзел Насельніцтва Эканоміка Культура і грамадства Сацыяльная сфера Узброеныя сілы Заўвагі Літаратура Спасылкі НавігацыяHGЯOiТоп-2011 г. (па версіі ej.by)Топ-2013 г. (па версіі ej.by)Топ-2016 г. (па версіі ej.by)Топ-2017 г. (па версіі ej.by)Нацыянальны статыстычны камітэт Рэспублікі БеларусьШчыльнасць насельніцтва па краінахhttp://naviny.by/rubrics/society/2011/09/16/ic_articles_116_175144/А. Калечыц, У. Ксяндзоў. Спробы засялення краю неандэртальскім чалавекам.І ў Менску былі мамантыА. Калечыц, У. Ксяндзоў. Старажытны каменны век (палеаліт). Першапачатковае засяленне тэрыторыіГ. Штыхаў. Балты і славяне ў VI—VIII стст.М. Клімаў. Полацкае княства ў IX—XI стст.Г. Штыхаў, В. Ляўко. Палітычная гісторыя Полацкай зямліГ. Штыхаў. Дзяржаўны лад у землях-княствахГ. Штыхаў. Дзяржаўны лад у землях-княствахБеларускія землі ў складзе Вялікага Княства ЛітоўскагаЛюблінская унія 1569 г."The Early Stages of Independence"Zapomniane prawdy25 гадоў таму было аб'яўлена, што Язэп Пілсудскі — беларус (фота)Наша вадаДакументы ЧАЭС: Забруджванне тэрыторыі Беларусі « ЧАЭС Зона адчужэнняСведения о политических партиях, зарегистрированных в Республике Беларусь // Министерство юстиции Республики БеларусьСтатыстычны бюлетэнь „Полаўзроставая структура насельніцтва Рэспублікі Беларусь на 1 студзеня 2012 года і сярэднегадовая колькасць насельніцтва за 2011 год“Индекс человеческого развития Беларуси — не было бы нижеБеларусь занимает первое место в СНГ по индексу развития с учетом гендерного факцёраНацыянальны статыстычны камітэт Рэспублікі БеларусьКанстытуцыя РБ. Артыкул 17Трансфармацыйныя задачы БеларусіВыйсце з крызісу — далейшае рэфармаванне Беларускі рубель — сусветны лідар па дэвальвацыяхПра змену коштаў у кастрычніку 2011 г.Бядней за беларусаў у СНД толькі таджыкіСярэдні заробак у верасні дасягнуў 2,26 мільёна рублёўЭканомікаГаласуем за ТОП-100 беларускай прозыСучасныя беларускія мастакіАрхитектура Беларуси BELARUS.BYА. Каханоўскі. Культура Беларусі ўсярэдзіне XVII—XVIII ст.Анталогія беларускай народнай песні, гуказапісы спеваўБеларускія Музычныя IнструментыБеларускі рок, які мы страцілі. Топ-10 гуртоў«Мясцовы час» — нязгаслая легенда беларускай рок-музыкіСЯРГЕЙ БУДКІН. МЫ НЯ ЗНАЕМ СВАЁЙ МУЗЫКІМ. А. Каладзінскі. НАРОДНЫ ТЭАТРМагнацкія культурныя цэнтрыПублічная дыскусія «Беларуская новая пьеса: без беларускай мовы ці беларуская?»Беларускія драматургі па-ранейшаму лепш ставяцца за мяжой, чым на радзіме«Працэс незалежнага кіно пайшоў, і дзяржаву турбуе яго непадкантрольнасць»Беларускія філосафы ў пошуках прасторыВсе идём в библиотекуАрхіваванаАб Нацыянальнай праграме даследавання і выкарыстання касмічнай прасторы ў мірных мэтах на 2008—2012 гадыУ космас — разам.У суседнім з Барысаўскім раёне пабудуюць Камандна-вымяральны пунктСвяты і абрады беларусаў«Мірныя бульбашы з малой краіны» — 5 непраўдзівых стэрэатыпаў пра БеларусьМ. Раманюк. Беларускае народнае адзеннеУ Беларусі скарачаецца колькасць злачынстваўЛукашэнка незадаволены мінскімі ўладамі Крадзяжы складаюць у Мінску каля 70% злачынстваў Узровень злачыннасці ў Мінскай вобласці — адзін з самых высокіх у краіне Генпракуратура аналізуе стан са злачыннасцю ў Беларусі па каэфіцыенце злачыннасці У Беларусі стабілізавалася крымінагеннае становішча, лічыць генпракурорЗамежнікі сталі здзяйсняць у Беларусі больш злачынстваўМУС Беларусі турбуе рост рэцыдыўнай злачыннасціЯ з ЖЭСа. Дазволіце вас абкрасці! Рэйтынг усіх службаў і падраздзяленняў ГУУС Мінгарвыканкама вырасАб КДБ РБГісторыя Аператыўна-аналітычнага цэнтра РБГісторыя ДКФРТаможняagentura.ruБеларусьBelarus.by — Афіцыйны сайт Рэспублікі БеларусьСайт урада БеларусіRadzima.org — Збор архітэктурных помнікаў, гісторыя Беларусі«Глобус Беларуси»Гербы и флаги БеларусиАсаблівасці каменнага веку на БеларусіА. Калечыц, У. Ксяндзоў. Старажытны каменны век (палеаліт). Першапачатковае засяленне тэрыторыіУ. Ксяндзоў. Сярэдні каменны век (мезаліт). Засяленне краю плямёнамі паляўнічых, рыбакоў і збіральнікаўА. Калечыц, М. Чарняўскі. Плямёны на тэрыторыі Беларусі ў новым каменным веку (неаліце)А. Калечыц, У. Ксяндзоў, М. Чарняўскі. Гаспадарчыя заняткі ў каменным векуЭ. Зайкоўскі. Духоўная культура ў каменным векуАсаблівасці бронзавага веку на БеларусіФарміраванне супольнасцей ранняга перыяду бронзавага векуФотографии БеларусиРоля беларускіх зямель ва ўтварэнні і ўмацаванні ВКЛВ. Фадзеева. З гісторыі развіцця беларускай народнай вышыўкіDMOZGran catalanaБольшая российскаяBritannica (анлайн)Швейцарскі гістарычны15325917611952699xDA123282154079143-90000 0001 2171 2080n9112870100577502ge128882171858027501086026362074122714179пппппп

          ValueError: Expected n_neighbors <= n_samples, but n_samples = 1, n_neighbors = 6 (SMOTE) The 2019 Stack Overflow Developer Survey Results Are InCan SMOTE be applied over sequence of words (sentences)?ValueError when doing validation with random forestsSMOTE and multi class oversamplingLogic behind SMOTE-NC?ValueError: Error when checking target: expected dense_1 to have shape (7,) but got array with shape (1,)SmoteBoost: Should SMOTE be ran individually for each iteration/tree in the boosting?solving multi-class imbalance classification using smote and OSSUsing SMOTE for Synthetic Data generation to improve performance on unbalanced dataproblem of entry format for a simple model in KerasSVM SMOTE fit_resample() function runs forever with no result