> > Have you ever heard of os.py? It is an os-independent module that works
> > on DOS, Mac, *or* Unix, depending on what system you are running.
>
> Yes. Its Crap. Feel free to recall my email from a year ago on the
> topic. The short line is that it is totally useless because you dont
> find out your program is going to fail until you get to the os.FOO
> where FOO isnt implemented on that system.
>
> If you write a program that imports 'Posix', then you should, at that
> moment, have a slim gaurentee that all the Posix calls (in the module)
> will work on that platform. Thats the job of the guy making the port.
>
> If you import 'os' then you have to then check its name space
> explicitly to make sure that the calls you are gong to use are in
> there.
>
jredford@lehman.com is correct: "Thats the job of the guy making the port."
If the person porting osmodule to a new system has done the job properly,
then there should be no problems. The same names should be defined in all
portable os modules and that set is documented. (And I've found it
reliable so far.) posix is another matter, as that has been typically used
for whatever posix compatible routines an implementation provides. Maybe
this is a historical mistake, but I suspect that it is because most C
implementations provide SOME subset of posix compatible functions, and so
it's easy to include them there. If you are using posix on a non posix
system - perhaps you do require a routine that's not in os module - then
you should wrap the suspect usage in a try/except clause.
jredford@lehman.com is also correct about some of his other criticisims
about python - in that and previous messages.
However, I think he's being quite disingenuous in the whole package in which
he wraps those criticisms. Neither Perl or Tcl or scheme provide a better
alternative to those problems. He may have other reasons to prefer one of
those languages - they all have their uses and advantages, and none of
them are perfect - but none of them provide the type of type-safety and
module signature checking that he wants from Python, or many of the other
features he seems to find lacking.
SML *does* provide most of those features. I also happen to find it
not as obvious and easy to write as Python. I think (IMHO) functors are
not quite as intuitive as Objects and classes, and it takes time to
think about and write and use signatures properly. That first may just
be part of the learning curve I'll get over, and may also be contingent
on my own history. The second may be a feature - a little thinking before
coding never hurt anyone!
If jredford@lehman.com were arguing that SML provided a better basis
for software engineering than Python, I would have to agree. But Tcl ?
- That's an assertion hard to take seriously!
But he does give a few valid criticisms of Python, mixed in with a bit
of disinformation and misleading and abusive remarks. Replying *TO* him
only seems to encourage the abuse and flames, but I would not throw out
(all) the critisism. ( Anyone volunteer to write a jredford inverse
text filter to remove some of the excess "personality" from the messages?)
BTW: For some informed opinion on Language Wars, see my Language Critiques
Web page at: <http://minsky.med.virginia.edu/sdm7g/LangCrit/>
---| Steven D. Majewski (804-982-0831) <sdm7g@Virginia.EDU> |---
---| Computer Systems Engineer University of Virginia |---
---| Department of Molecular Physiology and Biological Physics |---
---| Box 449 Health Science Center Charlottesville,VA 22908 |---