Copilot commands to specify usage of list-comprehension, isintance.

Author: adivekar-utexas

.github/copilot-instructions.md

@@ -5,11 +5,13 @@ Steps to follow when responding to the user's request:
 - Third, write a "Solution Critique" where you critique your "Solution Technical Specifications": identify weaknesses where the code does not align with the user's request, or where the approach does not meet a high bar on maintainability or performance. Break these into "Major improvements" (structural changes needed in the approach) vs "Nitpicks" (where it does not follow the "Rules for Python coding" below). Provide comprehensive feedback in this critique.
 - Fourth, implement the code for a "Finalized Solution" which incorporates the critique and follows "Rules for Python coding". This should be a detailed, well-thought-out solution. Make sure to incorporate the "Major improvements" from the critique into this solution. For "Nitpicks", either incorporate them if they are easy, or add TODOs. If you have any remaining concerns or potential risks in the finalized solution, call them out in a "Final Thoughts" section.
 Rules for Python coding:
-- Always add type-hints for function inputs, function return types, local variables and globals variables. For type-hints, use the Python typing library (i.e. "Dict", "Set", "List", "Tuple", etc) instead of inbuilts like "dict", "set", "list", "tuple", etc. Add these type hints all the time.
+- Always add type-hints for function inputs, function return types, local variables and globals variables. For type-hints, use the Python typing library (i.e. "Dict", "Set", "List", "Tuple", etc) instead of inbuilts like "dict", "set", "list", "tuple", etc. Add these type hints all the time. If you see any missing type hints in the code, add them.
+- Always prefer to fail-fast and check intermediate data: raise exceptions like ValueError, TypeError, AttributeError, OSError, etc. instead of allowing possibly incorrect data to be passed around. The exception to this is when working with functions annotated with `@safe_validate_arguments`, assume the function inputs have the correct types and values (though the intermediate data may).
+- Always use `isinstance` to check the type of a variable. Never use `type(x) == y` to check the type of a variable. Correct usage: `if isinstance(x, int):`, Incorrect usage: `if type(x) == int:`.
 - Always use `if len(struct) == 0` to check if a string or a container (list, set tuple, dict etc.) is empty or not. Never use the `not` keyword to check for emptiness. Correct usage: `if len(struct) == 0:`, Incorrect usage: `if not struct:`. Similarly, use `len(struct) > 0` to check if a string or container is not empty.
 - Always use `x is None` or `x is not None` to check if a variable is None, instead of `if not x`.
 - Write comments only for complex code pieces. Never write comments which explain WHAT the code does, a comment should always explain WHY something was done; the choices and reasoning behind the decision made. Always preserve links which are present in existing comments or docstrings.
-- Avoid creating unnecessary variables which are only used once. 
+- For intermediate processing in functions, prefer list comprehensions or dict comprehensions; try to avoid for-loops unless absolutely necessary. Particularly, avoid creating unnecessary looping variables which may leak into later parts of the function.
 - When writing Python docstrings, always include an "Example usage" section with examples on how to call the function or instantiate the class. In comments within "Example usage", follow the commenting rules.
 - When writing the "Example usage" section in docstrings, always output the examples without the three dots, so that it can easily be copied into a Jupyter notebook:
     Correct usage: