3 ms·
Yes? This proves that the writer thinks that everybody should obviously change from unittest to pytest. It does not prove the writer to be correct in all circ
by teddyh 5y ago
Yes? This proves that the writer thinks that everybody should obviously change from unittest to pytest. It does not prove the writer to be correct in all circumstances. Each project should make their own determination of whether a third-party library is worth it.
- robertlagrant 5y agoNo, that doesn't prove that. It just indicates the opposite of what you said, here: > And I doubt that, for most people, pytest is that much better to work with than the built-in unittest is.
- teddyh 5y agoThen why did you quote the author so selectively as to appear to indicate the opposite?
- robertlagrant 5y agoSorry, I'm not following. I'm saying the article says less than 30% of repos scanned used Unittest. That was in response to you seeming to say that most projects would choose Unittest. What've I missed?
- teddyh 5y agoOh, I see, you misunderstood me. I did not claim that “most projects would choose Unittest”. I claimed that for many projects, it would be wise to consider using unittest instead of, for example, pytest, as a way of minimizing usage of third-party modules.
- robertlagrant 5y ago> Every individual third-party library will have to overcome that threshold by being useful enough. And I doubt that, for most people, pytest is that much better to work with than the built-in unittest is. This sounds more like you're saying that pytest wouldn't overcome that threshold; I was saying that has already happened, at least according to the article's statement.
- teddyh 5y agoMaybe. But I would personally guess that most people nowadays are way too eager to use a new library than would be good for their projects in the long run. I very much doubt that most new libraries are that much better than the Python standard library counterparts that it’s worth using them in non-toy projects. Of course, all progress depends on the unreasonable man, etc.