By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,349 Members | 1,280 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,349 IT Pros & Developers. It's quick & easy.

py2exe: abnormal program termination

P: n/a
Today, I found strange error while using py2exe:

1. I wrote simple program and save as 1.py:
import win32ui
import win32con

win32ui.MessageBox('Test messageBox.' , 'Test', win32con.MB_OK |
win32con.MB_TOPMOST )

2. I create 1_setup.py file for py2exe:
from distutils.core import setup
import py2exe

setup(
version = "0.0",
description = "",
name = '',

options = {"py2exe": {"compressed": 1,
"optimize": 2,
"bundle_files": 1}},

console = ["1.py"],
zipfile = None,
)


3. I run 1.exe and get error:
[code:1:7ea8ce03ac]
Runtime Error!
Abnormal program termination.
[/code:1:7ea8ce03ac]
http://img74.imageshack.us/img74/4212/abnormal5mv.png

Is there a way to fix it?
Common way (python 1.py) works.

Thank you!

Mar 15 '06 #1
Share this Question
Share on Google+
16 Replies


P: n/a

PyDenis wrote:
3. I run 1.exe and get error:
[code:1:7ea8ce03ac]
Runtime Error!
Abnormal program termination.
[/code:1:7ea8ce03ac]
http://img74.imageshack.us/img74/4212/abnormal5mv.png


which win32ui build and python do you use? which OS? dual core? etc?

( Post a stack trace, if you get one, or if you have a C-debugger
installed )

recent win32ui builds introduced some new types of crashes with certain
python versions, dual cores CPU's, etc.

see https://sourceforge.net/tracker/?gro...18&atid=551954

Maybe use prior builds.

Your crash may have its reason also in the (old) "DestroyWindow" bug
#1048355 / patch #1449736 as it has no other main gui. This bug raises
often only with certain memory layouts. Only the patch would solve this.

( I remember also little about such error with a messagebox-only program
outside of any mainframe on win98 only (but guess this was fixed; I am
not sure; can be same as #1048355 ) )

Robert


Mar 15 '06 #2

P: n/a
Python:
ActivePython 2.4.2 Build 10 (ActiveState
Corp.) based on
Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC
v.1310 32 bit (Intel)] on win32
-------------------------
win32ui:
Dont know how to get version info.
Little snippet
[code:1:f18a50c332]import win32ui

aa = sorted(dir(win32ui))

for i in aa:
print '%s => %r' % (i, getattr(win32ui, i))
print [/code:1:f18a50c332]

gives me only

copyright => 'Copyright 1994-2004 Mark Hammond
(mh******@skippinet.com.au)'
-------------------------
AFAIK, win32ui is part of pywin32
-------------------------
Pythonwin.exe on about: pythonwin32 build
205
-------------------------
OS: Windows 2000 SP4
Dualcore: NO

Mar 15 '06 #3

P: n/a
I fixed problem using Atypes:

import ctypes

ctypes.windll.user32.MessageBoxA(0, 'test', 'Title',
win32con.MB_ICONINFORMATION | win32con.MB_OK |
win32con.MB_TOPMOST)
It compiles and runs fine with py2exe.
Dont remember buggy pywin32 :)

Mar 15 '06 #4

P: n/a
Could you perhaps use basic netiquette stuff, such as sticking to the same sub-
ject line for followup posts in the same thread, and including a least some trace
of the post you're commenting on ?

(this would be less of a problem if everyone was reading your posts in a news-
reader, but this group is available in many different forms...)

</F>

Mar 15 '06 #5

P: n/a
> Fredrik Lundhwrote:
Could you perhaps use basic netiquette stuff, such as sticking to the
same sub-
ject line for followup posts in the same thread, and including a least some trace of the post you're commenting on ?

(this would be less of a problem if everyone was reading your posts in a news- reader, but this group is available in many different forms...)

</F>


Excuse me, please.

I mean, that

1. When I post new message to WEBFORUM (not a Mailing List nor News
Group) not to include even part of message.

2. About subject line: if this forum huge depends from subject line,
this field must be disabled or set to "RE: % "+ (orig_msg.subject) by
forum admins. Forum using some webforum engine, and easiest way to
format messages - tune it up accurately instead of messaging about
netiquette.

