> 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.
"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.
> 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.
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.