Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Neil Hodgson wrote: >>- But then, the wide API gives all results as Unicode. If you want to >> promote only those entries that need it, it really means that you >> only want to "demote" those that don't need it. But how can you tell >> whether an entry needs it? There is no API to find out. > > >I wrote a patch for os.listdir at > http://www.scintilla.org/difft.txt that uses WideCharToMultiByte to > check if a wide name can be represented in a particular code page and > only uses that representation if it fits. This appears to be based on the usedDefault return value of WideCharToMultiByte. I believe this is insufficient: WideCharToMultiByte might convert Unicode characters to codepage characters in a lossy way, without using the default character. For example, it converts U+0308 (combining diaeresis) to U+00A8 (diaeresis) (or something like that, I forgot the exact details). So if you have, say, "p-umlaut" (i.e. U+0070 U+0308), it converts it to U+0070 U+00A8 (in the local code page). Trying to use this as a filename later fails. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Martin v. Löwis: > This appears to be based on the usedDefault return value of > WideCharToMultiByte. I believe this is insufficient: > WideCharToMultiByte might convert Unicode characters to > codepage characters in a lossy way, without using the default > character. For example, it converts U+0308 (combining diaeresis) > to U+00A8 (diaeresis) (or something like that, I forgot the > exact details). So if you have, say, "p-umlaut" (i.e. U+0070 > U+0308), it converts it to U+0070 U+00A8 (in the local code page). > Trying to use this as a filename later fails. There is WC_NO_BEST_FIT_CHARS to defeat that. It says that it will use the default character if the translation can't be round-tripped. Available on WIndows 2000 and XP but not NT4. We could compare the original against the round-tripped as described at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_2bj9.asp Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [C++-sig] GCC version compatibility
On Sun, Jul 17, 2005 at 04:01:20PM +1000, Anthony Baxter wrote: > On Saturday 16 July 2005 20:13, Christoph Ludwig wrote: > > I submitted patch #1239112 that implements the test involving two TUs for > > Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but > > that will take some time. > > I'm only vaguely aware of all of the issues here with linking, but if this > is to be considered for 2.4.2, it needs to be low risk of breaking anything. > 2.4.2 is a bugfix release, and I'd hate to have this break other systems that > work... I prepared the patch for 2.4.2 since it is indeed a bugfix. The current test produces wrong results if the compiler is GCC 4.0 which inhibits a successful build of Python 2.4. I tested the patch with GCC 2.95, 3.3 and 4.0 - those are the only compilers I have easy access to right now. I do not see how this patch could cause regressions on other platforms because it mimics the situation w.r.t. ccpython.cc: A C++ translation unit calls from main() an extern "C" function in a separate C translation unit. The test determines whether it is possible to produce an intact executable if the C compiler is used as linker driver. If this test causes problems on some platform then you'd expect trouble when linking the python executable out of ccpython.o and all the other C object modules anyway. But, of course, I might be wrong. I do not claim that I am familiar with every platform's peculiarities. That's why the patch is up for review. I'd appreciate if users on other platforms test it. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html ___ Python-Dev mailing list [email protected] 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/dist/src/Doc/lib emailutil.tex,1.11,1.12
[EMAIL PROTECTED] wrote:
> Update of /cvsroot/python/python/dist/src/Doc/lib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20654
>
> Modified Files:
> emailutil.tex
> Log Message:
> Note that usegmt is new in 2.4. Closes #1239681.
>
>
> Index: emailutil.tex
> ===
> RCS file: /cvsroot/python/python/dist/src/Doc/lib/emailutil.tex,v
> retrieving revision 1.11
> retrieving revision 1.12
> diff -u -d -r1.11 -r1.12
> --- emailutil.tex 1 Nov 2004 03:59:24 - 1.11
> +++ emailutil.tex 17 Jul 2005 11:47:46 - 1.12
> @@ -103,7 +103,8 @@
> Optional \var{usegmt} is a flag that when \code{True}, outputs a
> date string with the timezone as an ascii string \code{GMT}, rather
> than a numeric \code{-}. This is needed for some protocols (such
> -as HTTP). This only applies when \var{localtime} is \code{False}
> +as HTTP). This only applies when \var{localtime} is \code{False}.
> +New in Python 2.4.
> \end{funcdesc}
>
> \begin{funcdesc}{make_msgid}{\optional{idstring}}
Wouldn't that be \versionadded{2.4}?
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [C++-sig] GCC version compatibility
> I prepared the patch for 2.4.2 since it is indeed a bugfix. The current > test produces wrong results if the compiler is GCC 4.0 which inhibits a > successful build of Python 2.4. I should probably add that I'm not flagging that I think there's a problem here. I'm mostly urging caution - I hate having to cut brown-paper-bag releases . If possible, can the folks on c++-sig try this patch out and put their results in the patch discussion? If you're keen, you could try jumping onto HP's testdrive systems (http://www.testdrive.hp.com/). >From what I recall, they have a bunch of systems with non-gcc C++ compilers, including the DEC^WDigital^Compaq^WHP one on the alphas, and the HP C++ compiler on the HP/UX boxes[1]. (and, it should be added, I very much appreciate the work you've put into fixing this problem) Anthony [1] dunno how useful the HP/UX C++ compiler is going to be - last time I was exposed to it, many years ago, it was... not good. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] 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/dist/src/Doc/lib emailutil.tex,1.11,1.12
Reinhold> Wouldn't that be \versionadded{2.4}?
Yes, thanks. Corrected.
Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Neil Hodgson wrote: >There is WC_NO_BEST_FIT_CHARS to defeat that. It says that it will > use the default character if the translation can't be round-tripped. > Available on WIndows 2000 and XP but not NT4. Ah, ok, that's a useful feature. Of course, limited availability of the feature means that we either need to drop support for some systems, or provide yet another layer of fallback routines. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