3. I receive message about topic posts without host name, so could go
in Browser History to find it. I mean, misplaced 'netiquette'
eclipsed by this bug:
Hello,

You are receiving this email because you are watching the topic,
"Re: WORKAROUND" at niXforums. This topic has received
a reply since your last visit. You can use the following link to view
the replies made, no more notifications will be sent until you visit
the topic.

http:///files/forum/viewtopic.php?p=730860#730860

If you no longer wish to watch this topic you can either click the
"Stop watching this topic link" found at the bottom of the
topic above, or by clicking the following link:

http:///files/forum/viewtopic.php?t=...&unwatch=topic

--
Thanks, The Management
Please, sorry for my english.

Mar 15 '06 #6

P: n/a
> Fredrik Lundhwrote:
Could you perhaps use basic netiquette stuff, such as sticking to the
same sub-
ject line for followup posts in the same thread, and including a least some trace of the post you're commenting on ?

(this would be less of a problem if everyone was reading your posts in a news- reader, but this group is available in many different forms...)

</F>


Excuse me, please.

I mean, that

1. When I post new message to WEBFORUM (not a Mailing List nor News
Group) not to include even part of message.

2. About subject line: if this forum huge depends from subject line,
this field must be disabled or set to "RE: % "+ (orig_msg.subject) by
forum admins. Forum using some webforum engine, and easiest way to
format messages - tune it up accurately instead of messaging about
netiquette.

3. I receive message about topic posts without host name, so could go
in Browser History to find it. I mean, misplaced 'netiquette'
eclipsed by this bug:
Hello,

You are receiving this email because you are watching the topic,
"Re: WORKAROUND" at niXforums. This topic has received
a reply since your last visit. You can use the following link to view
the replies made, no more notifications will be sent until you visit
the topic.

http:///files/forum/viewtopic.php?p=730860#730860

If you no longer wish to watch this topic you can either click the
"Stop watching this topic link" found at the bottom of the
topic above, or by clicking the following link:

http:///files/forum/viewtopic.php?t=...&unwatch=topic

--
Thanks, The Management
Please, sorry for my english.

Mar 15 '06 #7

P: n/a
> Fredrik Lundhwrote:
Could you perhaps use basic netiquette stuff, such as sticking to the
same sub-
ject line for followup posts in the same thread, and including a least some trace of the post you're commenting on ?

(this would be less of a problem if everyone was reading your posts in a news- reader, but this group is available in many different forms...)

</F>


Excuse me, please.

I mean, that

1. When I post new message to WEBFORUM (not a Mailing List nor News
Group) not to include even part of message.

2. About subject line: if this forum huge depends from subject line,
this field must be disabled or set to "RE: % "+ (orig_msg.subject) by
forum admins. Forum using some webforum engine, and easiest way to
format messages - tune it up accurately instead of messaging about
netiquette.

3. I receive message about topic posts without host name, so could go
in Browser History to find it. I mean, misplaced 'netiquette'
eclipsed by this bug:
Hello,

You are receiving this email because you are watching the topic,
"Re: WORKAROUND" at niXforums. This topic has received
a reply since your last visit. You can use the following link to view
the replies made, no more notifications will be sent until you visit
the topic.

http:///files/forum/viewtopic.php?p=730860#730860

If you no longer wish to watch this topic you can either click the
"Stop watching this topic link" found at the bottom of the
topic above, or by clicking the following link:

http:///files/forum/viewtopic.php?t=...&unwatch=topic

--
Thanks, The Management
Please, sorry for my english.

Mar 15 '06 #8

P: n/a
"PyDenis" wrote:
1. When I post new message to WEBFORUM (not a Mailing List nor News
Group) not to include even part of message.


comp.lang.python is a newsgroup and the python-list mailing list is a mailing
list. your messages appear in both places.

</F>

Mar 15 '06 #9

P: n/a
PyDenis wrote:
I fixed problem using Atypes:

import ctypes

ctypes.windll.user32.MessageBoxA(0, 'test', 'Title',
win32con.MB_ICONINFORMATION | win32con.MB_OK |
win32con.MB_TOPMOST)
It compiles and runs fine with py2exe.
Dont remember buggy pywin32 :)

