Done: Unexpected behaviors in built-in functions will appreciate feedback/input etc.

I want to ask a question on main which will qualify as 'too broad but helpful enough to stay'. (like common pitfals/useful undocumented functions and few others)

I'm not the best when it comes to wording so I kindly ask for help. I will outline what should be the essence of the question and I would like to see an answer which will tackle style but also the scope of the question.

Here's the draft:

I'm sure I am not the only one non beginner in WL who from time to time finds himself not being able to predict an outcome of a specific function or being surprised it returned something.

I'm talking about cases which have in common that such problematic outcome could be considered an exception from a convention/best practices or even an apparent bug. Sometimes they are just that and sometimes there is a deeper explanation, deep enough not to be obvious when problem occurs.

Anyway, the time is wasted on debugging or guessing which exceptions to handle.

Cheat-sheet with those cases can speed up programming.

Here are three examples one could build a valid answer on:

List of ...Q functions that don't exclusively return True/False.

e.g., even though

An important feature of all the Wolfram Language property-testing functions whose names end in Q is that they always return False if they cannot determine whether the expression you give has a particular property.


one can be beaten by:


FileExistsQ::fstr: File specification is not a string of one or more characters.



Functions that don't respect Directory[] even though they could.

For people, like me, who started after v6 the separation between FrontEnd and Kernel is not so transparent at the beginning. I was hit by the fact that NotebookOpen does not respect Directory[]. Is there any reason for that? Which else?


Exceptions from styles inheritance / stylesheets stack

There are numerous. e.g.:

  • Despite DefaultNewInlineCellStyle -> "MyStyle" your inline cells will always inherit from "InlineCell" style. Similar issue affects "DockedCells".


| |
  • 7
    To my eyes, this question looks fine. Yes, it's overly broad, but some centralized cheat-sheet for this would be very useful. You might emphasize that you're asking about cases where the observed behavior deviates from the expected behavior based on either something in the docs or a pattern established by other functions, not just based on what the function name would suggest. And maybe change the "finds himself" to "finds "themselves" or something like that. The user base probably does skew male, but good to be as inclusive in language as possible. – b3m2a1 Nov 10 '17 at 22:53
  • 4
    Will this be a community wiki like the already extent Pitfalls question? And will it indefinitely extendable by other users in the same way that one is? – m_goldberg Nov 11 '17 at 17:53
  • @m_goldberg sure, it is about unexpected issues, I can't possibly know them all. – Kuba Nov 12 '17 at 14:33
  • 4
    Consider putting your examples as answers instead of using them in your question. It makes the question shorter, and people will automatically consider existing answers as examples anyway. – C. E. Nov 12 '17 at 20:46
  • I see three separate and unrelated questions here, so I would definitely say it's too broad. But I would also vote to close the pitfalls question as being too broad, so I'm clearly in the minority. – Jason B. Nov 13 '17 at 2:57
  • 3
    @JasonB. I like to think of it as "too broad, but too useful". It's not really exactly right for StackExchange, but to have a neutral, centralized source for these sorts of pitfalls would be super helpful. Wolfram can't host this directly since it's sorta anti-advertising and Community is too glitchy and (I think) less used. StackExchange is just the best place to host this. – b3m2a1 Nov 13 '17 at 10:49
  • @b3m2a1 btw, don't you think a better title is needed? – Kuba Nov 13 '17 at 11:04
  • 3
    For a title, I'd suggest "Unexpected behaviors in built-in functions". – J. M.'s technical difficulties Nov 13 '17 at 12:22
  • I second @J.M.'s suggestion or a variation on that. – b3m2a1 Nov 13 '17 at 19:05

You must log in to answer this question.

Browse other questions tagged .