Andrea,
I noticed that classes and functions from the wx.adv module are showing up in the main part of the docs as ClassName instead of in a adv section like what is happening for dataview. What do we need to do to set things up so wx.adv items are separated from the core and such?
--
Robin Dunn
Software Craftsman
http://wxPython.org
Robin,
Andrea,
I noticed that classes and functions from the wx.adv module are showing up
in the main part of the docs as ClassName instead of in a adv section like
what is happening for dataview. What do we need to do to set things up so
wx.adv items are separated from the core and such?
I don't expect it to be very complicated, I'll take a look at it right
now. I remember I had asked you a while back if we were going to have
a "wx.adv" sub-package but probably that part of the message got lost
somehow as I didn't get any reply back.
I didn't initially implement it as "adv" in the docs for two reasons:
we have never had a "wx.adv" sub-package before and there is nothing
really "advanced" about wx.SplashScreen or wx.TaskBarIcon.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 26 May 2012 00:31, Robin Dunn wrote:
Uhm, no, I'll backtrack here. It is going to get complicated and, most
importantly, ugly in the sphinxgenerator code. One things I do not
understand: is wx.SplashScreen (or any other "adv" stuff) going to be
defined as wx.adv.SplashScreen in the documentation? How about
parameter kind (i.e., is "wxGridSelectionModes" going to be defined as
wx.adv.GridSelectionModes or wx.adv.grid.GridSelectionModes or
something else?).
I believe the Sphinx documentation should follow the wxPython module
structure, not an unspecified (and flawed) wxWidgets definition of
what "wxAdvanced" should be. If you're telling me that from now on
wx.grid.Grid and wx.calendar.CalendarCtrl will be addressed as
"wx.adv.Grid" and "wx.adv.CalendarCtrl", then we may have a problem
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 26 May 2012 21:37, Andrea Gavana wrote:
Robin,
On 26 May 2012 00:31, Robin Dunn wrote:
Andrea,
I noticed that classes and functions from the wx.adv module are showing up
in the main part of the docs as ClassName instead of in a adv section like
what is happening for dataview. What do we need to do to set things up so
wx.adv items are separated from the core and such?I don't expect it to be very complicated, I'll take a look at it right
now.
Robin,
Andrea,
I noticed that classes and functions from the wx.adv module are showing up
in the main part of the docs as ClassName instead of in a adv section like
what is happening for dataview. What do we need to do to set things up so
wx.adv items are separated from the core and such?I don't expect it to be very complicated, I'll take a look at it right
now.I didn't initially implement it as "adv" in the docs for two reasons:
we have never had a "wx.adv" sub-package before and there is nothing
really "advanced" about wx.SplashScreen or wx.TaskBarIcon.
"Advanced" really isn't a very good name for it. It's actually used for things that depend on core but that are used less frequently and so are good candidates for excluding in applications that do not need them, in order to save memory, installer size, etc. There is a section in the MigrationGuide about this and the reasons for basically following the structure of the wx libraries. I'll paste it[1] below.
Uhm, no, I'll backtrack here. It is going to get complicated and, most
importantly, ugly in the sphinxgenerator code. One things I do not
understand: is wx.SplashScreen (or any other "adv" stuff) going to be
defined as wx.adv.SplashScreen in the documentation?
It would be nice if we could. Or at least have some notation in the SplashScreen's class documentation that this class is located in the wx.adv module. For example either using "wx.adv.SplashScreen" for the title at the top of the page, or having something like "Module: wx.adv" line near the top.
How about
parameter kind (i.e., is "wxGridSelectionModes" going to be defined as
wx.adv.GridSelectionModes or wx.adv.grid.GridSelectionModes or
something else?).
That is not a good example since it is an enum (and so from Python it is really just an integer) and also because it's defined inside the Grid class so the enum values will always be referenced via the class. However I do understand the gist of your question. I think if we're able to show the module where the class or enum is located on its page then it is probably okay to use just the base name when referring to it elsewhere.
I believe the Sphinx documentation should follow the wxPython module
structure, not an unspecified (and flawed) wxWidgets definition of
what "wxAdvanced" should be.
The point is that the Classic wxPython module structure was flawed, and the wxPython Phoenix module structure is going to more or less follow the wx DLL organization. So having the Sphinx documentation follow the wxPython (phoenix) module structure is essentially the same as following the wxWidgets definition.
If you're telling me that from now on
wx.grid.Grid and wx.calendar.CalendarCtrl will be addressed as
"wx.adv.Grid" and "wx.adv.CalendarCtrl", then we may have a problem
I think Grid will still have its own module since it is so big, but yes CalendarCtrl is in wx.adv already.
BTW, you can use the ModulfDef.module attribute while the sphinx_generator is running to get the name of the extension module where the items in that etg script are being put. The current possibilities are "_core", "_adv" and "_dataview" but there are going to be more, (I currently have plans for _grid, _html, _html2, _richtext, _stc, _propgrid, _xrc, _gl, and _msw). Using that attribute when the generator is running you should be able to record which module each of the items will be located in and then either use that in the source .txt files and/or while post-processing before running sphinx. Does that make sense or am I missing something?
The wx/__init__.py is essentially just "from wx.core import *", and then the wx.core Python module imports everything from the _core extension module. The others will follow the same pattern, but only wx.core will be loaded into the wx namespace.
[1]
"""
The 'wx' namespace and submodules reorganized
On 5/26/12 1:12 PM, Andrea Gavana wrote:
On 26 May 2012 21:37, Andrea Gavana wrote:
On 26 May 2012 00:31, Robin Dunn wrote:
---------------------------------------------
Some reorganization of what classes and functions goes in which internal wx extension module has been done. In Classic the organization of the extension modules was somewhat haphazard and chaotic. For example there were 5 separate modules whose contents were loaded into the main "wx" package namespace and several others that needed to be imported separately. However since there was not much organization of the core the C++ wxadv and wxhtml DLLs would need to be distributed with any applications built with a bundling tool even if the application did not use any of those classes.
For Phoenix the location of the wrapper code for the classes and functions will attempt to follow the same organization that wxWidgets uses for putting those same classes and functions into DLLs or shared libraries. This means that some things that were formerly in the core wx package namespace are no longer there. They will have to be used by importing a wx sumbodule. Most of them will be in the wx.adv module. Once nice advantage of doing this is that if your application is not using any of these lesser used classes then you will not have to bundle the new modules (nor the associated wx DLLs) with your application when you use py2exe or other executable builder.
"""
--
Robin Dunn
Software Craftsman
Hi Robin,
A little typo.
...
For Phoenix the location of the wrapper code for the classes and functions will attempt to follow the same organization that wxWidgets uses for putting those same classes and functions into DLLs or shared libraries. This means that some things that were formerly in the core wx package namespace are no longer there. They will have to be used by importing a wx sumbodule. Most of them will be in the wx.adv module. Once nice advantage of doing this is that if your application is not using any of these lesser used classes then you will not have to bundle the new modules (nor the associated wx DLLs) with your application when you use py2exe or other executable builder.
sumbodule > submodule
Werner
On 26/05/2012 23:54, Robin Dunn wrote:
Thanks.
On 5/26/12 11:24 PM, Werner wrote:
Hi Robin,
A little typo.
On 26/05/2012 23:54, Robin Dunn wrote:
...For Phoenix the location of the wrapper code for the classes and
functions will attempt to follow the same organization that wxWidgets
uses for putting those same classes and functions into DLLs or shared
libraries. This means that some things that were formerly in the core
wx package namespace are no longer there. They will have to be used by
importing a wx sumbodule. Most of them will be in the wx.adv module.
Once nice advantage of doing this is that if your application is not
using any of these lesser used classes then you will not have to
bundle the new modules (nor the associated wx DLLs) with your
application when you use py2exe or other executable builder.sumbodule > submodule
--
Robin Dunn
Software Craftsman
Robin,
Robin,
Andrea,
I noticed that classes and functions from the wx.adv module are showing
up
in the main part of the docs as ClassName instead of in a adv section
like
what is happening for dataview. What do we need to do to set things up
so
wx.adv items are separated from the core and such?I don't expect it to be very complicated, I'll take a look at it right
now.I didn't initially implement it as "adv" in the docs for two reasons:
we have never had a "wx.adv" sub-package before and there is nothing
really "advanced" about wx.SplashScreen or wx.TaskBarIcon."Advanced" really isn't a very good name for it. It's actually used for
things that depend on core but that are used less frequently and so are good
candidates for excluding in applications that do not need them, in order to
save memory, installer size, etc. There is a section in the MigrationGuide
about this and the reasons for basically following the structure of the wx
libraries. I'll paste it[1] below.Uhm, no, I'll backtrack here. It is going to get complicated and, most
importantly, ugly in the sphinxgenerator code. One things I do not
understand: is wx.SplashScreen (or any other "adv" stuff) going to be
defined as wx.adv.SplashScreen in the documentation?It would be nice if we could. Or at least have some notation in the
SplashScreen's class documentation that this class is located in the wx.adv
module. For example either using "wx.adv.SplashScreen" for the title at the
top of the page, or having something like "Module: wx.adv" line near the
top.How about
parameter kind (i.e., is "wxGridSelectionModes" going to be defined as
wx.adv.GridSelectionModes or wx.adv.grid.GridSelectionModes or
something else?).That is not a good example since it is an enum (and so from Python it is
really just an integer) and also because it's defined inside the Grid class
so the enum values will always be referenced via the class. However I do
understand the gist of your question. I think if we're able to show the
module where the class or enum is located on its page then it is probably
okay to use just the base name when referring to it elsewhere.I believe the Sphinx documentation should follow the wxPython module
structure, not an unspecified (and flawed) wxWidgets definition of
what "wxAdvanced" should be.The point is that the Classic wxPython module structure was flawed, and the
wxPython Phoenix module structure is going to more or less follow the wx DLL
organization. So having the Sphinx documentation follow the wxPython
(phoenix) module structure is essentially the same as following the
wxWidgets definition.If you're telling me that from now on
wx.grid.Grid and wx.calendar.CalendarCtrl will be addressed as
"wx.adv.Grid" and "wx.adv.CalendarCtrl", then we may have a problem
I think Grid will still have its own module since it is so big, but yes
CalendarCtrl is in wx.adv already.
If the wxPython structure has changed so much, then there is going to
be quite some refactoring of code to do amongst the wxPython
developers.
But I'll take your point on board, and I'll modify somehow the
sphinx_generator to handle such modifications.
BTW, you can use the ModulfDef.module attribute while the sphinx_generator
is running to get the name of the extension module where the items in that
etg script are being put. The current possibilities are "_core", "_adv" and
"_dataview" but there are going to be more, (I currently have plans for
_grid, _html, _html2, _richtext, _stc, _propgrid, _xrc, _gl, and _msw).
Using that attribute when the generator is running you should be able to
record which module each of the items will be located in and then either use
that in the source .txt files and/or while post-processing before running
sphinx. Does that make sense or am I missing something?
It will probably work, up to a point. It's relatively easy to refer to
the ModuleDef.module property of a class while that same class is
being analysed for docstrings, it is less easy when there are
cross-references between classes (i.e., hyperlinks in the wxWidgets
docs pointing to other classes or other methods in other classes) as
every single "class container" is analysed independently on a separate
process (i.e., splash.py in etg/ runs standalone and it contains only
wx.SplashScreen, listctr.py runs standalone and it contains a bunch of
stuff and so on).
I'll probably have to go and __import__ all the etg/ files at the
beginning in order to make the sphinx_generator aware of what class
belong to what library.
You caught me on a long Danish week-end (it's public holiday today),
but I'll see what I can do in the next few days.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 26 May 2012 23:54, Robin Dunn wrote:
On 5/26/12 1:12 PM, Andrea Gavana wrote:
On 26 May 2012 21:37, Andrea Gavana wrote:
On 26 May 2012 00:31, Robin Dunn wrote:
If the wxPython structure has changed so much, then there is going to
be quite some refactoring of code to do amongst the wxPython
developers.
While maintaining compatibility is highly desirable, it is not the highest priority for Phoenix. Project Phoenix is all about doing things better than before and creating that which wxPython should have been if the technology used and my inexperience at the time had allowed for it, even if that means sacrificing some backwards compatibility. As they say, hindsight is 20/20 and I'm trying to use that more perfect hindsight to create better vision for the future too.
BTW, you can use the ModulfDef.module attribute while the sphinx_generator
is running to get the name of the extension module where the items in that
etg script are being put. The current possibilities are "_core", "_adv" and
"_dataview" but there are going to be more, (I currently have plans for
_grid, _html, _html2, _richtext, _stc, _propgrid, _xrc, _gl, and _msw).
Using that attribute when the generator is running you should be able to
record which module each of the items will be located in and then either use
that in the source .txt files and/or while post-processing before running
sphinx. Does that make sense or am I missing something?It will probably work, up to a point. It's relatively easy to refer to
the ModuleDef.module property of a class while that same class is
being analysed for docstrings, it is less easy when there are
cross-references between classes (i.e., hyperlinks in the wxWidgets
docs pointing to other classes or other methods in other classes) as
every single "class container" is analysed independently on a separate
process (i.e., splash.py in etg/ runs standalone and it contains only
wx.SplashScreen, listctr.py runs standalone and it contains a bunch of
stuff and so on).I'll probably have to go and __import__ all the etg/ files at the
beginning in order to make the sphinx_generator aware of what class
belong to what library.
Could you update a db file or a pickled data structure of some sort as each etg script is run, and then refer to that information when you need it again later? There might be times when a class's info isn't recorded yet while other etg scripts still haven't run for the first time (although I try to keep them in dependency order) but once the etg scripts have all run then it should all be there, and IIUC you can probably take care of it in some post-processing in addition to that already being done.
I don't know if it would be any better than the above but something else that you might be able to use is the generated .pi files. These are created for tools like WingIDE so they have something to examine and introspect as Python code rather than having to settle for not enough information able to be gleaned from extension modules. So they basically have some Python stubs for every class, function and constant in the real .py/.pyd files, even that which is in the extension module. Again you may have chicken/egg problems, but it would be an easy way to find out which module a class is located in. (if "class %s" % className in piFileText:...)
On 5/28/12 12:09 PM, Andrea Gavana wrote:
--
Robin Dunn
Software Craftsman
Robin,
It will probably work, up to a point. It's relatively easy to refer to
the ModuleDef.module property of a class while that same class is
being analysed for docstrings, it is less easy when there are
cross-references between classes (i.e., hyperlinks in the wxWidgets
docs pointing to other classes or other methods in other classes) as
every single "class container" is analysed independently on a separate
process (i.e., splash.py in etg/ runs standalone and it contains only
wx.SplashScreen, listctr.py runs standalone and it contains a bunch of
stuff and so on).I'll probably have to go and __import__ all the etg/ files at the
beginning in order to make the sphinx_generator aware of what class
belong to what library.Could you update a db file or a pickled data structure of some sort as each
etg script is run, and then refer to that information when you need it again
later? There might be times when a class's info isn't recorded yet while
other etg scripts still haven't run for the first time (although I try to
keep them in dependency order) but once the etg scripts have all run then it
should all be there, and IIUC you can probably take care of it in some
post-processing in addition to that already being done.I don't know if it would be any better than the above but something else
that you might be able to use is the generated .pi files. These are created
for tools like WingIDE so they have something to examine and introspect as
Python code rather than having to settle for not enough information able to
be gleaned from extension modules. So they basically have some Python stubs
for every class, function and constant in the real .py/.pyd files, even that
which is in the extension module. Again you may have chicken/egg problems,
but it would be an easy way to find out which module a class is located in.
(if "class %s" % className in piFileText:...)
I believe I have got it working, you can check the main hyperlinks at
the bottom of this page:
http://xoomer.virgilio.it/infinity77/Phoenix/main.html
And maybe navigate through the "adv" sub-package from there.
One thing I believe we still haven't fully considered is what we are
going to do with wx.lib and its children... are we going to maintain a
single version and making it Python 2 and Python 3 compatible or are
we going to split it in two separate versions? Anyone care to share
some thoughts on this issue?
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 28 May 2012 21:44, Robin Dunn wrote:
On 5/28/12 12:09 PM, Andrea Gavana wrote:
I believe I have got it working, you can check the main hyperlinks at
the bottom of this page:http://xoomer.virgilio.it/infinity77/Phoenix/main.html
And maybe navigate through the "adv" sub-package from there.
Thanks Andrea, it's looking good. Is there a file or something I need to edit when I add new modules to the list to let the tools know they need to apply the same treatment for the new module? Or is it more involved than that?
One thing I believe we still haven't fully considered is what we are
going to do with wx.lib and its children... are we going to maintain a
single version and making it Python 2 and Python 3 compatible or are
we going to split it in two separate versions? Anyone care to share
some thoughts on this issue?
Actually I had started working on an email to ask for experiences or opinions about this myself. Here are the issues as I seem them, and some related ones too.
* First of all, this is probably obvious but just to be complete for this wx.lib discussion: I am not planning on trying to share wx.lib code for Classic and Phoenix. The API changes and such already mentioned will make this more effort than it is worth. Instead I'll do a svn copy (so the revision history is preserved) from the classic tree to the Phoenix source tree.
* Even if we stick with a minimum 2.x version of 2.7 (where the most compatibility aids have been added) there are still some things that can not be done when sharing the code because they will be syntax errors in one or the other flavor of Python. Since syntax is verified before the code in a module even starts executing then a syntax error will derail the import before we even have a chance to do anything about it. For example, using the u prefix on string constants (such as u"some text") is a syntax error in Python 3.2. So trying to keep both the python2- and the python3-compatible code in the same file will be tricky because in cases like that just doing conditionals is not enough.
* Duplicating and maintaining 2 sets of all the lib modules will be a major hassle too. It will take twice the work to fix a bug or add an enhancement, and there is the risk that if updating the copy is not done for some issue that the functionality could start to diverge.
So what other options are there? Here are a couple I have thought of:
* Maintain the modules for Python2 but write the code such that the 2to3 tool (plus perhaps some extra scripts of our own) will produce code for Python3 without needing any help from a human, and then automatically run those tools as needed to produce the Python3 version of the code. This has some advantages in that there will still be only one master copy of the code that needs to be maintained, but some disadvantages as well in that the conversion tools need to be rock-solid and be trusted to not produce bugs of their own in the code they produce.
* My other idea is sort of a hybrid approach where those modules that can be implemented for both Python2 and Python3 without many hassles and/or many conditionals checking the Python version are implemented as a single module. Other modules will have 2 implementations, each with the Python version embedded in the file name somehow, for example foomodule-py2.py and foomodule-py3.py. Then an import hook can be written and used that will watch for imports inside the wx package and will check first for the file name with verisoning in the name and will load that one if it is present, and will fall back to the normally named module if not. There may be some cases where a bit of refactoring will allow us to keep most of the code in a single non-versioned file and just move a few things out to a helper module that has -py2 and -py3 versions. For example foomodule.py, _foo_helper-py2.py and _foo_helper-py3.py
Has anybody seen approaches like these or something else being used by other projects?
While on the subject I've been thinking that I would discontinue the use of the 3rdParty folder in SVN for a couple reasons:
* There is probably going to need to be a new location for them anyway because of the Classic --> Phoenix differences.
* The svn:externals properties are basically ignored when using some other tool like git or mercurial as a front-end for subversion, and that makes it a major hassle keeping the external items in the proper place in the source tree and also keeping them up to date and making commits for them.
I think I've mentioned this before but I'm also planning on not including the Editra and XRCed packages in the wx.tools package any longer, as the original idea of making them (and others) into reusable components never came to pass. They're better as standalone applications so I think it is best to organize the code that way. I expect that I'll still include a launcher for at least XRCed in the distribution installers though. (Editra already has a good website and installer distribution.)
If you have any thoughts, objections, or better ideas for any of the above please speak up and let us know.
On 5/29/12 1:21 PM, Andrea Gavana wrote:
--
Robin Dunn
Software Craftsman
I believe I have got it working, you can check the main hyperlinks at
the bottom of this page:http://xoomer.virgilio.it/infinity77/Phoenix/main.html
And maybe navigate through the "adv" sub-package from there.
Thanks Andrea, it's looking good. Is there a file or something I need to
edit when I add new modules to the list to let the tools know they need to
apply the same treatment for the new module? Or is it more involved than
that?
No nothing special really, everything is handled by looking at the etg
files at the very beginning, and it worked smoothly at the first try
except for DatePickerCtrlGeneric and GenericCalendarCtrl, which are
explicitly handled in the `constants.py` module. Other than that, I
have just re-run it with the latest modifications you have made
(adding sashwin.py and laywin.py) and it runs without problems.
One thing I believe we still haven't fully considered is what we are
going to do with wx.lib and its children... are we going to maintain a
single version and making it Python 2 and Python 3 compatible or are
we going to split it in two separate versions? Anyone care to share
some thoughts on this issue?Actually I had started working on an email to ask for experiences or
opinions about this myself. Here are the issues as I seem them, and some
related ones too.* First of all, this is probably obvious but just to be complete for this
wx.lib discussion: I am not planning on trying to share wx.lib code for
Classic and Phoenix. The API changes and such already mentioned will make
this more effort than it is worth. Instead I'll do a svn copy (so the
revision history is preserved) from the classic tree to the Phoenix source
tree.* Even if we stick with a minimum 2.x version of 2.7 (where the most
compatibility aids have been added) there are still some things that can not
be done when sharing the code because they will be syntax errors in one or
the other flavor of Python. Since syntax is verified before the code in a
module even starts executing then a syntax error will derail the import
before we even have a chance to do anything about it. For example, using
the u prefix on string constants (such as u"some text") is a syntax error in
Python 3.2. So trying to keep both the python2- and the python3-compatible
code in the same file will be tricky because in cases like that just doing
conditionals is not enough.* Duplicating and maintaining 2 sets of all the lib modules will be a major
hassle too. It will take twice the work to fix a bug or add an enhancement,
and there is the risk that if updating the copy is not done for some issue
that the functionality could start to diverge.So what other options are there? Here are a couple I have thought of:
* Maintain the modules for Python2 but write the code such that the 2to3
tool (plus perhaps some extra scripts of our own) will produce code for
Python3 without needing any help from a human, and then automatically run
those tools as needed to produce the Python3 version of the code. This has
some advantages in that there will still be only one master copy of the code
that needs to be maintained, but some disadvantages as well in that the
conversion tools need to be rock-solid and be trusted to not produce bugs of
their own in the code they produce.* My other idea is sort of a hybrid approach where those modules that can be
implemented for both Python2 and Python3 without many hassles and/or many
conditionals checking the Python version are implemented as a single module.
Other modules will have 2 implementations, each with the Python version
embedded in the file name somehow, for example foomodule-py2.py and
foomodule-py3.py. Then an import hook can be written and used that will
watch for imports inside the wx package and will check first for the file
name with verisoning in the name and will load that one if it is present,
and will fall back to the normally named module if not. There may be some
cases where a bit of refactoring will allow us to keep most of the code in a
single non-versioned file and just move a few things out to a helper module
that has -py2 and -py3 versions. For example foomodule.py,
_foo_helper-py2.py and _foo_helper-py3.pyHas anybody seen approaches like these or something else being used by other
projects?While on the subject I've been thinking that I would discontinue the use of
the 3rdParty folder in SVN for a couple reasons:* There is probably going to need to be a new location for them anyway
because of the Classic --> Phoenix differences.* The svn:externals properties are basically ignored when using some other
tool like git or mercurial as a front-end for subversion, and that makes it
a major hassle keeping the external items in the proper place in the source
tree and also keeping them up to date and making commits for them.I think I've mentioned this before but I'm also planning on not including
the Editra and XRCed packages in the wx.tools package any longer, as the
original idea of making them (and others) into reusable components never
came to pass. They're better as standalone applications so I think it is
best to organize the code that way. I expect that I'll still include a
launcher for at least XRCed in the distribution installers though. (Editra
already has a good website and installer distribution.)If you have any thoughts, objections, or better ideas for any of the above
please speak up and let us know.
I have taken a look at what PyGTK and PyQT/PySide have done for Python
3, but these libraries seem to be rather different from wxPython when
it comes to third-party (i.e., wx.lib) widgets. Maybe I just don't
know how to look for information in that sense. I am a bit undecided,
but I tend to lean towards the Python2 + 2to3 + custom scripts
approach.
I may even give AGW a try in this sense, if you think the Phoenix
binaries are mature enough to try and do that.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 30 May 2012 02:03, Robin Dunn wrote:
On 5/29/12 1:21 PM, Andrea Gavana wrote:
Hey Robin,
I believe I have got it working, you can check the main hyperlinks at
the bottom of this page:http://xoomer.virgilio.it/infinity77/Phoenix/main.html
And maybe navigate through the "adv" sub-package from there.
Thanks Andrea, it's looking good. Is there a file or something I need to edit when I add new modules to the list to let the tools know they need to apply the same treatment for the new module? Or is it more involved than that?
One thing I believe we still haven't fully considered is what we are
going to do with wx.lib and its children... are we going to maintain a
single version and making it Python 2 and Python 3 compatible or are
we going to split it in two separate versions? Anyone care to share
some thoughts on this issue?Actually I had started working on an email to ask for experiences or opinions about this myself. Here are the issues as I seem them, and some related ones too.
* First of all, this is probably obvious but just to be complete for this wx.lib discussion: I am not planning on trying to share wx.lib code for Classic and Phoenix. The API changes and such already mentioned will make this more effort than it is worth. Instead I'll do a svn copy (so the revision history is preserved) from the classic tree to the Phoenix source tree.
* Even if we stick with a minimum 2.x version of 2.7 (where the most compatibility aids have been added) there are still some things that can not be done when sharing the code because they will be syntax errors in one or the other flavor of Python. Since syntax is verified before the code in a module even starts executing then a syntax error will derail the import before we even have a chance to do anything about it. For example, using the u prefix on string constants (such as u"some text") is a syntax error in Python 3.2. So trying to keep both the python2- and the python3-compatible code in the same file will be tricky because in cases like that just doing conditionals is not enough.
* Duplicating and maintaining 2 sets of all the lib modules will be a major hassle too. It will take twice the work to fix a bug or add an enhancement, and there is the risk that if updating the copy is not done for some issue that the functionality could start to diverge.
FWIW, in my experience, this would be the most problematic of all approaches. Without doubt, one copy of the codebase will gain primacy, while the other will be at best ignored, and at worst, sometimes changes won't be ported over mistakenly. As a practical matter, this will steer users to the better-maintained codebase, which will in turn hinder adoption of the new thing, and that cycle will likely continue until we do something like cut the cord on the Python 2 code.
So what other options are there? Here are a couple I have thought of:
* Maintain the modules for Python2 but write the code such that the 2to3 tool (plus perhaps some extra scripts of our own) will produce code for Python3 without needing any help from a human, and then automatically run those tools as needed to produce the Python3 version of the code. This has some advantages in that there will still be only one master copy of the code that needs to be maintained, but some disadvantages as well in that the conversion tools need to be rock-solid and be trusted to not produce bugs of their own in the code they produce.
* My other idea is sort of a hybrid approach where those modules that can be implemented for both Python2 and Python3 without many hassles and/or many conditionals checking the Python version are implemented as a single module. Other modules will have 2 implementations, each with the Python version embedded in the file name somehow, for example foomodule-py2.py and foomodule-py3.py. Then an import hook can be written and used that will watch for imports inside the wx package and will check first for the file name with verisoning in the name and will load that one if it is present, and will fall back to the normally named module if not. There may be some cases where a bit of refactoring will allow us to keep most of the code in a single non-versioned file and just move a few things out to a helper module that has -py2 and -py3 versions. For example foomodule.py, _foo_helper-py2.py and _foo_helper-py3.py
Has anybody seen approaches like these or something else being used by other projects?
No, but I do have another idea. Use git and store the Python 3 changes on a git branch. So your Py 2 code is in your master branch, then you create a branch to hold all the Py 3 specific changes and switch to that when producing your Python 3 build.
This would allow you to keep one version of the code, and once the changes are done, if you do find that most of the changes are Py 2 compatible and that it would not be much work to make the code compatible with both Pythons, you have the option of merging the code into the master branch. That way, you can leave the final decision on what to do about splitting wx.lib to the moment when you have all the data you need to make the decision about what is best.
Having stored changes to wxWebKit that were 100K+ for months, and having almost all the merge conflicts being real ones that needed dealt with, I can say that it works pretty well, even over the long haul.
While on the subject I've been thinking that I would discontinue the use of the 3rdParty folder in SVN for a couple reasons:
* There is probably going to need to be a new location for them anyway because of the Classic --> Phoenix differences.
* The svn:externals properties are basically ignored when using some other tool like git or mercurial as a front-end for subversion, and that makes it a major hassle keeping the external items in the proper place in the source tree and also keeping them up to date and making commits for them.
I think I've mentioned this before but I'm also planning on not including the Editra and XRCed packages in the wx.tools package any longer, as the original idea of making them (and others) into reusable components never came to pass. They're better as standalone applications so I think it is best to organize the code that way. I expect that I'll still include a launcher for at least XRCed in the distribution installers though. (Editra already has a good website and installer distribution.)
I do think tying specific versions of Editra to specific wxPython releases doesn't work well, though. I think it should have its own releases and just be easily retrievable when doing wxPython downloads. i.e. there should be a wxPython-tools package or wxPython-IDE.
If we can do eggs or something, is it possible to have wxpython-runtime, wxpython-docs, wxpython-demo, wxpython-tools, and most importantly, wxpython-all?
Thanks,
Kevin
On May 29, 2012, at 5:03 PM, Robin Dunn wrote:
On 5/29/12 1:21 PM, Andrea Gavana wrote:
From my perspective, the whole idea of bundling Editra and XRCed was to give users some good out-of-the-box tools they can use to develop wxPython apps. The wxPython Demo does a lot to help users get started (the ones who download the package, anyway…), but new wxPython developers are always faced with a simple question of "what should I use to develop my app?" If they go to the mailing list for help, they then typically get at least 10 suggestions, of just about everything from Notepad to emacs. 
And I think from a getting started perspective, if Step 1 is "spend a couple days looking at a bunch of editors", whereas with another tool, it's "download the IDE and start hacking", I think a lot of people will be drawn to that other tool. Plus, I think it's a good advertisement that wxPython uses wxPython apps to develop wxPython apps.
If you have any thoughts, objections, or better ideas for any of the above please speak up and let us know.
--
Robin Dunn
Software Craftsman
http://wxPython.org--
To unsubscribe, send email to wxPython-dev+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-dev?hl=en
Yes, most of the basics are there already.
On 5/30/12 12:32 AM, Andrea Gavana wrote:
I may even give AGW a try in this sense, if you think the Phoenix
binaries are mature enough to try and do that.
--
Robin Dunn
Software Craftsman
Good to know
One thing though, it appears to me that the snapshot builds are only
for Python 2.7. What should I do in order to setup my computer to
build Phoenix against Python 3? I know about the Visual Studio
requirements, but is there any other thing I should install/setup in
order to build from source?
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 30 May 2012 19:35, Robin Dunn wrote:
On 5/30/12 12:32 AM, Andrea Gavana wrote:
I may even give AGW a try in this sense, if you think the Phoenix
binaries are mature enough to try and do that.Yes, most of the basics are there already.
Hey Robin,
While on the subject I've been thinking that I would discontinue the use of the 3rdParty folder in SVN for a couple reasons:
* There is probably going to need to be a new location for them anyway because of the Classic --> Phoenix differences.
* The svn:externals properties are basically ignored when using some other tool like git or mercurial as a front-end for subversion, and that makes it a major hassle keeping the external items in the proper place in the source tree and also keeping them up to date and making commits for them.
I think I've mentioned this before but I'm also planning on not including the Editra and XRCed packages in the wx.tools package any longer, as the original idea of making them (and others) into reusable components never came to pass. They're better as standalone applications so I think it is best to organize the code that way. I expect that I'll still include a launcher for at least XRCed in the distribution installers though. (Editra already has a good website and installer distribution.)
From my perspective, the whole idea of bundling Editra and XRCed was to give users some good out-of-the-box tools they can use to develop wxPython apps. The wxPython Demo does a lot to help users get started (the ones who download the package, anyway…), but new wxPython developers are always faced with a simple question of "what should I use to develop my app?" If they go to the mailing list for help, they then typically get at least 10 suggestions, of just about everything from Notepad to emacs.
I must say I do agree on this one
Having Editra readily available (or easily installable as Kevin
suggested below) is a huge plus. It's a very good editor and I find
myself using it more and more, slowly getting away from PythonWin and
TextPad. But I agree with Kevin that giving new users ready access to
such a nice tool will boost the whole "wxPython experience".
On the other hand, Editra is a one-man project. I am not sure how
complicated it will be to port it to Python 3 (and I imagine it won't
be easy); we don't even know if Cody has actually time to do that. So,
maybe at the beginning Phoenix for Python 3 may not have a
"batteries-included" editor; nonetheless, I still believe it's worth
tying Editra to wxPython (maybe through a compromised solution using
eggs, as Kevin mentioned, if this is a technically feasible solution).
Just my 2c.
I do think tying specific versions of Editra to specific wxPython releases doesn't work well, though. I think it should have its own releases and just be easily retrievable when doing wxPython downloads. i.e. there should be a wxPython-tools package or wxPython-IDE.
If we can do eggs or something, is it possible to have wxpython-runtime, wxpython-docs, wxpython-demo, wxpython-tools, and most importantly, wxpython-all?
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 30 May 2012 17:57, Kevin Ollivier wrote:
On May 29, 2012, at 5:03 PM, Robin Dunn wrote:
I may even give AGW a try in this sense, if you think the Phoenix
binaries are mature enough to try and do that.Yes, most of the basics are there already.
Good to know
One thing though, it appears to me that the snapshot builds are only
for Python 2.7.
Yep, so far. We'll start getting some 3.2 snapshots too once some buildbot slaves are set up for them.
What should I do in order to setup my computer to
build Phoenix against Python 3? I know about the Visual Studio
requirements, but is there any other thing I should install/setup in
order to build from source?
I think you should probably already have everything else that you need since you are able run the etg scripts and build the docs. The build.py tool will download a sip binary (and will also update it when I switch to new versions) so if you also have Visual Studio 2008 then I think you should be good to go. Just make sure that the cl.exe executable is on the PATH and that the link.exe found first on the PATH is the one from VisualStudio and not the one from cygwin. I don't remember for sure but some of the command line tools like nmake may be an optional part of the install for Visual Studio, so you may want to double check that.
Currently the "build" command in build.py will run both the build_wx command (which builds wx widgets) and the setup_py command (which will build Phoenix using setup.py.) There is also a new build command available for building Phoenix called "waf_py" which uses the waf tool instead of setup.py. It doesn't support installs yet which is why I haven't switched it to be the default, but since you can run in-place after the build using the Phoenix/wx dir as your wx package there hasn't been a strong need for duplicating install and other distutils commands yet. Anyway, building with waf is lots faster[1] because it can do parallel builds (build.py defaults to 1 build job per processor core) and it will do better dependency checking and skip recompiling files that don't need to be rebuilt. Build.py will download a copy of waf automatically if you run this command so you don't need to worry about installing anything and keeping it up to date, just like the sip binary. To use it use the "build_wx waf_py" commands with build.py instead of just "build".
[1] WAF reduces the full rebuild compile time of the Phoenix binaries on one of my computers from about 45 minutes to about 5-10.
On 5/30/12 12:37 PM, Andrea Gavana wrote:
On 30 May 2012 19:35, Robin Dunn wrote:
On 5/30/12 12:32 AM, Andrea Gavana wrote:
--
Robin Dunn
Software Craftsman
Hi,
Hey Robin,
While on the subject I've been thinking that I would discontinue the use of the 3rdParty folder in SVN for a couple reasons:
* There is probably going to need to be a new location for them anyway because of the Classic --> Phoenix differences.
* The svn:externals properties are basically ignored when using some other tool like git or mercurial as a front-end for subversion, and that makes it a major hassle keeping the external items in the proper place in the source tree and also keeping them up to date and making commits for them.
I think I've mentioned this before but I'm also planning on not including the Editra and XRCed packages in the wx.tools package any longer, as the original idea of making them (and others) into reusable components never came to pass. They're better as standalone applications so I think it is best to organize the code that way. I expect that I'll still include a launcher for at least XRCed in the distribution installers though. (Editra already has a good website and installer distribution.)
From my perspective, the whole idea of bundling Editra and XRCed was to give users some good out-of-the-box tools they can use to develop wxPython apps. The wxPython Demo does a lot to help users get started (the ones who download the package, anyway…), but new wxPython developers are always faced with a simple question of "what should I use to develop my app?" If they go to the mailing list for help, they then typically get at least 10 suggestions, of just about everything from Notepad to emacs.
I must say I do agree on this one
Having Editra readily available (or easily installable as Kevin
suggested below) is a huge plus. It's a very good editor and I find
myself using it more and more, slowly getting away from PythonWin and
TextPad. But I agree with Kevin that giving new users ready access to
such a nice tool will boost the whole "wxPython experience".On the other hand, Editra is a one-man project. I am not sure how
complicated it will be to port it to Python 3 (and I imagine it won't
be easy); we don't even know if Cody has actually time to do that. So,
maybe at the beginning Phoenix for Python 3 may not have a
"batteries-included" editor; nonetheless, I still believe it's worth
tying Editra to wxPython (maybe through a compromised solution using
eggs, as Kevin mentioned, if this is a technically feasible solution).
My time has unfortunately been quite limited the last year+ due to
various pressures at work 
. After four years of work we may be
shipping in July though which should hopefully free up some time for
me again. (until the next series of 'emergencies' come up anyway...)
I had done some high level cursory sweeps 1 or 2 years ago with the
python 3 warnings turned on to prepare some things for Python 3
support. Though, since I have not felt much need or desire to use
Python3 as of yet so I am not entirely familiar with any stdlib
changes that may be in conflict so would need to test when builds are
available.
Cody
On Wed, May 30, 2012 at 3:07 PM, Andrea Gavana <andrea.gavana@gmail.com> wrote:
On 30 May 2012 17:57, Kevin Ollivier wrote:
On May 29, 2012, at 5:03 PM, Robin Dunn wrote:
And it looks like u"" will be coming back in Python 3.3... It doesn't actually do anything of course, other than not issue a SyntaxError exception.
On 5/29/12 5:03 PM, Robin Dunn wrote:
On 5/29/12 1:21 PM, Andrea Gavana wrote:
For
example, using the u prefix on string constants (such as u"some text")
is a syntax error in Python 3.2.
--
Robin Dunn
Software Craftsman
and couldn't we use:
from __future__ import unicode_literals
in 2.7 anyway?
-Chris
On Wed, May 30, 2012 at 5:13 PM, Robin Dunn <robin@alldunn.com> wrote:
On 5/29/12 5:03 PM, Robin Dunn wrote:
On 5/29/12 1:21 PM, Andrea Gavana wrote:
For
example, using the u prefix on string constants (such as u"some text")
is a syntax error in Python 3.2.And it looks like u"" will be coming back in Python 3.3... It doesn't
actually do anything of course, other than not issue a SyntaxError
exception.
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Hi,
On Thu, May 31, 2012 at 10:59 AM, Chris Barker <chris.barker@noaa.gov> wrote:
On Wed, May 30, 2012 at 5:13 PM, Robin Dunn <robin@alldunn.com> wrote:
On 5/29/12 5:03 PM, Robin Dunn wrote:
On 5/29/12 1:21 PM, Andrea Gavana wrote:
For
example, using the u prefix on string constants (such as u"some text")
is a syntax error in Python 3.2.And it looks like u"" will be coming back in Python 3.3... It doesn't
actually do anything of course, other than not issue a SyntaxError
exception.and couldn't we use:
from __future__ import unicode_literals
in 2.7 anyway?
Yes, if one wants to go through hundreds of thousands of lines of code
and remove the 'u' prefix from all strings using it. 3.3 sounds like
it will just ignore the 'u' so now instead of a syntax error it will
just be a regular unicode literal again.
Cody