This bug can be recreated by opening a file whose content is "input()" with IDLE, press F5 and the shell opens as expected. Without making the input in the shell stop, press F5 in the script again. In Python 3.5 IDLE only take input until another F5 (or Ctrl+F6) in the script. In Python 3.6 IDLE only take input until an Enter is pressed or another F5 (or Ctrl+F6) in the script.

I am not sure what you mean by 'this bug'.  I presume by 'take input' you mean 'display keystrokes on the input line'.  If so, the behavior you describe for 3.6 is the correct behavior and not a bug: accept kestrokes until 'Enter' is pressed or until the process awaiting input is killed.  F5 kills the current user code execution process, as opposed to the IDLE GUI interaction process, and starts a new one.  That is what 'Restart' means.

Experimenting with IDLE on 3.5 and 3.6 on Windows 10, I experienced the (correct) behavior described above.  It does not make any difference whether there was any unsent input before hitting F5 or not.  I did not notice any difference between the two versions.  In both, hitting 'Enter' terminates input.

Unless you can provide more details that convince me otherwise, I will close this as 'not a bug'.

What I meant was:
1. Open a file whose content is "input()" with IDLE
2. F5
3. Type something but without pressing Enter.
4. Come back to the script (with input() still responding to keystrokes on the input line)
5. F5
6. Bug. (Results vary even on the same machine by closing and opening Python again, sometimes whatever you pressed in step 3 disappears, sometimes it just takes input, doesn't respond to commands similar (not equal) to "while(1): pass")

*doesn't respond to commands. I mean something similar to (not equal) "while(1): pass")

What OS are you using?

> 6. Bug.

This does not tell me what you think the bug is.

> sometimes whatever you pressed in step 3 disappears,

When Shell is restarted by whatever means, any pending input, whether in response to '>>>' or user input(), is cancelled and *should* disappear and not be left to look as if it were processed.  It consistently does for me.

> doesn't respond to commands

When a user-coded input() is active, anything typed *should* be treated as text and not interpreted as a command.

I am using Windows 10 64-bit.

>> sometimes whatever you pressed in step 3 disappears,
>
> When Shell is restarted by whatever means, any pending input, whether in response to '>>>' or user input(), is cancelled and
> *should* disappear and not be left to look as if it were processed.  It  consistently does for me.
It doesn't for me.

> > doesn't respond to commands
> 
> When a user-coded input() is active, anything typed *should* be treated as text and not interpreted as a command.
Even before enters?

At the comments of http://inventwithpython.com/blog/2011/11/29/the-things-i-hate-about-idle-that-i-wish-someone-would-fix/ I found someone having the same problem as me, MrValdez ()

This is a relevant part of his comment:
> ANNOYANCE: input() doesn't play well when re-running a script when the script is already running.
> 
> Here's a use case. A student types this program in IDLE:
>
> --
>
> x = input("Typ a word:")
> print (x)
>
> --
>
> They run the code. In the shell window, the student would notice the mispelling. Without exiting the shell window,
> they would go edit the code and then press F5.
>
> The shell would still be running the previous code instead of restarting.
>
> In some of my exercises, the students would sometimes think their code are broken when in reality, they already 
> got the solution. They were just running the older instance.
>
> This becomes common enough that I ask my students to exit the shell window before running their scripts.

Characters typed before Enter are never sent the the execution process, so there are not even interpreted as a string, let alone a command.

Do you see exactly the following when you start IDLE?

Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32

If so, there must either be something different about your system, or you are doing something other than what I understand you to have done.

The 5 1/2-year-old report in not completely clear to me.  The behavior reported could have been affected by subsequent patches.

The only restart glitch I have noticed is that previous output very occasionally show up after the >>> prompt.

In any case, I cannot (intentionally) fix what I cannot see.

The implementation of standard input/output in IDLE was significantly changed in recent years.