[PyKDE] Sugestions for PyQt4

[Eric Jardim]

2006/3/20, Giovanni Bajo <rasky at develer.com>:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20060320/cbd332d6/attachment.html