[Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs

SourceForge.net noreply@sourceforge.net
Sat, 04 Jan 2003 06:05:58 -0800


Bugs item #661357, was opened at 2003-01-02 17:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470

Category: Tkinter
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Martin v. Löwis (loewis)
Summary: tkFileDialog.SaveAs

Initial Comment:
The SaveAs dialog gets a traceback due to the new
object-style Tk interface.  Run this test program:

from Tkinter import *
import tkFileDialog

def doit():
    savedialog = tkFileDialog.SaveAs(master=root)
    print savedialog.show(initialdir="/tmp",
initialfile="foo.py")

root = Tk()
button = Button(root, text="Save...", command=doit)
button.pack()
mainloop()

I get this traceback:

Traceback (most recent call last):
  File "/usr/local/lib/python2.3/lib-tk/Tkinter.py",
line 1306, in __call__
    return apply(self.func, args)
  File "tkf.py", line 5, in doit
    print savedialog.show(initialdir="/tmp",
initialfile="foo.py")
  File
"/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py",
line 54, in show
    s = self._fixresult(w, s)
  File
"/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line
58, in _fixresult
    path, file = os.path.split(result)
  File "/usr/local/lib/python2.3/posixpath.py", line
65, in split
    i = p.rfind('/') + 1
AttributeError: '_tkinter.Tcl_Obj' object has no
attribute 'rfind'


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-04 09:05

Message:
Logged In: YES 
user_id=6380

But that's not a new problem, is it? tkFileDialog has always
worked that way. So I don't think it's a problem in practice.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-04 03:33

Message:
Logged In: YES 
user_id=21627

On NT+, it is not a problem: tkFileDialog will return
Unicode objects, which you can then pass to open(). The
problem exists on Unix: If you have a file name with
non-ASCII characters, tkFileDialog will still return a
Unicode object, but you can't pass that to open, unless the
file system default encoding was changed.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-03 19:55

Message:
Logged In: YES 
user_id=6380

I guess that's only an issue on Windows NT descendants?

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 19:16

Message:
Logged In: YES 
user_id=21627

This is fixed with

_tkinter.c 1.142
tkFileDialog.py 1.9

To provide full backwards compatibility, neither str() nor
unicode() are appropriate, as Tkinter traditionally returns
byte strings for ASCII and Unicode strings otherwise. To
support that behaviour, I added a .string attribute to
Tcl_Objs, which is polymorphically either one or the other
string type.

For the other builtin Tcl types, this should not be an
issue, as they will always have ASCII string representations.

One potential advantage of path objects is that they keep
internally both the Unicode representation and the "native"
byte string representation. Python now only accesses the
Unicode representation, which could cause problems as you
might not be able to open the file afterwards (unless the
Python file system encoding matches the Tcl file system
encoding).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-03 17:14

Message:
Logged In: YES 
user_id=6380

In order of preference, I like 3 the best, 1 fine, and 2 not
at all.

I don't know what properties Tcl path objects have that
would be beneficial to Python, but I expect that they will
relatively rarely be bounced right back to Tcl.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 13:54

Message:
Logged In: YES 
user_id=21627

I see - it appears that the dialogs behave differently on
Windows and X in this respect...

I can see two alternative strategies:

1. Fix this specific problem, by converting the result of
the dialog in _fixresult to string.

2. Enhance the Tk wrapper type, to support all string
operations, by lazily converting itself to a string if a
string method is requested. Then, .rfind would work on the
path object.

There is, in principle, a third alternative:
3. Convert path objects to Python strings, as Python does
not have a separate path type. However, this somewhat
defeats one purpose of using Tcl objects: If the path is
passed back to Tcl, Tcl won't need to reparse it if it is
still a path.

Which of these would you recommend?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-01-03 10:24

Message:
Logged In: YES 
user_id=6380

Python 2.3a1 (a tad post-release)
Tcl/Tk 8.4
Mandrake Linux 8.1 I believe
Linux kernel 2.2.17-21mdk

The output from that snippet is
<path object at 0x082b3c98> /tmp/foo.py path



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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 06:28

Message:
Logged In: YES 
user_id=21627

Also, can you please try

x=root.tk.call(("tk_getSaveFile","-initialdir","/tmp","-initialfile","foo.py"))
print repr(x),str(x),x.typename

I always get plain strings as a result of that call.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-01-03 05:56

Message:
Logged In: YES 
user_id=21627

I can't reproduce this. What system and Tcl version?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470