As part of this change, a new req.filetype attribute should possibly be added. This is necessary as req.finfo returns a tuple of attributes about the file, but not the request_rec->finfo->filetype attribute.
Other alternative is for finfo to return a class like object that acts like a tuple, but also allows access by name to attributes of structure. In other words like the traditional result of the Python os.stat() function call.
To be able to meaningfully make use of the filtetype attribute, however exposed, there needs to be Python constants for:
APR_NOFILE = 0,
APR_UNKFILE = 127
Because this is an enum where literal values are not assigned to all values, actual literal constants cannot simply be provided in Python module as no gaurantees by ANSI C standard (I think) that successive values will be used. Thus, would need through the mod_python._apache module to expose the actual integer values for these enum values and these would then subsequently be set in the mod_python.apache module.
If existing naming practice in conjunction with variables related to finfo structure are used, the APR_ prefix would be dropped and the constants would be:
mod_python.apache.UNKFILE = 127
Is the use of the unprefixed names acceptable? Do we run the risk over time of having naming collisions if we keep dropping prefixes? Should we instead from now on always keep the prefixes? If we do that, what do we do about all the mod_python.apache.FINFO_* constants? Do we provided prefixed versions, document them and deprecate use of the older variants?
Overall, there are a mix of constants in the mod_python.apache module which do an don't have prefixes. Some really core ones it would not make sense to change to now have prefixes, but some others outside of that core could perhaps be. For example all the URI_* constants. Even if we do not change anything, we need to define a rule/guideline for going forwards.