Hi Neil,
It is my understanding that classic will die as soon or soon after
Phoenix is released, Phoenix will support Py2.7, Py3.3+.
Looking at e.g. ClassDesigner I see same or similar errors showing with
Classic 3.0 and Phoenix, which makes sense as the underlying wxWidgets
code is the same. Phoenix is 'just' a different way of wrapping the C++
code and brings some clean up of the API, e.g. overloaded methods don't
have multiple names in Python.
I would like to find a way that work on Phoenix is not duplicating the
work you do on Classic and vice versa.
Maybe another way to split could be:
ui/wx = Dabo 0.9x using Classic 2.8
- This works, so don't disturb it
ui/wx2 = based on Dabo2 supporting Classic 3 on Py2 and Phoenix on Py2.7
and Py3.4+
- But does this bring more then a git branch? Especially all the IDE
stuff is not separated by that.
Yes, there is a lot of "if phoenix else" needed, which can be relatively
easily removed once Dabo fully transitioned to Phoenix.
The Py2/Py3 differences should all be handled with six, they can be left
in or again be removed once Dabo fully transitioned to Py3.
Werner
On 2/26/2015 22:55, 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]
