gmane.comp.python.pyqt-pykde

Phil Thompson | 7 Oct 09:55

Re: Re: PyQt4 and Python 3.0

On Tue, 07 Oct 2008 00:29:12 -0700, Glenn Linderman <v+python <at> g.nevcal.com>
wrote:
> On approximately 10/6/2008 10:07 PM, came the following characters from 
> the keyboard of Phil Thompson:
>> On Mon, 6 Oct 2008 21:30:49 -0500, "Arthur Pemberton" <pemboa <at> gmail.com>
>> wrote:
>>> On Mon, Oct 6, 2008 at 7:33 PM, Doug Bell <dougb <at> bellz.org> wrote:
>>>> Giovanni Bajo wrote:
>>>>> On 10/6/2008 7:27 PM, Joshua Kugler wrote:
>>>>>> Phil Thompson wrote:
>>>>>>
>>>>>>> On Fri, 3 Oct 2008 17:11:19 +0200, Detlev Offenbach
>>>>>>> <detlev <at> die-offenbachs.de> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> will there be PyQt4 support for Python 3.0 once it goes final?
>>>>>>> Not straight away. I will take the opportunity to break backwards
>>>>>>> compatibility (eg. removing QVariant, QString, QChar, QByteArray
>> etc),
>>>>>>> and
>>>>>>> those changes will be made over a period of time. So it may be a
>> while
>>>>>>> before the API is stable enough for anything other than playing.
>>>>>> Before you do that, please take into consideration Guido's advice:
>>>>>>
>>>>>> "Don't change your APIs incompatibly when porting to Py3k."
>>>>>>
>>>>>> http://www.artima.com/weblogs/viewpost.jsp?thread=227041
>>>>> I think the main collision here is that Guido is trying to help
people

(Continue reading)

Glenn Linderman | 7 Oct 10:11

X-Face

Re: Re: PyQt4 and Python 3.0

On approximately 10/7/2008 12:55 AM, came the following characters from 
the keyboard of Phil Thompson:
> On Tue, 07 Oct 2008 00:29:12 -0700, Glenn Linderman <v+python <at> g.nevcal.com>
> wrote:

>> What's the point in fixing anything, without unifying QString and Python 
>> string?  Or can you just ignore Python str (except for converting from 
>> it), and unify QString and unicode?  And if you can, is the reason why 
>> it wasn't just because it hadn't been thought of then, or that the 
>> technology to do so wasn't understood, rather than it being technically 
>> impossible? I'm too new to Py & Qt to understand the history here.
> 
> It was discussed during the development of PyQt4, but in the end I took a
> conservative approach. Since then things like Jambi have come along with a
> different approach which people don't seem to complain about.

I see.  Thanks for the explanation.

>> I can't speak for other users, but I'm mostly interested in seeing 
>> something for Py3 for new applications.  Note that making PyQt4 on Py2 
>> more Pythonic only helps those users that are willing to make a porting 
>> or rewrite investment on that platform.
>>
>> I'd actually rather see a port of PyQt4 to Py3 without (many) new 
>> features, and then see the Pythonic rewrite happen there.
> 
> I think most people today will be planning to use Python 2 for new
> (non-trivial) developments. Presumably that will change over time.

You've certainly been around supporting the community longer than I, and

(Continue reading)

Sundance | 7 Oct 11:33

Re: Re: PyQt4 and Python 3.0

Phil Thompson wrote:

> Regarding numbering, my current thinking is...
> 
> from PyQt4 import QtCore2, QtGui2

Hi all,

I would like to go out on a limb and share a few thoughts that came to 
me with you guys.

Essentially, the name of PyQt4 seems to carry some embedded confusion, 
in particular about what exactly the '4' applies to -- the whole PyQt, 
or only the Qt part. That's not a bad thing in itself; for long, it has 
been applying to both, so the double meaning is fitting.

However, if the versioning of PyQt is going to become dissociated from 
that of Qt, perhaps the naming scheme itself should reflect it.

It's not necessary to change the name of PyQt itself, although perhaps 
that might be envisioned (anyone knows the name of a species of, err, 
cute pythons?), but mostly it'd be about getting the 'Qt' part out of 
the actual name so we could do something like:

  from Viper import Qt4

or

  from Viper.Qt3 import qt, qttable

(Continue reading)

Henrik Pauli | 7 Oct 11:57

