minimal python27.dll?

[est]

Hi guys,

I need to ship python runtime environment package on Windows, if I
want to stripping unnessasery functions from python27.dll to make it
as small as possible(and perhaps finally UPX it), which parts of
python27.dll do you think can be removed?

From what I think, these parts are not needed when shipping with final
end-user product:

1. debugging
2. parse text .py files, because everything is already in bytecode

Any ideas? Critics?

Thanks in advance!

[Tim Golden]

On 27/04/2011 11:43, est wrote:
> I need to ship python runtime environment package on Windows, if I
> want to stripping unnessasery functions from python27.dll to make it
> as small as possible(and perhaps finally UPX it), which parts of
> python27.dll do you think can be removed?

Perhaps have a look at tinypy?

http://www.tinypy.org/

Even if it's not exactly what you want, I expect that the
author will have useful ideas / experience.

TJG

[Martin v. Loewis]

You really should be looking at object sizes first. In your build
of Python, find out what object files are largest, and check whether
they can be removed or shrinked. Starting with functions that you know
you won't need isn't as productive, as it likely leads only to small
reductions. E.g. you'll find that there is actually no debugging
support in python27.dll anymore that is worth stripping.

OTOH, you'll also find that the CJK codecs use quite some space,
if you don't need them, they give a rather impressive reduction.
Likewise for the Unicode database, although you may actually need
it in some cases.

I'd rather go for a static build of Python, and let the linker figure
out what's needed.

Regards,
Martin

[Ryan Kelly]

On Wed, 2011-04-27 at 22:06 +0200, Martin v. Loewis wrote:
> Am 27.04.2011 12:43, schrieb est:
> > Hi guys,
> >
> > I need to ship python runtime environment package on Windows, if I
> > want to stripping unnessasery functions from python27.dll to make it
> > as small as possible(and perhaps finally UPX it), which parts of
> > python27.dll do you think can be removed?
> >
>

> I'd rather go for a static build of Python, and let the linker figure
> out what's needed.

I have vague recollections that pythonXY.dll could not be statically
linked on Windows, or that doing so causes some serious loss of
functionality. Was this ever true, and is it still?

Cheers,

Ryan

--
Ryan Kelly
http://www.rfk.id.au | This message is digitally signed. Please visit
ry...@rfk.id.au | http://www.rfk.id.au/ramblings/gpg/ for details

[est]

On Apr 27, 11:15 pm, Tim Golden <m...@timgolden.me.uk> wrote:
> Perhaps have a look at tinypy?
>
>    http://www.tinypy.org/
>
> Even if it's not exactly what you want, I expect that the
> author will have useful ideas / experience.
>
> TJG

Thanks, but I still need the completeness of CPython. AFAIK TinyPy is
a python implementation from scratch

On Apr 28, 4:06 am, "Martin v. Loewis" <mar...@v.loewis.de> wrote:
>
> OTOH, you'll also find that the CJK codecs use quite some space,
> if you don't need them, they give a rather impressive reduction.
> Likewise for the Unicode database, although you may actually need
> it in some cases.

On the CJK issue, why python ship its own codec, not using OS builtin?

If I don't need the full Unicode5.1 can I just map python's unicode
functions to some Win32 unicode API?

[Martin v. Loewis]

> I have vague recollections that pythonXY.dll could not be statically
> linked on Windows, or that doing so causes some serious loss of
> functionality. Was this ever true, and is it still?

You'll have to rebuild Python to make use of static linkage, of course,
but then: it is certainly possible. The main functionality that you
lose is the ability to load extension modules (.pyd files). Whether
that's a serious loss or not depends on your application - in cases
where you want static linkage, you can often accept not being able
to do dynamic linkage.

Regards,
Martin

[Martin v. Loewis]

> I have vague recollections that pythonXY.dll could not be statically
> linked on Windows, or that doing so causes some serious loss of
> functionality. Was this ever true, and is it still?

You'll have to rebuild Python to make use of static linkage, of course,

[Martin v. Loewis]

> On the CJK issue, why python ship its own codec, not using OS builtin?

The OS doesn't provide all the codecs that Python provides. For the one
it does provide, it behaves semantically different in border cases from
the ones that come with Python.

> If I don't need the full Unicode5.1 can I just map python's unicode
> functions to some Win32 unicode API?

That should be possible - but I doubt it's a matter of "just".

Regards,
Martin