Another wish (?) for R 4.0.0: print(*, width = <n>)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Another wish (?) for R 4.0.0: print(*, width = <n>)

Martin Maechler
One of the things I often wish R would work with:

When calling print() explicitly --- as I do not so rarely, e.g.,
specifying  digits = <nd> ---
it sometimes seems awkward that from the printing options() ,
one can specify 'digits' and it has default  digits = NULL which is
documented to be equivalent to  digits = getOption("digits"),
but one cannot specify 'width'
... well "even worse": one *can* specify 'width = .' but it is
silently ignored - as well documented  on  ?print.default

Before considering to add this for R 4.0.0, doing the work
myself, I'd quickly wanted to hear opinions / caveats / .. about this.

wishing you all a  Happy New Year,
Martin

Martin Maechler
ETH Zurich and R Core Team

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

Re: Another wish (?) for R 4.0.0: print(*, width = <n>)

R devel mailing list
 For whatever my 2c are worth I think this would be nice.  I'm still uncomfortable at having to call `options` in my package `diffobj` to set output width.

And since the topic is here, what about `show`?  Feels like it should accept `...` so that it too could be given some set of standard or non standard parameters, including `width`.
Happy new decade.
B.

    On Tuesday, January 7, 2020, 6:58:32 AM EST, Martin Maechler <[hidden email]> wrote:  
 
 One of the things I often wish R would work with:

When calling print() explicitly --- as I do not so rarely, e.g.,
specifying  digits = <nd> ---
it sometimes seems awkward that from the printing options() ,
one can specify 'digits' and it has default  digits = NULL which is
documented to be equivalent to  digits = getOption("digits"),
but one cannot specify 'width'
... well "even worse": one *can* specify 'width = .' but it is
silently ignored - as well documented  on  ?print.default

Before considering to add this for R 4.0.0, doing the work
myself, I'd quickly wanted to hear opinions / caveats / .. about this.

wishing you all a  Happy New Year,
Martin

Martin Maechler
ETH Zurich and R Core Team

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

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

Re: Another wish (?) for R 4.0.0: print(*, width = <n>)

Henrik Bengtsson-5
On Tue, Jan 7, 2020 at 6:14 AM brodie gaslam via R-devel
<[hidden email]> wrote:
>
>  For whatever my 2c are worth I think this would be nice.  I'm still uncomfortable at having to call `options` in my package `diffobj` to set output width.

Adding a few more cents: It might be worth considering "who" should be
allow to control the 'width' argument.  In an interactive session,
it's neat for the user to quickly be able to adjust 'width'.  But in
what cases should this be controlled by a (package) developer?  What
assumptions can the developer safely make about the 'width' of the end
user?  I don't know the answer to this and I'm sure one can find valid
cases where it makes sense to set the 'width' in a package - maybe
like width = 0.90 * getOption("width", 80)?

Could it be that print() ignoring 'width' has protected us from
packages producing output with a fixed, hardcoded width that is set by
the developer?  If print() us updated to acknowledge 'width', will we
start seeing print(..., width = 120) and so on in package code?  Is
this good or bad?  This might be a complementary problem to what we
have with 'stringsAsFactors' where the user's settings can override
the intention of the developer.

/Henrik





