wx.adv docs

[Robin Dunn]

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

[Andrea Gavana]

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. 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/

[Andrea Gavana]

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.

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
:-)

[Robin Dunn]

On 5/26/12 1:12 PM, Andrea Gavana wrote:
> 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.
>

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

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.

[Werner]

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

Werner

[Robin Dunn]

Thanks.

[Andrea Gavana]

Robin,

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.

[Robin Dunn]

On 5/28/12 12:09 PM, Andrea Gavana 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:...)

[Andrea Gavana]

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.

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?

[Robin Dunn]

On 5/29/12 1:21 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.

[Andrea Gavana]

On 30 May 2012 02:03, Robin Dunn wrote:
> On 5/29/12 1:21 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?

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.

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.

[Kevin Ollivier]

Hey Robin,

On May 29, 2012, at 5:03 PM, Robin Dunn wrote:

> On 5/29/12 1:21 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.

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.)

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. ;)

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

> 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...@googlegroups.com
> or visit http://groups.google.com/group/wxPython-dev?hl=en

[Robin Dunn]

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.

[Andrea Gavana]

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.

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

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?

[Robin Dunn]

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:
>>>
>>> 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.

[Cody]

Hi,

On Wed, May 30, 2012 at 3:07 PM, Andrea Gavana <andrea...@gmail.com> wrote:
> On 30 May 2012 17:57, Kevin Ollivier wrote:
>> Hey Robin,
>>
>> On May 29, 2012, at 5:03 PM, Robin Dunn wrote:
>>> 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. ;-) 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. ;)
>
> 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

[Robin Dunn]

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.

http://docs.python.org/dev/whatsnew/3.3.html

[Chris Barker]

On Wed, May 30, 2012 at 5:13 PM, Robin Dunn <ro...@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?

-Chris


--

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....@noaa.gov

[Cody]

Hi,

On Thu, May 31, 2012 at 10:59 AM, Chris Barker <chris....@noaa.gov> wrote:
> On Wed, May 30, 2012 at 5:13 PM, Robin Dunn <ro...@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

[Robin Dunn]

On 5/31/12 8:59 AM, Chris Barker wrote:
> On Wed, May 30, 2012 at 5:13 PM, Robin Dunn<ro...@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, but that is just one example. I'm pretty sure I ran into one or
two other things that were SyntaxErrors in one or the other Python
flavor when I was porting the build tools and the unittests, although I
don't remember exactly what they were. I was able to find workarounds
for those cases however, (which is why I don't remember them I suppose.)

[Andrea Gavana]

Which is what it should always have been. There was no point at the
start in removing the 'u' prefix. I wonder how many developers have
had to refactor their code to deal with this nonsense, and I can
imagine GUI frameworks were hit the most. We now get it back.

Funny situation though, for wx.lib and Editra and the other 3rd party
packages with a lot, *a lot* of unicode literals in them. Do we keep
them there and support Python 2.7 and 3.3+ (thus excluding 3.0, 3.1
and 3.2) or do we do something else?

That's a bit of a pity. I got Phoenix built with PortablePython 3.2
but I am not going to touch AGW if we can keep the 'u' stuff in. I'll
just wait for PortablePython 3.3 and for a (possibly) final decision
on what Python versions we are going to support.

[Chris Barker]

On Thu, May 31, 2012 at 9:51 AM, Cody <codyp...@gmail.com> wrote:
>> 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.

I agree that this is a good change, but at least removing the "u" is
automatable. (presumably 2to3 does it as well)

Andrea wrote:
> Do we keep
> them there and support Python 2.7 and 3.3+ (thus excluding 3.0, 3.1
> and 3.2) or do we do something else?

good point -- this _may_ be a reason to use the "from __future__
import unicode_literals" option, but as Robin mentions, unicode
literals are only one issue.

I imagine that in general 3.* users are more active an bleeding edge,
and thus supporting only 3.3+ may be OK. An by definition, anyone
going to 3.* with wxPython is new to 3.* anyway (at least for the GUI
portion of the code)

It is odd that the 'u' wasn't ignored in the first place. oh well.

[Robin Dunn]

On 5/31/12 1:45 PM, Chris Barker wrote:
>
> It is odd that the 'u' wasn't ignored in the first place. oh well.

I don't remember for sure but I think it was left in (and ignored) in
3.0 and 3.1, but was then removed in 3.2 assuming that nobody needed it
any more.

[DevPlayer]

On Friday, May 25, 2012 6:31:22 PM UTC-4, 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. -- Robin Dunn

 

I thought _core was for essentially "native" widgets and _adv was for non-native widgets?

 

Personally I'd love to see some note in the new web-docs of which widgets are native to which OSes.

like line "Native widget: MSWXP+, MacOS10+" etc.

 

For apps (like basic admin tools) that use only native widgets is certain a memory saver, as basically the wx core would mostly be Python signatures to operating system calls and generic initialization code no? TO me I'd expect _adv and non-_core to be groupings of native widgets into a new-non-native widget;

 

To me however I'd organize the code into "native", "common" and "advanced". Where common widgets are not native but are used "commonly" and  where advanced widgets would be something used often only in certain kinds of "apps like calendar widgets". To me this structure also lends itself to easier maintainability.

 

 

 

[Chris Barker]

On Fri, Jun 1, 2012 at 7:14 AM, DevPlayer <devp...@gmail.com> wrote:

> Personally I'd love to see some note in the new web-docs of which widgets
> are native to which OSes.
> like line "Native widget: MSWXP+, MacOS10+" etc.
>
> For apps (like basic admin tools) that use only native widgets is certain a
> memory saver, as basically the wx core would mostly be Python signatures to
> operating system calls and generic initialization code no?

well, python wrappers of C++ wrappers to OS calls -- not sure how big
those are, but maybe not so small (though smaller than a fully
wx-implemented widget, to be sure)

But it's nice to know what's a native widget and what's not in any case.