VB to Python migration

[Josh]

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

[Nicolas Kassis]

Re: VB to Python migration

Josh wrote:
[color=blue]
> 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[/color]

For the Database, you should use the SQLObject(sqlob ject.org) module.

Nic

[Ravi Teja]

Re: VB to Python migration

230 UI screens is a lot. An app of that nature is not something people
commonly do in Python (although I would be happy to see people show me
wrong). You are building a GUI app that likely need not run anywhere
except on Windows and perhaps most what of what is does is edit and
report on data from the database. This is the very task 4GL tools like
Visual Basic were created for.

VB6 has certainly been outdated for quite a while ago now and you
should probably make the switch but don't discount the tools that
exactly specialize in this domain such as Visual Studio.NET and Delphi.
Python is a great general purpose language but the above tools are
leaps and bounds ahead of the tools available to Python in this very
specific domain. Additionally your team already is familiar with the
RAD paradigm. As easy as Python is, it takes a while to develop
expertise in a new language and it's paradigms (especially when it is
such a leap - VB and Python are almost at the opposite ends of the
spectrum).

IronPython has a lot of promise but is not mature enough yet to bet a
project large enough to take 2 years (or more) to develop. At that
project size, it is not sane to attempt anything adventurous unless you
have have enough funds to buffer when things go wrong. I am not
recommending against Python, just to plan VERY VERY carefully on what
you embark on.

Start using Python gradually in your development. Refactor some
functionality into COM components for starters to simplify your VB
code. When Python is doing much of the heavy lifting, you are ready to
make the change. By the time you are ready to make the full switch, you
will know.

Personally, for a project like this, I would go with Borland Studio (it
has ECO which is a tremenduous advantage for data driven GUIs) and
supplement it with Boo (a Python like language for .NET).

[Steven D'Aprano]

Re: VB to Python migration

On Fri, 27 Jan 2006 23:48:51 +0000, Josh wrote:
[color=blue]
> 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?[/color]

I know little about VB, but if it can call external programs, then it
should be able to call a Python program from the command line.

[snip]
[color=blue]
> Any answers/suggestions/pointers are greatly appreciated.[/color]


I suggest you hire a couple of experienced Python developers, pick half a
dozen screens, say three simple screens and three complex ones, and build
them in Python. That will give you an idea of how much work is involved.
Don't get your VB developers to try to port it themselves, that's a recipe
for disaster: they will be trying to learn Python, and will end up writing
VB code in Python, which is sure to be slow, inefficient, bulky and buggy.

You may also like to think about using a web front end. If your GUI app
only uses simple controls like text fields and push buttons, a web front
end might simplify things a lot.

Good luck.



--
Steven.

[Jon-Pierre Gentil]

Re: VB to Python migration

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Josh wrote this on Friday 27 January 2006 05:48 pm in
<DjyCf.110918$A P5.12355@edtnps 84>:
[color=blue]
> 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?[/color]

I would look into Qt, PyQt, and the Qt Designer. It'll provide one of the
easiest ways of porting your existing GUI dialogs into Python. Start
building and componentizing your code. In VB6, all classes are flat under
a single branch of a project tree, whereas in Python you'll likely
implement modules of similar functionality. Overall porting your
application will be a combination of rewriting, refactoring, and
copy-and-translate code. Good luck. :-) It actually sounds like a fun
project to be on. I had a lot of VB6 experience back in "the day" and a
project like that would be a lot of fun to me.


- --
_______________ _______________ _______________ ____________

