Hacker News Reader

Comment by rich_sasha | Hacker News Reader

I think sadly a lot of Python in the wild relies heavily, somewhere, on the crazy unoptimisable stuff. For example pytest monkey patches everything everywhere all the time.

You could make this clean break and call it Python 4 but frankly I fear it won't be Python anymore.

View on HN

As a person who has spent a lot of time with pytest, I'm ready for testing framework that doesn't do any of that non-obvious stuff. Generally use unittest as much as I can these days, so much less _wierd_ about how it does things. Like jeeze pytest, do you _really_ need to stress test every obscure language feature? Your job is to call tests.

Yeah, I've been thinking about how I'd do it from scratch, honestly. (One of the reasons Pytest could catch on is that it supported standard library `unittest` classes, and still does. But the standard library option is already ugly as sin, being essentially an ancient port of JUnit.)

I think it's not so much that Pytest is using obscure language features (decorators are cool and the obvious choice for a lot of this kind of stuff) but that it wants too much magic to happen in terms of how the "fixtures" automatically connect together. I would think that "Explicit is better than implicit" and "Simple is better than complex" go double for tests. But things like `pytest.mark.parametrize` are extremely useful.

If you do that you then have a less productive language for many use cases IMHO.

All the dynamism from Python should stay where it is.

Just JIT and remember a type maybe, but do not force a type from a type hint or such things.

As a minimum, I would say not relying on that is the correct thing. You could exploit it, but not force it to change the semantics.

I think there are ways that it could be reined in quite a bit with most people not noticing. But it would still be a different language.

Allowing metaprogramming at module import (or another defined phase) would cover most monkey patching use cases. From __future__ import python4 would allow developers to declare their code optimisable.

Perl 6 showed what happens when you do something like that.

Reply on news.ycombinator.com