better use win32api.MessageBox
win32api/gui/... are flat modules unlikely to have errors.

I tested your 2-liner with build207/py2.4.2 and build205/py2.3.5 with
py2exe and cx_Freeze in each combination and could not reproduce the bug
on XP, W2K and 98.
( The DestroyWindow bug appears only for more complex apps explicitly
using .DestroyWindow from certain Notification Handlers; the dual core
bug does not apply here )

I'm curious what it is?
If you could post a bug - if reproduceable - with all your detailed
context data to pywin32 project/bugs on sf.net, that would be fine.

--- Python GUI situation:

win32ui most probably is responsible for this bug; its a complex beast
with lot of descriptional status (MFC).
win32ui wants a mainframe, a document-template, an all that like until
you can do any simple thing :-( :-) But once settled and maybe hiding
its added complexity in a custom wrapper you can program quite fluid
apps with official Windows look&feel with it.

Yet in my recent tests with wxPython (I tried now 4x over years to get
something stable with wx :-( ), Boa, Kommodo, ... I had so much more
freezes and damages, and fat memory consumption and slowness and
fatigue, and funny appearance, that I'd say, for Windows its better to
live with win32ui for non-trivial GUI's (especially distributable ones),
which appear and behave like real Windows apps - and not like something
copyied from a Donald Duck magazine.

Testing the latest wx and Boa last week (for py2.3) it hit the
high-score: All other old win32api/ui apps - just by starting them -
press magically buttons themslef, raise this and that. Never saw such
behaviour. wx modified something in the libraries. There were new
Windows ctrl-libs in the main Python folder after wx-install (which I
never requested/allowed). But even removing them did not heal the
ghostly behavor of normal win32 apps not having anything to do with wx.
Only after uninstalling wx & boa win32 was stable again...

There are some other (open) things like PyFltk and worse ...

In my opinion the overall situation of Python GUI's (platform
independent) is not in line with and not up to the level of the
wonderful language itself and to its stability.
There is always a fragile TCL or XY-C++ or MFC or this and that in the
middle - and I can't believe, that it is necessary. Python is a best OO
language for GUI programming also and it should glue soon to OS-libs
(win32api/gui../ctypes , gtk, ...) .

I'd believe there is still room for a relly good, platform independent
speedy, flat, python-only OO GUI library - which loads modules with
discipline into memory, allows building distributables below 2MB, raises
only Python exceptions and would even attack Delphi in terms of
stability, endurance, VHL language typing speed - first by Pythons
qualities, and quickly by features (for which people would contribute
very quickly if a good plan is raised).
( But maybe I'm only dreaming ... ? )

Anygui was an academical test.

Some want to see wx as standard Python GUI lib. In my opinion thats
compromising cheaply with a C++ monster for producing clumsy test
in-door apps by carefully avoiding too much stepping with broken builds ..

It is strange, that each of the big python IDE's uses another GUI
toolkit: In an urge they use everything from Tk and to even the 20MB
MozillaWindowing-Toolkit (Komodo; I dropped 3.5 yesterday from my HD
after it core-dumped on second start and stepped 20x slower in the
debugger than PythonWin, no consistent Interactive Win/history, 100MB in
memory, .. ).

Python first should maybe have a real Python GUI toolkit and unite the
OS'es directly - as good as it does for the os module ?
Robert

Mar 15 '06 #10

P: n/a
On 3/15/06, robert <no*****@no-spam-no-spam.com> wrote:
PyDenis wrote:
I fixed problem using Atypes:

import ctypes

ctypes.windll.user32.MessageBoxA(0, 'test', 'Title',
win32con.MB_ICONINFORMATION | win32con.MB_OK |
win32con.MB_TOPMOST)
It compiles and runs fine with py2exe.
Dont remember buggy pywin32 :)
better use win32api.MessageBox
win32api/gui/... are flat modules unlikely to have errors.

I tested your 2-liner with build207/py2.4.2 and build205/py2.3.5 with
py2exe and cx_Freeze in each combination and could not reproduce the bug
on XP, W2K and 98.
( The DestroyWindow bug appears only for more complex apps explicitly
using .DestroyWindow from certain Notification Handlers; the dual core
bug does not apply here )

