On Wed, 10 Jun 2009 10:59:00 +0100, Mark Summerfield <[email protected]> wrote: > Also, just realised that the roadmap doesn't mention exceptions. > > I was hoping that, for example, QString.toInt() would return an int on > success and raise a ValueError (or whatever) on failure to be more > Pythonic. Similarly QFile.open(). > > The thing I find particularly galling about QString.toInt() returning a > tuple is that it is really easy to write: > > my_int = someQString.toInt() > > and not realise until sometime later in the code that my_int is in fact > a tuple---or maybe not notice at all if you're really only checking for > 0: > > if not my_int: > # meant for zero but actually will never get here > > Still I guess the problem will go away once QString is gone, since we'll > just write: > > my_int = int(some_string) > > in the normal way.
Yes. When you look at it most of the cases will disappear anyway. I didn't intend that the roadmap describes every planned change, though it might be worth adding this now as a way of collecting candidates. >> > PS I think that QUrl is a good candidate for having __hash__. >> >> The problem is that (unlike the other candidates) QUrl is not >> supported by qHash() which means that I'd have to invent a hash >> function. This would then cause potential problems if QUrl support was >> added to qHash() at a later date. It would be better to persuade Nokia >> to add the support to qHash(). > > One way to do it is to use qHash(QUrl.toString()). Of course two QUrls > could produce different QStrings for equivalent URLs, so it would only > guarantee uniqueness of the QString representation, not URL uniqueness; > but that might be sufficient for the common cases. That's not the point. I want __hash__ to be a wrapper around qHash() as that is simple and consistent behaviour and allows PyQt code to, for example, work with persistent data that contains hash values created by C++ code. Inventing a (perfectly reasonable) hash function for PyQt that is different than a future hash function added to Qt would be a problem. Phil _______________________________________________ PyQt mailing list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
