[Spambayes] Training by the command line on Windows

[Tim Peters]

[papDoc]
> Is there a way to train using the command line on windows ?
>
> This is what I get with sb_mboxtrain
>
> Microbe% cripts/sb_mboxtrain.py -d hammie.db -g Tata/26
<
> ...
>     import fcntl
> ImportError: No module named fcntl

Windows doesn't support fcntl -- that's a Unixism.  Ditto os.ftruncate().

> If I look in my python directory I see a file FCNTL.py saying
> import warnings
> warnings.warn("the FCNTL module is deprecated; please use fcntl",
>               DeprecationWarning)
>
> But I can't find the fcntl.py ???

On Unix boxes there's no fcntl.py either, and the import of fcntl is
satisfied by C code in Python's fcntlmodule.c.  That isn't compiled on
Windows because the OS simply doesn't support it.

> Then I said lets try to go further so I copied the file FCNTL.py to
> fcntl.py and then I get errors from lockf.

That's futile -- but you already learned that <wink>.

> I said  I don't need lock since I  know  what  I'm doing.

Now you're cooking!

> Commented this out then I get error from
>   os.ftruncate(f.fileno(), 0)

Replacing that one with

    f.seek(0)
    f.truncate()

instead might work on Windows, or maybe plain

    f.truncate(0)

would work.  It depends on what (if anything) the program assumes about the
position of the file pointer after the truncate.

> so before I remove all the code from the program I say let ask
> what should I do !!

You're doing fine -- Python supports ways of writing portable code, but
doesn't *force* people to write portable code, and "it's a feature" that
Python exposes OS-specific facilities for those who want them.  It's a fact
of life, though, that Unix-heads tend to write the least portable code,
because there are so many gimmicks unique to Unixish systems.  On Windows,
we tend to hide the Windows-specific gimmicks in modules with discouraging
names instead (like winsound and _winreg).