On Thursday 20 October 2005 03:21, Giovanni Bajo wrote:
James Emerton [EMAIL PROTECTED] wrote:
I'm very in favour of the automatic conversion of QStrings into native
Python strings. I always thought that multiple string types was an
annoyance exclusive to C++. I'm also not convinced
I don't know how difficult or feasible it is, but I would suggest
using macros, so people can choose whether to use QString or python
str while compiling pyqt.
Just an idea.
Mike
On 10/18/05, Phil Thompson [EMAIL PROTECTED] wrote:
I'm wondering whether QString should be dropped in PyQt4 in
I heard Mike Tammerman said:
I don't know how difficult or feasible it is, but I would suggest
using macros, so people can choose whether to use QString or python
str while compiling pyqt.
Please, no!
If we do that, we'll never be able to release a PyQt program and be
certain it'll work on
Simon Edwards [EMAIL PROTECTED] wrote:
We could do something ugly like make QTextEdit.text() return a Python
string
(which is what most people want most of the time), and then add a keyword
argument qstring_please for the case where QString is desired...
optimises
the common case (for people)
Am Donnerstag 20 Oktober 2005 04:52 schrieb S Brown:
The usual way of changing the default font in eric3 doesn't seem to be
working.
I select
Preferences-Editor-Highlighting Style-Python-Default
and then change the font colour or font itself and nothing changes in the
editor.
Now the
Yes, I believe it would good to have two libraries. It's orthogonal to this
string issue though, but I wouldn't mind a more Pythonic way to use Qt. I'm
sure there are dozen of things that could be done easily in Python and are
harder in Qt because of C++. Of course, this is a totally different
On Thursday 20 Oct 2005 07:51, Simon Edwards wrote:
If methods like QTextEdit.text() could magically read minds and return a
Python string or a QString when desired, then everyone would be happy. :-)
Really, what we have in PyQt3 works fine with string except for in the case
of return types.
On Thu, 20 Oct 2005 03:21:33, Giovanni Bajo wrote:
In my humble opinion, PyQt should stay as close to C++ Qt as possible. It's
a binding. There are many, many, many places where the Qt API could be made
more Pythonic (just stretch your imagination), but those can find their
place in a library
James Emerton [EMAIL PROTECTED] wrote:
That's a valid point, but I don't think it needs to be a 'totally
separate project.' I understand the potential for incompatibility
with two versions of PyQt, but what if they had different names? They
can still be built from the same codebase, with
David Boddie [EMAIL PROTECTED] wrote:
I wonder what it means to have a Pythonic API. Apart from transparent
use of native types and classes, how could you make it so much more
Pythonic? Allow direct access to properties as attributes? Change
method names to lower case with underscores? I've
Heh, you're right! (Feeling kind of dumb right now...)
I didn't notice the Identifier category, which is obviously the category
which applies to non-keywords... like random gibberish blah blah blah. I
assumed that anything that wasn't a special type of construct (eg. a
keyword) would be
11 matches
Mail list logo
