Bug 343 – QFileDialog.getOpenFileName returns string of tuple instead of just string

PySide Bugzilla Closed for New Bugs

PySide is now a Qt Add-on and uses the Qt Project's JIRA Bug Tracker instead of this Bugzilla instance. This Bugzilla is left for reference purposes.

Bug 343 - QFileDialog.getOpenFileName returns string of tuple instead of just string

Summary:

QFileDialog.getOpenFileName returns string of tuple instead of just string

Status:	CLOSED INVALID

Product:	PySide
Classification:	Unclassified
Component:	QtGui
Version:	0.4.0
Platform:	PC MS Windows XP/Vista/7

Importance:	P3 normal
Assigned To:	renato filho

URL:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2010-09-04 04:52 EEST by andylomas
Modified:	2011-06-08 18:12 EEST (History)
CC List:	11 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description andylomas 2010-09-04 04:52:06 EEST

I’m trying to convert an application from PyQt4 to Qt and have found what
appears to be a difference in the return results from
QFileDialog.getOpenFileName

I’m calling QFileDialog with the following call:

filepath = unicode(QFileDialog.getOpenFileName(self, “Species Explorer – Open
Species”, dir, “Species Files (*.species)”))

When I use PyQt4 I just get a string with the file selected using the dialog
box. For example:

u"C:/production/species/testSpecies.species"

When I use PySide I get a string that contains a tuple with two sub-strings:
the filename and the value of the filter. For instance:

u"(u’C:/production/species/testSpecies.species’, u’Species Files (*.species)’)"

Comment 1 Hugo Parente Lima 2010-09-06 17:07:45 EEST

It returns a tuple because we are compatible with API2 of PyQt, not API1, so if
you want to run your program with both, PySide and PyQt, you need to enable the
API2 in PyQt:

import sip
sip.setapi("QFileDialog", 2)

then QFileDialog will also return a tuple in PyQt.

Comment 2 Matti Airas 2010-12-17 20:25:05 EET

*** Bug 555 has been marked as a duplicate of this bug. ***

Comment 3 Matti Airas 2011-01-19 06:40:12 EET

*** Bug 625 has been marked as a duplicate of this bug. ***

Comment 4 Hugo Parente Lima 2011-05-06 22:02:50 EEST

*** Bug 848 has been marked as a duplicate of this bug. ***

Comment 5 Anton Chikin 2011-05-07 04:52:12 EEST

Hugo,
I'm sorry. Could you please be more verbose on this issue?
I understand that you are keeping in sync with PyQt API, but what was the
overall reason for returning a tuple where Qt API says "string"?

Comment 6 Hugo Parente Lima 2011-05-09 17:19:18 EEST

Qt QStrings are mutable objects, Python strings not. All QStrings in PySide
were converted to unicode or str Python objects, so the only way to deal with
the QString* arguments in those functions were returning it in a tuple as we
can't modify the received argument.

You can check the PySide docs about this function here:

http://www.pyside.org/docs/pyside/PySide/QtGui/QFileDialog.html?highlight=getopenfilename#PySide.QtGui.PySide.QtGui.QFileDialog.getOpenFileName

Comment 7 Anton Chikin 2011-05-09 17:56:35 EEST

Hugo, thank you!

Comment 8 Luke Polak 2011-06-08 17:24:14 EEST

I think there is still a problem with getting string instead of tuple after
using that function. After executing the following code:

l_filename = str(QFileDialog.getOpenFileName(self.window, u'Import', '',
u'Package files (*%s)'%Package.EXTENSION))

l_filename is string type, with contents:

"(u'C:/path/to/file.pac', u'Package (*.pac)')"

and I think that's what the first poster was telling about, that we get string
in return, and not tuple currently (at least in some circumstances). Currently
using eval on that string gives correct value, that should be returned.

Comment 9 Hugo Parente Lima 2011-06-08 17:40:03 EEST

(In reply to comment #8)
> I think there is still a problem with getting string instead of tuple after
> using that function. After executing the following code:
> 
> l_filename = str(QFileDialog.getOpenFileName(self.window, u'Import', '',
> u'Package files (*%s)'%Package.EXTENSION))
> 
> l_filename is string type, with contents:
> 
> "(u'C:/path/to/file.pac', u'Package (*.pac)')"

You are converting a tuple to a string and you got the expected Python
behavior.

> and I think that's what the first poster was telling about, that we get string
> in return, and not tuple currently (at least in some circumstances). Currently
> using eval on that string gives correct value, that should be returned.

Please, read the comment 6, it explains why we need to return a tuple.

Regards.

Comment 10 Luke Polak 2011-06-08 17:53:33 EEST

I still don't understand. Shouldn't I get tuple as return value in this
function? Currently I get string, with contents from converting tuple that
should be returned, to string (it's like correct return value was passed to
str() function and returned). Or is it intended way as it is? :)

I'm not telling that it's bad, that tuple is returned (I understand why it is
that way), but that I get string in return, which I must first eval to get that
tuple.

Comment 11 Luke Polak 2011-06-08 18:12:34 EEST

Ahhh sorry, I must be tired, I didn't notice I'm making str from that tuple,
disregard my comments :)