#orms

Ogier Jersey headquarter’s Helical Staircase,

Yayoi Kusama, “LOVE IS CALLING” 

  This last category of being opens up a whole new can of orms.       2017   orms in the brain orms in the heart   orms in the nose orms daily in his own mouth   orms, that their feet swell’d orms like eels, &c.   orms are so many orms; that therefore was no more than natural       1727   —   Orms, who came to us Orms left us the next day   Orms understood Orms misunderstood   Orms met the men he did meet Orms had met a man something like himself   Orms all Orms, whose name was mis-understood   Orms the whole story Orms. how could this have happened       1832   —   known at present, of the Orms       1912   to Orms, north side Orms to corner Orms       1878 several places were named Orms-by, Orms-ton, Orms-kirk, and others...       1887   Any one acquainted with the legends of the north must be familiar with Lind-orms, and in those of Germany the Lind-wurm is no unfrequent actor.       1828   orme, ormes and orms       1912   ove! abo lent, be to, orms: ly to ted to e wal irral; acebo d       1835   Orms. For heaven's sake, explain this mystery       1774   The beauteous orms, the dazzling splendours, the breathing odom's of the East       1818

—

sources —

2017 Kathryn Schulz, "Fantastic Beasts and How to Rank Them : The relative plausibility of impossible beings tells you a lot about how the mind works." Dept. of Speculation, The New Yorker (November 6, 2017 issue) : 26 1727 William Ramesey, A Theologico-philosophical Dissertation Concerning Worms in All Parts of Human Bodies : containing several most curious and uncommon observations of natural productions. : 83 and throughout 1832 Benjamin Lincoln, Dr. Lincoln's Appeal : With Dr. Woodward's Letter to Professor Lincoln, &c. : 33 and throughout 1912 William Richard Cutter, Genealogical and Family History of Western New York : 100 1878 City Documents (Providence, Rhode Island) 1887 George Chalmers, Caledonia, Or, A Historical and Topographical Account of North Britain from the Most Ancient to the Present Times : With a Dictionary of Places, Chorographical and Philological : 542 1828 Thomas Crofton Croker, Fairy Legends and Traditions of the South of Ireland (Part II) : 271 1912 Cutter, ibid. 1835 The Chinese Repository 4 : 37 1774 The Romance of an Hour : A Comedy of Two Acts, as it is Performed, with universal applause, at The Theatre Royal in Covent-Garden, written by Hugh Kelly, Esq. : 29 1818 The Edinburgh Review 29 : 1

note — several of these orms, e.g., ex Ramesey 1727 — and many more discarded — were artefacts of OCR misreads, typically of italicized words. Schulz's essay on impossible beings — orms mysteriously among them — is brilliant. She is also the author of Being Wrong : Adventures in the Margin of Error (2010)

(Last session)

My friend's "homework" from last time was to turn the code snippet we had (list filtering) into a function because modular code is easy to read and functions are reusable (which means less repetition).

She did this! And the function worked as expected, outputting a list of missing items that exist on one list (the first parameter) but not another (the second parameter). I was really happy about this success!

I had a couple of notes for her about how she accomplished this:

The first thing that caught my eye was the return statement. She wrote it to return a `print()` function, as in

return print(missing_items)

I was of two minds about this! It's not good practice to return a `print()` because the value returned is always `None`. So, if one were to assign a variable to the result of her function, it would look something like this:

missing_items = list_filtering_function(list_one, list_two)

and the value of `missing_items`, instead of being a list of items missing from the second list that are present in the first, would be `None`. This could lead to confusion and problems (bugs!) down the line, if we were to use the `missing_items` variable for some other purpose (like populating a new csv or something).

On the other hand, it was a good instinct to notice that nothing displayed for her if she simply returned the list of missing items! I suggested that she return the list, and print it outside of the function instead, to make the program display the result of the function.

def find_missing_items(outer_list, inner_list): """ compares two lists, and returns the items contained in outer_list that are not found in inner_list """ # initialize result missing_items = [] for item in outer_list: if item not in inner_list: missing_items.append(item) return missing_items # outside scope of function, create some simple lists to test it all_fruits = ["strawberry", "watermelon", "blueberry", "kiwi", "rambutan", "durian", "mango", "tomato", "cucumber"] available_fruits = ["strawberry", "rambutan", "mango"] # call the function and assign the result to a new variable unavailable_fruits = find_missing_items(all_fruits, available_fruits) # print the result! print(unavailable_fruits) # alternatively, print and call in the same line (more concise, less readable to a beginner, and the result can't be reused without calling the function again) print(find_missing_items(all_fruits, available_fruits))

2. The other notes were mostly minor, but the main other one was choosing descriptive names for functions and variables. I emphasized clarity and specificity over shorter names, because any worthwhile IDE (we're using VSCode) will have a shortcut for re-entering long function/variable names, and clarity/specificity in naming will help you remember what the function does and avoid confusing it with other, similar functions. We came up with `find_missing_items` for the function, and `big_list` and `small_list` for the params. I now think that `outer_list` and `inner_list` would be more appropriate, to reflect SQL outer/inner join language, or to evoke a Venn diagram of the two lists, but `big_list` and `small_list` get the job done: she will always know which param is which!

We committed these changes to her git branch (have I talked about git branches here?) and pushed the changes up to the remote repo. My next task is to clone her repo on my own machine and play around with SQLAlchemy and a simple database structure, since we also discussed her existing codebase at work, and what it's trying to accomplish, and I think that querying a persistent database would be wayyyyy more efficient than literally building a new database every time using CSVs, and then outputting new CSVs and saving them to a folder...the program took like 4 hours to finish running. Yikes!

[infomercial voice]: There's gotta be a better way!