Python linker

[byteschreck@googlemail.com]

I love python - I use it as a utility language to complement my C#
programming every day. However, the reason I do not use it as my
primary language is - surprise, surprise - not its lack of static type
checking, but the size of standalone executes (which embed the python
runtime).

Would it be possible to link only the used functions into your
resulting executable? After all, a typical application might only use
20% of everything that is in the Python .dlls.

The same applies to wxPython - it would be great if you could only link
in what you need. Would it be possible to write such linkers at all
(maybe based on GCC)?

[Sion Arrowsmith]

Re: Python linker

<byteschreck@go oglemail.comwro te:

>I love python - I use it as a utility language to complement my C#
>programming every day. However, the reason I do not use it as my
>primary language is - surprise, surprise - not its lack of static type
>checking, but the size of standalone executes (which embed the python
>runtime).

Er, what? How are you generating your standalone executables? What
size is "acceptable "? python24.dll is only 1.8M -- surely on any
non-embedded platform these days 1.8M isn't worth bothering about.
And since you mention wx (all of another 4.8M) I'd guess we're
talking about desktop applications. Who's going to notice if your
executable is a couple of M slimmer?

--
\S -- siona@chiark.gr eenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[Irmen de Jong]

Re: Python linker

byteschreck@goo glemail.com wrote:

I love python - I use it as a utility language to complement my C#
programming every day. However, the reason I do not use it as my
primary language is - surprise, surprise - not its lack of static type
checking, but the size of standalone executes (which embed the python
runtime).

Why not just install Python itself,
so that all of your python programs are only a few Kb each.
Because they all use the single shared installation.

--Irmen

[tac-tics]

Re: Python linker


byteschreck@goo glemail.com wrote:

I love python - I use it as a utility language to complement my C#
programming every day. However, the reason I do not use it as my
primary language is - surprise, surprise - not its lack of static type
checking, but the size of standalone executes (which embed the python
runtime).
>
Would it be possible to link only the used functions into your
resulting executable? After all, a typical application might only use
20% of everything that is in the Python .dlls.
>
The same applies to wxPython - it would be great if you could only link
in what you need. Would it be possible to write such linkers at all
(maybe based on GCC)?

For your distribution, just move your DLLs to the appropriate system
folder. That's what DLLs do. You throw them in system32, forget they
were there in the first place, and the Linker Troll does the rest for
you.

[byteschreck@googlemail.com]

Re: Python linker

I develop shareware applications that need to be extremely slim (less
than 1 MB is preferable).

