If anyone's interested I've implemented a fairly user friendly lazy import mechanism in the form of context managers (auto_proxy_import/init) at https://pypi.org/project/lazyimp/ that I use fairly heavily. Syntactically it's just wrapping otherwise unmodified import statements in a with block, so tools 'just work' and it can be easily disabled or told to import eagerly for debugging. It's powered primarily by swapping out the frame's f_builtins in a cext (as it needs more power than importlib hooks provide), but has a lame attempt at a threadsafe pure python version, and a super dumb global hook version.
I was skeptical and cautious with it at first but I've since moved large chunks of my codebase to it - it's caused surprisingly few problems (honestly none besides forgetting to handle some import-time registration in some modules) and the speed boost is addictive.
If you're building anything past a hello world c ext you're already off the path of shit like poetry, in which case AIUI we're basically on our own as we've always been lol, for better and worse.
Again I don't think setup.py is going away. Given that distsetuputiltools is a jenga tower of decades old monkeypatches documentation is understandably sparse, but they're at least passively open about how gross it is to work within. Subclassing or otherwise manually overriding the behavior of distutils classes like build_* is just how stuff is done at this level and I don't expect that to change, beyond just updating your stuff to subclass or hook direct setuptools equivs of existing distutils classes. distutils is already vendored by setuptools anyway, so you're already not really hitting 'distutils' as much as 'setuptools._distutils' aliased to distutils upon importing setuptools (and specifically importing it first ( https://github.com/pypa/setuptools/blob/c121d289da5d19cf6df2... )), so all this really does is collapse a level of hack.
As long as py2 remains supported I expect whatever changes happen here to be py2 compat, but I do expect new setuptools to break compat with old setup.py's. But setup.py being what it is it wouldn't be out of character to make your setup.py manually support both old pre-distutils-removal setuptools and new post-distutils-removal setuptools, but that's just how setup.py maintenance goes lol.
ed: ok well not so much py2 being 'supported' as 'no showstopping incompatibilities for anyone still straddling that ever widening gap' :)
AIUI, as the official way setuptools is used is a setup.py calling setuptools.setup(), doing this will remain supported in perpetuity and will really still be powering everything under the hood, it's just no longer what people are told to do when they ask 'how do I make a new python library?' - newcomers and people with simple requirements will be directed to poetry or whatever and avoid that whole mess. For obvious historical reasons python's pretty averse to large breaking changes, and its support for all kinds of weird native interops and obscure platforms is one of its major assets (but also why setuptools is such a mess), so that's almost certainly not going anywhere, even if it's now kept even further back in the shadows. Regarding pyproject.toml if you already have a setup.py doing what you need then it's really only for specifying suported python versions and setup_requires (solving the problem of your setup.py itself needing Cython/wheel/etc).
Significant but as it's freethreaded you only run one large process. That alone allows for all kinds of additional optimizations that would be pointless with a lot of little singlethreaded processes in which sharing anything mutable between them has massive overhead.
Past some critical mass local dev indeed simply doesn't work, but the majority of codebases aren't ~that~ large. And until that point I feel there's an analogy between having a light laptop and remotely doing your heavy lifting with the whole working remote thing in general. In theory, on paper, and assuming reliable decent internet connectivity, with a little elbow grease there should be no discernable difference between thin client remote dev and an in-your-lap xeon, just like with high quality low latency video teleconferencing with a team that knows how to do it there should be nothing lost with physical distance. In practice though the overhead of doing any little thing, no matter how small the overhead may be optimized down to, is still real. Non-verbal communication is lost on zoom and the distance between you and your real UI grew by hundreds of miles and dozens of links, and the tradeoffs your environment makes when there's no such thing as a 'quick check' add up fast. But it's obviously not one dimensional, and there's probably irony in the weight shedding that offers you 20 hrs of battery life coming with a price tag of requiring reliable wifi to get any real work done.
I'm a fellow fan of antlr but it's not really an option for the base interpreter. They're (rightfully) very stingy about deps. cpython supports a wide range of platforms and has its own very permissive license - it's a pretty self-contained codebase and they prefer to keep it that way.
The whole point of python is to eschew 'magic' in favor of dumb explicitness, and this is about as big of a conflict as you can get to that. Python lacks statement lambdas not because they've never considered the possibility but explicitly because "if it's that important it deserves a name (as an inner function)". Type annotations work so well in python as compared to ruby or clojure exactly because of this philosophy. The PEP seems to make no mention of things like reproducibility, IO in macro expansion, static analysis like in mypy, or any of the other realities of things like this. If macro expansion is limited to something carefully statically interpretable like constexpr then I'm cautiously receptive to it, OR as it positions itself to be 'for experimenting with language features' and that's genuine then I'd be fine with it if it's only enabled in debug builds, but in lieu of those the instant it's released generally it's a python 4 flag day.
> You could use this to do little stunts like adding an "unless x:" statement equivalent to "if not x:"
You say that like it's a good thing. Python is a language empowered by its constraints. You have indeed always been able to pull stunts like this but it's strongly frowned upon - python is not ruby, lambdas intentionally do not have statements, and terseness is not a virtue.
python's never really been about dogma. part of why its package management is such a mess is because it's been so successful at integrating with everything under the sun and still needs to support it all.