MMap "access" keyword, choice of exception class

[Tim Peters]

[Jay Todd Miller]
> I have written (and submitted) a patch which adds a  new keyword
> parameter to mmap: "access".  One dubious kind of access which I added
> for the sake of completeness is "readonly".  A readonly mmap maps true
> OS protected readonly memory and does not update the underlying file.

I don't think that's dubious; if you're accessing, e.g., a critical data
file, readonly mode can be a comfort.  Besides, some file sources don't
support writing at all.

> When python detects and attempt to write a readonly mmap, an exception
> is raised;  Is there an obvious choice for what the exception class
> should be?
>
> I need to re-submit the patch for a few stylistic issues anyway, and
> would like to fix this while I'm at it.  Right now, the
> patch raises ValueError.  SystemError and RuntimeError also come to
> mind.

SystemError is used for things that "can't happen" -- a SystemError is
Python telling you that something is insane in Python's own implementation.
For example, if the Python Virtual Machine sees an undefined bytecode; it's
akin to an assert.

RuntimeError is generally used for obscure insanity caused by user code.
For example, if the PRINT_ITEM opcode discovers that the user has deleted
sys.stdout.  Python won't stop you from doing that, but if you do then some
parts of Python just can't work anymore.  RuntimeError is also used when
forbidden operations are attempted when in restricted execution made.

TypeError may fit best:  the mmap object is of a flavor that doesn't support
modification.  TypeError is what you get if, e.g., you try to assign to a
readonly attribute, or to a component of an immutable container, and those
are at least vaguely related.