CarForumPoster fucked around with this message at 10:13 on Apr 5, 2024

    {
    'text': 'replace the whole thing anyways right so',
     'start': 1331.08,
     'duration': 4.28
    }

Cyril Sneer fucked around with this message at 03:46 on Apr 17, 2024

config_1 = {'val1': 100, 'val2': 200}
# {'val1': 100, 'val2': 200}

config_2 = {**config_1, 'val2': 0}
# {'val1': 100, 'val2': 0}

default_person = {"name": "john doe", "age": 50, "mother": {"name": "jane doe", "age": 80}}
default_hobbies = {"hobbies": ["going to church", "reading the bible"]}

sample_person = {**default_person, **default_hobbies}
# {'name': 'john doe', 'age': 50, 'mother': {'name': 'jane doe', 'age': 80}, 'hobbies': ['going to church', 'reading the bible']}

sample_stoner = {**default_person, **default_hobbies, "mother": {"name": "janet doe"}, "hobbies": ["smoking weed"]}
# {'name': 'john doe', 'age': 50, 'mother': {'name': 'janet doe'}, 'hobbies': ['smoking weed']}
# see how it replaces, it doesn't update partials/nested

boofhead fucked around with this message at 21:00 on Apr 24, 2024

Data Graham fucked around with this message at 03:06 on Apr 27, 2024

• Your error handling choices only look good on the surface. Yes, you've made an error message slightly more fancy by adding some text to it, yes, the functions will always raise errors of a consistent type. They also don't react in any meaningful way to handle the errors that might be raised or enrich any of the error messages with context that would be useful to an end user (or logging system). You could argue that they make the software worse because they swallow the stack trace that might contain something meaningful (because they don't raise from the base exception).
  
• Docstrings for each function are a good practice. Some docstring formats have a description for each argument, raised exception, and a description of the return value, and I tend to like these because it's helpful to tie relevant info directly to an argument. The docstrings you wrote contain the function's name, just reworded, and are not useful. In fact, you could take the tiny bit of extra information from the docstring and put it back into the function name and have a function name that is even better than the one you started with. calculate_most_common_genre_by_user is better than calculate_most_common_genre (but I would probably go with top_genre_by_user personally).
  
• Normalize your use of single or double quotes. Run it through a formatter like black or ruff. The best case is that the reviewer doesn't notice or thinks it's a bit sloppy, the worst case is that they assume you copied it from two different websites.
  
• You don't have any type annotations in your arguments or on your return values. Help your IDE help you.
  
• Your unit tests check that an answer was returned, but stop short of actually seeing if that answer is correct. Constructing a tiny fake dataset with some known answers for your unit tests is a great way to validate that, and it seems like that's what you did from the filenames, but it seems unfinished.