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]
