On Thu, 30 Apr 2009 at 11:26, glyph at divmod.com wrote: > On 08:25 am, martin at v.loewis.de wrote: >> > Why did you choose an incompatible approach for PEP 383? >> >> Because in Python, we want to be able to access all files on disk. >> Neither Java nor Mono are capable of doing that. > > Java is not capable of doing that. Mono, as I keep pointing out, is. It uses > NULLs to escape invalid UNIX filenames. Please see: > > http://go-mono.com/docs/index.aspx?link=T%3AMono.Unix.UnixEncoding > > "The upshot to all this is that Mono.Unix and Mono.Unix.Native can list, > access, and open all files on your filesystem, regardless of encoding." And then it goes on to say: "You won't be able to pass non-Unicode filenames as command-line arguments."(*) Not only that, but you can't reliably use such files with System.IO (whatever that is, but it sounds pretty basic). This support is only available "within the Mono.Unix and Mono.Unix.Native namespaces". Now, I don't know what that means (never having touched Mono), but it doesn't sound like it simplifies cross-platform support, which is what PEP 383 is aiming for. So it doesn't sound like Mono has solved the problem that Martin is trying to solve, even if it is possible to put Unix specific code into your Mono ap to deal with byte filenames on disk from within your GUI. FWIW I'm +1 on seeing PEP 383 in 3.1, if Martin can manage the patch in time. --David (*) I'd argue that in an important sense that makes Martin's statement about Mono being unable to access all files on disk a true statement; but, then, I freely admit that I have a bias against GUI programs in general :)
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