I'm curious what it is?
If you could post a bug - if reproduceable - with all your detailed
context data to pywin32 project/bugs on sf.net, that would be fine.

--- Python GUI situation:

win32ui most probably is responsible for this bug; its a complex beast
with lot of descriptional status (MFC).
win32ui wants a mainframe, a document-template, an all that like until
you can do any simple thing :-( :-) But once settled and maybe hiding
its added complexity in a custom wrapper you can program quite fluid
apps with official Windows look&feel with it.

Yet in my recent tests with wxPython (I tried now 4x over years to get
something stable with wx :-( ), Boa, Kommodo, ... I had so much more
freezes and damages, and fat memory consumption and slowness and
fatigue, and funny appearance, that I'd say, for Windows its better to
live with win32ui for non-trivial GUI's (especially distributable ones),
which appear and behave like real Windows apps - and not like something
copyied from a Donald Duck magazine.


win32gui and wxPython use *exactly* the same controls in almost all
cases. If you're seeing something "donald duck" then you're either
doing something wrong, or you're using a custom control. wx is also in
a far better position for most non-trivial UIs, becuase it has
infrastructure that win32 (pretty much alone among modern UI toolkits)
lacks, like layout algorithms and i18ln support.
Testing the latest wx and Boa last week (for py2.3) it hit the
high-score: All other old win32api/ui apps - just by starting them -
press magically buttons themslef, raise this and that. Never saw such
behaviour. wx modified something in the libraries. There were new
Windows ctrl-libs in the main Python folder after wx-install (which I
never requested/allowed). But even removing them did not heal the
ghostly behavor of normal win32 apps not having anything to do with wx.
Only after uninstalling wx & boa win32 was stable again...

I dont know where you get your wx libs from, or what "press magically
buttons themself" means, but the official wx installer doesn't do any
of this. Whatever you saw had nothing to do with wx.
There are some other (open) things like PyFltk and worse ...

In my opinion the overall situation of Python GUI's (platform
independent) is not in line with and not up to the level of the
wonderful language itself and to its stability.
There is always a fragile TCL or XY-C++ or MFC or this and that in the
middle - and I can't believe, that it is necessary. Python is a best OO
language for GUI programming also and it should glue soon to OS-libs
(win32api/gui../ctypes , gtk, ...) .

