R devel - Mar 2023 - transform.data.frame() ignores unnamed arguments when no named argument is provided

>>>>> Gabriel Becker 
>>>>>     on Thu, 2 Mar 2023 14:37:18 -0800 writes:
    > On Thu, Mar 2, 2023 at 2:02?PM Antoine Fabri
    > <antoine.fabri at gmail.com> wrote:

    >> Thanks and good point about unspecified behavior. The way
    >> it behaves now (when it doesn't ignore) is more
    >> consistent with data.frame() though so I prefer that to a
    >> "warn and ignore" behaviour:
    >> 
    >> data.frame(a = 1, b = 2, 3)
    >> 
    >> #> a b X3
    >> 
    >> #> 1 1 2 3
    >> 
    >> 
    >> data.frame(a = 1, 2, 3)
    >> 
    >> #> a X2 X3
    >> 
    >> #> 1 1 2 3
    >> 
    >> 
    >> (and in general warnings make for unpleasant debugging so
    >> I prefer when we don't add new ones if avoidable)
    >> 

    > I find silence to be much more unpleasant in practice when
    > debugging, myself, but that may be a personal preference.

+1

I also *strongly* disagree with the claim

   " in general warnings make for unpleasant debugging "

That may be true for beginners (for whom debugging is often not really
feasible anyway ..), but somewhat experienced useRs should know

about
    options(warn = 1) # or
    options(warn = 2) # plus  options(error = recover) #
or
    tryCatch( ...,  warning = ..)

or  {even more}

Martin

--
Martin Maechler
ETH Zurich  and  R Core team

Let me expand a bit, I might have expressed myself poorly.

 If there is a good reason for a warning I want a warning, and because I
take them seriously I don't want my console cluttered with those that can
be avoided. I strongly believe we should strive to make our code silent,
and I like my console to tell me only what I need to know. In my opinion
many warnings would be better designed as errors, sometimes with an
argument to opt in the behaviour, or a documented way to work around. Some
other warnings should just be documented behavior, because the behavior is
not all that surprising.

Some reasons why I find warnings hard to debug:
- options(warn = 1) is not always enough to spot the source of the warning
- options(warn = 2) fails at every warning, including the ones that are not
interesting to the user and that they may not do anything about, in these
cases you'll have to find a way to shut off the first to get to the second,
and if it's packaged code that's not fun.
- Unlike with errors, traceback() won't help.
- tryCatch() will help you only if you call it at the right place, assuming
you've found it.
- We might also have many harmless warnings triggered through loops and
hiding important ones.
- When you are sure that you are OK with your code despite the warning, say
`as.numeric(c("1", "2", "foo"))`, a workaround
might be expensive (here we
could use regex first to ditch the non numeric strings but who does that)
so you're tempted to use `suppressWarnings()`, but then you might be
suppressing other important warnings so you just made your code less safe
because the developper wanted to make it safer (you might say it's on the
user but still, we get suboptimal code that was avoidable).

Of course I might miss some approaches that would make my experience of
debugging warnings more pleasant.

In our precise case I don't find the behavior surprising enough to warrant
more precious red ink since it's close to what we get with data.frame(),
and close to what we get with dplyr::mutate() FWIW, so I'd be personally
happier to have this documented and work silently.

Either way I appreciate you considering the problem.

Thanks,

Antoine

	[[alternative HTML version deleted]]

I am probably mistaken but it looks to me like the design of much of the
data.frame infrastructure not only does not insist you give columns names, but
even has all kinds of options such as check.names and fix.empty.names

https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/data.frame

During the lifetime of a column, it can get removed, renamed, transfomed in many
ways and so on. A data.frame read in from a file such as a .CSV often begins
with temporary created names.

It is so common, that sometimes not giving a name is a choice and not in any way
an error. I have seen some rather odd names in backticks that include spaces and
seen duplicate names. The reality is you can index by column number two and
maybe no actual name was needed by the one creating or modifying the data.

Some placed warnings are welcome as they tend to reflect a possibly serious
error.  But that error may not easily be at this point versus later in the game.
If later the program tries to access the misnamed column, then an error makes
sense. Warnings, if overused, get old quickly and you regularly see code written
to suppress startup messages or warnings because the same message shown every
day becomes something you ignore mentally even if not suppressed. How many times
has loading the tidyverse reminded me it is shadowing a few base R functions?
How many times have I really cared?

What makes some sense to me is to add an argument to some functions BEGGING to
be shown the errors of your ways and turn that on as you wish, often after
something has gone wrong.

-----Original Message-----
From: R-devel <r-devel-bounces at r-project.org> On Behalf Of Martin
Maechler
Sent: Friday, March 3, 2023 10:26 AM
To: Gabriel Becker <gabembecker at gmail.com>
Cc: Antoine Fabri <antoine.fabri at gmail.com>; R-devel <r-devel at
r-project.org>
Subject: Re: [Rd] transform.data.frame() ignores unnamed arguments when no named
argument is provided
>>>>> Gabriel Becker 
>>>>>     on Thu, 2 Mar 2023 14:37:18 -0800 writes:
    > On Thu, Mar 2, 2023 at 2:02?PM Antoine Fabri
    > <antoine.fabri at gmail.com> wrote:

    >> Thanks and good point about unspecified behavior. The way
    >> it behaves now (when it doesn't ignore) is more
    >> consistent with data.frame() though so I prefer that to a
    >> "warn and ignore" behaviour:
    >> 
    >> data.frame(a = 1, b = 2, 3)
    >> 
    >> #> a b X3
    >> 
    >> #> 1 1 2 3
    >> 
    >> 
    >> data.frame(a = 1, 2, 3)
    >> 
    >> #> a X2 X3
    >> 
    >> #> 1 1 2 3
    >> 
    >> 
    >> (and in general warnings make for unpleasant debugging so
    >> I prefer when we don't add new ones if avoidable)
    >> 

    > I find silence to be much more unpleasant in practice when
    > debugging, myself, but that may be a personal preference.

+1

I also *strongly* disagree with the claim

   " in general warnings make for unpleasant debugging "

That may be true for beginners (for whom debugging is often not really
feasible anyway ..), but somewhat experienced useRs should know

about
    options(warn = 1) # or
    options(warn = 2) # plus  options(error = recover) #
or
    tryCatch( ...,  warning = ..)

or  {even more}

Martin

--
Martin Maechler
ETH Zurich  and  R Core team

______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel