def push_accepts_more(self):
<EOL>if not self._is_complete:<EOL><INDENT>return True<EOL><DEDENT>if self.indent_spaces==<NUM_LIT:0>:<EOL><INDENT>if self.input_mode=='<STR_LIT>':<EOL><INDENT>if not self._full_dedent:<EOL><INDENT>return False<EOL><DEDENT><DEDENT>else:<EOL><INDENT>try:<EOL><INDENT>code_ast = ast.parse(u'<STR_LIT>'.join(self._buffer))<EOL><DEDENT>except Exception:<EOL><INDENT>return False<EOL><DEDENT>else:<EOL><INDENT>if len(code_ast.body) == <NUM_LIT:1>:<EOL><INDENT>return False<EOL><DEDENT><DEDENT><DEDENT><DEDENT>last_line = self.source.splitlines()[-<NUM_LIT:1>]<EOL>return bool(last_line and not last_line.isspace())<EOL>
Return whether a block of interactive input can accept more input.

        This method is meant to be used by line-oriented frontends, who need to
        guess whether a block is complete or not based solely on prior and
        current input lines.  The InputSplitter considers it has a complete
        interactive block and will not accept more input only when either a
        SyntaxError is raised, or *all* of the following are true:

        1. The input compiles to a complete statement.

        2. The indentation level is flush-left (because if we are indented,
           like inside a function definition or for loop, we need to keep
           reading new input).

        3. There is one extra line consisting only of whitespace.

        Because of condition #3, this method should be used only by
        *line-oriented* frontends, since it means that intermediate blank lines
        are not allowed in function definitions (or any other indented block).

        If the current input produces a syntax error, this method immediately
        returns False but does *not* raise the syntax error exception, as
        typically clients will want to send invalid syntax to an execution
        backend which might convert the invalid syntax into valid Python via
        one of the dynamic IPython mechanisms.