[PyQt] PyQt4 for Python 3

[Phil Thompson]

On Wed, 10 Jun 2009 10:59:00 +0100, Mark Summerfield <list at qtrac.plus.com>
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