> Are you willing to monitor and fix new Py_USING_UNICODE issues or
> are you proposing just to produce a patch now and then expect
> contributors to maintain this feature?
Neither, I suppose, or perhaps both. I am proposing to produce a patch
now which fixes the non-Unicode build under Windows.
Larry Hastings:
> As for future development of Windows-specific Python features...
> doesn't that generally happen in modules, rather than the Python
> interpreter, these days? Either in Mark Hammond's pywin32 (what used
> to be called "win32all"), or perhaps done in Python using ctypes.
> There
Neil Hodgson wrote:
>> - There will be some opposition to the obvious policy of "keeping
>> the bare minimum inside the DLL" because of inefficiencies in the
>> Python build system.
>
> It is also non-optimal for those that do want the full set of
> modules as separate files can add overhead f
There are exactly four non-Unicode build breakages in the Python source
tree that are Win32-specific. Two are simply a matter of #if, two also
require new alternative code (calls to PyString_FromStringAndSize()).
All told, my changes to Win32-specific code to fix Py_USING_UNICODE
consists of exact
"Larry Hastings" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Second of all, the dumb-as-a-bag-of-rocks Windows linker (at least
> the one used by VC++ under MSVS .Net 2003) *links in unused static
> symbols*. If I want to excise the code for a module, it is not
> sufficient to co
Giovanni Bajo:
> - There will be some opposition to the obvious policy of "keeping the bare
> minimum inside the DLL" because of inefficiencies in the Python build
> system.
It is also non-optimal for those that do want the full set of
modules as separate files can add overhead for block si
Larry Hastings:
> First and foremost: turning off Py_USING_UNICODE *breaks the build*
> on Windows. The following list of breakages were all fixed with
> judicious applications of #ifdef Py_USING_UNICODE:
> * The implementation of "multi-byte codecs" (CJK codecs) implicitly
> assumes that they
I myself wonder why python.dll can't just load a companion i18n.dll
when and if it's called for in the script. Such as by having week
references to those functions and loading the dll as needed.And
probably throwing an exception if it can't be loaded. Most of the CJK
stuff could then be carried in
Larry Hastings wrote:
> First and foremost: turning off Py_USING_UNICODE *breaks the build*
> on Windows.
Probably nobody does that nowadays. My own feeling (but I don't have numbers
for backing it up) is that the biggest size in the .DLL is represented by
things like the CJK codecs (which are ab
Larry Hastings wrote:
> Of course, it's not the most important thing in the world--after all,
> I'm the first person to even *notice*, right? But it seems a shame
> that
> one can break the build so easily. If it pleases the stewards of
> Python, I would be happy to submit patches that fix the no
I'm an indie shareware Windows game developer. In indie shareware
game development, download size is terribly important; conventional
wisdom holds that--even today--your download should be 5MB or less.
I'd like to use Python in my games. However, python24.dll is 1.86MB,
and zips down to 877k. I
11 matches
Mail list logo
