4 ms·
Why weren't the functionality of those for-loops tested? It seems like a strange thing to burden PyLint with catching.
by xapata 10y ago
Why weren't the functionality of those for-loops tested? It seems like a strange thing to burden PyLint with catching.
- brazzledazzle 10y agoWell the blog is called Code Without Rules so...
- itamarst 10y agoThe thought was that in the end you need principles, not rules. "Always write unit tests" is a good rule, and this code actually had unit tests, but the truth is some code doesn't need unit tests. That being said, since you seem like a suitably snarky person, you may enjoy the email newsletter I write which is dedicated to the ways I've screwed up: https://softwareclown.com/ https://softwareclown.com/
- brazzledazzle 10y agoI try to keep the snark at bay but it probably still wins more than it should. I signed up. Better to learn from your mistakes than my own. The testimonial was awesome by the way.
- itamarst 10y agoThey were tested, but it didn't catch the bug unfortunately. I got bit by the fact that I was testing with synchronous callbacks, but real world use was with asynchronous callbacks.
- OskarS 10y agoIt's an extremely common bug in basically all languages that allow closures to capture "live" variables. Almost every developer that uses any kind of async programming gets bit by it eventually. For-loops and closures do not mix well.
- deleted 10y ago[deleted]
- xapata 10y agoThe author did not create any closures in the example code. Python only creates a closure for a def in a def. Regardless, using functools.partial solves that problem: ``callback = partial(print, i)``.
- deleted 10y ago[deleted]
- xapata 10y agoSounds like the issue is that you tested parallelized code as if it were serial. That'll be a problem regardless how many issues PyLint spots. Whenever I have async/parallel code I am paranoid about racing and deadlocks. I always test with a bit of fuzzy sleeps to tease out any issues. Also, you described two separate bugs. The first one doesn't sound like an asynchronous callback issue. It sounds like a text editor with autocomplete would have avoided the problem. Or coding in an environment that encourages frequently running the code to look at its results.