Jon-Pierre Gentil KC9CAF PGP: 0x7E1CBA17
jabber: jgentil@sebista r.net web: www.sebistar.net
"If you think education is expensive, try ignorance."
_______________ _______________ _______________ ____________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQIcBAEBCgAGBQJ D2yoeAAoJEPtxPm pAsx/rdkkP/A8oGRQF2n7UqpbT HkuMIPT5
u0LFh75ry/6RiXpOa72iLkPb9 giXp+pSGGlGbR7S gdh5NmMnhd882SJ knVP8vFta
wcbdwORilBjR4I4 WsnN5o+fcUz8PPE Rj0yfYndEEC7SBQ OOahcpX6FSd9gNj be2s
MMDy5TqDE0kTP2P tGknncLB+v4XoFk UcZtFhVtKh29y0k ORCJ1jIHq+O7vN9 Wgwv
BrzNse44n/TSW8Z2iCX8h+tsC K0vSzqe6GJKA5IR HmUjoRWyiQH6LKb oZcA8qNrA
JQlCa9deRSLWFWO IUsHIKBeGDmiO+E 7E6g1jfADwQuS+T DW1yxV+1HwGR5LC QFgV
kXVEMDzyk1SIvAV EuXIefXuZQq9naf PhDx4qpnnxqK1HK 1F97meYYm7/tAoHZGKM
6kJ9tq9P5I3TkFB 9dRVuNftKkKZz8f 6RCJFcsHvqOu2H9 4Fui5upUs3/royp8TVQ
CeY74vtlFXKkPGj t07RfJFMqxacGL3 ONjgYdRluV5pkDe Xoer65Vhqd7kHFl pVW0
Gilw4ITDEIlIuX+ iOvSP5CBixBqwrv hARGYQxCMoiwtZj fbbGo0iKYHhx4/qAGAv
qoxY0Ae6D3mTTIR XiKrVBLlXgj3kQI qCzOuCPTEhN/ydY2WeKYlArBQAL 42H7Rkv
atlNHGjEcMMTcHe sfK0e
=b2Qh
-----END PGP SIGNATURE-----

[Luis M. González]

Re: VB to Python migration

