René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Basics notes","articleBody":"## 1. Style guide violations\r\n\r\n### Explanations in Code\r\n\r\nThe style guide specifies that we should [not have explanations in code](https://github.com/stanfordpython/course-reader/blob/master/STYLE.md#explanations-in-code). You do this once, in the file reading section:\r\n\r\n```python\r\nfile_text = f.read(size) # Reads size bytes from the file; if size is omitted, the entire file is read.\r\nfirst_line = f.readline() # Reads the file one line at a time.\r\nall_lines = f.readlines() # Returns a list with all lines of the file.\r\n```\r\n\r\n### Printed Output\r\nThe style guide specifies\r\n\u003e When an expression will result in printed terminal output, this should be written after the expression and a blank line. Each line of output should be commented out with the hash sign at the beginning of the line, a space, and then the terminal output. The implication sign should not be included.\r\n\r\nBut many of your examples use the implication sign to offset printed output, like\r\n```python\r\nprint(\"I'm dancing.\")              # =\u003e I'm dancing.\r\nprint('\"This is fun!\" he cried.')  # =\u003e \"This is fun!\"\r\n```\r\n\r\nMaybe remove the print statements or convert the implication comments to print-style comments?\r\n\r\n### Italics\r\nYou frequently use italics to denote terms when they're introduced.\r\n\r\n### Nitpicky Spacing\r\nYou're using two spaces instead of one in many of the return value implicatures\r\n\r\n```python\r\nmath.gcd(45, 105)  # =\u003e 15\r\nmath.cos(3.14)     # =\u003e -0.9999987317275395\r\nmath.cos(math.pi)  # =\u003e -1.0\r\n```\r\n\r\nI know this is very nitpicky but... let's be consistent?\r\n\r\n## 2. File I/O with `open`/`close`\r\n\r\nYou wrote\r\n\u003e It's almost always a better idea to use the paradigm of the context manager when performing File I/O in Python. Cases where it is superior to use the open/close paradiem are significantly fewer - only use it if you have a clear, good reason to do so.\r\n\r\nI'm curious: can you think of any time where it's superior to use the open/close paradigm?\r\n\r\n### Reading Bytes\r\n`f.read(size)` reads `size` many bytes only when the file is open in bytes mode and `size` many characters otherwise.\r\n\r\n## 3. C-Style Formatting\r\nWhy are we showing them C-style formatting at all if we immediately move on to say \"never do this\"?\r\n\r\nAlso, this code is incorrect:\r\n```python\r\nprint(\"{0} then {1} then {0} then {1} then {0}.\" % (\"Parth\", \"Michael\"))  # =\u003e Parth then Michael then Parth then Michael then Parth\r\n```\r\n\r\n## 4. Add Filenames\r\nWhen a file is introduced, I think we should add filenames at the top to make it clear that this is happening inside a file.\r\n\r\n```python\r\n\"\"\"\r\nFile: hello.py\r\n--------------\r\n\"\"\"\r\n...\r\n```\r\n\r\n## 5. Revisit the Signature\r\nLet's have a consistent signature.","author":{"url":"https://github.com/parthsarin","@type":"Person","name":"parthsarin"},"datePublished":"2020-08-23T06:10:28.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/5/course-reader/issues/5"}