fcntl semantics

[buzmeg at newsguy.com]

I've had to deal with fcntl directly for a while now and was thinking of moving
my C programs to Python.  However, the OS dependence of the packed structure
used to access fcntl pretty much stops that idea cold.  So, my question is:

Why does fcntl use a packed struct as it's third argument?  And why does it
throw away the return code in that case?

That particular mechanism actually goes out of its way to lose data.  The
complier knows the correct form of struct to put the data in when it compiles
the modules, throws it away, the user has to dig out what that structure was,
and then hard code it into the Python code.  Additionally, it throws away the
error/return code when you pass it a packed struct as the final argument.

I can think of several ways that it could be coded, but the one I find the most
appealing is:

fcntl(fd,op,arg):
    arg is a hash -- keys are fcntl struct member names -- vals are values
    return value is a hash in same form
    Exception raised on error with return/error value in exception object

All the information from the C function fcntl is accessible without any of the
nasty OS/compiler dependence.  It even allows future extension to the fcntl
structs to be accomodated without changing the language semantics.  It also
doesn't require in place modification of data so it has a low surprise factor. 
In addition, the type of arg is different and identifiable from the previous
form of fcntl (thus, previous semantics can even be preserved if desired).

I would really like to know if there is a good reason for requiring packed data
for fcntl (Perl does the same blasted thing), and, if not, the proper mechanism
for attempting to get this changed in the language.  I would even write the
code, if required.

Thanks,
Andy L.