Talk:Symmetric difference: Difference between revisions
→Set type: clarity, data validation and sanitation.
(→Set type: clarity, data validation and sanitation.) |
|||
Line 18:
::::Hi Michael, I wrote the note because of personal experience. before Python had an explicit set type I had learned to ''not'' use lists as sets because of the duplicates issue. I n Python the idiom then was to use the keys of a dictionary (map or hash) and code around that to make it look like a set. It was quicker to find out if a key is in a dict than in a list and the keys of a dict are unique. Seeing more than one of the RC examples using lists, and knowing how easy it is to have duplicates in a list made me check the algorithms used.
::::I reasoned that the task is about sets. If I use a set type then the type ensures there are no duplicates. Isn't it fair that if another example is using lists then either they show how their lists are further constrained to work as sets, or that the algorithm will give a set-like answer if such checks are not shown? --[[User:Paddy3118|Paddy3118]] 23:39, 9 February 2010 (UTC)
:::::I understand where you're coming from; I couldn't earn my paycheck if I didn't deal with practical concerns when dealing with my code. However, when I write code, I work to keep input validation a component distinct from operating on that input; it improves mine and my coworkers' comprehension of my code, as well as keep the algorithms themselves visible and distinct. With this task, as I understand it and your understanding of it, the task description specifies that the input has the properties of a set, and requires that an algorithm be applied to that input. Verifying and ensuring that the data passed in meets the constraints of being a set falls under data validation and sanitation, and, for clarity's sake, I believe that such things should be a distinct component of the program where clarity is key.
:::::I'm not saying it ''must'' be a separate example, but rather that if it's included, it should be not be confused with the actual implementation of the algorithm itself (<math>(A \setminus B) \cup (B \setminus A)</math>). By all means, point out practical considerations and caveats; add them to the example's prologue, add them as an identified component of example code, or some other means, but ensure that input validation isn't confused with algorithm implementation.
:::::By changing the task to require input sanitation, it became necessary to mark a number of examples as incorrect, adding templates to identify those examples as requiring attention. If one were to change that requirement to allow noting input constraints as an alternate requirement, the ENAs aren't required, observers of the code are warned of caveats, and the core algorithm is still demonstrated. Does that make sense? --[[User:Short Circuit|Michael Mol]] 05:50, 10 February 2010 (UTC)
| |||