4 ms·

There really needs to be one tool that combines installing, building, testing and running Python projects. This tool should be officially endorsed by core devel

There really needs to be one tool that combines installing, building, testing and running Python projects. This tool should be officially endorsed by core developers of Python and gradually added to the standard distribution model. The good starting point for this would be Pip. It is de facto standard tool for installing packages. It can be extended to do more. Also, the standard should favor pure-Python packages, in order to untangle Python from it's legacy as a glue language for modules written in C(++). Otherwise, no progress will be made at the language level and Python will die out once C becomes legacy language, replaced by safer systems programming languages. We need to learn from Java's and Javascript's ecosystems. Those languages are now used mostly in their pure form. They are portable, optimized and more stable than most languages. With enough care, Python can become the same.

Kamq 4y ago
> Also, the standard should favor pure-Python packages, in order to untangle Python from it's legacy as a glue language for modules written in C(++). Never gonna happen. Python's explosion has been through data science and ml, which is based entirely around calling Fortran/C/C++/etc. > Otherwise, no progress will be made at the language level and Python will die out once C becomes legacy language, replaced by safer systems programming languages. I assume you mean Rust here. Do you think python can't already call rust? It's been able to do that for the better part of a decade. I mean, this is once of python's main selling points. It doesn't matter what your numeric/scientific library is written in, python can call it, and it's vaguely convenient to write (depending on your taste for comprehensions). Why would the python ecosystem shoot themselves in the foot like that?
- wheelerof4te 4y ago
  "Never gonna happen. Python's explosion has been through data science and ml, which is based entirely around calling Fortran/C/C++/etc." What's Django, then? "I assume you mean Rust here. Do you think python can't already call rust? It's been able to do that for the better part of a decade." Python can only call C code. The fact that Rust itself (or Fortran, btw) has good C ABI is on Rust, not Python. Also, by calling Rust's C ABI, you are making a double indirection, thus severely reducing performance. That's why I said we need to optimize Python, and even make progress towards making Python - in Python itself. Just like Go can compile itself, Python should be able to run itself. But, that is all for the long run.
  - Kamq 4y ago
    > What's Django, then? Pretty rare compared to data work, at least among python projects I've worked on. > Python can only call C code. The fact that Rust itself (or Fortran, btw) has good C ABI is on Rust, not Python. Also, by calling Rust's C ABI, you are making a double indirection, thus severely reducing performance. That's a bit of an implementation detail, but fair. There is some overhead. But every language since C has shied away from committing to a stable abi (or at least the C ecosystem is willing to commit to one, the standard mentions nothing about it). That's only overhead at the boundaries though, and the common pattern of using python as an orchestrator with the vast majority of logic happening inside native code really does minimize the overhead you actually experience. At least you can architect an application that way (same pattern works with things like pyspark as well). > That's why I said we need to optimize Python By all means, optimize python. I think you'll run into the GIL pretty fast, but I wasn't objecting to that. I was objecting to making things like pyspark or tensorflow second class citizens. Doing that is going to destroy python.
solarkraft 4y ago
I'm doubly confused. Not only is Python perfectly capable of binding to Rust, but also why would you want things you'd usually do in faster languages to be done in Python? It's great as glue but I think we'd agree that it's not very good at some performance critical things.
cozzyd 4y ago
Python is barely newer than C++ and I predict it will die long before C and C++...
dragonwriter 4y ago
> Also, the standard should favor pure-Python packages, in order to untangle Python from it's legacy as a glue language for modules written in C(++). Why? Except for the C(++) part, which was never particularly accurate in the first place except that that’s the most popular set of lower-level languages to start with, what's thr problem with Python being a glue language? > Otherwise, no progress will be made at the language level Clearly false, as progress continues to be made at the language level. > Python will die out once C becomes legacy language, replaced by safer systems programming languages. Why? Python works as glue for Rust as well as anything else. If anything, the biggee threat to Python as a glue language is more dev-friendly system languages, not safer ones, but even there I don't see how packaging deemphasizing support for non-Python modules does anything but accelerate Python problems. > We need to learn from Java's and Javascript's ecosystems. Those languages are now used mostly in their pure form. They always were, though; both were designed for use cases without any reliable lower-level besides their own VM, and became popular in that environment. That's not what Python’s ecosystem grew on, and arguably what Java and JS teach here is lean into what made you a success.

