2006/3/20, Giovanni Bajo <<a href="mailto:rasky@develer.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rasky@develer.com</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I would like to state that PyQt (both 3 and 4) are currently just plain<br>wrappers against the C++ interface. They do not pythonize the interface in<br>any way. There are many things that could be done to improve the Qt API,
<br>were Qt written in Python. But Qt is written in C++, and PyQt goal is to<br>expose Qt to Python. And I think it's a valuable goal.</blockquote><div><br>
Sure! <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As I said elsewhere, I believe this kind of improvements belongs to a<br>separate wrapper, such as PyPyQt built on top of PyQt. Others would prefer a
<br>PyQt compilation switch or something like that.</blockquote><div><br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This was discussed at length (at least for QString) in the mailing list.<br>Phil empowered QString so to expose the buffer interface and thus making
<br>them duck-typable with Python strings everywhere. This is a very good<br>compromise IMO. Anything else should be done elsewhere. Also notice that<br>QString is mutable, and any unicode <-> QString conversion causes an
<br>additional copy (which might cause performance issues in some side case).</blockquote><div><br>
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 :)<br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">How do you plan to modify pyuic4 so to infer the context without a preceding
<br>"self."? It's going to be non-trivial.</blockquote><div><br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Alas, we can't do this *and* preserve C++ compatibility, because of the way<br>getters are usually called (like color()). So either we have a property
<br>(.color) or a getter (.color()), we can't have both. In this case, this<br>change would break compatibility.</blockquote><div><br>
Hmm, sure. This might be a hard decision to make.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, another suggestion that was made in the past was to accept properties<br>in the constructor as keyword arguments (QWidget(parent, color=
Qt.white,<br>width=100)). This could be made without breaking compatibility *for now*,<br>but it could be an issue if PyQt/SIP start supporting keyword arguments in<br>function calls.</blockquote><div><br>
That looks easy. <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It could make sense if they are optional (and needed only for interaction
<br>with the Designer. How should a signal function be defined, though? Maybe<br>it's better to just use a syntax like "foo = QSIGNAL()". As for the slot<br>decorator, there is a similar decoratory already that it's used to
<br>disambiguate overload resolution. So it's currently possible to mark slots.<br>It might make sense to reuse this decorator instead of creating a new one.</blockquote><div><br>
Hmm, I did not know that. Can you show me an example.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think there are techinical issues, as Phil already rejected this. I don't
<br>know the details.</blockquote><div><br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thanks for the input!<br></blockquote></div><br>
At your orders :)<br>
<br>
--<br>
Eric Jardim<br>