From bbo|ker @end|ng |rom gm@||@com  Fri Mar  3 21:58:30 2023
From: bbo|ker @end|ng |rom gm@||@com (Ben Bolker)
Date: Fri, 3 Mar 2023 15:58:30 -0500
Subject: [Rd] 
 transform.data.frame() ignores unnamed arguments when no named
 argument is provided
In-Reply-To: <CAEKh8uh2pY5N98eufV2DX01wfCp++rMDSEPwXA-AUCogHBkDGA@mail.gmail.com>
References: <CAEKh8ug=Vy=rDkqCEKnrGL4h7A7fPmF_zpcwq2CTybNmOTgNnw@mail.gmail.com>
 <e9c6473a-a005-5236-a616-4c34b596e593@fau.de>
 <CAEKh8uhE=JEWRvio1DqabZ4MyWM7p_7NCmVkQ_6k8Ovy6N22WA@mail.gmail.com>
 <CAD4oTHE43AFFkQFGrL5jDs9U5Jon99ZvYwTTt+6pT5A-2R-FhQ@mail.gmail.com>
 <25602.4458.303335.397238@stat.math.ethz.ch>
 <CAEKh8uh2pY5N98eufV2DX01wfCp++rMDSEPwXA-AUCogHBkDGA@mail.gmail.com>
Message-ID: <CABghstT+5CX8f15X8zTFp_DgKGwe6g2F6=g9bJvworFhyLXHTQ@mail.gmail.com>

   For what it's worth I think the increased emphasis on classed
errors should help with this (i.e., it will be easier to filter out
errors you know are false positives/irrelevant for your use case).

On Fri, Mar 3, 2023 at 12:17?PM Antoine Fabri <antoine.fabri at gmail.com> wrote:
>
> 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]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] transform.data.frame() ignores unnamed arguments when no named argument is provided
Ben Bolker