Re: [Python-Dev] FormatError() in callproc.c under win32
> From: eckha...@satorlaser.com > To: python-dev@python.org > Subject: Re: [Python-Dev] FormatError() in callproc.c under win32 > Date: Tue, 27 Jan 2009 12:16:01 +0100 > CC: coder_infi...@hotmail.com > > On Monday 26 January 2009, Martin v. Löwis wrote: > > > In callproc.c from trunk is a function called SetException(), which calls > > > FormatError() only to discard the contents. Can anyone enlighten me to > > > the reasons thereof? The left over call to FormatError() looks like a mistake to me. > > > > Interestingly enough, the code used to say > > > >PyErr_SetString(PyExc_WindowsError, lpMsgBuf); > > > > Then it was changed to its current form, with a log message of > > > >Changes for windows CE, contributed by Luke Dunstan. Thanks a lot! > > > > See > > > > > http://ctypes.cvs.sourceforge.net/viewvc/ctypes/ctypes/source/callproc.c?hideattic=0&r1=1.127.2.15&r2=1.127.2.16 > > > > I suggest you ask Thomas Heller and Luke Dunstan (if available) what the > > rationale for this partial change was. > > I can only guess: > 1. Those changes seem to generate TCHAR strings. This is necessary to compile > it on both win9x (TCHAR=char) and CE (TCHAR=wchar_t). Since win9x was dropped > from the supported platforms, that isn't necessary any more and all the code > could use WCHAR directly. As far as I remember TCHAR was char for Windows NT/2K/XP Python builds too, at least at that time, but yes it would be clearer to use WCHAR instead now. > 2. Those changes also seem to change a few byte-strings to Unicode-strings, > see format_error(). This is a questionable step, since those are changes that > are visible to Python code. Worse, even on the same platform it could return > different string types when the lookup of the errorcode fails. I wonder if > that is intentional. Probably not intentional. Yes, it would be better if the return value was either always char or always WCHAR. > > In any case, CCing Luke on the issue, maybe he can clarify things. > > cheers > > Uli Good luck, Luke ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python for Windows CE
Hi, I would like to explore the possibility of submitting patches to allow Python to work on Windows CE out of the box. I have a few questions in preparation: 1. Is there any reason in principle why patches for Windows CE support would be rejected? 2. Should I submit unified diffs or context diffs? One page says: "Context diffs are preferred, so generate the patch using diff -c." http://www.python.org/dev/tools/ Another says: "We like unified diffs. We grudgingly accept contextual diffs..." http://www.python.org/dev/patches/ 3. The page http://www.python.org/dev/patches/style/ says that platform-specific code should use preprocessor symbols documented for the compiler, but existing Python code uses e.g. the invented MS_WIN32 symbol instead of the standard _WIN32. Should we create a symbol MS_WINCE for consistency or use the more common _WIN32_WCE? 4. The latest existing patch set uses os.name = "ce", and this can be used to distinguish Windows CE from other operating systems in Python code. The existing patches also set sys.platform = "Pocket PC", but I am not so keen on keeping this, mainly because Windows CE is equivalent to Win32 in many cases. Any comments? 5. Windows CE lacks some header files that are present on other platforms, e.g. . If we ignore the actual declarations in the header for a moment, there are a few ways to solve this problem: (a) The obvious solution is to wrap each #include inside #ifndef MS_WINCE...#endif (b) Instead we could use #ifdef HAVE_DIRECT_H, requiring patches to #define HAVE_DIRECT_H for other platforms (c) The existing patch set uses a simpler solution by creating a (possibly empty) direct.h in a Windows CE-specific subdirectory of the Python source tree, and adding that directory to the compiler include path. This means that the source files probably won't need to be patched and it may help when building C extension modules. Is there any objection to the method (c) of providing missing headers? What is the preferred solution? In later emails I will of course go into more detail about the patches required. Any general tips on how to submit good patches are welcome. Thanks, Luke Dunstan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for Windows CE
- Original Message - From: ""Martin v. Löwis"" <[EMAIL PROTECTED]> To: "Luke Dunstan" <[EMAIL PROTECTED]> Cc: Sent: Thursday, May 04, 2006 5:03 AM Subject: Re: [Python-Dev] Python for Windows CE > Luke Dunstan wrote: >> 1. Is there any reason in principle why patches for Windows CE support >> would >> be rejected? > > No, not in principle. Of course, > - the patch shouldn't break anything > - you should state an explicit commitment to support the port for > some years (or else it might get removed at the slightest problem) Thanks for your response. I hope I can continue to support Python for Windows CE for a while at least. >> 4. The latest existing patch set uses os.name = "ce", and this can be >> used >> to distinguish Windows CE from other operating systems in Python code. >> The >> existing patches also set sys.platform = "Pocket PC", but I am not so >> keen >> on keeping this, mainly because Windows CE is equivalent to Win32 in many >> cases. Any comments? > > I would guide the decision based on the number of API changes you need > to make to the standard library (e.g. distutils). In any case, the > platform module should be able to reliably report the specific system > (including the specific processor architecture). OK. Actually I think distutils will be the last thing to be ported because it is not necessary for using the rest of Python. Does distutils has support for cross-compiling anyway? > >> (b) Instead we could use #ifdef HAVE_DIRECT_H, requiring patches to >> #define >> HAVE_DIRECT_H for other platforms > > That would be best. Python generally uses autoconf methodology, which > implies that conditionally-existing headers should be detected using > HAVE_*_H. > > Regards, > Martin OK, but what about ANSI C headers like signal.h? I expected HAVE_SIGNAL_H to exist already but I just came across this patch: http://svn.python.org/view/python/trunk/pyconfig.h.in?rev=35255&r1=35221&r2=35255 I am guessing that the reason for this patch was to reduce the number of #ifdefs in the Python source to ease maintenance. Would you want to add some of them back again? Luke ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] MSVC 6.0 patch
Hi, This patch submitted in March allows Python trunk to be built using MSVC 6: http://sourceforge.net/tracker/index.php?func=detail&aid=1457736&group_id=5470&atid=305470 It is not my patch but I am quite interested because the code changes are also required to build with MS eMbedded Visual C++ 4.0, the Windows CE 4.x compiler. I'm guessing that the person assigned to the patch is too busy so I hope somebody else can take over? Thanks, Luke ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46064 - in python/trunk: Include/Python.h Include/pyport.h Misc/ACKS Misc/NEWS Modules/_localemodule.c Modules/main.c Modules/posixmodule.c Modules/sha512module.c P
- Original Message - From: ""Martin v. Löwis"" <[EMAIL PROTECTED]> To: "Neal Norwitz" <[EMAIL PROTECTED]> Cc: "Python Dev" Sent: Tuesday, May 23, 2006 2:38 PM Subject: Re: [Python-Dev] [Python-checkins] r46064 - in python/trunk: Include/Python.h Include/pyport.h Misc/ACKS Misc/NEWS Modules/_localemodule.c Modules/main.c Modules/posixmodule.c Modules/sha512module.c PC/pyconfig.h Python/thread_nt.h > Neal Norwitz wrote: >> What is the reason for the DONT_HAVE_* macros? Can we use the HAVE_* >> versions? > > I think the actual rationale is that the contributor didn't want to be > bothered with modifying configure.in, and running autoconf. I thought that smaller patches would generally be preferred, but yes it is also more effort to modify configure, especially when doing development on Windows. In the case of errno.h there was already 3 occurrences of DONT_HAVE_ERRNO_H in the source and no occurrences of HAVE_ERRNO_H, and I wanted to be consistent. > I accepted the change since systems which don't have, say, , > are "unusual", in the sense that they aren't standard C systems > (as standard C mandates errno.h, atleast in a hosted environment). > So far, only one target platform doesn't have these things (Windows > CE), so the reasoning is that the burden of setting things right > should be on that system. Yes, this is also my reasoning and is supported by the comments in Include/pyport.h about sys/stat.h. > Of course, it would be fairly straight-forward to convert this > to standard autoconf machinery (if one remembers to update > PC/pyconfig.h accordingly). I'm sure Luke Dunstan would be willing > to revise the patch in that direction if that is agreed. > > Regards, > Martin Yes, I can do that. But what about the other 3 versions of pyconfig.h in platform subdirectories? Luke ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