I'd believe there is still room for a relly good, platform independent
speedy, flat, python-only OO GUI library - which loads modules with
discipline into memory, allows building distributables below 2MB,
Python all by itself is bigger than this unless you totally gut the
standard library, and even then it's just barely under 2MB.
raises
only Python exceptions and would even attack Delphi in terms of
stability, endurance, VHL language typing speed - first by Pythons
qualities, and quickly by features (for which people would contribute
very quickly if a good plan is raised).
( But maybe I'm only dreaming ... ? )

Anygui was an academical test.

Some want to see wx as standard Python GUI lib. In my opinion thats
compromising cheaply with a C++ monster for producing clumsy test
in-door apps by carefully avoiding too much stepping with broken builds ...

It is strange, that each of the big python IDE's uses another GUI
toolkit: In an urge they use everything from Tk and to even the 20MB
MozillaWindowing-Toolkit (Komodo; I dropped 3.5 yesterday from my HD
after it core-dumped on second start and stepped 20x slower in the
debugger than PythonWin, no consistent Interactive Win/history, 100MB in
memory, .. ).

Python first should maybe have a real Python GUI toolkit and unite the
OS'es directly - as good as it does for the os module ?

Even a minimal GUI toolkit is an order of magnitude more complicated
than the os module.

Robert

--
http://mail.python.org/mailman/listinfo/python-list

Mar 15 '06 #11

P: n/a
> wx is also in
a far better position for most non-trivial UIs, becuase it has
infrastructure that win32 (pretty much alone among modern UI toolkits)
lacks, like layout algorithms and i18ln support.


Qt has all of this. On all platforms. Just for the record.

And layout algorithms - that was something I discovered in tk (using it from
tcl, btw) 10 years ago - but my VB experience some years later didn't
include that. Maybe that has changed - but the straight VB 6.0 GUI builder
certainly encouraged you to use windows UI-units or however these thingies
were called.

Regards,

Diez
Mar 15 '06 #12

P: n/a
On 3/15/06, Diez B. Roggisch <de***@nospam.web.de> wrote:
wx is also in
a far better position for most non-trivial UIs, becuase it has
infrastructure that win32 (pretty much alone among modern UI toolkits)
lacks, like layout algorithms and i18ln support.
Qt has all of this. On all platforms. Just for the record.


I know - so do almost all other toolkits, but not the win32 API, which
is what I was comparing it to.
And layout algorithms - that was something I discovered in tk (using it from
tcl, btw) 10 years ago - but my VB experience some years later didn't
include that. Maybe that has changed - but the straight VB 6.0 GUI builder
certainly encouraged you to use windows UI-units or however these thingies
were called.

Dialog units. But thats a mapping mechanism for scaling dialogs to
screen resolution, not a layout mechanism. The traditional mechanism
on win32 (VB and otherwise) is to place your controls in absolute
(dialog unit) coordinates. If you want to scale with window resizes,
you need to do it manually. Even Delphi has better layout support than
that!
Regards,

Diez
--
http://mail.python.org/mailman/listinfo/python-list

Mar 15 '06 #13

P: n/a
>> > a far better position for most non-trivial UIs, becuase it has
> infrastructure that win32 (pretty much alone among modern UI toolkits)
> lacks, like layout algorithms and i18ln support.
Qt has all of this. On all platforms. Just for the record.


I know - so do almost all other toolkits, but not the win32 API, which
is what I was comparing it to.


Ah, I misread your statement as win32 _having_ layout algorithms.
Dialog units. But thats a mapping mechanism for scaling dialogs to
screen resolution, not a layout mechanism. The traditional mechanism
on win32 (VB and otherwise) is to place your controls in absolute
(dialog unit) coordinates. If you want to scale with window resizes,
you need to do it manually. Even Delphi has better layout support than
that!


Yes - and as I knew tk when first seing win32, I thought of it being
archaic.

Sorry for the confusion,

Diez
Mar 15 '06 #14

P: n/a
Chris Mellon wrote:

win32gui and wxPython use *exactly* the same controls in almost all
(win32ui or win32gui? the later is almost only a better ctypes replacement )
cases. If you're seeing something "donald duck" then you're either
doing something wrong, or you're using a custom control. wx is also in
a far better position for most non-trivial UIs, becuase it has
infrastructure that win32 (pretty much alone among modern UI toolkits)
lacks, like layout algorithms and i18ln support.


Yes, wx is of course fat.
But I guess things like a layout algorithm ? is done very quickly in a
clean Python only lib. I can just imagine ...
Testing the latest wx and Boa last week (for py2.3) it hit the
high-score: All other old win32api/ui apps - just by starting them -
press magically buttons themslef, raise this and that. Never saw such
behaviour. wx modified something in the libraries. There were new
Windows ctrl-libs in the main Python folder after wx-install (which I
never requested/allowed). But even removing them did not heal the
ghostly behavor of normal win32 apps not having anything to do with wx.
Only after uninstalling wx & boa win32 was stable again...

I dont know where you get your wx libs from, or what "press magically
buttons themself" means, but the official wx installer doesn't do any
of this. Whatever you saw had nothing to do with wx.


that last test was with py2.3.5 / pywin32 205 /
wxPython2.6-win32-ansi-2.6.2.1-py23.exe

then run a few dialog examples of win32 and the dance begins.

There are some other (open) things like PyFltk and worse ...

In my opinion the overall situation of Python GUI's (platform
independent) is not in line with and not up to the level of the
wonderful language itself and to its stability.
There is always a fragile TCL or XY-C++ or MFC or this and that in the
middle - and I can't believe, that it is necessary. Python is a best OO
language for GUI programming also and it should glue soon to OS-libs
(win32api/gui../ctypes , gtk, ...) .

I'd believe there is still room for a relly good, platform independent
speedy, flat, python-only OO GUI library - which loads modules with
discipline into memory, allows building distributables below 2MB,

