On 10.01.2011 14:33, ext Thomas Perl wrote:
Would something like Python's own "from __future__ import ..." help
there? You would still need to ship both "variants" (the old one and
the new one), but if an import could pull all switches so that the new
behaviour is activated, would that work?
Yes, it'd probably be something like that. PyQt uses the following
syntax to select the optional (in PyQt, that is) API 2:
import sip
sip.setapi('QString', 2)
from PyQt4 import QtCore
# This will raise an attribute exception because QString is only wrapped
# in version 1 of the API.
s = QtCore.QString()
We'd need to have something similar which would need to be
1) not ugly
2) generic enough to be used for any new future features, not just
properties
3) feasible to implement
Alternatively, if it's easy to implement (and the resources are
available) what about creating a "PySide playground" where such
features are implemented and can be tested by the community, so that
when the time for a possible PySide 2.0 comes, we know what features
work and are useful and just have to move the working, useful
playground feature into the stable release.
The problem with doing such backwards-incompatible version releases is
that due to the existing code-base (esp. PyQt users migrating to
PySide), we'd in practice need to support both versions indefinitely,
effectively branching the PySide project. Or at least that's my
worst-case scenario. :-) But in any case, as the future is still wide
open, this option continues to be a valid discussion point. Having a
clean, new API always has its benefits.
Cheers,
ma.
_______________________________________________
PySide mailing list
PySide@lists.openbossa.org
http://lists.openbossa.org/listinfo/pyside
