Question: posix fcntl module

Sheila King sheila at
Wed Aug 29 07:18:32 CEST 2001

On Wed, 29 Aug 2001 00:32:00 -0400 (EDT), Ignacio Vazquez-Abrams
<ignacio at> wrote in comp.lang.python in article
<mailman.999059623.9527.python-list at>:

:On Wed, 29 Aug 2001, Sheila King wrote:
:> On Tue, 28 Aug 2001 20:02:51 -0400 (EDT), Ignacio Vazquez-Abrams
:> <ignacio at> wrote in comp.lang.python in article
:> <mailman.999043423.30546.python-list at>:
:>  [snip]
:> :Also, you should make it so that the file is immediately opened in __init__(),
:> Why? I don't see any persuasive reason for that. The methods that I'm
:> using under windows don't allow for me to separate the action of opening
:> the file and obtaining the lock (there is a single command which does
:> both), and I wanted to keep the functions between the windows and the
:> posix versions as close to parallel as possible. In any case, I can't
:> see any compelling reason for the file opening to occur in the init
:> function.
:I just finished talking with a friend who's done more recent Win32 development
:than me, and he claims that you can reopen the file (without closing it) using
:the aforementioned API function again in order to apply a lock. It sounds
:fishy to me too, but it might be worth a shot.

I'm sorry. You lost me here.
The windows function I'm using (which was mentioned elsewhere) is
CreateFile. Whether or not I can reopen the file without having closed
it is immaterial to my module, since my unlock function closes the file
and deletes the file handle.

What am I supposed to "give a shot" to???

So far, my windows code is all performing as I expect (not that I've
shared it here...). That may be partly why I'm confused by this segue
into discussing the Windows implementation.

Sheila King

More information about the Python-list mailing list