On 24 Nov 2020, at 11:58, Antoine Pitrou email@example.com wrote:
On Tue, 24 Nov 2020 10:23:10 +0000 Paul Moore firstname.lastname@example.org wrote:
On Tue, 24 Nov 2020 at 10:18, Antoine Pitrou email@example.com wrote:
On Mon, 23 Nov 2020 08:09:07 +0000 Paul Moore firstname.lastname@example.org wrote:
But it's not as limiting as you suggest - it *does* preclude most scientific use (because of numpy etc) but (for example) a large number of web libraries are pure Python.
Not sure what you mean here, but while Web frameworks themselves may be pure Python, you can have C accelerators in a template engine or in a ORM layer. Also, the database driver most likely isn't in pure Python (if you want it to be performant anyway).
All I meant was that how limiting it is depends on what type of application you're trying to write.
Sure, but the number of applications which don't depend whatsoever on non-stdlib C extensions is probably much smaller than you were trying to say. You should not fool yourself: the suggested "zipapp" (does it exist already? I lost track of the number of weird things that have been implemented in core Python in the name of packaging) would mostly be a non-solution.
This already exists, see <https://docs.python.org/3/library/zipapp.html https://docs.python.org/3/library/zipapp.html>
It is basically a zipped up directory with an ``__main__.py``. This works for some applications, but is not comparable to py2exe/py2app/pyinstaller/….
IMHO any changes to CPython for this should be solutions for clear problems that are best fixed in the core, preferably along side changes to the prospective users of those changes to ensure that the changes are actually useful.
Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/