Re: Re: PyQt4 and Python 3.0

On Tuesday 07 October 2008, Sundance wrote:
> Phil Thompson wrote:
> > Regarding numbering, my current thinking is...
> >
> > from PyQt4 import QtCore2, QtGui2
>
> Hi all,
>
> I would like to go out on a limb and share a few thoughts that came to
> me with you guys.
>
> Essentially, the name of PyQt4 seems to carry some embedded confusion,
> in particular about what exactly the '4' applies to -- the whole PyQt,
> or only the Qt part. That's not a bad thing in itself; for long, it has
> been applying to both, so the double meaning is fitting.
>
> However, if the versioning of PyQt is going to become dissociated from
> that of Qt, perhaps the naming scheme itself should reflect it.
>
> It's not necessary to change the name of PyQt itself, although perhaps
> that might be envisioned (anyone knows the name of a species of, err,
> cute pythons?), but mostly it'd be about getting the 'Qt' part out of
> the actual name so we could do something like:
>
>   from Viper import Qt4
>
> or
>
>   from Viper.Qt3 import qt, qttable
>

(Continue reading)

Phil Thompson | 7 Oct 12:10

Re: Re: PyQt4 and Python 3.0

On Tue, 7 Oct 2008 11:34:24 +0200, Sundance <sundance <at> ierne.eu.org> wrote:
> Phil Thompson wrote:
> 
>> Regarding numbering, my current thinking is...
>> 
>> from PyQt4 import QtCore2, QtGui2
> 
> Hi all,
> 
> I would like to go out on a limb and share a few thoughts that came to 
> me with you guys.
> 
> Essentially, the name of PyQt4 seems to carry some embedded confusion, 
> in particular about what exactly the '4' applies to -- the whole PyQt, 
> or only the Qt part. That's not a bad thing in itself; for long, it has 
> been applying to both, so the double meaning is fitting.

Strictly speaking the '4' refers to PyQt and not Qt, but this is one case
where it's better if I agree with everybody else rather than insist on my
view of the world.

So I think the confusion is usually about the digits after the '4' rather
than the '4' itself.

> However, if the versioning of PyQt is going to become dissociated from 
> that of Qt, perhaps the naming scheme itself should reflect it.
> 
> It's not necessary to change the name of PyQt itself, although perhaps 
> that might be envisioned (anyone knows the name of a species of, err, 
> cute pythons?), but mostly it'd be about getting the 'Qt' part out of

(Continue reading)

Daniel Miller | 7 Oct 15:07

Re: PyQt4 and Python 3.0


On Oct 7, 2008, at 6:10 AM, Phil Thompson wrote:

>> And we could have just as many Viper versions as we'd damn well  
>> please
>> within any given Python and Qt release timeframe -- we'd simply  
>> import
>> from Viper2, Viper3... rather than Viper.
>>
>> Thoughts?
>
> With 20/20 hindsight (starting 10 years ago) I should have done  
> something
> along these lines. I'm certainly not going to change the structure  
> of PyQt3
> at this stage.
>
> At the moment I'm considering two possibilities...
>
> from PyQt4 import QtCore2

Why would you want to do this?

> ...which has the disadvantage of the number of changes needed if  
> you use
> the QtCore2.QLabel() style (which I do), and...
>
> from PyQt4v2 import QtCore

Or this? Do you like to make developers needlessly change their code?

(Continue reading)

Glenn Linderman | 7 Oct 19:43

X-Face

Re: PyQt4 and Python 3.0

On approximately 10/7/2008 6:07 AM, came the following characters from 
the keyboard of Daniel Miller:

> Or this? Do you like to make developers needlessly change their code? 
> These are simply gratuitous name changes. It would be much more logical 
> to keep the package and module names as similar as possible between 
> versions. The correct place to put the version is in a __version__ 
> attribute of the top-level package (i.e. in __init__.py). Then if you 
> really need to know the version inside your program, do this:
> 
> import PyQt
> print PyQt.__version__ # --> PyQt 4.3.3
> 
> People will not normally have multiple versions of PyQt installed, and 
> if they do, they will certainly not be using multiple versions in a 
> single application. To solve the problem of having multiple versions of 
> PyQt installed at once, use the established egg/setuptools packaging 
> scheme where the version can be "required" before import like so:
> 
> require("PyQt==4.3.*")

