IndentationError when pasting code in Python 3 interpreter modeHow do I protect Python code?python open built-in function: difference between modes a, a+, w, w+, and r+?Find full path of the Python interpreter?If Python is interpreted, what are .pyc files?Why does Python code run faster in a function?Python Class method definition : “unexpected indent”OpenCv pytesseract for OCRtkinter button to run command and destroy popup windowTypeError: unsupported operand type(s) for %: 'NoneType' and 'float'removed spaces and tabs in python code but still error coming

What is a "major country" as named in Bernie Sanders' Healthcare debate answers?

Is the Dodge action perceptible to other characters?

How to draw a Venn diagram for X - (Y intersect Z)?

Is there any reason to concentrate on the Thunderous Smite spell after using its effects?

A command to output each line forward then backwards

Is there a tool to measure the "maturity" of a code in Git?

Other than good shoes and a stick, what are some ways to preserve your knees on long hikes?

What is the source of "You can achieve a lot with hate, but even more with love" (Shakespeare?)

Teleport everything in a large zone; or teleport all living things and make a lot of equipment disappear

How to publish superseding results without creating enemies

Why are some files not movable on Windows 10?

Can an infinite series be thought of as adding up "infinitely many" terms?

How would you control supersoldiers in a late iron-age society?

Can I travel to European countries with the Irish passport and without destination Visa?

How do certain apps show new notifications when internet access is restricted to them?

Pronunciation of "солнце"

Can a character with good/neutral alignment attune to a sentient magic item with evil alignment?

Why is belonging not transitive?

What would happen if Protagoras v Euathlus were heard in court today?

What is this gigantic dish at Ben Gurion airport?

Ethernet, Wifi and a little human psychology

Seven Places at Once - Another Google Earth Challenge?

How to be sure services and researches offered by the University are not becoming cases of unfair competition?

Are there any “Third Order” acronyms used in space exploration?



IndentationError when pasting code in Python 3 interpreter mode


How do I protect Python code?python open built-in function: difference between modes a, a+, w, w+, and r+?Find full path of the Python interpreter?If Python is interpreted, what are .pyc files?Why does Python code run faster in a function?Python Class method definition : “unexpected indent”OpenCv pytesseract for OCRtkinter button to run command and destroy popup windowTypeError: unsupported operand type(s) for %: 'NoneType' and 'float'removed spaces and tabs in python code but still error coming






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








3















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
















migrated from unix.stackexchange.com Apr 22 at 9:42


This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.

























    3















    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
















    migrated from unix.stackexchange.com Apr 22 at 9:42


    This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.





















      3












      3








      3








      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Apr 22 at 9:56









      sepp2k

      311k41 gold badges611 silver badges630 bronze badges




      311k41 gold badges611 silver badges630 bronze badges










      asked Apr 15 at 9:23









      JiaHao XuJiaHao Xu

      7564 silver badges16 bronze badges




      7564 silver badges16 bronze badges





      migrated from unix.stackexchange.com Apr 22 at 9:42


      This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.











      migrated from unix.stackexchange.com Apr 22 at 9:42


      This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.









      migrated from unix.stackexchange.com Apr 22 at 9:42


      This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.
























          1 Answer
          1






          active

          oldest

          votes


















          19
















          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




















          • 4





            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
            Apr 16 at 0:19










          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          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: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          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/4.0/"u003ecc by-sa 4.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%2fstackoverflow.com%2fquestions%2f55792377%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









          19
















          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




















          • 4





            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
            Apr 16 at 0:19















          19
















          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




















          • 4





            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
            Apr 16 at 0:19













          19














          19










          19









          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 Apr 15 at 9:53









          Philip CoulingPhilip Couling

          8,0463 gold badges28 silver badges57 bronze badges




          8,0463 gold badges28 silver badges57 bronze badges










          • 4





            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
            Apr 16 at 0:19












          • 4





            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
            Apr 16 at 0:19







          4




          4





          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
          Apr 16 at 0:19





          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
          Apr 16 at 0:19








          Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.







          Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.




















          draft saved

          draft discarded















































          Thanks for contributing an answer to Stack Overflow!


          • 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%2fstackoverflow.com%2fquestions%2f55792377%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

          Tamil (spriik) Luke uk diar | Nawigatjuun

          Align equal signs while including text over equalitiesAMS align: left aligned text/math plus multicolumn alignmentMultiple alignmentsAligning equations in multiple placesNumbering and aligning an equation with multiple columnsHow to align one equation with another multline equationUsing \ in environments inside the begintabularxNumber equations and preserving alignment of equal signsHow can I align equations to the left and to the right?Double equation alignment problem within align enviromentAligned within align: Why are they right-aligned?

          Where does the image of a data connector as a sharp metal spike originate from?Where does the concept of infected people turning into zombies only after death originate from?Where does the motif of a reanimated human head originate?Where did the notion that Dragons could speak originate?Where does the archetypal image of the 'Grey' alien come from?Where did the suffix '-Man' originate?Where does the notion of being injured or killed by an illusion originate?Where did the term “sophont” originate?Where does the trope of magic spells being driven by advanced technology originate from?Where did the term “the living impaired” originate?