Delphi applications easily meet this requirement and I can expect end
users to download the .NET framework (if they don't already have it!).

However, I cannot expect users to download 3.5 MB.

For corporate clients, size does not matter the least, but for end
users, anything that is a couple of megs seems "bloated".

For your distribution, just move your DLLs to the appropriate system
folder. That's what DLLs do. You throw them in system32, forget they
were there in the first place, and the Linker Troll does the rest for
you.

[Simon Brunning]

Re: Python linker

On 18 Jul 2006 08:01:22 -0700, byteschreck@goo glemail.com
<byteschreck@go oglemail.comwro te:

I develop shareware applications that need to be extremely slim (less
than 1 MB is preferable).
>
Delphi applications easily meet this requirement and I can expect end
users to download the .NET framework (if they don't already have it!).

So, they'll download and install the .NET framework at 23 MB, but they
won't download and install Python at 9 and half?

--
Cheers,
Simon B,
simon@brunningo nline.net,

http://www.brunningonline.net/simon/blog/

[Ben Sizer]

Re: Python linker

Simon Brunning wrote:

So, they'll download and install the .NET framework at 23 MB, but they
won't download and install Python at 9 and half?

I think the .NET framework gets thrown down via Windows Update - or at
least it did for me - so that doesn't count as a 'separate download'
for many purposes.

--
Ben Sizer

[Ben Sizer]

Re: Python linker

Sion Arrowsmith wrote:

Er, what? How are you generating your standalone executables? What
size is "acceptable "? python24.dll is only 1.8M -- surely on any
non-embedded platform these days 1.8M isn't worth bothering about.
And since you mention wx (all of another 4.8M) I'd guess we're
talking about desktop applications. Who's going to notice if your
executable is a couple of M slimmer?

I've considered making a few lightweight GUI apps in the past but you
just can't do it with wxPython. When you have similar products done in
Visual C++ weighing in at kilobytes rather than megabytes, it's hard to
convince people that it's worth downloading your product. Say I wanted
to develop a simple Notepad clone with 1 or 2 extra features: the MS
executable is 68Kb, yet to simulate it in wxPython would be over 5MB;
nobody would want it. I suppose you can use the msvcrt library directly
and cut out wx from the dependencies, but sadly the Python overhead is
still a slight deterrent.

Not that I see an easy solution to this, of course.

--
Ben Sizer

[Larry Bates]

Re: Python linker

Don't use wx, use native Windows controls that already
exist on the machine. That makes the application very small.

That said, I disagree that 3.5Mb is too much to download. It
only takes about 7 seconds on my machine (cable modem). If your
users won't wait that long, they weren't very interested in your
application.

-Larry


byteschreck@goo glemail.com wrote:

I develop shareware applications that need to be extremely slim (less
than 1 MB is preferable).
>
Delphi applications easily meet this requirement and I can expect end
users to download the .NET framework (if they don't already have it!).
>
However, I cannot expect users to download 3.5 MB.
>
For corporate clients, size does not matter the least, but for end
users, anything that is a couple of megs seems "bloated".
>

>For your distribution, just move your DLLs to the appropriate system
>folder. That's what DLLs do. You throw them in system32, forget they
>were there in the first place, and the Linker Troll does the rest for
>you.

>

[John J. Lee]

Re: Python linker

Sion Arrowsmith <siona@chiark.g reenend.org.ukw rites:
[...]

Who's going to notice if your executable is a couple of M slimmer?

Anybody with a modem.


John

[John J. Lee]

Re: Python linker

Larry Bates <larry.bates@we bsafe.comwrites :
[...]

That said, I disagree that 3.5Mb is too much to download. It
only takes about 7 seconds on my machine (cable modem). If your
users won't wait that long, they weren't very interested in your
application.

[...]

For some markets (very far from all, of course!), that attitude sounds
like a recipe for failure.


John

[Alex Martelli]

Re: Python linker

Ben Sizer <kylotan@gmail. comwrote:

Sion Arrowsmith wrote:

Er, what? How are you generating your standalone executables? What
size is "acceptable "? python24.dll is only 1.8M -- surely on any
non-embedded platform these days 1.8M isn't worth bothering about.
And since you mention wx (all of another 4.8M) I'd guess we're
talking about desktop applications. Who's going to notice if your
executable is a couple of M slimmer?

>
I've considered making a few lightweight GUI apps in the past but you
just can't do it with wxPython. When you have similar products done in
Visual C++ weighing in at kilobytes rather than megabytes, it's hard to
convince people that it's worth downloading your product. Say I wanted

What framework (if any) is your Visual C++ code using? If it's using
wxWidgets (the framework underlying wxPython) I very much doubt that it
can be a few kilobytes -- unless the wxWidgets DLL is already installed
on the target machines so that it doesn't need to be packaged together
with the application code.

to develop a simple Notepad clone with 1 or 2 extra features: the MS
executable is 68Kb, yet to simulate it in wxPython would be over 5MB;
nobody would want it. I suppose you can use the msvcrt library directly
and cut out wx from the dependencies, but sadly the Python overhead is
still a slight deterrent.
>
Not that I see an easy solution to this, of course.

The easy solution is to compare apples with apples: if, in your
application space, it is crucial to use only DLLs that are already
installed on the target machines, you can do that from Python (with
ctypes, for example) just as you can from C. Of course, coding to
(e.g.) the Win32 API directly is not to everybody's tastes, but it's
just about as bad in any language.

Of course, if you believe that the runtime libraries for a given
language (Visual Basic N for some specific value of N, Visual C++ M for
some specific value of M, ...) are going to be already installed on the
target machine, then the hypothetical constraint says that you must use
that specific language and version. For example, nobody will ever
program applications in VB6, because at some point in time the runtime
libraries for VB5 were widespread and those for VB6 were not, so a
program prepared for VB5 could be distributed as a much-smaller package.

What generally happens in the real world is rather different:
applications get programmed in whatever language and release/version is
handy, and the runtimes are separately offered for download and install
to those users who have not yet installed any previous application using
the same language and release/version. For example, msvcr80.dll is
indispensable to use programs written with Microsoft Visual Studio 2005,
and you'll find thousands of sites on the web offering it for separate
download and installation; mfc80u.dll, similarly (albeit only at
hundreds of sites;-); and so on, and so forth.

The situation is quite similar for other languages, Python included, and
other frameworks, wxWidgets (and wxPython on top it it) included.


Alex

[Alex Martelli]

Re: Python linker

<byteschreck@go oglemail.comwro te:

I develop shareware applications that need to be extremely slim (less
than 1 MB is preferable).
>
Delphi applications easily meet this requirement and I can expect end
users to download the .NET framework (if they don't already have it!).
>
However, I cannot expect users to download 3.5 MB.
>
For corporate clients, size does not matter the least, but for end
users, anything that is a couple of megs seems "bloated".

So use IronPython -- that's what it's for, after all: letting you write
Python applications for .NET. See
<http://www.codeplex.co m/Wiki/View.aspx?Proje ctName=IronPyth on>: it's
now in Beta9 and the final non-beta release should be out soon.


Alex

[Ben Sizer]

Re: Python linker

Alex Martelli wrote:

What framework (if any) is your Visual C++ code using? If it's using
wxWidgets (the framework underlying wxPython) I very much doubt that it
can be a few kilobytes -- unless the wxWidgets DLL is already installed
on the target machines so that it doesn't need to be packaged together
with the application code.

Sure, I meant without wxWidgets.

The easy solution is to compare apples with apples: if, in your
application space, it is crucial to use only DLLs that are already
installed on the target machines, you can do that from Python (with
ctypes, for example) just as you can from C.

But even that is sadly not practical, since the Python DLL alone is
about 30 times the size of a tiny app like Notepad (for example).

What generally happens in the real world is rather different:
applications get programmed in whatever language and release/version is
handy, and the runtimes are separately offered for download and install
to those users who have not yet installed any previous application using
the same language and release/version.

The real world is a big and diverse place, and I assure you that my
applications are no less real than your own! :) Sometimes you simply
cannot pick a language and version at leisure and expect everybody to
install whatever is required. There are some things - casual
entertainment products for example, or one-shot system checking tools,
etc - where people are reluctant to install anything at all, and will
not bother if they see a 6MB download.

I wasn't saying this was a problem with Python - though I do expect
that .dll could be trimmed down a bit - but it is a bit of a shame that
I can't easily distribute something less than 1MB in size using Python.

--
Ben Sizer