Kamq 4y ago

> Also, the standard should favor pure-Python packages, in order to untangle Python from it's legacy as a glue language for modules written in C(++). Never gonna happen. Python's explosion has been through data science and ml, which is based entirely around calling Fortran/C/C++/etc. > Otherwise, no progress will be made at the language level and Python will die out once C becomes legacy language, replaced by safer systems programming languages. I assume you mean Rust here. Do you think python can't already call rust? It's been able to do that for the better part of a decade. I mean, this is once of python's main selling points. It doesn't matter what your numeric/scientific library is written in, python can call it, and it's vaguely convenient to write (depending on your taste for comprehensions). Why would the python ecosystem shoot themselves in the foot like that?

wheelerof4te 4y ago
"Never gonna happen. Python's explosion has been through data science and ml, which is based entirely around calling Fortran/C/C++/etc." What's Django, then? "I assume you mean Rust here. Do you think python can't already call rust? It's been able to do that for the better part of a decade." Python can only call C code. The fact that Rust itself (or Fortran, btw) has good C ABI is on Rust, not Python. Also, by calling Rust's C ABI, you are making a double indirection, thus severely reducing performance. That's why I said we need to optimize Python, and even make progress towards making Python - in Python itself. Just like Go can compile itself, Python should be able to run itself. But, that is all for the long run.
- Kamq 4y ago
  > What's Django, then? Pretty rare compared to data work, at least among python projects I've worked on. > Python can only call C code. The fact that Rust itself (or Fortran, btw) has good C ABI is on Rust, not Python. Also, by calling Rust's C ABI, you are making a double indirection, thus severely reducing performance. That's a bit of an implementation detail, but fair. There is some overhead. But every language since C has shied away from committing to a stable abi (or at least the C ecosystem is willing to commit to one, the standard mentions nothing about it). That's only overhead at the boundaries though, and the common pattern of using python as an orchestrator with the vast majority of logic happening inside native code really does minimize the overhead you actually experience. At least you can architect an application that way (same pattern works with things like pyspark as well). > That's why I said we need to optimize Python By all means, optimize python. I think you'll run into the GIL pretty fast, but I wasn't objecting to that. I was objecting to making things like pyspark or tensorflow second class citizens. Doing that is going to destroy python.

solarkraft 4y ago

I'm doubly confused. Not only is Python perfectly capable of binding to Rust, but also why would you want things you'd usually do in faster languages to be done in Python? It's great as glue but I think we'd agree that it's not very good at some performance critical things.

cozzyd 4y ago

Python is barely newer than C++ and I predict it will die long before C and C++...

dragonwriter 4y ago

> Also, the standard should favor pure-Python packages, in order to untangle Python from it's legacy as a glue language for modules written in C(++). Why? Except for the C(++) part, which was never particularly accurate in the first place except that that’s the most popular set of lower-level languages to start with, what's thr problem with Python being a glue language? > Otherwise, no progress will be made at the language level Clearly false, as progress continues to be made at the language level. > Python will die out once C becomes legacy language, replaced by safer systems programming languages. Why? Python works as glue for Rust as well as anything else. If anything, the biggee threat to Python as a glue language is more dev-friendly system languages, not safer ones, but even there I don't see how packaging deemphasizing support for non-Python modules does anything but accelerate Python problems. > We need to learn from Java's and Javascript's ecosystems. Those languages are now used mostly in their pure form. They always were, though; both were designed for use cases without any reliable lower-level besides their own VM, and became popular in that environment. That's not what Python’s ecosystem grew on, and arguably what Java and JS teach here is lean into what made you a success.