El 22/12/10 12:22, Phil Thompson escribió:
On Wed, 22 Dec 2010 11:56:20 +0100, "Hans-Peter Jansen"<h...@urpla.net>
wrote:
On Wednesday 22 December 2010, 07:00:01 Phil Thompson wrote:
On Wed, 22 Dec 2010 01:33:49 +0100, "Hans-Peter Jansen"
<h...@urpla.net>
wrote:
On Tuesday 21 December 2010, 23:58:39 Erik Janssens wrote:
you could just access sql through python instead of through qt,
NULL would then correspond to None
...by the price of renouncing QtSql neck and crop. That's a high
price to pay, isn't it?
Sure, Camelot does this, but I really appreciate displaying tables
with a million records with a few lines of code without any worry
(thanks to Qt's decent fetch mechanics under the model/view
covers).
On Tue, 2010-12-21 at 23:52 +0100, TP wrote:
Phil Thompson wrote:
API v1 will be supported until PyQt5 or Python v4.
Is it contractual? Why Python v4? It seems to me that nobody
knows when Python v4 will appear.
It's contractual in the sense that I commit (to you lot) not to break
compatibility during the lifetime of currently available major
versions of PyQt and Python.
Anyway, it seems to be a problem that API2 does not support
NULL, even if it corresponds to side cases (as mine).
This is unfortunate, since sacrificing API 2 QVariants is a long
ranging
decision to better make _early_ on - changing it lately in a
project will cause headaches, guaranteed (apart from the unpythonic
annoyance, that let to inventing it in the first place).
The question is, what would be the prize of getting away from that
asymmetry? PyQt would always return None for QString::Null
QString::null
QVariants(), which cannot appended to, etc.. Anything else with
significance?
How about an QVariant API 3 with this behavior?
There are two issues, QVariant and QString. I don't believe the
QVariant issue is a significant one as it easy to work around and
(arguably) the workaround forces you to write code that is easier to
understand.
The asymmetric behaviour of the v2 conversion between a null QString
and a Python unicode/string object is more of a problem as it makes
it impossible to distinguish a database NULL value from an empty
string. The root cause of this is the fact that QString() creates a
null QString rather than an non-null empty QString - and there is not
a lot I can do about that.
What about a QString API 3 variant that returns None, if it encounters
QString::null values?
This would correspond to Pythons expliciteness nicely, doesn't it?
The only adverse effect, I can think of, is not being able to use None
as a string, eg. appending something to None isn't possible, while this
is (sadly) possible with Qt and uninitialized QStrings (aka
QString::null).
#include<QtCore>
int main(int argc, char * argv[])
{
// inconsistent Qt API behavior:
// Qt should distinguish between QString::null and QString("")
QString s; // = QString::null;
s.append("test");
qWarning()<< "main:<"<< s<< ">";
return 0;
}
That's exactly why v3 would be a bad idea. You would have to explicitly
test for None in many cases just because Qt returned QString() instead of
QString("").
I would be more receptive to introducing a new type (eg. QPyNullVariant)
to the QVariant v2 API that wrapped a null QVariant.
Phil
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
I think this should be done, it is crucial to work with databases through qt to
correctly identify null values.
Regards,
Miguel Angel.
_______________________________________________
PyQt mailing list PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
