Mark Hammond wrote: > > > It may be necessary to call different routines depending on whether > > you have a byte or a character string; this is not something a getargs > > converter can do. It also may be that, depending on which system > > routine you call, the system will *return* either wide or narrow > > strings to you. Every time you find another use of file names, Marc > > suggests you put that into fileapi.c. > > I'm sure that is not what Marc meant. I think he simply meant a conversion > function that would return the filename as either byte or Unicode. Get your > arg from PyArg_ParseTuple, and convert it with this function. What I meant is to move all the file name code from fileobject.c and posixmodule.c to a new file fileapi.c which lives in the Python/ subdir and then let it expose C APIs which the other two files then use in their machinery. It's basically about cleaning up the various bits and pieces in the source code; note that this does not only involve APIs which work on file names, but also other APIs which take filenames as arguments and or return filenames (even though starting out with a file name mapping API would already go a long way). The benefits of such an approach would be two-fold: 1. You centralize the need for #ifdefs and other platform specific quirks in one file. As a result future fixes will only involve this one file. (Py_FileSystemDefaultEncoding should also live in this file, BTW) 2. The C APIs can well be used by other parts of the Python interpreter which need to open and handle files. Extensions would also benefit from this, e.g. they could use the API functions to open files with Unicode names in a cross-platform way using a single API. > Have I missed it all these years, or should we define a PyArg_ParseTuple > format that takes a "void **" and a function pointer to a type conversion > function? Isn't this what "O&" is meant for ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
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