Re: Python linker

[Ben Sizer]

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

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

Re: Python linker

[Alex Martelli]

<[EMAIL PROTECTED]> 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".

So use IronPython -- that's what it's for, after all: letting you write
Python applications for .NET.  See
: it's
now in Beta9 and the final non-beta release should be out soon.


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

Re: Python linker

[Alex Martelli]

Ben Sizer <[EMAIL PROTECTED]> wrote:

> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python linker

[John J. Lee]

Larry Bates <[EMAIL PROTECTED]> writes:
[...]
> 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python linker

[John J. Lee]

Sion Arrowsmith <[EMAIL PROTECTED]> writes:
[...]
> Who's going to notice if your executable is a couple of M slimmer?

Anybody with a modem.


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

Re: Python linker

[Larry Bates]

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


[EMAIL PROTECTED] 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.
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python linker

[Ben Sizer]

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

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

Re: Python linker

[Ben Sizer]

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

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

Re: Python linker

[Simon Brunning]

On 18 Jul 2006 08:01:22 -0700, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> 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!).

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,
[EMAIL PROTECTED],
http://www.brunningonline.net/simon/blog/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python linker

[byteschreck]

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.

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

Re: Python linker

[tac-tics]

[EMAIL PROTECTED] 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.

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

Re: Python linker

[Irmen de Jong]

[EMAIL PROTECTED] 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python linker

[Sion Arrowsmith]

 <[EMAIL PROTECTED]> 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).

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 -- [EMAIL PROTECTED] -- 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
-- 
http://mail.python.org/mailman/listinfo/python-list