>
> And since the topic is here, what about `show`?  Feels like it should accept `...` so that it too could be given some set of standard or non standard parameters, including `width`.
> Happy new decade.
> B.
>
>     On Tuesday, January 7, 2020, 6:58:32 AM EST, Martin Maechler <[hidden email]> wrote:
>
>  One of the things I often wish R would work with:
>
> When calling print() explicitly --- as I do not so rarely, e.g.,
> specifying  digits = <nd> ---
> it sometimes seems awkward that from the printing options() ,
> one can specify 'digits' and it has default  digits = NULL which is
> documented to be equivalent to  digits = getOption("digits"),
> but one cannot specify 'width'
> ... well "even worse": one *can* specify 'width = .' but it is
> silently ignored - as well documented  on  ?print.default
>
> Before considering to add this for R 4.0.0, doing the work
> myself, I'd quickly wanted to hear opinions / caveats / .. about this.
>
> wishing you all a  Happy New Year,
> Martin
>
> Martin Maechler
> ETH Zurich and R Core Team
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> [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: Another wish (?) for R 4.0.0: print(*, width = <n>)

Pages, Herve
In reply to this post by R devel mailing list
On 1/7/20 06:13, brodie gaslam via R-devel wrote:
...
> Happy new decade.

  *** caught segfault ***
conflicting decade boundaries

Traceback:
  1: new_decade <- 2020:2029
  2: previous_decade <- 2011:2020
  3: previous_previous_decade <- 2001:2010
  4: current_millenium <- 2001:3000
  5: previous_millenium <- 1001:2000
  6: previous_previous_millenium <- 1:1000

Cheers,
H.


--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: [hidden email]
Phone:  (206) 667-5791
Fax:    (206) 667-1319
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Another wish (?) for R 4.0.0: print(*, width = <n>)

Iñaki Ucar
On Wed, 8 Jan 2020 at 02:05, Pages, Herve <[hidden email]> wrote:
>
> On 1/7/20 06:13, brodie gaslam via R-devel wrote:
> ...
> > Happy new decade.
>
>   *** caught segfault ***
> conflicting decade boundaries

https://xkcd.com/2249/ ;-)

>
> Traceback:
>   1: new_decade <- 2020:2029
>   2: previous_decade <- 2011:2020
>   3: previous_previous_decade <- 2001:2010
>   4: current_millenium <- 2001:3000
>   5: previous_millenium <- 1001:2000
>   6: previous_previous_millenium <- 1:1000
>
> Cheers,
> H.

Iñaki

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

Re: Another wish (?) for R 4.0.0: print(*, width = <n>)

Martin Maechler
In reply to this post by Henrik Bengtsson-5
>>>>> Henrik Bengtsson
>>>>>     on Tue, 7 Jan 2020 13:31:18 -0800 writes:

    > On Tue, Jan 7, 2020 at 6:14 AM brodie gaslam via R-devel
    > <[hidden email]> wrote:
    >>
    >> For whatever my 2c are worth I think this would be nice.  I'm still uncomfortable at having to call `options` in my package `diffobj` to set output width.

    > Adding a few more cents: It might be worth considering "who" should be
    > allow to control the 'width' argument.  

Well, I tend to disagree; this is not about control (and playing
police .. ;-).
Everbody can set  options() even now and that is a pretty bad
thing unless they are properly localized
{with which I mean: It's +- okay, if you use

- in a function

   op <- options(..) ; on.exit(options(op))

- in a script

   op <- options(..)

   ................
   ................

   options(op)

}
and yes I know people even invented  withOptions(...) etc.

Good programmring style for *functions* according to my book is
to have them depend only on their arguments, and if a global
option really (reall? think twice!) should influence behavior,
there should be arguments of the function which have a default
determined by the global option.

{ And then in my personal style book, global options should never
  influence anything but "output" {print, plot, ..} and so the
  stringsAsFactors global option is an atrocity and horror ......}


    > In an interactive session,
    > it's neat for the user to quickly be able to adjust 'width'.  But in
    > what cases should this be controlled by a (package) developer?  

packages can set global options now which is much worse than
using it explicitly in some function calls.

Making 'width' an explicit argument {only in some cases, you
cannot do it for auto-printing of course!}

    > What assumptions can the developer safely make about the 'width' of the end
    > user?  I don't know the answer to this and I'm sure one can find valid
    > cases where it makes sense to set the 'width' in a package - maybe
    > like width = 0.90 * getOption("width", 80)?

Indeed.
I also would want to set width in  tests/*.R where I use *.Rout.save
or even more often in \examples{..} in help pages
when printing things that look best, say with  width=111
rather than the default 80.


    > Could it be that print() ignoring 'width' has protected us from
    > packages producing output with a fixed, hardcoded width that is set by
    > the developer?  If print() us updated to acknowledge 'width', will we
    > start seeing print(..., width = 120) and so on in package code?  Is
    > this good or bad?  This might be a complementary problem to what we
    > have with 'stringsAsFactors' where the user's settings can override
    > the intention of the developer.

    > /Henrik

A good package developer will think many times before doing that
(but maybe do it in examples, as I mentioned); careless package
developers do all kind of things anyway.
R (and free software in general) is also about giving freedom to
useRs ..  .. and some of us old folks know that with freedom
comes responsibility ..

Thank you, Henrik, for your valuable thoughts!


[Brodie G.:]
    >> And since the topic is here, what about `show`?  Feels like it should accept `...` so that it too could be given some set of standard or non standard parameters, including `width`.

I'm not proposing to touch show().
Very often when working with S4 objects, I devise a
sophisticated print() method, with defaults, (often times "smart",
i.e. depending on other arguments) for all but the first
argument and then the show() method just calls that print method.

Best, Martin


    >> Happy new decade.
    >> B.
    >>
    >> On Tuesday, January 7, 2020, 6:58:32 AM EST, Martin Maechler <[hidden email]> wrote:
    >>
    >> One of the things I often wish R would work with:
    >>
    >> When calling print() explicitly --- as I do not so rarely, e.g.,
    >> specifying  digits = <nd> ---
    >> it sometimes seems awkward that from the printing options() ,
    >> one can specify 'digits' and it has default  digits = NULL which is
    >> documented to be equivalent to  digits = getOption("digits"),
    >> but one cannot specify 'width'
    >> ... well "even worse": one *can* specify 'width = .' but it is
    >> silently ignored - as well documented  on  ?print.default
    >>
    >> Before considering to add this for R 4.0.0, doing the work
    >> myself, I'd quickly wanted to hear opinions / caveats / .. about this.
    >>
    >> wishing you all a  Happy New Year,
    >> Martin
    >>
    >> Martin Maechler
    >> ETH Zurich and R Core Team

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