[Python-Dev] ctypes is in SVN now.

[Giovanni Bajo]

Thomas Heller <theller at python.net> wrote:

>>> Ideally this would be integrated with distutils because the
>>> setup-script has most of the information that's needed.
>>>
>>> OTOH, extensions could be built with distutils even for core
>>> Python, and even on Windows.  For extensions that are *not* builtin
>>> or not included with Python itself distutils works good enough.
>>
>> I fear this is an orthogonal change. Alas, using distutils to build
>> core extensions is not something I'm ready to tackle at the moment.
>>
>> I was just thiking of something much more naive like using a free
>> tool to build .vcproj/.sln (see www.cmake.org for instance) from a
>> script description. With such a tool, it would be very easy to build
>> a .pyd file around a self-contained .c file (like _heapqmodule.c,
>> etc.), it would mostly be a couple of line changes in the script
>> file, and then re-run the tool executable to regenerate vcproj/sln.
>> OTOH, both the tool executable (cmake.exe in this example) and the
>> current version of the generated vcproj/sln files would be committed
>> in SVN under PCbuild, so to have a minimal impact on developer
>> habits.
>
> While I don't understand *why* you would want to do this (building
> Python interpreters with a customized list of builtin modules could be
> a reason for this, I've had thought about something like that for py2exe
> a long time ago),

That's exactly the reason: packaged executables. I'm sure there is still
some weird encoding in world, with 2Mb of cute codec data tables, which is
only waiting for people to find out and merge it into python.dll -- because
it's harder to maintain it as an external .pyd with the current PCbuild.
That's unreasonable IMVHO. CJK codecs *ought* to be distributed as an
external .pyd.
-- 
Giovanni Bajo