On Tuesday 30 September 2008, Martin v. Löwis wrote:
Ulrich Eckhardt wrote:
Well, currently it does make a difference. Simple example:
CreateFile().
It's not so simple: Python doesn't actually call CreateFile
Martin, CreateFile() was just used as an example. You can substitute it
On Friday 26 September 2008, Martin v. Löwis wrote:
Please don't. Whether or not _UNICODE is defined should have no effect.
Well, currently it does make a difference. Simple example: CreateFile().
It's not so simple: Python doesn't actually call CreateFile, AFAICT
(well, it does, in
Ulrich Eckhardt wrote:
Well, currently it does make a difference. Simple example: CreateFile().
It's not so simple: Python doesn't actually call CreateFile
Martin, CreateFile() was just used as an example. You can substitute it with
LoadString() or CreateProcess() if you like, the problem
On Thursday 25 September 2008, Martin v. Löwis wrote:
1. TCHAR is always WCHAR
Python shouldn't be using TCHAR at all; that getpathp uses it is
misguided (IMO).
It already does, see below...
The first point is interesting to the desktop win32 variants because
everything since NT4 (or
Please don't. Whether or not _UNICODE is defined should have no effect.
Well, currently it does make a difference. Simple example: CreateFile().
It's not so simple: Python doesn't actually call CreateFile, AFAICT
(well, it does, in _msi.c, but I hope you aren't worried about that
module on
On Wednesday 24 September 2008, Neal Norwitz wrote:
In general, we try to ensure that there is an active maintainer,
preferably more than one. As long as it doesn't make the code that
much harder to maintain, it is desirable to support more platforms.
Actually, looking at the sources, there
1. TCHAR is always WCHAR
Python shouldn't be using TCHAR at all; that getpathp uses it is
misguided (IMO).
The first point is interesting to the desktop win32 variants because
everything since NT4 (or even 3.x) also used UCS2 or UTF-16 internally. Only
win9x and ME(?) use 8-bit chars, and
Martin v. Löwis wrote:
- Is anyone already working on this? I know that Brad Clements made an attempt
some years ago but didn't get it integrated, are there any others? Maybe even
any ongoing work?
My understanding is that Python works fairly well on CE as-is, so no
significant patches
I used to follow the Python-CE list. I believe that Luke Dunstan (who
has done the most recent work on a port) discussed a previous attempt to
get the patch-set accepted into trunk but it was rejected because it
required too *many* changes.
Perhaps. But I also recall committing patches that
Greetings!
I'm currently trying to assess the effort required for a CE port. I'm already
aware of the project at http://pythonce.sourceforge.net, but I find it a
waste of time to have two separate projects which then require syncing
changes back and forth.
Questions:
- What are the feelings
On Tue, Sep 23, 2008 at 1:52 AM, Ulrich Eckhardt
[EMAIL PROTECTED] wrote:
Greetings!
I'm currently trying to assess the effort required for a CE port. I'm already
aware of the project at http://pythonce.sourceforge.net, but I find it a
waste of time to have two separate projects which then
11 matches
Mail list logo