Python all by itself is bigger than this unless you totally gut the
standard library, and even then it's just barely under 2MB.

???

This 2-liner hello world 1.py with win32ui(=MFC) of this thread with
py2exe / cx_freeze / py2.3 / win32ui 205 is all compressed 869kB , or
even 700 kB with upx&7zip.
A quite big app (upx'ed) with win32ui, ssl, enc., unicode and all ..

app.zip 683 kB
app.exe 8 kB
_socket.pyd 16 kB
_sre.pyd 18 kB
_ssl.pyd 192 kB
_winreg.pyd 11 kB
datetime.pyd 17 kB
pywintypes23.dll 39 kB
unicodedata.pyd 167 kB
w9xpopen.exe 3 kB
win32api.pyd 21 kB
win32clipboard.pyd 6 kB
win32gui.pyd 25 kB
win32help.pyd 11 kB
win32task.dll 21 kB
win32ui.pyd 156 kB
zlib.pyd 23 kB
AES.pyd 13 kB
Blowfish.pyd 11 kB
DES3.pyd 9 kB
select.pyd 5 kB
python23.dll 361 kB

... is not more than 1700kB. That competes with Delphi.

A real Python OO GUI lib would be similar in size, maybe even smaller.
you'd hardly get more than 2MB (without docs) after all compressions.

Python first should maybe have a real Python GUI toolkit and unite the
OS'es directly - as good as it does for the os module ?

Even a minimal GUI toolkit is an order of magnitude more complicated
than the os module.


Of course its some effort, but with Python you code very very fast.

Once a basic OO message handling system is wired and the first commctrls
of Windows are covered and resembled on the other systems, things would
go very fast. Resembling indispensable things of MFC/wx like
tool/statusbars, docking windows, ... can also be coded quickly with a
clean python GUI system. And soon first professional apps could be built
.... the more I think about it

Most effort would be to have a mature, compatible event system. wx
learned it anyway from Windows (WM_ -> EVT_ ) and resembled it more on
Linux, etc.

That would be principally ok here too, as Windows is quite good in this
(despite the rest of the OS). One could "steal" a few principles,
abstract algs. and even names in less time than gluing the fragile C++.

Robert
Mar 15 '06 #15

P: n/a
> Yes, wx is of course fat.
But I guess things like a layout algorithm ? is done very quickly in a
clean Python only lib. I can just imagine ...


No. Layout-engines actually are non-trivial. They use constraint-solvers to
do optimization of sizes and offsets. Creating a well-balanced, easy to use
system is pretty difficult to do. Making that work in an intuitive manner
using a GUI-designer adds to that complexity - big time.

Diez
Mar 15 '06 #16

P: n/a
On 3/15/06, robert <no*****@no-spam-no-spam.com> wrote:
Chris Mellon wrote:

win32gui and wxPython use *exactly* the same controls in almost all
(win32ui or win32gui? the later is almost only a better ctypes replacement )


Both. wx wraps native controls. If you see something out of place it's
either a custom control for whatever reason, a control win32 doesn't
have (people often assume that Office is "native" windows, it is not),
or something you're doing wrong.
cases. If you're seeing something "donald duck" then you're either
doing something wrong, or you're using a custom control. wx is also in
a far better position for most non-trivial UIs, becuase it has
infrastructure that win32 (pretty much alone among modern UI toolkits)
lacks, like layout algorithms and i18ln support.
Yes, wx is of course fat.
But I guess things like a layout algorithm ? is done very quickly in a
clean Python only lib. I can just imagine ...
Testing the latest wx and Boa last week (for py2.3) it hit the
high-score: All other old win32api/ui apps - just by starting them -
press magically buttons themslef, raise this and that. Never saw such
behaviour. wx modified something in the libraries. There were new
Windows ctrl-libs in the main Python folder after wx-install (which I
never requested/allowed). But even removing them did not heal the
ghostly behavor of normal win32 apps not having anything to do with wx.
Only after uninstalling wx & boa win32 was stable again...

I dont know where you get your wx libs from, or what "press magically
buttons themself" means, but the official wx installer doesn't do any
of this. Whatever you saw had nothing to do with wx.


that last test was with py2.3.5 / pywin32 205 /
wxPython2.6-win32-ansi-2.6.2.1-py23.exe


I can't give you any sort of diagnosis without more information about
what actually happened. I don't use python2.3 so it's remotely
possible that could be related, but wxPython doesn't put anything in
the base Python dir so I suspect that there is more going on here than
is immediately obvious.
then run a few dialog examples of win32 and the dance begins.

There are some other (open) things like PyFltk and worse ...

In my opinion the overall situation of Python GUI's (platform
independent) is not in line with and not up to the level of the
wonderful language itself and to its stability.
There is always a fragile TCL or XY-C++ or MFC or this and that in the
middle - and I can't believe, that it is necessary. Python is a best OO
language for GUI programming also and it should glue soon to OS-libs
(win32api/gui../ctypes , gtk, ...) .

