@HumanoidTyphoon91
I found this to be a very interesting talk, even though I didn't like most of the final refactored code in the presentation. One thing I'd like to point out, though, is that the class (that IMHO really shouldn't be a class) didn't make testing better. You are testing internals, implementation details just for the sake of testing it. If you stopped one step before, would have been better (though again, at least I learned about the _bool_ function, so thanks for that).
@diepmai6656
thank you Brett Slatkin, I have learned a lot from your book Effective python
@htpcmagistrat3535
Good talk @brettorama , though I agree with other commenters that refactoring from functions to classes is probably a bad idea and a Java-ism that does not belong in Python land. You linked to the talk that people should stop using classes, so I will forgive you for that, though :) I have a comment on the tombstones you suggest at the end of your talk; it is not the only way to safeguard against setting pet.age = 5. Rather than sprinkle your code with superfluous tombstone properties, you could just add _slots_ = 'name', 'animal' to the Pet class.
@iktunutki
I think the presentations you pointed to are really great! It's a bit strange that you'd mention them and then do a presentation that contains far more "write some classes" advice than I would consider idiomatic in Python. I found the advice about writing a class and defining a _bool_ really hacky, not pythonic and not "obvious" (not idiomatic will always imply "not obvious to the reader"). I'm also not convinced it's a good idea in terms of testing. You're testing the internals of the class, i.e. reimplementing the logic inside of the tests: why would I care that "November" is not an "ary" month, when all I want to know is if oysters are good to eat during that month?
@younglife88
i liked presentation, gives me more to learn and what others do... especially if you are learning, but not everything is or should become a class like others have said... but i think if your objects eventually become repeated code, classes will help out amazingly.
@linpershey
great talk!
@anandiyer5361
Have a question. How is refactoring the class to include an animal as part of its __init__, superior to inheritance?
@lazywarrior
I have to admit the comment section is more interesting and also more to my liking.
@nguyenthanhdat93
Great tips! Thank you for sharing
@cnliving
Exellent talking on rewriting python code~
@stanleychan3212
Sorry, but I don't think writing OystersGood class and TomatoesGood class is good design when simple functions suffices. Plus I find it hard to treat OystersGood(month=1) as a tangible object.
@Andrumen01
There is a small caveat to refactoring that is hardly mentioned: If refactoring MUST break the old functions, version! Refactoring, most times, leads to a completely new version. This way, you don't lose (a lot of) backward compatibility and can move forward to better software.
@warvariuc
The example made the code after refactoring more complex with all this backwards compatibility stuff.
@lawrencerosen7113
I never saw Python 2, please give some idea how These things are best done in the Pythob-3 context
@TheWillRogers
This is awesome. Really helped. But the age belongs to the pet. Gila does not have age like it does scales, but Geraldo the Gila does have an age.
@andreas_bergstrom
Can't we all just stop using these nonsense code examples with animals, cars, etc.? Would be way easier to follow along if people instead used real world scenarios such as a game, webshop, discussion board or what not.
@jiansenxmu
Thanks!
@pritam-kunduu
Portland Oregon definitely reminds me of DAYS GONE ðŸ¤
@Yqhs
If we are talking about readability he sholdnt use .format() ?
@tib7209