str() not displaying names

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

str() not displaying names

Etienne Sanchez
In some cases, str() does not print the "names" attribute of the object:

u <- structure(c(5, 6), names = c("a", "b"), color = "blue")
str(u)
#  atomic [1:2] 5 6
#  - attr(*, "color")= chr "blue"

Is it a bug or a design choice?

Originally asked here:
https://stackoverflow.com/q/47185756/6656269

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: str() not displaying names

Martin Maechler
[This is a "re-post" -- for some reason it never appeared on R-devel]

>>>>> Etienne Sanchez <[hidden email]>
>>>>>     on Tue, 14 Nov 2017 19:33:07 +0100 writes:

> In some cases, str() does not print the "names" attribute of the object:
>
> u <- structure(c(5, 6), names = c("a", "b"), color = "blue")

> str(u)
> #  atomic [1:2] 5 6
> #  - attr(*, "color")= chr "blue"
>
> Is it a bug or a design choice?


> Originally asked here:
> https://stackoverflow.com/q/47185756/6656269

It's not a bug in the sense that a long time ago -- when I wrote
the first version of str(), for S-plus, before R existed --
I had decided that when  is.vector(.) was false, for whatever
reason, the atomic vectors should be shown as above.

I don't remember if S-plus used the same somewhat surprising
definition of is.vector(.) as R does (but I think it did):
it is only TRUE for a vector that has no other attributes than
possibly "names".

I did occasionally find that the historical choice probably was
not quite the best in hindsight, but never got convinced that it
should be changed...
Once I'll have finished the  deparse/dput/dump changes in
R-devel (hopefully within a week), and as R-devel has quite a
few small changes to R <= 3.4.x anyway, I may consider to change
utils:::str.default here  ... and have a few dozens of package
maintainers and R users live with the fact the str() outputs
will have changed in late spring next year ...

Notably if you or other give convincing reasons why it's worth
to change... but note that it's quite easy to give "Pro"
reasons, but there are "Cons" and for such cases a lot of "Cons"
are related to "there must 100's of 1000s of R code lines using
str(), and so there will be 100s of places where the output
changes, ( ... but then I'd guestimate that the change would be
to the better in most cases).


Martin

--
Martin Maechler, ETH Zurich


> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: str() not displaying names

Martin Maechler
>>>>> Martin Maechler <[hidden email]>
>>>>>     on Thu, 16 Nov 2017 22:00:16 +0100 writes:

    > [This is a "re-post" -- for some reason it never appeared
    > on R-devel]
>>>>> Etienne Sanchez <[hidden email]>
>>>>> on Tue, 14 Nov 2017 19:33:07 +0100 writes:

    >> In some cases, str() does not print the "names" attribute
    >> of the object:
    >>
    >> u <- structure(c(5, 6), names = c("a", "b"), color =
    >> "blue")

    >> str(u) # atomic [1:2] 5 6 # - attr(*, "color")= chr
    >> "blue"
    >>
    >> Is it a bug or a design choice?


    >> Originally asked here:
    >> https://stackoverflow.com/q/47185756/6656269

    > It's not a bug in the sense that a long time ago -- when I
    > wrote the first version of str(), for S-plus, before R
    > existed -- I had decided that when is.vector(.) was false,
    > for whatever reason, the atomic vectors should be shown as
    > above.

    > I don't remember if S-plus used the same somewhat
    > surprising definition of is.vector(.) as R does (but I
    > think it did): it is only TRUE for a vector that has no
    > other attributes than possibly "names".

    > I did occasionally find that the historical choice
    > probably was not quite the best in hindsight, but never
    > got convinced that it should be changed...  Once I'll have
    > finished the deparse/dput/dump changes in R-devel
    > (hopefully within a week), and as R-devel has quite a few
    > small changes to R <= 3.4.x anyway, I may consider to
    > change utils:::str.default here ... and have a few dozens
    > of package maintainers and R users live with the fact the
    > str() outputs will have changed in late spring next year
    > ...

    > Notably if you or other give convincing reasons why it's
    > worth to change... but note that it's quite easy to give
    > "Pro" reasons, but there are "Cons" and for such cases a
    > lot of "Cons" are related to "there must 100's of 1000s of
    > R code lines using str(), and so there will be 100s of
    > places where the output changes, ( ... but then I'd
    > guestimate that the change would be to the better in most
    > cases).

I have been daring (again!)  and did change  str()   so it will
typically no longer print the ominous  "atomic" in such cases.

This is for "R-devel" with svn rev >= 73780 ..

It will slightly change str() output for such cases, but in the
half a dozen cases I've looked the cases were always for the
better.

Martin

--
Martin Maechler
ETH Zurich and R Core

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel