object.enable() anti-pattern

Cameron Simpson cs at zip.com.au
Fri May 10 18:25:41 EDT 2013


On 10May2013 09:22, Roy Smith <roy at panix.com> wrote:
| In article <518cc239$0$29997$c3e8da3$5496439d at news.astraweb.com>,
|  Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
| > > int fd = 37;
| > > 
| > > I've just created a file descriptor.  There is not enough information
| > > given to know if it corresponds to an open file or not.
| > 
| > No, you haven't created a file descriptor. You've made up a number which 
| > C will allow you to use as an index into the file descriptor table, 
| > because C is a high-level assembler with very little in the way of type 
| > safety, and what little there is you can normally bypass.
| 
| No, I've created a file descriptor, which is, by definition, an integer. 
| It has nothing to do with C.  This is all defined by the POSIX 
| interface.  For example, the getdtablesize(2) man page says:
| 
| "The entries in the descriptor table are numbered with small integers 
| starting at 0.  The call getdtablesize() returns the size of this table."
[... snip ...]

I'm with Steven here.

You've made a number that can be used with calls that access the
OS file descriptor table. But it isn't a file descriptor. (Yes, the
in-program number is just a number either way.)

The descriptor table is an in-kernel data structure, filled with
file descriptors. All you have is a label that may or may not access
a file descriptor.

Anyway, we all know _what_ goes on. We're just having terminology issues.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au>

My computer always does exactly what I tell it to do but sometimes I have
trouble finding out what it was that I told it to do.
        - Dick Wexelblat <rlw at ida.org>



More information about the Python-list mailing list