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:
...Qfunctions that don't exclusively return
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
Directoryeven 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
NotebookOpendoes not respect
Directory. Is there any reason for that? Which else?
Exceptions from styles inheritance / stylesheets stack
There are numerous. e.g.:
DefaultNewInlineCellStyle -> "MyStyle"your inline cells will always inherit from
"InlineCell"style. Similar issue affects