Hi,
I'll keep working on 'phoenix2ndtry'.
- main goal get Py3.4 with recent Phoenix build
- secondary goal Py2.7 with recent Phoenix build
Werner
On 2/28/2015 1:03, Paul McNett wrote:
At such time as dabo works on wx 3.x, we can warn that wx 2.8.x is no
longer supported. For a time, it may continue to work, but not
guaranteed. wx 3 is their stable version, so that's what Dabo2
supports, period.
Ideally, Dabo2 would work with both wx 2.8 and wx 3.0, but if that's
not straightforward, drop 2.8.x. Dabo already works on 2.8 and we can
tell people to stick with Dabo0.
We will definitely need to keep supporting python2.7 for the
foreseeable future, which means we'll need to support wxPython 3.x as
well.
We want to support Python 3 ASAP, which is why we are working on
getting Phoenix support working.
From all I've heard, it still seems to make sense to keep separate
ui/uiwx-python2 and a ui/uiwx-python3 libraries. We can smart-switch
between them on startup based on the python version, but keeping them
separate will keep our energies focused.
Everything in uiwx-python3 will need to be python3 compatible but not
python2 compatible.
Everything in uiwx-python2 will need to be python2 compatible but not
python3 compatible.
Everything else will need to be python2 AND python3 compatible.
Paul
On 2/26/15 1:55 PM, Neil Flowers wrote:
I don't doubt that it could be done. Obviously I have not
participated in the Phoenix compatibility changes, but given what I
have seen of them and the wx classic 3.0 changes, I believe it would
be possible to have both classic and Phoenix exist under one UI
umbrella, as they currently exist. Rather, my concern lies with the
implications of this design. By keeping a unified code base, we make
the implicit assumption that these forks will continue to stay close
enough together to reasonably support. If this is not absolutely the
case, future rebasing will have to involve ever increasing levels of
"forked" code paths (if phoenix: ... else: ..., if py2: ... else:
..., etc). As John suggested, this would basically tank readability
and elegance. Moreover, the more work invested in this design, the
more work it would require to actually decouple them if the original
assumption fails to hold.
I didn't see the original message, so you may have already discussed
this. If there is compelling reason to believe that classic and
Phoenix will remain tightly coupled - that is, changes will be ported
between them reliably and the Py2/3+ divide itself does not spiral
too far out of control - or alternatively if classic will be
discontinued altogether, then it may be alright to avoid splitting.
However, it is worth considering the downsides of this design, and
that the choice could come back to haunt Dabo later, depending on wx.
In response to an older message, my thoughts on splitting the UI
packages would be to just have two total, one for classic and one for
Phoenix. Judging by Phoenix's purpose, classic will not be ported to
python 3. As such, you would only need bases for classic/py2 and
Phoenix/(py2?)/py3. Any backwards compatibility for classic 2.8 would
probably best be left in with classic 3.x code.
Neil
On February 26, 2015 12:29:35 PM PST, john <[email protected]> wrote:
On 02/26/2015 09:32 AM, Werner wrote:
If this can be verified then I don't think there is a need to go to
another 'ui' module, as it should be possible to stay compatible with
2.8.12+ classic and 3.x Classic and Phoenix on Py2.7 and Py3.4.
I believe you are asking for a very tall order. I'm sure Neil would
agree that when we reviewed the code the difference between python 2
and
python 3 along with the differences between wxpython versions would
have
made the final Dabo look like a old 50's comedy routine (who's on
first)
- and impossible to follow. This I believe will break one of the first
rules of Python - make it readable.
But I guess if the others disagree with me - I'd have to go along.
Johnf
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance:
http://mail.leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message:
http://leafe.com/archives/byMID/[email protected]
--- StripMime Report -- processed MIME parts ---
multipart/alternative
text/plain (text body -- kept)
text/html
---
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message: http://leafe.com/archives/byMID/[email protected]
