5 ms·

> Adding third-party libraries is a huge step to take for a project Really? I've can't think of a "real" project that did not include 3rd party libs. Reinven

> Adding third-party libraries is a huge step to take for a project Really? I've can't think of a "real" project that did not include 3rd party libs. Reinventing wheels or struggling with poorer implementations (unittest vs pytest, http vs requests, etc) is huge drain for a project. A huge misstep.

teddyh 5y ago
I should have written “Adding each extra third-party library as an additional dependency is always a huge step to take for a project”. Any one third-party library comes with these drawbacks, and each library must be evaluated individually. Some may be worth the pain (requests, etc.), but many are not. One should try to minimize the number of third-party dependencies one has, not necessarily eliminate them entirely. It’s simply that the lower number of third-party libraries you depend on, the less pain you get of the kinds I listed. 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.
- robertlagrant 5y ago
  From the article: > While pytest is very popular, 28% of codebases still use the built-in unittest package.
  - 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 ago
      No, 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 ago
        Then why did you quote the author so selectively as to appear to indicate the opposite?
        robertlagrant 5y ago
        Sorry, 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 ago
        Oh, 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 ago
        Maybe. 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.

teddyh 5y ago

I should have written “Adding each extra third-party library as an additional dependency is always a huge step to take for a project”. Any one third-party library comes with these drawbacks, and each library must be evaluated individually. Some may be worth the pain (requests, etc.), but many are not. One should try to minimize the number of third-party dependencies one has, not necessarily eliminate them entirely. It’s simply that the lower number of third-party libraries you depend on, the less pain you get of the kinds I listed. 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.

robertlagrant 5y ago
From the article: > While pytest is very popular, 28% of codebases still use the built-in unittest package.
- 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 ago
    No, 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 ago
      Then why did you quote the author so selectively as to appear to indicate the opposite?
      - robertlagrant 5y ago
        Sorry, 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 ago
        Oh, 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 ago
        Maybe. 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.