Recently, "Martin v. Loewis" <martin@v.loewis.de> said:
> > That's the global, sure but the code using it is scattered
> > across fileobject.c and the posix module. I think it would be
> > a good idea to put all this file naming code into some
> > Python/fileapi.c file which then also provides C APIs for
> > extensions to use. These APIs should then take the file name
> > as PyObject* rather than char* to enable them to handle
> > Unicode directly.
>
> What do you gain by that? Most of the posixmodule functions that take
> filenames are direct wrappers around the system call. Using another
> level of indirection is only useful if the fileapi.c functions are
> used in different places.
Well, I only know about the Mac and (to a lesser extent) about
Windows, but there's lots of methods that are not in
{posix,mac,nt}module.c there that want filenames. And I think mmap
also uses filenames, no? All in all I'm in favor of a single place
where file name encoding magic is handled. Whether a fileapi.c is
needed or something simpler can do the trick (a PyArg_Parse fmt that
returns two items: the filename to use plus a routine you're expected
to call on it before you return?) I'm not sure.
--
- Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma Goldman -
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