Just upgraded to wx 2.8

wxPython Users
1

Unfortunately, that’s just in Python code, which is all the UI for what we’re up to (and sure, there’s logic in between, but it’s mostly UI stuff and most of that was generated with Boa and modified from there for additional logic and/or shortcomings in Boa). The rest is done in C, as you suggested.

Thank you for the link to the Boa upgrade tool. Unfortunately, it seemed to hang on the very first directory I gave it. Either that, or it is going to take a very long time on each directory (tool didn’t seem to have any option for recursing into subdirectories).

However, again, the question I ask is if upgrading my code is an actual show stopper. I understand that it gives warnings, but from what I can tell, looks like the wxPython module still exists in the wx library, which should maintain backward compatability, no?

Is this what is causing the problem I am having with py2exe?

In other words, the upgrade to a newer compatability is going to take a lot of work. In fact, I already swtiched the nomenclature from wxBLAH to wx.BLAH and then had to fix some specifics (like wx.grid, and then undoing a lot of the changes made to Boa code e.g. wxDialog1->wx.Dialog1). So, I’ve been moving forward on the new nomenclature, but I’m currently stuck on the Event stuff (which it looks like Boa might be able to handle, but I can’t get it to work)

I would image that backwards compatability would be a very high priority for whomever the powers-that-be who decide to update wxPython, right? If I go through this exercise, what’s to say that I won’t have to go through it again in 2 years when backwards compatability is again not maintained?

  • Aaron
···

From: Peter Damoc [mailto:pdamoc@gmail.com]
Sent: Wednesday, January 31, 2007 11:40 AM
To:
wxPython-users@lists.wxwidgets.org
Subject: Re: [wxPython-users] Just upgraded to wx 2.8

Hi Aaron,

maybe this will help:
http://wiki.wxpython.org/index.cgi/Boa040Upgrade

and… just in case you missed it… there is a deprecation warning:

  "The wxPython compatibility package is no longer automatically generated "
  "or activly maintained.  Please switch to the wx package as soon as possible.",

Do you have 225 kloc of UI code? That sounds huge. Don’t you have some kind of data/display separation? MVC/MVP and friends?

Peter

On 1/31/07, ** Aaron Rubin** <Aaron.Rubin@4dtechnology.com > wrote:

Hi Werner -

I'm having a hard time finding anything about a code converter from Boa.
Do you have a link?  I'm looking at about 225,000 lines of code in
Python, so the concept of changing all the code is a bit daunting.  Do
you suppose that's the problem that is causing this error?  Any reason
aside from just being more practical to switch from importing *?

Our build script also clears out the dist folder before it rebuilds,
although it actually deletes the entire dist folder.

Any other ideas?

> -----Original Message-----

From: Werner F. Bruhin [mailto:werner.bruhin@free.fr ]
Sent: Wednesday, January 31, 2007 2:07 AM
To: wxPython-users@lists.wxwidgets.org
Subject: Re: [wxPython-users] Just upgraded to wx 2.8

Hi Aaron,

Aaron Rubin wrote:

I am using py2exe (version 0.6.6) along with Python 2.4 and
wxPython
2.8. I was using wxPython 2.6 before.

I can run my application just fine from Wing IDE, but when
I build it
using py2exe, I get the following error

AttributeError: ‘module’ object has no attribute ‘build’

This happens on the line of code:

from wx import *
One you should no longer use this type of import, change it to:

import wx

And make corresponding changes in your code (e.g. wxFrame
becomes wx.Frame etc), if there is a lot of code you might
want to look at Boa’s
2.4 to 2.5/2.6 code converter - it converts a lot of the code
but there are still some things you might have to do manually.

Allows when you change e.g. Python, or wxPython you should
clear the dist folder of py2exe, I just include the following
code in my setup.py.

cleanup dist and build directory first (for new py2exe

version) if os.path.exists(“dist/prog”):
shutil.rmtree(“dist/prog”)

if os.path.exists(“dist/lib”):
shutil.rmtree(“dist/lib”)

if os.path.exists(“build”):
shutil.rmtree(“build”)

Hope this helps
Werner

I have noticed that the module ‘build’ is relatively new, so maybe
something is cached somewhere?

Any idears? Thanks!

  • Aaron Rubin

–

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.17/661 - Release Date:
30/01/2007 23:30

To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org

---------------------------------------------------------------------

To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

–
There is NO FATE, we are the creators.

2

Hi Aaron,

Aaron Rubin wrote:

Unfortunately, that's just in Python code, which is all the UI for what we're up to (and sure, there's logic in between, but it's mostly UI stuff and most of that was generated with Boa and modified from there for additional logic and/or shortcomings in Boa). The rest is done in C, as you suggested.

What version of Boa do you have? With 2.8 you should use the latest from CVS which is 0.5.2 and the code converter is under the Tools menu (last item). It should do a pretty good job for all your Boa generated code as that is what we had concentrated on, manually created wxPython might or might not get converted.

We don't handle sub-directories and if you convert a directory it creates a new directory with the upgraded code. If the directory contains a lot of files and/or large files it will take some time - but I am sure it is still faster then doing it by hand.

Also don't feed it new and old code, I don't think that will work correctly.

If you have problems with please post to the Boa list on gmane (preferably with the file/folder causing the problem).

You are four versions behind with your upgrade :wink: , i.e. one should have upgraded to the new name space with 2.5 or at least 2.6.

Werner

3

I would image that backwards compatability would be a very high priority for whomever the powers-that-be who decide to update wxPython, right? If I go through this exercise, what’s to say that I won’t have to go through it again in 2 years when backwards compatability is again not maintained ?

I am not sure how much you have followed this but it really has very little to do with wx. It was basically a python-wide decision to stop importing *, and wx just followed along. Even a few years ago (in fact, probably always), people were warning of the dangers of importing * and saying never to do it, except in wx! So technically, wx has been maintaining backwards compatibility for a long time and as someone else mentioned this method of importing has been deprecated for quite a while.

The point is, wx didn’t just decide to do something different for the heck of it. The arguments against importing * just became too strong and the advantages of using namespaces became too apparent. This is a change you should be making if possible no matter what module/package you are using.

I hope this has helped to clear things up. If I have incorrectly stated anything hopefully someone else will chime in. Perhaps wx’s generousity in letting you avoid namespaces for so long has caused you more pain in the end :slight_smile: