[Tim]
't' is not ANSI C, so there's no guarantee that it's portable. Hate to say it, but Python should really strip t out before passing a mode string to fopen!
[Greg Stein]
Should we also filter the socket type when creating sockets? Or the address family?
Filtering 't' is a matter of increasing portability by throwing out an option that doesn't do anything on the platforms that accept it, yet can cause a program to die on platforms that don't -- despite that it says nothing. So it's helpful to toss it, not restrictive.
What if I pass "bamboozle" as the fopen mode? Should that become "bab" after filtering? Oh, but what about those two "b" characters?
Those go far beyond what I suggested, Greg. Even so <wink>, it would indeed help a great many non-C programmers if Python defined the mode strings it accepts & barfed on others by default. The builtin open is impossible for a non-C weenie to understand from the docs (as a frustrated sister delights in reminding me). It should be made friendlier. Experts can use a new os.fopen if they need to pass "bamboozle"; fine by me; I do think the builtins should hide as much ill-defined libc crap as possible (btw, "open" is unique in this respect).
Maybe just reduce it to one? We also can't forget to filter chmod() arguments... can't have unknown bits set.
I at least agree that chmod has a miserable UI <wink>.
etc etc
In other words, I think the idea of "stripping out the t" is bunk. Python is not fatherly. It gives you the rope and lets you figure it out for yourself. You should know that :-)
So should Mark -- but we have his testimony that, like most other people, he has no idea what's "std C" and what isn't. In this case he should have noticed that Python's "open" docs don't admit to "t"'s existence either, but even so I see no reason to take comfort in the expectation that he'll eventually be hanged for this sin. ypu-i'd-rather-"open"-died-when-passed-"t"-ly y'rs - tim