I second the suggestion of using Boo for this case.
Why use Delphi or VB when you have a more "pythonic" first class .NET
language?
You already have a very good IDE for creating your project
(SharpDevelop), which is free, open source and already has the Boo
bindings included (download here the latest version:
http://build.sharpdevelop.net/BuildArtefacts/).

Boo is a perfect language for someone wanting to develop Windows GUI
apps because it has all the nice features and syntax of Python, while
being specifically created to run on the .NET framework.

However, if you still want to use pure Python, it won't take too long
to get what you need. Ironpython is in version 1.0 Beta 2, and moving
full steam towards a stable release.
I'm sure that soon it will be integrated to Visual Studio.

[DH]

Re: VB to Python migration

see vb2py to help the conversion

http://vb2py.sourceforge.net/

or if you want to convert vb6 to vb.net instead, there are tools from
microsoft and others to help with that, such as:
http://www.microsoft.com/downloads/d...displaylang=en

or if you want to start over from scratch, the other recommendations are
good, like pyqt and qt designer, or else do it as a web app instead of
desktop app if it just involves basic form controls.

[Thomas Ganss]

Re: VB to Python migration

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

thomas


[color=blue]
> 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[/color]

[John M. Gabriele]

Re: VB to Python migration

Josh wrote:[color=blue]
> 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?[/color]

Dunno what you mean by "calling the screens" from the existing
program. (?)

Is your VB6 progam object-based? If so, it sounds like you might
have your work cut out for you in duplicating the classes in Python
(I've never used VB6 and don't even know if it's an OO language.).

I'd look into how you can start with unit tests + your classes
right from the start. And, it goes without saying to use version
control from the start (svn or, if you're adventurous, maybe bzr
(i.e. Bazaar-NG)).
[color=blue]
> We are also looking for a graphics toolkit to use.[/color]

You might take a peek at Python + PyGTK + Glade:
http://pygtk.org/ . Dunno the state of GTK on Windows,
but I've heard it's workable. No idea about Glade on
Windows.

Here's an article from 2001:

http://www.linuxjournal.com/article/4702

but if you look around there should be some newer tutorials
around.
[color=blue]
> [snip]
>
> Any answers/suggestions/pointers are greatly appreciated.[/color]

As Steven suggested, I'd examine whether or not your app
might work as a web app. That completely frees you from Windows
altogether. Just make sure it runs alright with Firefox/Opera/
Safari. :)

---J
[color=blue]
> Thanks,
>
> Josh Isted[/color]


--
(remove zeez if demunging email address)

[Magnus Lycka]

Re: VB to Python migration

Josh wrote:[color=blue]
> 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.[/color]

mxODBC is probably the best way to talk to Jet in a way (DB API)
that makes it reasonably easy to port the data to another RDBMS.
Writing multi RDBMS applications is a whole chapter in itself,
if not a subject for a whole book.

Whether to use an ORM such as SQLObject on top of that is another
issue...

[Magnus Lycka]

Re: VB to Python migration

Ravi Teja wrote:[color=blue]
> 230 UI screens is a lot. An app of that nature is not something people
> commonly do in Python (although I would be happy to see people show me
> wrong).[/color]

Maybe not, but I don't doubt that it's reasonable to replace a
VB app with 230 UI screens with Python code.

A code of that size is something that's grown over time, and if
it's rewritten, it seems likely that it will end up with fewer
screens without fewer features.

Besides, while VB makes it very easy to duplicate a lot of code,
and end up in a situation where you have to manually change things
230 times through the GUI if something changes in all screens, it's
very convenient to use inheritence for GUI development with e.g.
wxPython. I supect the screens have a lot in common, and that it
would be fairly clear how to build a class hierachy of that, and
avoid code duplication. The end result will be a more homogenous
application and a lower maintenance cost.

The really silly thing to do is to apply VB idioms on Python.

[Ravi Teja]

Re: VB to Python migration

Magnus Lycka wrote:[color=blue]
> Ravi Teja wrote:[color=green]
> > 230 UI screens is a lot. An app of that nature is not something people
> > commonly do in Python (although I would be happy to see people show me
> > wrong).[/color]
>
> Maybe not, but I don't doubt that it's reasonable to replace a
> VB app with 230 UI screens with Python code.
>
> A code of that size is something that's grown over time, and if
> it's rewritten, it seems likely that it will end up with fewer
> screens without fewer features.[/color]

Rewrites are always good and result in smaller code base if features
are not added. However, I doubt that will make the screens fewer. Lines
of code? Certainly.
[color=blue]
> Besides, while VB makes it very easy to duplicate a lot of code,
> and end up in a situation where you have to manually change things
> 230 times through the GUI if something changes in all screens, it's
> very convenient to use inheritence for GUI development with e.g.
> wxPython. I supect the screens have a lot in common, and that it
> would be fairly clear how to build a class hierachy of that, and
> avoid code duplication. The end result will be a more homogenous
> application and a lower maintenance cost.[/color]

You are comparing Python with VB 6. That's not what the OP is moving to
as an alternative. It's .NET. VB 6 has been out of development since 8
years? Its not something to be compared to anymore. .NET on the other
hand has all the advantages of Python accessible toolkits for this task
and then some. For example, it's not just inheritance but visual
inheritance. It's not just a GUI but GUI with data bindings, with
sophisticated caching, paging etc. GUI Builders are far more
sophisticated and integrated than, say wxGlade.

I am not saying Python is unfit for 230 screens. Just that I have not
seen anyone build such a thing and better write about it. People on the
other hand have build web sites with such volume. Result? We have a ton
of web application frameworks to address such needs. We would have the
same for Data GUIs if that was the case. We have people drooling over
TurboGears, not Dabo (apologies Dabo team).
[color=blue]
> The really silly thing to do is to apply VB idioms on Python.[/color]

It is. But that's what people do on their first few projects and it's
perfectly natural. Didn't you :-) ?

[Magnus Lycka]

Re: VB to Python migration

Ravi Teja wrote:[color=blue]
> Rewrites are always good and result in smaller code base if features
> are not added. However, I doubt that will make the screens fewer. Lines
> of code? Certainly.[/color]

That depends on whether you just refactor the implementation
of if you look at the problem domain with a different perspective
than you had the first time around. Obviously, I don't know anything
about this particular system, but with 230 screen it seems like
some things could be generalized. I suspect a much smaller number
of slightly context sensitive screens would suffice... My gut
tells me that if I looked at the system, I'd find lots of screens
that were basically the same, just slightly different... Whether
to use the same actual screen and perhaps let it be modified in runtime
due to some data driven approach or share most code in base classes
and have small modules with the specialized behaviour is something
to argue about in some design meetings. I'll leave that to the guys
who have to do it.
[color=blue]
> You are comparing Python with VB 6. That's not what the OP is moving to
> as an alternative.[/color]

No, but it's what they've used and know. It's the reference for
their thinking.
[color=blue]
> It's .NET. VB 6 has been out of development since 8
> years? Its not something to be compared to anymore. .NET on the other
> hand has all the advantages of Python accessible toolkits for this task
> and then some.[/color]

But as indicated by the OP, there might be reasons not to
sit down in that warm and soft lap from Redmond once more...

I assume they don't consider Python as a chance to avoid having
to really understand OO, or to be able to stay with the current
code base. Avoiding vendor lock-in is a very reasonable aspect,
and making it easier to port to non-windows platforms is also a
reasonable aspect.
[color=blue]
> I am not saying Python is unfit for 230 screens. Just that I have not
> seen anyone build such a thing and better write about it.[/color]

Right, and this is interesting. After about 25 years of
programming I'm still not sure whether I should be impressed
or worried when I hear people describing systems with
hundreds of screens and hundreds of database tables.

I've worked with systems like that, and while I'm sure there
are situations where such big systems are really warranted,
the systems of this size that I saw could probably have been
shrunk to a quarter of their size if proper software development
practices had been used.
[color=blue]
> People on the
> other hand have build web sites with such volume. Result? We have a ton
> of web application frameworks to address such needs.[/color]

I'm not 100% sure that the plethora of Python web kits is entirely
a benefit.
[color=blue][color=green]
>>The really silly thing to do is to apply VB idioms on Python.[/color]
>
> It is. But that's what people do on their first few projects and it's
> perfectly natural. Didn't you :-) ?[/color]

No, I had used Python for years the first time I had to code VB.
I'm sure I wrote stupid code, but most of my awkward programming
experiences have been when I had to code Perl or VB6 after long
periods when I had only written Python and C++.

[Josh]

Re: VB to Python migration

Nicolas Kassis wrote:[color=blue]
> Josh wrote:
>
>[color=green]
>>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[/color]
>
>
> For the Database, you should use the SQLObject(sqlob ject.org) module.
>
> Nic
>[/color]

Thanks for the info, I took a look at SQLObject, but I'm not sure if
that's the way we want to go quite yet. We have a lot of embedded SQL in
the program and it looks like we'd have to convert it all to SQLObject
object code, which would just add to the initial complexity of the
project. I'll keep this bookmarked for future reference but I don't
think it'll work at the moment.

Josh

[Josh]

Re: VB to Python migration

Jon-Pierre Gentil wrote:[color=blue]
> I would look into Qt, PyQt, and the Qt Designer. It'll provide one of the
> easiest ways of porting your existing GUI dialogs into Python. Start
> building and componentizing your code. In VB6, all classes are flat under
> a single branch of a project tree, whereas in Python you'll likely
> implement modules of similar functionality. Overall porting your
> application will be a combination of rewriting, refactoring, and
> copy-and-translate code. Good luck. :-) It actually sounds like a fun
> project to be on. I had a lot of VB6 experience back in "the day" and a
> project like that would be a lot of fun to me.[/color]

We had looked at QT a while ago, but not in relation to Python. We were
just looking at it in relation to rewriting in C++. We'll have to
revisit it, paying attention to PyQt.

It is a rather fun project to be on. It's such a gigantic program
though, it gets difficult to comprehend how long it's going to take to
make this transision. Whether it's to Python, or some other direction.

Josh