from tkFileDialog import askopenfilenames

a = askopenfilenames()
print a
print type(a)

'''
--output--
J:/PortablePython_1.1_py2.6.1/Aatest26/tk_new/rgb2hex.py
J:/PortablePython_1.1_py2.6.1/Aatest26/tk_new/bluebtn.jpg
J:/PortablePython_1.1_py2.6.1/Aatest26/tk_new/redbtn.jpg
<type 'unicode'>
'''

---- behaviour seen on windows xp 2.6.1 python release.  Linux
distributions seem fine.
---- parsing above string (as it's not a tuple anymore) is difficult as
it is a list of filenames separated by a space but spaces can be in the
middle of filenames.

With 2.6.2 on Windows, I get filenames surrounded by {}, all in a 
single unicode string.
The change may be related to the new Tk library used, not directly the 
tkFileDialog module.

(BTW, I don't see *any* unit tests for tkinter :( )

> With 2.6.2 on Windows, I get filenames surrounded by {}, all in a
> single unicode string.

This string surrounded by { } indicates it is supposed to be a tcl
list, which didn't get converted but should be done by tkFileDialog.

> The change may be related to the new Tk library used, not directly the
> tkFileDialog module.
>

It could be, or not. A simple solution would be to call the splitlist
function from _tkinter on that string, which tkFileDialog should be
doing indifferently of expecting objects from _tkinter or not.

> (BTW, I don't see *any* unit tests for tkinter :( )
>

There are some one a separated branch for now, but it doesn't include
tkFileDialog yet.

I've written a quick workaround for the issue, where I manually split the filenames and always return a tuple.

It might be useful to someone experiencing this problem, so I'm adding it to the issue here.

Two issues related with the workaround suggested by nosklo.

1. Splitting the filepaths isnt simple, as there may be blank spaces etc.
2. We have different versions of Python installed in our Lab machines, some have 2.5 and others got 2.6. If I run the code using the version2.6 workaround on a machine with version2.5, obviously it gives an error!!

Any updates on a fix? This bug is really giving me a hard time.

Update!! I found a very good workaround for this and it works very nicely, with both 2.5 and 2.6 versions. 

Below is the segment from my code:-

from Tkinter import *
import tkFileDialog

master = Tk()
master.withdraw() #hiding tkinter window

Inputfiles = tkFileDialog.askopenfilenames(title="Select the source input file(s)", filetypes=[("mpf file",".mpf"),("All files",".*")])

#Heres the TRICK!
InputfilesList =  master.tk.splitlist(Inputfiles)

UGH! Sorry for that, I mispasted something and didn't notice, since it filled the comment entry box perfectly :(

This is the real message I meant to paste:

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

vijay,

The workaround I provided above takes the blank spaces in filepaths
you mention into account and splits the paths correctly in all
situations I can think of. I'm using it in production now for over an
year, and had no issues at all. Perhaps you can provide an example of
path that would break the code, so it can be fixed.

thanks in advance
Clovis

Hi Clovis

Ok, I did not check if your split string function check for spaces or not, sorry for that. 

In my first post I mentioned this:-

"2. We have different versions of Python installed in our Lab machines, some have 2.5 and others got 2.6. If I run the code using the version2.6 workaround on a machine with version2.5, obviously it gives an error!!"

Infact I started out using your split string function but it was on a machine with Python2.6. It worked fine. Then I ran the same code on a machine with version Python2.5 and it threw an error when I tried calling your function, because the argument I passed to your function was already a tuple and not a string!! (I hope I could explain without confusing)

I would prefer my code to have some level of downward compatibility (to be able to run on Python of lower versions). Thats the reason I prefer to use the 'splitlist' method from Tkinter, as I dont need to change my code for different Python versions.

Best Regards
Vijay

There seems some similarity between this issue and issue #10316 which occurs on Linux.