[Patches] [ python-Patches-539392 ] Unicode fix for test in tkFileDialog.py

[noreply@sourceforge.net]

Patches item #539392, was opened at 2002-04-04 20:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=539392&group_id=5470

Category: Tkinter
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Bernhard Reiter (ber)
Assigned to: Martin v. Löwis (loewis)
Summary: Unicode fix for test in tkFileDialog.py

Initial Comment:
Patch is against current CVS form 20020404.
It also gives pointers to the problem described
in
http://mail.python.org/pipermail/python-list/2001-June/048787.html



Python's open() uses the Py_FileSystemDefaultEncoding.
Py_FileSystemDefaultEncoding is NULL (bltinmodule.c)
for most systems.
Setlocate will set it.  Thus we fixed the example and
set the locale to
the user defaults. Now "enc" will have a useful
encoding thus the
example will work with a non ascii characters in the
filename,
e.g. with umlauts in it.  It bombed on them before.

        Traceback (most recent call last):
  File "tkFileDialog.py", line 105, in ?
    print "open", askopenfilename(filetypes=[("all
filez", "*")])
  UnicodeError: ASCII encoding error: ordinal not in
range(128)

open() will work with the string directly now.
encode(enc) is only needed for terminal output,
thus we enchanced the example to show the two uses of
the returned filename
string separatly.

(It might be interesting to drop a note about this in
the right part of the user documentation.)

If you comment out the setlocale() you can see that
open fails,
which illustrates what seems to be a design flaw in tk.
Tk should be able to give you a string in exactly
the encoding in which the filesystem gave it to tk.


4.4.2002
Bernhard <bernhard@intevation.de>
Bernhard <bh@intevation.de>


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-08 17:00

Message:
Logged In: YES 
user_id=21627

Sorry, I misinterpreted your patch first.

I agree with your distinction of a file system encoding, and
a terminal encoding; I still hope to enhance Python to
expose an estimate of both - then leaving it to the
application to make use of either as appropriate (the file
system encoding would be used implicitly as is done today).

As for the flaw in Tk: it turns out that Tcl has a different
notion of the default encoding than Python - Tcl always uses
a locale-aware default encoding, whereas Python has a
system-wide fixed default encoding (usually ASCII). 

It is a good thing that Tkinter manages to represent file
names correctly (i.e. as Unicode strings) in most cases - if
you want to get the file name in the encoding in which the
file system gave it to you, you need to establish the value
of Tcl's "encoding system" command.

Committed as tkFileDialog.py 1.7.

----------------------------------------------------------------------

Comment By: Bernhard Reiter (ber)
Date: 2002-04-07 20:20

Message:
Logged In: YES 
user_id=113859

I agree with your analysis that the appplication has
to set the locale, if it wants to support non-ASCII filenames.

This is why we fixed the _test_ code to demonstrate exactly
this. The code of the modules itself is untouched.
If you do not fix the _test_ code it will bomb on non-ascii
file names.

Our code also demonstrates that there might be a difference
in the file system encoding (suitable for open) and the
terminal encoding (suitable for printing).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-04-04 22:16

Message:
Logged In: YES 
user_id=21627

I think this patch is not acceptable. If the application
wants to support non-ASCII file names, it must invoke
setlocale(); it is not the library's responsibility to make
this decision behind the application's back.

People question the validity of using CODESET in the file
system, so each developer needs to make a concious decision.
BTW, how does Tcl come up with the names in the first place?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=539392&group_id=5470