VB to Python migration

Thomas Ganss tganss_at_t_dash_online_dot_de-remove-all-after-first-real-dash at yahoo.com
Sat Jan 28 15:16:36 EST 2006

Josh schrieb:

You haven't specified where your main pains are.
Do you have at least rudimentary architecture ?
How often do you have code reviews / refactored your code ?
Have you been striving for good code ? Is it a total mess ?

Guessing only from the number of screens, you probably
have more than trivial amounts of data.

*Based on that assumption*, I'ld move the data FIRST.
Get rid of the JET engine! If you are certain you will
have to support SQL server, make it SQL server and
MSDE/new express version first. Only then (perhaps)
think about adding a totally free database engine.
If not, take your pick but *move the data*.

While you are on it, refactor the old code into something
at least resembling a 3 to 5 layered approach with COM.
Doesn't need to be perfect 100%, but more than 50%.

Then exchange the parts that benefit the most by
implementation inheritance, since VB's interface inheritance
is arguably the "best" technical reason for redundant code.

I'ld guess the business layer[s] would be the next things to convert -
but if your VB-forms are mostly slightly augmented copies differing
only slightly, the GUI actually might benefit most from a rewrite,
if the business rules are written redundance poor.

One of the typical scenarios asking for GUI inheritance
is insurance - customer data is only specific for few fields
and even policy field groupings resemble each other across
similar policies. A "minmally redundant" business layer could
even in VB be implemented without too much sweat- for instance
by having methods overwritten in a inheritance based OOP -
design as name mangled methods on objects responsible across
similar problem domains, keeping the "common" methods clean.

Check your code with a critical eye -
even code forced to be totally OOP for

technical reason=langauge

can be written across a wide spectrum of quality.

If there is nothing which is good enogh to be converted last
or no segregation/layering at all in the current program,
(even if it came from the DOS dinosaurs, there were
"good coding practices" known - some of the old "libraries"
were better decoupled than modern day OOP class libraries.)
get rid of most of the people responsible and start only then.

my 0.02 EUR


> We have a program written in VB6 (over 100,000 lines of code and 230 UI 
> screens) that we want to get out of VB and into a better language. The 
> program is over 10 years old and has already been ported from VB3 to 
> VB6, a job which took over two years. We would like to port it to 
> Python, but we need to continue to offer upgrades and fixes to the 
> current VB6 version. Does anybody know of ways we could go about 
> rewriting this, one screen at a time, in Python, and calling the screens 
> from the existing program?
> We are also looking for a graphics toolkit to use. IronPython with it's 
> .NET bindings and ability to integrate with Visual Studio looks good, 
> but leaves that bad MS taste in the mouth.
> We currently use a MS Access back end and need to migrate to a proper 
> SQL server. We need to leave options open for SQL Server (for customers 
> who want to use existing infrastructure) and something like MySQL or 
> PostgreSQL. But in the mean time, we need to be able to access an 
> MSAccess (Jet) database from Python.
> Any answers/suggestions/pointers are greatly appreciated.
> Thanks,
> Josh Isted

More information about the Python-list mailing list