Conversation
…g the first 3 tests in wave 1
…passing all tests.
…d repr in clothin class. passing all tests
…ed condition_description method. passing all tests
…wap_best_by_category methods, passed all tests except those for the last method.
…ion in item.py for condition_description
…choose_and_swap_items method in vendor class
kelsey-steven-ada
left a comment
There was a problem hiding this comment.
Great work Dalia! I've left a mix of suggestions and questions to consider for feedback. Please reply here on Github or reach out on Slack if there's anything I can clarify =]
| from .item import Item | ||
|
|
||
| class Electronics(Item): | ||
| def __init__(self, id=None, condition =0, type = 'Unknown'): |
There was a problem hiding this comment.
I'm seeing inconsistent spacing between parameters and the assignment operators to their default values across files. It is common enough inside of function definitions to forgo spaces around the assignment operator and a default value that I recommend choosing either no spaces on either side (id=None) or spaces on both sides (id = None) and being consistent with that usage across all function definitions.
| self.fabric = fabric | ||
|
|
||
| def __repr__(self): | ||
| return f"{super().__repr__()}. It is made from {self.fabric} fabric." No newline at end of file |
There was a problem hiding this comment.
Great use of the superclass!
| super().__init__(id, condition) | ||
| self.fabric = fabric | ||
|
|
||
| def __repr__(self): |
There was a problem hiding this comment.
Awesome to see you exploring dunder methods, as you saw both __str__ and __repr__ can meet our test needs. Since the goal of stringifying an object in this project is to create a human-friendly description over a detailed debugging description, I would suggest using __str__ over __repr__.
| def condition_description(self): | ||
| if self.condition == 5: | ||
| description = "like new" | ||
| elif self.condition >= 4: |
There was a problem hiding this comment.
I like the use of comparison operators that account for decimal condition values.
| if type(self.inventory) is not list: | ||
| raise TypeError("Please enter the inventory as a list.") |
There was a problem hiding this comment.
I would suggest placing the validation before allocating the instance variable self.inventory. We could make a small change to the if-statement to check if it is not a list or None:
if type(inventory) is not list and inventory is not None:
raise TypeError("Please enter the inventory as a list.")
# If we get here, the parameter inventory is either a list or is None
self.inventory = [] if inventory is None else inventory| if not category and self.inventory: | ||
| result_list = self.inventory | ||
| elif not self.get_by_category(category) or not self.inventory: | ||
| print("No inventory to display.") | ||
| return False | ||
| else: | ||
| result_list = self.get_by_category(category) |
There was a problem hiding this comment.
We could restructure this a little to reduce nesting:
result_list = self.get_by_category(category) if category else self.inventory
if not result_list:
print("No inventory to display.")
return None| for i in range(len(result_list)): | ||
| print(f"{i+1}. {result_list[i]}") | ||
| return True |
There was a problem hiding this comment.
Nice use of range to give us an index to work with. Another way we could do this is with the enumerate function:
for index, item in enumerate(result_list, start=1):
print(f"{index}. {item}")| self.swap_items(other_vendor,my_item, their_item ) | ||
| return True |
There was a problem hiding this comment.
Since swap_items returns a True/False value we could directly return the result of that:
return self.swap_items(other_vendor, my_item, their_item)| # ********************************************************************* | ||
| # ****** Complete Assert Portion of this test ********** | ||
| # ********************************************************************* | ||
| assert result == None |
There was a problem hiding this comment.
Nice assert, we definitely want to confirm our return value is None. We generally also want to confirm that there weren't side affects or changes to the input that we didn't intend. What could we check about the vendor's inventory to confirm that its content didn’t change?
There was a problem hiding this comment.
That makes sense. Then we would check the following:
assert "a" in vendor.inventory
assert "b" in vendor.inventory
assert "c" in vendor.inventory
assert len(vendor.inventory) == 3
I have an additional question, isn't it better to write "assert result is None"? Or I am thinking about "assert not result". Which of the three ways is best?
There was a problem hiding this comment.
If we want to know if a variable is pointing to specifically None, we want to use assert result is None. Any comparison directly to None we want to use the is/is not operators with. assert not result is less specific, since the assert will pass if the variable points to a falsy value like 0 or an empty collection as well as None.
| assert len(fatimah.inventory) == 3 | ||
| assert len(jolie.inventory) == 0 | ||
| assert item_a in fatimah.inventory | ||
| assert item_b in fatimah.inventory | ||
| assert item_c in fatimah.inventory | ||
| assert not result No newline at end of file |
There was a problem hiding this comment.
Great assertions, very complete checks!
No description provided.