4 ms·

Man, I never understood the love for py.test. People say "it's Pythonic, you just use asserts", but asserts aren't Pythonic. For one, asserts are removed when

Man, I never understood the love for py.test. People say "it's Pythonic, you just use asserts", but asserts aren't Pythonic. For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration. Secondly, crawling up the stack to inspect the bytecode to figure out what condition was actually asserted so you can print a nice error... that's the opposite of Pythonic. Sure, the unittest module in the standard library is a bit Java-ish, but it's much less magic, and I feel like keeping per-test state in a class that gets instantiated multiple times is more Pythonic than having everything be top-level functions. And of course unittest is in the standard library, which means that most apps and libraries are going to use it, most people are going to be familiar with it, so your app or library will be more approachable to co-workers and/or contributors if it's tested the same way. Heck, a lot of Python frameworks have their own test helpers built on top of unittest (hello, Twisted and Django!) so you don't get to choose anyway. You could write Python code with three-tab indents, but you should use 4-spaces like everybody else. You could write your own custom packaging and dependency management system, but you should use setuptools like everybody else. You could any number of custom test harnesses, but you should use unittest like everybody else.

orf 10y ago
> For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration Which is not something anyone has ever wanted. > Sure, the unittest module in the standard library is a bit Java-ish, but it's much less magic, and I feel like keeping per-test state in a class that gets instantiated multiple times is more Pythonic than having everything be top-level functions. It's really really unpythonic. It looks horrible and leads to messy tests. With pytest you get dependency injection via fixtures which cuts down on so much repetitive initialisation code. We've got both kinds of tests in our codebase, and the pytest ones are a lot nicer to write and refactor.
- bpicolo 10y ago
  So unpythonic that it even uses camelcase.
- 291289812 10y ago
  "Unpythonic" must be something positive. Whenever someone uses that word, I like the code or the application in question. "Pythonic" seems to mean using magic until an application works in 99% of the cases, satisfies some superficial criteria of readability to those intimately familiar with it and is utterly un-debuggable for those who aren't.
  - orf 10y ago
    > Whenever someone uses that word, I like the code or the application in question. Then either they are not describing something unpythonic or you can't visualize how better the code would look if it was pythonic. > "Pythonic" seems to mean using magic until an application works in 99% of the cases, satisfies some superficial criteria of readability to those intimately familiar with it and is utterly un-debuggable for those who aren't. Not at all, it's usually exactly the opposite. Open a python shell and type "import this", if Python code satisfies a large enough number of those then it's Pythonic. The first six pretty much sum it up: > Beautiful is better than ugly. > Explicit is better than implicit. > Simple is better than complex. > Complex is better than complicated. > Flat is better than nested. > Sparse is better than dense. Words to live by. They all help improve debugging and readability.
    - 9912121qwq 10y ago
      Hardly anyone writes code like that in the Python world. It's all about features and gross hacks.
scrollaway 10y ago
A long time ago, people would have made the exact same arguments about the `requests` library, which is today considered one of the highest quality third party libraries in Python ({{cn}}). In fact, a lot of the arguments still apply. "urllib3 is in the stdlib, why use requests?". I can get behind that argument in specific cases, too - I have a library which uses urllib3 because it only ever needs to GET from a couple of URLs and introducing an extra dependency just for that is a hassle. But here's the thing about tests. You want them to be clear, you want them to be easy, painless and even fun to write. pytest achieves that. unittest doesn't. If you're serious about testing, unittest will harm your project. PS: https://leclan.ch/tabs/ https://leclan.ch/tabs/
rat87 10y ago
> run Python with "-O" no one ever does this Yes Pytest is black magic(I tried and failed to understand it for my own dark purposes). But it lets you get context without violating repeating yourself over and over.
- nilliams 10y ago
  You should repeat yourself in your tests. See DAMP vs DRY [1]. Also that repetition is valuable feedback that you may have a design problem, that something about your object hierarchy is overly-complex, for example. If you hide it, you're just sweeping the problem under the rug. [1] http://stackoverflow.com/a/11837973 http://stackoverflow.com/a/11837973
Twirrim 10y ago
> For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration. That's almost entirely all python -O actually does. The only other thing it does is set __debug__ to 0. There's essentially no real value in running code with the -O flag.

orf 10y ago

> For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration Which is not something anyone has ever wanted. > Sure, the unittest module in the standard library is a bit Java-ish, but it's much less magic, and I feel like keeping per-test state in a class that gets instantiated multiple times is more Pythonic than having everything be top-level functions. It's really really unpythonic. It looks horrible and leads to messy tests. With pytest you get dependency injection via fixtures which cuts down on so much repetitive initialisation code. We've got both kinds of tests in our codebase, and the pytest ones are a lot nicer to write and refactor.

bpicolo 10y ago
So unpythonic that it even uses camelcase.
291289812 10y ago
"Unpythonic" must be something positive. Whenever someone uses that word, I like the code or the application in question. "Pythonic" seems to mean using magic until an application works in 99% of the cases, satisfies some superficial criteria of readability to those intimately familiar with it and is utterly un-debuggable for those who aren't.
- orf 10y ago
  > Whenever someone uses that word, I like the code or the application in question. Then either they are not describing something unpythonic or you can't visualize how better the code would look if it was pythonic. > "Pythonic" seems to mean using magic until an application works in 99% of the cases, satisfies some superficial criteria of readability to those intimately familiar with it and is utterly un-debuggable for those who aren't. Not at all, it's usually exactly the opposite. Open a python shell and type "import this", if Python code satisfies a large enough number of those then it's Pythonic. The first six pretty much sum it up: > Beautiful is better than ugly. > Explicit is better than implicit. > Simple is better than complex. > Complex is better than complicated. > Flat is better than nested. > Sparse is better than dense. Words to live by. They all help improve debugging and readability.
  - 9912121qwq 10y ago
    Hardly anyone writes code like that in the Python world. It's all about features and gross hacks.

scrollaway 10y ago

A long time ago, people would have made the exact same arguments about the `requests` library, which is today considered one of the highest quality third party libraries in Python ({{cn}}). In fact, a lot of the arguments still apply. "urllib3 is in the stdlib, why use requests?". I can get behind that argument in specific cases, too - I have a library which uses urllib3 because it only ever needs to GET from a couple of URLs and introducing an extra dependency just for that is a hassle. But here's the thing about tests. You want them to be clear, you want them to be easy, painless and even fun to write. pytest achieves that. unittest doesn't. If you're serious about testing, unittest will harm your project. PS: https://leclan.ch/tabs/ https://leclan.ch/tabs/

rat87 10y ago

> run Python with "-O" no one ever does this Yes Pytest is black magic(I tried and failed to understand it for my own dark purposes). But it lets you get context without violating repeating yourself over and over.

nilliams 10y ago
You should repeat yourself in your tests. See DAMP vs DRY [1]. Also that repetition is valuable feedback that you may have a design problem, that something about your object hierarchy is overly-complex, for example. If you hide it, you're just sweeping the problem under the rug. [1] http://stackoverflow.com/a/11837973 http://stackoverflow.com/a/11837973

Twirrim 10y ago

> For one, asserts are removed when you run Python with "-O", so, uh, good luck running your test suite in that configuration. That's almost entirely all python -O actually does. The only other thing it does is set __debug__ to 0. There's essentially no real value in running code with the -O flag.