A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2010-November/105537.html below:

[Python-Dev] Removal of Win32 ANSI API

[Python-Dev] Removal of Win32 ANSI APIVictor Stinner victor.stinner at haypocalc.com
Fri Nov 12 13:13:08 CET 2010
On Thursday 11 November 2010 21:02:43 Antoine Pitrou wrote:
> On Thu, 11 Nov 2010 20:44:52 +0100
> 
> "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > > How do you support cross-platform code using bytes filenames?
> > > IIRC, it has already been argued that it was an important feature. Many
> > > filesystem-related utilities might prefer to handle filenames in bytes
> > > form.
> > 
> > It would be a policy decision. However, I think it is hear-say that
> > filesystem-related utilities might prefer byte file names.
> 
> One possible situation is when you receive filenames in bytes form from
> an external API or tool (or even the contents of a file). If you don't
> know the encoding, keeping the bytes form is obviously recommended.

I disagree with you: the filename stored in the binary content/network stream 
may be encoded with a different code page than the current Windows code page. 
The application have to decode the filename itself, the application has more 
information about the right encoding than Windows.

Examples:
 - MKV video stores filenames in utf-8
 - ZIP stores filenames in cp437 or utf-8
 - tar stores filenames... in the locale encoding (except for PAX format which 
uses utf-8)
 - etc.

Victor
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4