[Python-Dev] RE: Python on Windows chapter.

[Tim Peters]

[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