[Python-ideas] IntFlags

[random832 at fastmail.us]

On Fri, Mar 6, 2015, at 11:09, Andrew Barnert wrote:
> Classic Mac didn't provide anything remotely close to the POSIX APIs.
> IIRC, you called FSSpecMake to create an FSSpec structure from a volume
> ID, directory ID, and bare filename, then called FSSpecOpenDF with it,
> after which you'd call various other APIs to map blocks of data to memory
> handles.
> 
> For that matter, Win16 and early Win9x didn't have anything quite like
> the POSIX APIs, but mapping CreateFile and HANDLE values to open and file
> descriptors wouldn't be quite as ridiculous as mapping FSSpecOpenDF and
> refnum values.

In both cases, open/read/write are in the libraries provided with the
commonly available C compilers on the platform (MPW or Codewarrior in
the Mac case, MSVC or Borland etc in the Windows/DOS case), and it
doesn't really matter that they're not part of the platform proper.

I don't think there's ever been a compiler for Windows or DOS that
_didn't_ provide these functions. It depends on how you define "quite
like" the POSIX APIs, I guess.

Anyway, the source code of the os module for classic mac clearly shows
that it is implemented in terms of pre-existing POSIX-like functions
provided either by the supported build platforms or by something called
"GUSI", rather than directly in terms of the native API.
https://hg.python.org/cpython/file/364638d6434d/Mac/Modules/macmodule.c
- you have to go further back to find a version of python that actually
had dosmodule.c, but it looks basically the same.

> At any rate, I think os.open has always been only available on Unix and
> NT.

Nope. List of functions on the os module on Mac in python 2.0:
https://docs.python.org/release/2.0/mac/module-mac.html

> The whole point of it is to interface with libraries that want to use
> file descriptors or to access platform-specific features; if you want
> cross-platform files, you just call open.

The os module provides the same interface on all platforms _so that_ the
higher-level functions like builtin open can be implemented in terms of
it. It's the implementation (and list of available functions) that's
different between platforms, not the interface.

> That's why the API is so close
> to the POSIX API; if it tried to wrap things up at a higher level, it
> wouldn't be able to provide access to flags that only Solaris offers,
> etc.

Your theory doesn't explain listdir and walk.

The reason the API is so close to the POSIX API is because the work of
emulating that API was already done on these platforms in order to
support ports of Unix C programs, and because no-one saw any value in
supporting platform-specific features not exposed through that layer.