I have a source code which IDLE 3.0a5 cannot parse, but Python 3.0a5 
can (also attached): 

#!/usr/bin/python
# -*- coding: utf-8 -*-

def načtiSlovník(zdroj='slovník.txt'):
    soubor = open(zdroj, mode='r', encoding='utf_8')
    řádky = soubor.readlines()
    for řádek in řádky:
        print(řádek, end='')

načtiSlovník()
# End of source code


I have set up Default Source Encoding to UTF-8 in IDLE's general 
configuration. Still, when I open that source code and try to run it, 
IDLE complains about "invalid character in identifier" and highlights 
"zdroj" red in the first line (sic!). 

However, when I run the source code from command line (by "python 
<filename>"), it gets executed well and does what it shall do. 

I should probably add, that I have installed py3k:62932M, May 9 2008, 
16:23:11 [MSC v.1500 32 bit (Intel)] on win32. I use Windows XP SP 3. 
IDLE uses Tk version 8.4

3.0b2, WinXP
I cut and pasted the text above into an empty IDLE edit window, hit F5,
and in the blink of an eye, both IDLE windows disappeared.  No error
message, no Window's error box, just gone.

The pasted text was saved to the file.  When I added input() statements,
and ran with CPython directly, it got to the function call and then
crashed.  Rerunning with Idle with input() at the top, it still crashed,
indicating that it crashed during compilation and never started execution.

I was NOT able to Reproduce it in IDLE 3.0b2 running on Linux. Would you
like to try with 3.0b2 and also do.

tjreedy: I did not properly get your comment. When you open Idle
instance and create a new Document, cut-paste the code, and Run. The
Execution happens in the IDLE instance which was running. No need of
input() call.

When one runs a file with Python30.exe, it opens a window, runs the
file, and closes the window too fast to see what happened.  The point of
the input() statements is to 'pause' execution.  This is standard
debugging along with print()/write() statements.  With three input()s, I
determined that CPython compiled the file, executed the def statement,
and failed the function call (due, I presume, to the requested disk file
not being present).  IDLE, on the other hand, crashed before getting to
the first input() before the function def.  So it crashed while
compiling the file -- or as a result of trying to execute input().

I just tried cut and paste into the IDLE shell window (without the
encoding cookie) and it runs as expected, giving
IOError: [Errno 2] No such file or directory: 'slovník.txt'
Retrying with the cookie gives the same.  I have no idea if it is
recognized in interactive mode or if interactive mode is utf8 by default.

I just tried running from a file without the coding line and IDLE
crashed again.  So the problem is reading from a file on Windows.

IDLE is doing *something* different than bare CPython.  Actually, it
uses pythonw30.exe rather that python.exe, but when I replace the input
statements with file write statements (input raises error with pythonw),
pythonw also executed through to the def statement. But I still suspect
something in the interaction between IDLE and pythonw.  There was a
another problem with IDLE and pythonw in .a5
http://bugs.python.org/issue2841 
which seems to have disappeared without being officially fixed.

I managed to get a proper traceback:

Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\afa\python\py3k\lib\tkinter\__init__.py", line 1405, in __call__
    return self.func(*args)
  File "c:\afa\python\py3k\lib\idlelib\MultiCall.py", line 165, in handler
    r = l[i](event)
  File "c:\afa\python\py3k\lib\idlelib\ScriptBinding.py", line 124, in
run_module_event
    code = self.checksyntax(filename)
  File "c:\afa\python\py3k\lib\idlelib\ScriptBinding.py", line 86, in
checksyntax
    source = f.read()
  File "C:\afa\python\py3k\lib\io.py", line 1692, in read
    decoder.decode(self.buffer.read(), final=True))
  File "C:\afa\python\py3k\lib\io.py", line 1267, in decode
    output = self.decoder.decode(input, final=final)
  File "C:\afa\python\py3k\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x8d in position
34: character maps to <undefined>

This is because the file is opened in text mode, using the default
encoding (cp1252). It should instead open it in binary mode, and look
for a -*-coding-*- directive.
There is an attempt for this in linecache.py, but the logic there is wrong.

Is there already a function to properly open a python source file?
tokenize.detect_encoding could be used, but is there a way to open a
file in binary & universal mode?

the following very simple example might be the the same issue:

x="ěščřžýáíé"
print (x)

It reliably puts down IDLE entirely without any error message. It is
saved in UTF-8. 
python +idle 3.0, wxp sp3

This is now fixed in r68022.

Thank you. Not sure, what to do now, cause the putting down of IDLE is
fixed, but still within IDLE I get wrong output:

x="ěščřžýáíé"
print (x)

>>> 
ěščřžýáíé

when running this script under python command line form another editor,
I get the output readable as expected. Shall I open another issue?

Moreover: do you think its good idea to change the file encoding at
opened and then saved file without any question when there is no
encoding declaration? :-( Users do not edit just python programs, they
can edit also config files, text files, etc ....

It could be that at first saving we are asked to use 
*utf8 
*used one.

Well, if you're still using 3.0, it's not patched yet. :)

> Thank you. Not sure, what to do now, cause the putting down of IDLE is
> fixed, but still within IDLE I get wrong output:

In general, when a reported issue is closed, and you have a further
issue, the right thing is to report this as a new issue, rather than
following up on closed one.

In the specific case, I believe you are referring to issue 4008, and
its duplicates #4410, and #4623. There might be more duplicate reports,
so no need to report yet another one.

> Moreover: do you think its good idea to change the file encoding at
> opened and then saved file without any question when there is no
> encoding declaration?

See my previous comment: one issue at a time. This issue was about
code that IDLE 3.0a5 cannot parse, but IDLE 3.0 can. If you have
a further issue with the proposed solution, please report it separately.

> Users do not edit just python programs, they
> can edit also config files, text files, etc ....

I don't think IDLE was designed to support editing any other files.
I would be opposed to adding user interface relevant only for editing
non-Python text files. If IDLE would assume a different encoding at save
time than was assumed at load time, this might be still considered
a bug; you would need to provide detailed instructions to reproduce
such a bug.