I'd believe there is still room for a relly good, platform independent
speedy, flat, python-only OO GUI library - which loads modules with
discipline into memory, allows building distributables below 2MB,

Python all by itself is bigger than this unless you totally gut the
standard library, and even then it's just barely under 2MB.

???

This 2-liner hello world 1.py with win32ui(=MFC) of this thread with
py2exe / cx_freeze / py2.3 / win32ui 205 is all compressed 869kB , or
even 700 kB with upx&7zip.
A quite big app (upx'ed) with win32ui, ssl, enc., unicode and all ..

app.zip 683 kB
app.exe 8 kB
_socket.pyd 16 kB
_sre.pyd 18 kB
_ssl.pyd 192 kB
_winreg.pyd 11 kB
datetime.pyd 17 kB
pywintypes23.dll 39 kB
unicodedata.pyd 167 kB
w9xpopen.exe 3 kB
win32api.pyd 21 kB
win32clipboard.pyd 6 kB
win32gui.pyd 25 kB
win32help.pyd 11 kB
win32task.dll 21 kB
win32ui.pyd 156 kB
zlib.pyd 23 kB
AES.pyd 13 kB
Blowfish.pyd 11 kB
DES3.pyd 9 kB
select.pyd 5 kB
python23.dll 361 kB

.. is not more than 1700kB. That competes with Delphi.


Sorry, I was talking about Python 2.4, which is much larger (unicode
conversion tables, I think). 1,824KB, which can be packed down to a
bit less than 800k by UPX (at the cost of not being able to share it
betwen processes)
A real Python OO GUI lib would be similar in size, maybe even smaller.
you'd hardly get more than 2MB (without docs) after all compressions.

Python first should maybe have a real Python GUI toolkit and unite the
OS'es directly - as good as it does for the os module ?
Even a minimal GUI toolkit is an order of magnitude more complicated
than the os module.


Of course its some effort, but with Python you code very very fast.

Once a basic OO message handling system is wired and the first commctrls
of Windows are covered and resembled on the other systems, things would
go very fast. Resembling indispensable things of MFC/wx like
tool/statusbars, docking windows, ... can also be coded quickly with a
clean python GUI system. And soon first professional apps could be built
... the more I think about it


I think you seriously understimate the work involved in such a system.
Especially if you want them to have native look & feel thats
comparable to what wxPython offers. If you give Python a 10x LOC
advantage (not unreasonable) and a 5x productivity advantage you're
still looking at at least 100k LOC and 5+ man-years to create the
equivilent to Qt or wxWidgets in pure Python. And starting on Windows
is really a pretty poor plan - the toolkits on other platforms are far
more capable. wx already suffers in places because of a
windows-centric API that precludes access to more powerful features on
other platforms.

Don't let me stop you, though.
Most effort would be to have a mature, compatible event system. wx
learned it anyway from Windows (WM_ -> EVT_ ) and resembled it more on
Linux, etc.

That would be principally ok here too, as Windows is quite good in this
(despite the rest of the OS). One could "steal" a few principles,
abstract algs. and even names in less time than gluing the fragile C++.

Robert
--
http://mail.python.org/mailman/listinfo/python-list

Mar 15 '06 #17

This discussion thread is closed

Replies have been disabled for this discussion.