*Newbie Question* --> Is it viable to distribute Python apps over the Internet?
Denis Agar
hours this easter reseaching Python GUIs, compilers, and the language
in general. It's been arduous trying to piece together knowledge from
different places but I'm slowly getting the hang of it. A little about
me: My only other (major) experience with programming was a semester
of Visual Basic in school. I really wanted to get away from the
hodgepodge of bad vibes coming from Microsoft, and was suggested
almost unanimously Python by a forum (http://www.shareaza.com/forum)
I'm blabbering! Anyway, my problem is this. I tried to compile a
simple Hello World program into something runnable on non-python
computers, and it came out being 7MB in size. Is there something I'm
doing wrong? Just so you know, I do know somewhat what I'm doing. I
know that it's incorporating all of the GUI. So is there a way to not
incoporate all of the gui, and still have a functional program? I'm
thinkin in the 800k range for a simple program? The reason I ask is
because I'm thinking of porting something I made in VB to Python
before I develop it any further.
PS: The program is 92k in Visual Basic.
Dennis Reinhardt
My anti-spam program is 797 KB. 800K is doable. If you download, you can
see the files I include. I use a browser for GUI and do not include a
separate GUI framework.
--
Dennis Reinhardt
Den...@dair.com http://www.spamai.com?ng_sig
Jp Calderone
Though 7MB is slightly larger than the numbers I've seen, it is in the
right ballpark.
It's easy to see why. You're distributing an entire runtime environment,
instead of just your application. When you write VB code, you're only
distributing your application.
It is unlikely you'll be able to get your app down to 800kB, though 3MB or
4MB may be likely. If size is your main concern, I'd recommend simply *not*
bundling the Python runtime with your application. This will give you a
"Hello world" that is 1kB or 2kB. It will run on all machined with the
required runtime libraries, and you can simply point everyone else towards
http://www.python.org/ for a free download of what they're missing.
Jp
--
Seduced, shaggy Samson snored.
She scissored short. Sorely shorn,
Soon shackled slave, Samson sighed,
Silently scheming,
Sightlessly seeking
Some savage, spectacular suicide.
-- Stanislaw Lem, "Cyberiad"
--
up 32 days, 13:02, 2 users, load average: 0.23, 0.21, 0.13
Grant Edwards
>> I'm blabbering! Anyway, my problem is this. I tried to compile
>> a simple Hello World program into something runnable on
>> non-python computers, and it came out being 7MB in size. Is
>> there something I'm doing wrong? Just so you know, I do know
>> somewhat what I'm doing. I know that it's incorporating all of
>> the GUI. So is there a way to not incoporate all of the gui,
>> and still have a functional program? I'm thinkin in the 800k
>> range for a simple program? The reason I ask is because I'm
>> thinking of porting something I made in VB to Python before I
>> develop it any further.
>
> Though 7MB is slightly larger than the numbers I've seen, it is
> in the right ballpark.
>
> It's easy to see why. You're distributing an entire runtime
> environment, instead of just your application. When you write
> VB code, you're only distributing your application.
Has anybody tried distributing their Python app w/o bundled
Python but with a wrapper/isntaller that will download and
install Python if it isn't installed? I'm currently
distributing a very simple wxWindows app bundled with Python
and wxWindows (so the download is pretty huge). For customers
that already have Python and wxWindows, it seems like a waste.
I've now idea how many customers (if any) already do have
Python. I suspect very few do, so it's sort of a moot point.
--
Grant Edwards grante Yow! CHUBBY CHECKER just
at had a CHICKEN SANDWICH in
visi.com downtown DULUTH!
Cameron Laird
Jp Calderone <exa...@intarweb.us> wrote:
.
.
.
>instead of just your application. When you write VB code, you're only
>distributing your application.
.
.
Until it turns out that your customer has a VB run-time
which differs subtly but crucially from yours.
At which point you get involved in distribution of
*larger* files than the corresponding Python-based ones.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
Greg Brunet
news:25a672ee.03042...@posting.google.com...
> I'm blabbering! Anyway, my problem is this. I tried to compile a
> simple Hello World program into something runnable on non-python
> computers, and it came out being 7MB in size. Is there something I'm
> doing wrong? Just so you know, I do know somewhat what I'm doing. I
> know that it's incorporating all of the GUI. So is there a way to not
> incoporate all of the gui, and still have a functional program? I'm
> thinkin in the 800k range for a simple program? The reason I ask is
> because I'm thinking of porting something I made in VB to Python
> before I develop it any further.
>
> PS: The program is 92k in Visual Basic.
Realize that VB has a runtime as well, and if you packaged all of the
supporting files with it that are needed, (and probably already on your
computer), it would likely be in the same range as your 7 MB. To more
closely compare apple to apples, I would recommend doing the following:
two install/setup programs. The first with Python and your GUI support
files (in my case wxPython), the second with the required scripts
(packaged using Py2exe or comparable tool).
The first setup program would be comparable to VBRun60.exe which
contains the VB runtime files (though it doesn't include 3rd party OCX's
which can also get quite large). My version of this has: python22.dll,
wxc.pyd, & wxmsw233h.dll. (or uh.dll) Packaged in a setup program
(compressed), they are about 2 MB. As long as you don't change versions
of python of wxPython, this setup file could be shared among your
applications.
The second setup program would have your script (converted to an EXE so
that people can just run it without having to load the entire python
environment). Even with all of the supporting scripts that will come
along in the package, this should only be 1/2 meg in size, maybe less.
In my tests, a fair amount of this size comes from the supporting
wxpython PYC files, which, with a little extra work, could be packaged
into the first setup program.
If you look at it this way, you'll end up with something comparable to
your VB experience. For a more detailed example of all this, check out:
http://wiki.wxpython.org/index.cgi/SmallApp
--
Greg
Dennis Reinhardt
> It is unlikely you'll be able to get your app down to 800kB, though 3MB
or
> 4MB may be likely. If size is your main concern, I'd recommend simply
*not*
> bundling the Python runtime with your application. This will give you a
> "Hello world" that is 1kB or 2kB.
On Windows, which is where Visual Basic runs after all, a complete Python
hello world is 459 KB. 3-4 MB is *not* required. See the online builder
for constructing Python hello-world class executables at
http://www.dair.com/autorun/arpyexe.cgi
A serious app (SpamAI below) is built differently and has much more code
than hello world. Current size is 797 KB. 800 KB *is* likely.
The python DLL is bundled as are all required PY files in both of the
executables above.
laotseu
(snip)
>
> I'm blabbering! Anyway, my problem is this. I tried to compile a
> simple Hello World program into something runnable on non-python
> computers, and it came out being 7MB in size. Is there something I'm
> doing wrong? Just so you know, I do know somewhat what I'm doing. I
> know that it's incorporating all of the GUI. So is there a way to not
> incoporate all of the gui, and still have a functional program? I'm
> thinkin in the 800k range for a simple program? The reason I ask is
> because I'm thinking of porting something I made in VB to Python
> before I develop it any further.
>
> PS: The program is 92k in Visual Basic.
<OT>
Just for your information : your 92k VB program won't run without the
vbrun.dll, which is at least 1.x Mo... To be sure to have a correct
setup, you must package a VB program with the runtime (vbrun.dll) and
any 'external' ActiveX component, type libs etcs used by the application
(and be sure you won't write many real-life VB apps without ActiveX
components and type libs etc)
</OT>
Laotseu
Denis Agar
that most people already have such as the ones employed by Visual
Basic or Visual C++?
Gerhard Häring
VB's GUI code is likely in the VB runtime. With "VC GUI" you likely mean
the MFC classes, which are usually in the MFC42.DLL. It can be used from
Python via the win32 extensions, which are a relatively slim download.
But looking at the included examples, I wouldn't want to develop a GUI
using the win32 extensions, as it's basically hardcore win32 API
programming.
-- Gerhard
Cameron Laird
.
.
Let's note, though, that there are several contributors
to c.l.p who speak with comfort about having delivered
applications to customers coded in Python against MFC.
Gerhard and I haven't, but apparently it's not infeasible.
Jp Calderone
>
> On Windows, which is where Visual Basic runs after all, a complete Python
> hello world is 459 KB. 3-4 MB is *not* required. See the online builder
> for constructing Python hello-world class executables at
> http://www.dair.com/autorun/arpyexe.cgi
>
> A serious app (SpamAI below) is built differently and has much more code
> than hello world. Current size is 797 KB. 800 KB *is* likely.
>
> The python DLL is bundled as are all required PY files in both of the
> executables above.
Is the app that generates these available (commercially or for free)?
Jp
--
A sad spectacle. If they be inhabited, what a scope for misery
and folly. If they be not inhabited, what a waste of space.
-- Thomas Carlyle, looking at the stars
--
up 32 days, 23:02, 2 users, load average: 1.49, 1.35, 1.35
Dennis Reinhardt
(1) http://www.dair.com/autorun/arpyexe.cgi
Use of the web page is free.
(2) A serious app (SpamAI sig link below)
I packaged the Python tree manually. I started with the main DLL and then
included modules as Python found them not present in the tree at the time.
Packaging = Python = Free. The trick here is to assign system.path and
prevent Python from searching its own install, using only the tree being
constructed.
I used TinySetup (www.tinysetup.com) for setup tasks. Free after
registration (tinysetup is my site, btw). I used WinRAR (www.rarlabs.com)
for self-extracting compression. Commercial = $29
Graham Fawcett
Excellent point. I took a peek at the Chandler 0.2 package that was
made available recently. It was ~13Mb, and it seemed an awful shame to
have so much "bloat" when a pre-installed interpreter (and wxPython
lib) could have cut the package down to almost nothing.
It would be great to see this integrated with the Python Package Index
as well, for a CPAN-style (grab what I need when I need it)
installation. Well, I assume that's the point of PyPI in the first
place.
Presumably a small C program could be written and made available as a
bootstrap to be placed in binary executable installers (Inno Setup,
etc) that could detect the absence of a Python environment and
download/install it prior to final installation of the application.
The Java Web Start model might be worth consideration as well. It
would cordon off the interpreter into a separate, single download,
take care of the PyPI/Distutils stuff, etc. and still leave the client
with a configuration-free environment. Just fire up the Python Web
Start, download the application stub, and let PWS do the rest. This
would also isolate and take care of differences between build
environments (*nix vs. Windows, for example, where, in the latter, the
presence of a compiler is an abberation).
I guess the moral of the story is, "contribute some time to
PyPI/Distutils development." Or, befriend a PyPI/Distutils developer
and send him food and get-out-of-work-free tickets. ;-)
-- Graham
A. Lloyd Flanagan
> (snip)
> >
> <OT>
> Just for your information : your 92k VB program won't run without the
> vbrun.dll, which is at least 1.x Mo... To be sure to have a correct
> setup, you must package a VB program with the runtime (vbrun.dll) and
> any 'external' ActiveX component, type libs etcs used by the application
> (and be sure you won't write many real-life VB apps without ActiveX
> components and type libs etc)
> </OT>
>
> Laotseu
Yes, and it can be extremely difficult to ensure that you've got all
the ActiveX components and DLLs you need in your install package. If
you're using database access, the client PC probably requires the
whole MS MDAC installed; they may well need to update various Windows
controls; any third-party controls need to be installed; etc. God
help you if you've got version conflicts with another application, or
another version of VB. All part of the wonders of component-based
development, or at least the MS implementation thereof.
</OT></rant>
I've had a lot fewer problems with distributed python apps. Once your
target PC has python on it, and wxPython if appropriate, you can set
up everything with dist-utils. 3 easy installs is better than one
difficult one.
John J. Lee
> On Mon, Apr 21, 2003 at 08:49:30PM +0000, Dennis Reinhardt wrote:
> >
> > On Windows, which is where Visual Basic runs after all, a complete Python
> > hello world is 459 KB. 3-4 MB is *not* required. See the online builder
> > for constructing Python hello-world class executables at
> > http://www.dair.com/autorun/arpyexe.cgi
[...]
> > The python DLL is bundled as are all required PY files in both of the
> > executables above.
>
> Is the app that generates these available (commercially or for free)?
Probably py2exe or McMillan Installer, I imagine. Both know about
dependencies, so you don't end up with the whole Python distribution
in your .exe.
John
Dennis Reinhardt
free)?
JJL> Probably py2exe or McMillan Installer, I imagine.
Nope.... neither one. I used Python itself and other programs, as described
in separate posting.
--
Dennis Reinhardt
Den...@dair.com http://www.spamai.com?ng_clp
JanC
> Presumably a small C program could be written and made available as a
> bootstrap to be placed in binary executable installers (Inno Setup,
> etc) that could detect the absence of a Python environment and
> download/install it prior to final installation of the application.
This can already be done using NSIS and its download plugin ("NSISdl").
<http://nsis.sourceforge.net/>
--
JanC
"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Robin Munn
> I guess the moral of the story is, "contribute some time to
> PyPI/Distutils development." Or, befriend a PyPI/Distutils developer
> and send him food and get-out-of-work-free tickets. ;-)
I've heard of those. Those are those little pieces of paper that say
"Pay to the order of ________", right? :-)
--
Robin Munn <rm...@pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838 50FF 2478 CFFB 081A 8338 54F7 845D ACFD 6AFB 6838
A.M. Kuchling
> I guess the moral of the story is, "contribute some time to
> PyPI/Distutils development." Or, befriend a PyPI/Distutils developer
> and send him food and get-out-of-work-free tickets. ;-)
Contribute time, not money. Money does not make interested developers
materialize, and money doesn't help figure out what to do. The great
problem is that no one is particularly interested in improving Python's
packaging, not even to the extent of offering opinions on concrete proposals
or trying out code.
(Things that might help: join the Catalog-SIG and try a system that someone
else has built. Comment on existing proposals like PEPs 262 and 314.
Review the existing code and offer patches.)
--amk (www.amk.ca)
TAMORA: O cruel, irreligious piety!
-- _Titus Andronicus_, I, i
Alex Martelli
...
> Money does not make interested developers materialize,
Surely you're joking, Mr Kuchling?
Alex
Denis Agar
> >the MFC classes, which are usually in the MFC42.DLL. It can be used from
> >Python via the win32 extensions, which are a relatively slim download.
> >
> >But looking at the included examples, I wouldn't want to develop a GUI
> >using the win32 extensions, as it's basically hardcore win32 API
> >programming.
> .
> .
> .
> Let's note, though, that there are several contributors
> to c.l.p who speak with comfort about having delivered
> applications to customers coded in Python against MFC.
> Gerhard and I haven't, but apparently it's not infeasible.
Ok, try to ignore the thickness of my skull, but you're saying that it
is possible to create progams using mfc42.dll, a GUI that most people
have already? I have the win32 extensions and am in the process of
trying to understand them. (PS: Anyone got some (s)ample code they
could throw my way?)
But, as I understand it, this would be hard.
This isn't a request nor a demand nor a manifesto of any kind, but ---
would it be possible to make a simple PythonCardish GUI shaping-type
languagey thing (I'm not yet up on the lingo) that interfaces with the
win32 extensions and dumbs it down to about my level? I'm just
wondering about it is all. . .
Dylan Reinhardt
> Ok, try to ignore the thickness of my skull, but you're saying that it
> is possible to create progams using mfc42.dll, a GUI that most people
> have already? I have the win32 extensions and am in the process of
> trying to understand them. (PS: Anyone got some (s)ample code they
> could throw my way?)
You might find this walkthrough helpful/useful/amusing:
http://www.onlamp.com/pub/a/python/excerpts/chpt20/?page=5
Dylan
Alex Martelli
...
> Ok, try to ignore the thickness of my skull, but you're saying that it
> is possible to create progams using mfc42.dll, a GUI that most people
> have already? I have the win32 extensions and am in the process of
Yes, with Python and a simple add-on you can choose to reuse any DLL
you may have lying around. win32all (PythonWin in particular) does
that for MFC specifically. Other add-ons such as the oldie (but
goldie) calldll, and the newer (and more powerful) ctypes, let you
do that for ANY dll (with more Python-side work to adapt it). Good
luck -- it IS, of course, lower-level programming than typical Python
work, since you want to use DLLs designed for lower-level languages.
> trying to understand them. (PS: Anyone got some (s)ample code they
> could throw my way?)
> But, as I understand it, this would be hard.
Of course it would.
> This isn't a request nor a demand nor a manifesto of any kind, but ---
> would it be possible to make a simple PythonCardish GUI shaping-type
> languagey thing (I'm not yet up on the lingo) that interfaces with the
> win32 extensions and dumbs it down to about my level? I'm just
> wondering about it is all. . .
The anygui project, anygui.sf.net, aims to design a uniform wrapper
that can use most any GUI toolkit as a back-end -- this would include
(at least potentially) MFC, or the bare Win32 API's, etc. It's not
moving very fast, but there's nothing specific holding it back save
for big ambitions and scarce time being spent on it;-). Once anygui
is stable, and there exists a working back-end for your chosen GUI
toolkit[s], it would surely be possible to write a screen-painter
front-end on top of it -- there is no conceptual block against that.
The pragmatical likelihood of this actually happening, like for any
other open-source software project, depends on how likely it is that
some active developers find that investing their time and energy into
it "scratches their itch". anygui's slow progress so far seems to
suggest that, while intellectually interesting and stimulating, it
may not speak to an actual NEED of its developers -- so, it becomes a
"back-burner", "in our copious spare time" project, and those do not
tend to move forwards all that rapidly.
Alex
Graham Fawcett
Alex, are you demonstrating the materialization of an interested
developer? ;-)
I think there are a lot of things that could motivate a developer to
contribute time:
money,
pride in workmanship,
sense of contribution,
sense of community and belonging,
unabashed praise from colleagues,
too much free time on hand,
invitations to Python conferences,
win-a-lunch-date-with-the-BDFL opportunities,
t-shirts ("import me", "I hacked Python and made the world a better
place for thousands of developers, and all I got was this lousy
t-shirt"),
plaques and certificates for the den,
thinkgeek toys,
prepaid slashdot subscriptions,
O'Reilly gift certificates,
prepaid Internet access or server hosting (okay, maybe that's too
much),
...
and of course,
the way that girls go crazy for Python contributors.
Of course we have no infrastructure for this (at least for the ones
that cost money). But I'm sure we could create one if the need arose.
If it would help to move our goals along, I would gladly pay an annual
Python tax, and/or participate in some kind of token economy. It would
be a small price to pay in return for the *tremendous* advantages (and
joys!) that the Python community provides to me.
In short, I think we should all send $20 a year to Guido, in return
for which he will dress in a toga once a month and do a
deus-ex-machina to bless and thank some unsuspecting Python
contributor on our common behalf.
-- Graham
A.M. Kuchling
> Of course we have no infrastructure for this (at least for the ones
> that cost money). But I'm sure we could create one if the need arose.
Two sites were created for this purpose, SourceExchange and Cosource. Both
are now dead and gone, which should tell you something. Such a tip-jar
system produces trivial amounts of money, $20 or $100. If you had $50K to
spend, you could hire a developer to work on something for 40 hours a week,
but that amount of money is not found in a tip jar.
The limited resource is not money, it's time, and tiny amounts of cash are
not sufficient incentive to make someone allocate time to a project. Most
developers have lots and lots of projects they can spend time on, some
software-related, some not; their projects multiply over time. The solution
is to add more people, expanding the amount of time available, instead of
using money to affect the allocation of a shrinking pool of available time.
Many projects will still never be completed, in that model.
--amk (www.amk.ca)
MACBETH: Throw physic to the dogs; I'll none of it.
-- _Macbeth_, V, iii
John J. Lee
> JpC> > Is the app that generates these available (commercially or for
> free)?
> JJL> Probably py2exe or McMillan Installer, I imagine.
>
> Nope.... neither one. I used Python itself and other programs, as described
> in separate posting.
Yes, I read your post. You said you did some kind of manual hack to
package your app, but clearly you have some system for your web page
packager (neat, BTW :-), which you didn't specify.
So, does your thing work better on space than the alternatives? Maybe
it's worth making it available if so...
John
Cameron Laird
A.M. Kuchling <a...@amk.ca> wrote:
>On 24 Apr 2003 06:56:51 -0700,
> Graham Fawcett <graham_...@hotmail.com> wrote:
>> Of course we have no infrastructure for this (at least for the ones
>> that cost money). But I'm sure we could create one if the need arose.
>
>Two sites were created for this purpose, SourceExchange and Cosource. Both
there were FAR less successful than expected.
One of the characteristics of software is that
we deal with enormous temporal ranges (from
microseconds to minutes, in a typical appli-
cation; as engineering goes, that's a big
factor). It's impressive that the effici-
ency of our work structures can be almost
equally far removed from the smooth output of
some of its work products.
>are now dead and gone, which should tell you something. Such a tip-jar
>system produces trivial amounts of money, $20 or $100. If you had $50K to
>spend, you could hire a developer to work on something for 40 hours a week,
>but that amount of money is not found in a tip jar.
.
[stuff I don't follow,
but perhaps is true]
.
Dennis Reinhardt
> package your app,
I have posted a 390 KB starter Python Hello World that runs on a Windows
computer without Python at: http://www.spamai.com/hello/hello.zip.
Decompress to a directory and click on runmain.bat. The runmain.bat file
contains:
bin\python.exe bin\main.py
exit
The main.py program is not too complicated either:
import sys
sys.path = [".", ".\\bin", ".\\bin\\libstd", ".\\bin\\libxtra"]
import os
def write_file_basic (filepath, filecontents):
emfile_open_flags = os.O_WRONLY+os.O_CREAT+os.O_TRUNC+os.O_BINARY
emf = os.open(filepath, emfile_open_flags)
os.write(emf, filecontents)
os.close(emf)
html= """<html>
<head><title>Hello from Python</title></head>
<body bgcolor=#e8fbfe>
<h1>Sss...</h1>(how Pythons say "hello")<p>
current directory: %s
</body></html>
""" % os.getcwd()
write_file_basic("hello.html", html)
os.startfile("hello.html")
sys.exit(0)
The path bin/libstd contains the library files needed to import os. If you
call more functions, add to path bin/libstd or bin/libxtra.
Writing an html file and then shelling to it is just to get started. For my
own app, I wrote a socket-level http server and call that.
Maintaining this "manual hack" is far less effort than you would guess. I
have not had to revise the library files I use for months now. It is very
clear when one is missing and what needs to be added.
> but clearly you have some system for your web page
> packager (neat, BTW :-), which you didn't specify.
Errr..., that's right, I didn't specify how I did it. I have abandoned this
particular approach myself and describing what is going on is tough There
is lots of non-portable stuff in there.
Instead, I have posted code for the approach I am actually using above.
The general approach for the web page is that I coded a stub in my own
compiler language (www.pld2.com) which embedded python and library code. At
run time, this is extracted from the exe and run. The exe file has internal
pointers which the online Perl code can use to patch the stub code to
produce a custom exe. Cross-program dependencies abound.
> So, does your thing work better on space than the alternatives? Maybe
> it's worth making it available if so...
Yes 390 KB is smaller than any other solution I am aware of. I just have
made it available. Thanks for you interest.
Oh, btw, I made a zip file available above because lots of people can access
this format. The same file compressed with WinRar in rar format is about 80
KB smaller. WinRar provides a self-extracting format also.
Alex Martelli
> Alex Martelli <al...@aleax.it> wrote in message
> news:<F3Epa.51023$LB6.1...@news1.tin.it>...
>> A.M. Kuchling wrote:
>> ...
>> > Money does not make interested developers materialize,
>>
>> Surely you're joking, Mr Kuchling?
>
> Alex, are you demonstrating the materialization of an interested
> developer? ;-)
Just asserting it;-). Put ENOUGH money [or goods and services
worth money, as are many of those you list] as the reward for
some activity, and people interested in that activity WILL magically
materialize, just like that. Many of them will be people that
would normally still be interested, but not have time due to their
engagement in other gainful activities (because e.g. raising a
family does cost a lot of money, and to a lesser extent do so many
creature comforts).
> and of course,
> the way that girls go crazy for Python contributors.
Well, THAT, too (I didn't *know*, when I fell in love with Python,
that it would help me connect with the most wonderful woman in the
world -- but, had I known, I'd surely have jumped into it sooner).
> Of course we have no infrastructure for this (at least for the ones
> that cost money). But I'm sure we could create one if the need arose.
I'm not so sure, myself -- but it's sure worth trying.
> If it would help to move our goals along, I would gladly pay an annual
> Python tax, and/or participate in some kind of token economy. It would
> be a small price to pay in return for the *tremendous* advantages (and
> joys!) that the Python community provides to me.
>
> In short, I think we should all send $20 a year to Guido, in return
That's the kind of thing the Python Sofware Foundation is going to
aim for -- collect small (or large!-) donations (tax-deductible, too,
for US citizens), and use them to fund Python development (and/or
other such Pythonic activities). Stay tuned for further announcements...
Alex
Cameron Laird
Alex Martelli <al...@aleax.it> wrote:
>Denis Agar wrote:
> ...
>> Ok, try to ignore the thickness of my skull, but you're saying that it
>> is possible to create progams using mfc42.dll, a GUI that most people
>> have already? I have the win32 extensions and am in the process of
>
>Yes, with Python and a simple add-on you can choose to reuse any DLL
>you may have lying around. win32all (PythonWin in particular) does
>that for MFC specifically. Other add-ons such as the oldie (but
>goldie) calldll, and the newer (and more powerful) ctypes, let you
>do that for ANY dll (with more Python-side work to adapt it). Good
>luck -- it IS, of course, lower-level programming than typical Python
>work, since you want to use DLLs designed for lower-level languages.
.
.
>The anygui project, anygui.sf.net, aims to design a uniform wrapper
>that can use most any GUI toolkit as a back-end -- this would include
>(at least potentially) MFC, or the bare Win32 API's, etc. It's not
.
.
All true, of course.
I want to emphasize again that, for the specific question
of construction of Python-scripted GUI applications, it is
not necessary to comprehend the full generality of these
possibilities. Mark Hammond and his beneficiaries have
successfully used win32all (or PythonWin) to write such
programs.
Dennis Reinhardt
There is something I forgot to mention. Suppose you start with a decent
size app already? You do not have to go through and add files to this
structure 1-by-1.
To seed this structure initially, comment out the sys.path line so that you
are using your system python path. Now, delete *.pyc where the *.py exists.
Run your program and exercise its functions. Exit. Now, where *.pyc files
exist in the system python path, you need to copy the .py files to a
subdirectory listed in sys.path.
In one step, you have now populated your subdirectories with the required
libraries. There may be other files that you will end up needing and
restoring the sys.path statement will quickly find them.
Gerhard Häring
Poor man's modulefinder, eh? Neat :-)
-- Gerhard
John J. Lee
[John Lee wrote:]
> > Yes, I read your post. You said you did some kind of manual hack to
> > packager (neat, BTW :-), which you didn't specify.
>
> Errr..., that's right, I didn't specify how I did it. I have abandoned this
I didn't intend any implied criticism, Dennis -- I was just explaining
why I naturally assumed you were using a pre-existing solution rather
than your own thing to make your Python-packaging web page.
> particular approach myself and describing what is going on is tough There
> is lots of non-portable stuff in there.
>
> Instead, I have posted code for the approach I am actually using above.
Cool.
John
Courageous
>Just asserting it;-). Put ENOUGH money [or goods and services
>worth money, as are many of those you list] as the reward for
>some activity, and people interested in that activity WILL magically
>materialize, just like that.
This is correct. For $200K a year, I'd probably even write programs
in Perl. :-)
C//