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 --- _______________________________________________ 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]
