Skip to content

attach "warning" is a message

3 messages · Barry Rowlingson, Simon Urbanek, Martin Maechler

Original
Barry Rowlingson
# 
If I mask something via `attach`:
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
Simon Urbanek
# 
Barry,

it is not a warning nor plain output, it is a message, so you can use
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
Martin Maechler
# 
> 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 at 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 at r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >>