read.table and strip.white

Prof Brian D Ripley <ripley@stats.ox.ac.uk> writes:

On Wed, 31 May 2000, Uwe Ligges wrote:

Prof Brian Ripley wrote:

[...]

I was rather surprised here, and this is not what the prototype does:

  .col1. .col2. .col3.
1      1      1      1
2      2      2      2

Should not strip.white be true for the header line?

If there are no compatibility problems, setting it to TRUE would be
useful ...
But compatibility is an important point, especially in read.table(.), I
think. Many R users have got their own functions using read.table(.), I
suppose. Maybe changing the defaults could break anything?

That's tantamount to saying we should not fix bugs because users might be
relying on the undocumented and unintended behaviour!  Yes, changing this
could change things: for a start the V&R MASS datasets would load correctly
on R without R-specific editing.  Does anyone seriously intend to have
heading spaces in their column names in a data frame? Especially as those
are not S variable names, and as you see S-PLUS (but not R) does enforce
that.  (read.table circumvents that by not using the class
constructor, but S-PLUS has an explicit call to make.names lacking in R.)

I am inclined to make the change _and_ to check the column names.

I tend to agree, recently having had dealings with an SPSS-created
.cvs file with "Height SDS" and so on as variable names. However, it
would seem that the prototype *does* read the leading whitespace and
replaces it with a dot while fixing the names, no? I don't disagree
that we're probably better off without that effect, but if we're going
for compatibility.