[Rd] attach "warning" is a message
Martin Maechler
m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Tue Aug 10 11:50:01 CEST 2021
>>>>> Simon Urbanek
>>>>> on Tue, 10 Aug 2021 11:28:19 +1200 writes:
> Barry,
> it is not a warning nor plain output, it is a message, so you can use
>> d = data.frame(x=1:10)
>> x=1
>> suppressMessages(attach(d))
>>
> Looking at the history, this used to be cat() but got changed to a message in R 3.2.0 (r65385, CCIng Martin in case he remembers the rationale for warning vs message). I don't know for sure why it is not a warning, but I can see that it is more in the line with informative messages (like package masking) as opposed to a warning - in fact the change suggest that the intention was to synchonize both. That said, I guess the two options are to clarify the documentation (also in library()) or change to a warning - not sure what the consequences of the latter would be.
> Cheers,
> Simon
Thank you, Simon.
One rationale back then was that message() *is* in some sense
closer to cat() than warning() is (and indeed, to synchronize
with the conflict messages from `library(.)` or `require(.)`.
Also, I would say that a message is more appropriate here than a
warning when someone explicitly attach()es something to the
search() path (s)he may get a notice about masking but to be
warned is too strong {warnings being made into errors in some setups}.
So I'd propose to only update the documentation i.e.
help(attach).
Martin
>> On 10/08/2021, at 2:06 AM, Barry Rowlingson <b.rowlingson using lancaster.ac.uk> wrote:
>>
>> If I mask something via `attach`:
>>
>>> d = data.frame(x=1:10)
>>> x=1
>>> attach(d)
>> The following object is masked _by_ .GlobalEnv:
>>
>> x
>>>
>>
>> I get that message. The documentation for `attach` uses the phrase
>> "warnings", although the message isn't coming from `warning()`:
>>
>> warn.conflicts: logical. If ‘TRUE’, warnings are printed about
>> ‘conflicts’ from attaching the database, unless that database
>> contains an object ‘.conflicts.OK’. A conflict is a function
>> masking a function, or a non-function masking a non-function.
>>
>> and so you can't trap them with options(warn=...) and so on. This sent me
>> briefly down the wrong track while trying to figure out why R was showing a
>> masking error in one context but not another - I wondered if I'd supressed
>> warning()s in the other context.
>>
>> Personally I'd like these messages to be coming from warning() since that
>> seems the appropriate way to warn someone they've done something which
>> might have unwanted effects. But fixing the documentation to say "If
>> ‘TRUE’, *messages* are printed" is probably less likely to break existing
>> code.
>>
>> Happy to add something to bugzilla if anyone thinks I'm not being overly
>> pedantic here.
>>
>> Barry
>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
More information about the R-devel
mailing list