I would like to state that PyQt (both 3 and 4) are currently just plain
wrappers against the C++ interface. They do not pythonize the interface in
any way. There are many things that could be done to improve the Qt API,
were Qt written in Python. But Qt is written in C++, and PyQt goal is to
expose Qt to Python. And I think it's a valuable goal.
Sure!
As I said elsewhere, I believe this kind of improvements belongs to a
separate wrapper, such as PyPyQt built on top of PyQt. Others would prefer a
PyQt compilation switch or something like that.
Hmm, nice idea. This will make Phil's job easier, and we have no obligations to follow the C++ idoms. We should talk about this later.
This was discussed at length (at least for QString) in the mailing list.
Phil empowered QString so to expose the buffer interface and thus making
them duck-typable with Python strings everywhere. This is a very good
compromise IMO. Anything else should be done elsewhere. Also notice that
QString is mutable, and any unicode <-> QString conversion causes an
additional copy (which might cause performance issues in some side case).
Hmm, sure. I remember that discussion, but it growed so much that I got lost :) Unless someone give a good reason, I sholud say to leave QString there. But it is not up to me :)
The performance problem can be solved with something like a QString cache. As QStrings are implicit shared, if we convert to/from python unicode string all the time, we could loose some performance. But with the cache, recently used strings will remain there, and it is quick. And the mutability can also be a problem.
How do you plan to modify pyuic4 so to infer the context without a preceding
"self."? It's going to be non-trivial.
There is no need to change pyuic4 to get the context. We just have to query the Python stack to know in which class we are calling the "tr" function. Someone (I think it was Bruno Silva) sugested this a long time ago. I think it is still on the list archive.
Alas, we can't do this *and* preserve C++ compatibility, because of the way
getters are usually called (like color()). So either we have a property
(.color) or a getter (.color()), we can't have both. In this case, this
change would break compatibility.
Hmm, sure. This might be a hard decision to make.
Also, another suggestion that was made in the past was to accept properties
in the constructor as keyword arguments (QWidget(parent, color= Qt.white,
width=100)). This could be made without breaking compatibility *for now*,
but it could be an issue if PyQt/SIP start supporting keyword arguments in
function calls.
That looks easy.
It could make sense if they are optional (and needed only for interaction
with the Designer. How should a signal function be defined, though? Maybe
it's better to just use a syntax like "foo = QSIGNAL()". As for the slot
decorator, there is a similar decoratory already that it's used to
disambiguate overload resolution. So it's currently possible to mark slots.
It might make sense to reuse this decorator instead of creating a new one.
Hmm, I did not know that. Can you show me an example.
I think there are techinical issues, as Phil already rejected this. I don't
know the details.
I think the problem is ambiguity. But we can find a "safe algebra" between all cases that will solve 95% of the most common used cases. Take a look at QtRuby, they do something like that.
Thanks for the input!
At your orders :)
--
Eric Jardim
_______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