> For more info on how it works see "Automatic 
> Discovery" <http://peak.telecommunity.com/DevCenter/PythonEggs>
> 
> This is definitely the most sane way to go as it allows developers to 
> upgrade without changing anything that does not change from one version 
> of PyQt to the next. Of course, if there are compatibility-breaking 
> changes they will need to be fixed, but those should be the only changes 
> required. It should NOT be required to touch every single source file 
> that imports PyQt just to change it to import PyQt4v2 or whatever crazy

(Continue reading)

Doug Bell | 7 Oct 12:25

Re: Re: PyQt4 and Python 3.0

Phil Thompson wrote:
> On Tue, 07 Oct 2008 00:29:12 -0700, Glenn Linderman
> <v+python <at> g.nevcal.com> wrote:
> > On approximately 10/6/2008 10:07 PM, came the following characters
> > from the keyboard of Phil Thompson:
> >> On Mon, 6 Oct 2008 21:30:49 -0500, "Arthur Pemberton"
> >> <pemboa <at> gmail.com> wrote:
> >>> Take some time with the community, collect opinion on all the bad
> >>> parts of PyQt, and then make a clean break to rewrite PyQt4 for
> >>> Python 2.6, making use of future features whenever possible.
> >> 
> >> I definitely won't be targeting 2.6 for anything. The idea that
> >> people will move their 2.x code to 2.6, and then move it again to
> >> 3.0 is, to me, crazy.

But the idea that people will do a major move to a new PyQt and then do
a major move to Python 3.0 isn't crazy?  Personally, I'd rather get it
over with all at once.

> > I think PyQt4 as is, with bug fixes if Python 2.6 breaks anything, is 
> > adequate for 2.6.
> > 
> >> I will set something up to gather opinion and to present my current
> >> thinking. I will particularly need help in identifying individual
> methods
> >> that should be made more Pythonic.

> >> Note that a side effect of all this is that Python3 support drops down
> >> the
> >> priority list (by a long way) as making PyQt4 for Python2 more Pythonic

(Continue reading)

Phil Thompson | 7 Oct 12:45

Re: Re: PyQt4 and Python 3.0

On Tue, 7 Oct 2008 06:25:59 -0400, Doug Bell <dougb <at> bellz.org> wrote:
> Phil Thompson wrote:
>> On Tue, 07 Oct 2008 00:29:12 -0700, Glenn Linderman
>> <v+python <at> g.nevcal.com> wrote:
>> > On approximately 10/6/2008 10:07 PM, came the following characters
>> > from the keyboard of Phil Thompson:
>> >> On Mon, 6 Oct 2008 21:30:49 -0500, "Arthur Pemberton"
>> >> <pemboa <at> gmail.com> wrote:
>> >>> Take some time with the community, collect opinion on all the bad
>> >>> parts of PyQt, and then make a clean break to rewrite PyQt4 for
>> >>> Python 2.6, making use of future features whenever possible.
>> >> 
>> >> I definitely won't be targeting 2.6 for anything. The idea that
>> >> people will move their 2.x code to 2.6, and then move it again to
>> >> 3.0 is, to me, crazy.
> 
> But the idea that people will do a major move to a new PyQt and then do
> a major move to Python 3.0 isn't crazy?  Personally, I'd rather get it
> over with all at once.

Personally, so would I. However this whole discussion started because
others said that they'd like to make that decision for themselves.

>> > I think PyQt4 as is, with bug fixes if Python 2.6 breaks anything, is 
>> > adequate for 2.6.
>> > 
>> >> I will set something up to gather opinion and to present my current
>> >> thinking. I will particularly need help in identifying individual
>> methods
>> >> that should be made more Pythonic.

(Continue reading)

Giovanni Bajo | 7 Oct 18:10

Re: Re: PyQt4 and Python 3.0

