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