On 10/7/2008 12:25 PM, Doug Bell wrote:
> Phil Thompson wrote:
>> On Tue, 07 Oct 2008 00:29:12 -0700, Glenn Linderman
>> <v+python <at> g.nevcal.com> wrote:
>>> On approximately 10/6/2008 10:07 PM, came the following characters
>>> from the keyboard of Phil Thompson:
>>>> On Mon, 6 Oct 2008 21:30:49 -0500, "Arthur Pemberton"
>>>> <pemboa <at> gmail.com> wrote:
>>>>> Take some time with the community, collect opinion on all the bad
>>>>> parts of PyQt, and then make a clean break to rewrite PyQt4 for
>>>>> Python 2.6, making use of future features whenever possible.
>>>> I definitely won't be targeting 2.6 for anything. The idea that
>>>> people will move their 2.x code to 2.6, and then move it again to
>>>> 3.0 is, to me, crazy.
> 
> But the idea that people will do a major move to a new PyQt and then do
> a major move to Python 3.0 isn't crazy?  Personally, I'd rather get it
> over with all at once.

Ask the KDE4 guys about "get it over with all at once". They changed 
SCM, build system and Qt major version at the same time, with no option 
of having releases inbetween. Ask them if they'd ever do that again.
--

-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com

Sundance | 7 Oct 16:19

Re: Re: PyQt4 and Python 3.0

Henrik Pauli wrote:

>> And we could have just as many Viper versions as we'd damn well
>> please within any given Python and Qt release timeframe -- we'd
>> simply import from Viper2, Viper3... rather than Viper.
>
> Hmmm, true that, but since Py2 and Py3 are completely different
> matters (as far as I understand), thus have completely separate module
> bases, it could be just Viper in both, without clashing whatsoever.  

Hi,

Maybe I didn't express myself clearly, but in my thinking, 'Viper' 
versions and Python versions would be orthogonal, so Viper2, Viper3... 
would be referring to the respective versions of the bindings, NOT the 
versions of Python. The whole /point/ would be to be independant of the 
Python versioning scheme. :)

In other words, a given version of 'Viper' could conceivably be designed 
to be able to build against both Python 2 and Python 3, although of 
course a later version would eventually drop support for Python 2. 
That's what drove the organisation of the scheme I posted about: it 
allows smooth transitioning between versions of Python as well as 
between versions of Qt -- without making it mandatory, either, because 
supporting several Python versions with one build is bound to be a lot 
of work that Phil may not want to undertake.

Also, Phil wrote:

> Strictly speaking the '4' refers to PyQt and not Qt, but this is one

(Continue reading)

Phil Thompson | 7 Oct 16:49

Re: Re: PyQt4 and Python 3.0

On Tue, 7 Oct 2008 16:20:13 +0200, Sundance <sundance <at> ierne.eu.org> wrote:
> You also suggest the 'from PyQt4v2 import QtCore' and 'from PyQt4.v2 
> import QtCore' schemes, in which, if I'm not mistaken, the '4' in PyQt4 
> would now start referring to the Qt version, is that correct?

Yes - as (probably) everybody else already thinks of it.

> If so, 
> the scheme would be functionally equivalent to what I suggested, minus 
> the possibility to support different Qt versions within one PyQt 
> version, which is really no big deal AFAIC. So the only issues left 
> would then be possible ambiguities with the current PyQt4 module's 
> organisation, and, well, aesthetics.
> 
> On that note, please don't go with 'from PyQt4 import QtCore2'. :) If 
> the module's name is QtCore in Qt, it should be QtCore in the bindings 
> as well. Plus I can already foresee namespace clashes with that scheme.

The more I think of QtCore2, the less I like it.

Phil

Henrik Pauli | 7 Oct 22:18

Re: Re: PyQt4 and Python 3.0

On Tuesday 07 October 2008, Sundance wrote:
> Henrik Pauli wrote:
> >> And we could have just as many Viper versions as we'd damn well
> >> please within any given Python and Qt release timeframe -- we'd
> >> simply import from Viper2, Viper3... rather than Viper.
> >
> > Hmmm, true that, but since Py2 and Py3 are completely different
> > matters (as far as I understand), thus have completely separate module
> > bases, it could be just Viper in both, without clashing whatsoever.
>
> Hi,
>
> Maybe I didn't express myself clearly, but in my thinking, 'Viper'
> versions and Python versions would be orthogonal, so Viper2, Viper3...
> would be referring to the respective versions of the bindings, NOT the
> versions of Python. The whole /point/ would be to be independant of the
> Python versioning scheme. :)

If you read it again, you'll see I wrote pretty much that; or at the very 
least a completely different issue :)

Return

Return to gmane.comp.python.pyqt-pykde.

Advertisement

Project Web Page

Discussion of PyQt, Python language bindings for Qt and KDE

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane