4 ms·

the real problem is python, great at the start of a project, by the end i am dying to rewrite in java.

echelon 1y ago
Python needs a version 4 to make a clean break: - runtime optionally type checked interfaces - make depending on system python an antipattern - a reasonable package manager with lockfiles and transitive dependency versions - package org namespaces - steps towards hermetic builds with less linking against system libraries and dependencies - cleanup and slimming down of the standard library. Removal of cruft. Less "batteries included" so people lean more on packages and enforcing good practices with packages.
- Jabrov 1y ago
  The latest versions of Python 3 already have or can do most of these things.
  - echelon 1y ago
    They do not enforce it. It's not about "can do". It's about defaults and enforcing stricter standards. Python is too flexible. It produces sloppy code. And in no world are Python builds and dependencies solved. It's a major headache.
    - 7bit 1y ago
      If you want Python to be like TypeScript, why don't you just write a typescript then?
      - Philpax 1y ago
        Personally, I do; my only interactions with Python are unwilling (work or AI-related code). Given that I don't have much of a choice in the matter, I'd like to see Python improve as a language and as an ecosystem. I hope that one day I will not feel dread upon encountering it in the wild.
      - echelon 1y ago
        Either python needs to be a language geared at code no longer than 1000 loc, or it needs tools to enable safely building large scale apps.
        zahlman 1y ago
        Setuptools comes to around 100kloc now (per a naive search and `wc` of the .py files in a new environment) and installs without a hitch for everyone. Pip, nearly double that. Yes, both of those are heavily using vendoring, but because of bootstrapping problems because they are the default build tool and package installer respectively. (And quite a bit of devendoring would be possible if some system maintainers didn't insist on "building from source" when there is only Python code. Yes, technically pre-compiling .py to .pyc can be considered "building", but pip would already do that during installation.) If they didn't have to worry about those issues (or the additional Pip issue of "how do you get the packages for Pip's dependencies if you don't already have Pip?"), they would install and run just fine from a series of wheels that are all pure Python code. For that matter, one of those dependencies, `pyparsing`, is around 10k lines installed (and the repository is much larger with tests etc.). That's with it not having any dependencies of its own. There is no real barrier anywhere around the 1k loc mark. The problems large projects run into have more subtle causes.
      - mamcx 1y ago
        Because typescript is not python. Look, is correct to understand that the BEST way, the BEST refactoring of all, is to change to a language + libraries that fix core issues (similar how you can't outrun a bad diet you can't outrun bad semantics) BUT, also change it means lose a lot of nice things. For example I move from python to F# and then Rust, for what I say that is now the best overall decision at all, BUT I miss dearly Django (and instant run and REPL) IF I could get Django (that means transitively use python) and get better type system and perf from it, I could consider it and surely use it, like "python get as swift or go but with rust algebraic types, whatever it means to get here and yet is Django and python. ok? Is unreasonable? but sincerely, it will nice if the best ideas get retrofitted in other languages because, well, I wish everyone get as more nice things as possible instead of keep with suboptimal options (that is what I say: breaking languages is not something that must be forbidden forever) Is unreasonable? (I say again) could be, but I think is a good thing to explore. Maybe is not that much, and if at the end things get better, great!
    - zahlman 1y ago
      > > runtime optionally type checked interfaces > They do not enforce it. It's not about "can do". It's about defaults and enforcing stricter standards. How exactly do you want to "enforce" an "optional" runtime type check for an interface, that is different from opting in by calling `isinstance`? For that matter, `TypeError` exists and is raised non-optionally by all sorts of things. > And in no world are Python builds and dependencies solved. It's a major headache. For your specific set of dependencies, perhaps. Lots of people are using Python just fine. A large majority of what I'm interested in using would install fully (including transitive dependencies) from pre-built wheels on my system; and of those wheels, a large majority contain only Python code that doesn't actually require a build step. (Numpy is the odd one out here.) In fact, of the top 10 largest packages in my system's `dist-packages` (all stuff that came provided with my Linux distro; I respect PEP 668 and don't let Python native packaging tools touch that environment), at least 9 have wheels on PyPI, and 4 of them have `none-any` wheels. (And of course, tons of the smaller ones are pure Python - there's simply no room for a compiled binary there.)
- a_t48 1y ago
  uv solves or improves 2,3,5. (It's scary how often lately I find myself saying or seeing someone say that) --- For posterity - make depending on system python an antipattern uv is virtual env, uv managed python executable first, opt in to system python packages only a reasonable package manager with lockfiles and transitive dependency versions uv.lock, check. I think base pip also has transitive dependencies, though, and has since 2020? steps towards hermetic builds with less linking against system libraries and dependencies I know there's build isolation for dependencies in uv, I'm not sure it solves the problem you have What is it you mean by package org namespaces?
  - echelon 1y ago
    And yet `uv` isn't widely used. None of the ML projects I'm frequenting utilize it. > What is it you mean by package org namespaces? eg. `google/protobuf`. An organization would parent all of its packages under its namespace. > uv is virtual env, uv managed python executable first, opt in to system python packages only A project should blow up if you attempt to use system python. It should not work. `python main.py` should handle all of this for you. An ideal Python would work like Rust's cargo. And there would be only one way to use it. You keep seeing this come up because it's still a systemic issue with the ecosystem. Python needs to enforce this top down.
    - zahlman 1y ago
      > An organization would parent all of its packages under its namespace. If you're talking about what you write in the code to import it, nothing prevents anyone from doing this. They just don't, because PyPI is a free-for-all by design. If you're talking about names used on PyPI, see https://peps.python.org/pep-0752/ https://peps.python.org/pep-0752/. But this is not a language feature. > A project should blow up if you attempt to use system python. It should not work. Why? > `python main.py` should handle all of this for you. How could it, given the issues you've identified? > You keep seeing this come up because it's still a systemic issue with the ecosystem. Python needs to enforce this top down. A very large fraction of Python users (whom you'll likely never hear from because they have their own ways of sharing code amongst themselves) actively don't want that kind of enforcement.
- throw2022110401 1y ago
  > Python needs a version 4 to make a clean break The tragedy of Python 3 is that they made the community go through a billion dollar migration but didn't tackle any of the hard stuff. And the reason they didn't was the Perl 6 debacle. So it's all Larry Wall's fault.
  - echelon 1y ago
    Python 3 took the exact same path as Larry Wall's Perl 6. But unlike Perl, it was able to come out largely unscathed. Python could do with more major version upgrades, but small scoped upgrades that only change tiny, manageable pieces. Forcing a good package manager on all Python developers would be a good candidate for this.
- wiseowise 1y ago
  > Less "batteries included" so people lean more on packages and enforcing good practices with packages. No, just no. If anything, Python needs more batteries built-in.
dimgl 1y ago
Sounds like trading one problem for another
- mikert89 1y ago
  idk maybe im old, but most of the high scale serious systems i have seen are in a language like java or c++. big important python systems are mostly from startups that succeeded and have trouble migrating off
- spruce_tips 1y ago
  checkout java 23. it has come a long way
999900000999 1y ago
It's fine for very very small projects. I have a couple of small tools which work well. One is basically a 200 loc script that coverts files. The moment you need multiple files, the project is probably big enough where you really need a strong type system. Java and C# fit extremely well for this. Both have caught up in terms of ease of use. The latest .net let's you run a C# file individually like a bash script. The gift and curse of python is that it's really easy to do a lot. So you can be sloppy , just tossing stuff in, up until issues start to arise. Next thing you know you have a giant code base no one has any chance of understanding. Still, it's a great first language. You can make small tools within a month. C isn't nearly as forgiving. If you love the Python syntax, Nim is here.
- FpUser 1y ago
  >"Still, it's a great first language. You can make small tools within a month. C isn't nearly as forgiving." If C and Python are the only options I would strongly vote for C being the first. It will weed out those who are unfit. Myself I use many languages including Python but I started programming by entering machine codes in hex. Obviously I do not do it now but I think it did benefit me in general.
  - 999900000999 1y ago
    Not everyone is going to become a Staff Engineer at Google. Python can help a bartender write a small application to track her stock for example. In fact with a bit of computer vision this can work very well. I originally just wanted to make small games, I was hacking together sloppy JavaScript. I don't like gate keeping. The future is probably even a higher level language than Python. Maybe an embedded llm that sorta decides what to do at runtime.
    - FpUser 1y ago
      I was talking about teaching programming on pro level. If one just wants to play anything goes. Whatever they feel like. >" I don't like gate keeping." I hate it too. Cheers. >"higher level language than Python" I do not see Python as a high level language. Sure it is not assembly but that's about it in my opinion.

Python needs a version 4 to make a clean break: - runtime optionally type checked interfaces - make depending on system python an antipattern - a reasonable package manager with lockfiles and transitive dependency versions - package org namespaces - steps towards hermetic builds with less linking against system libraries and dependencies - cleanup and slimming down of the standard library. Removal of cruft. Less "batteries included" so people lean more on packages and enforcing good practices with packages.

Jabrov 1y ago
The latest versions of Python 3 already have or can do most of these things.
- echelon 1y ago
  They do not enforce it. It's not about "can do". It's about defaults and enforcing stricter standards. Python is too flexible. It produces sloppy code. And in no world are Python builds and dependencies solved. It's a major headache.
  - 7bit 1y ago
    If you want Python to be like TypeScript, why don't you just write a typescript then?
    - Philpax 1y ago
      Personally, I do; my only interactions with Python are unwilling (work or AI-related code). Given that I don't have much of a choice in the matter, I'd like to see Python improve as a language and as an ecosystem. I hope that one day I will not feel dread upon encountering it in the wild.
    - echelon 1y ago
      Either python needs to be a language geared at code no longer than 1000 loc, or it needs tools to enable safely building large scale apps.
      - zahlman 1y ago
        Setuptools comes to around 100kloc now (per a naive search and `wc` of the .py files in a new environment) and installs without a hitch for everyone. Pip, nearly double that. Yes, both of those are heavily using vendoring, but because of bootstrapping problems because they are the default build tool and package installer respectively. (And quite a bit of devendoring would be possible if some system maintainers didn't insist on "building from source" when there is only Python code. Yes, technically pre-compiling .py to .pyc can be considered "building", but pip would already do that during installation.) If they didn't have to worry about those issues (or the additional Pip issue of "how do you get the packages for Pip's dependencies if you don't already have Pip?"), they would install and run just fine from a series of wheels that are all pure Python code. For that matter, one of those dependencies, `pyparsing`, is around 10k lines installed (and the repository is much larger with tests etc.). That's with it not having any dependencies of its own. There is no real barrier anywhere around the 1k loc mark. The problems large projects run into have more subtle causes.
    - mamcx 1y ago
      Because typescript is not python. Look, is correct to understand that the BEST way, the BEST refactoring of all, is to change to a language + libraries that fix core issues (similar how you can't outrun a bad diet you can't outrun bad semantics) BUT, also change it means lose a lot of nice things. For example I move from python to F# and then Rust, for what I say that is now the best overall decision at all, BUT I miss dearly Django (and instant run and REPL) IF I could get Django (that means transitively use python) and get better type system and perf from it, I could consider it and surely use it, like "python get as swift or go but with rust algebraic types, whatever it means to get here and yet is Django and python. ok? Is unreasonable? but sincerely, it will nice if the best ideas get retrofitted in other languages because, well, I wish everyone get as more nice things as possible instead of keep with suboptimal options (that is what I say: breaking languages is not something that must be forbidden forever) Is unreasonable? (I say again) could be, but I think is a good thing to explore. Maybe is not that much, and if at the end things get better, great!
  - zahlman 1y ago
    > > runtime optionally type checked interfaces > They do not enforce it. It's not about "can do". It's about defaults and enforcing stricter standards. How exactly do you want to "enforce" an "optional" runtime type check for an interface, that is different from opting in by calling `isinstance`? For that matter, `TypeError` exists and is raised non-optionally by all sorts of things. > And in no world are Python builds and dependencies solved. It's a major headache. For your specific set of dependencies, perhaps. Lots of people are using Python just fine. A large majority of what I'm interested in using would install fully (including transitive dependencies) from pre-built wheels on my system; and of those wheels, a large majority contain only Python code that doesn't actually require a build step. (Numpy is the odd one out here.) In fact, of the top 10 largest packages in my system's `dist-packages` (all stuff that came provided with my Linux distro; I respect PEP 668 and don't let Python native packaging tools touch that environment), at least 9 have wheels on PyPI, and 4 of them have `none-any` wheels. (And of course, tons of the smaller ones are pure Python - there's simply no room for a compiled binary there.)
a_t48 1y ago
uv solves or improves 2,3,5. (It's scary how often lately I find myself saying or seeing someone say that) --- For posterity - make depending on system python an antipattern uv is virtual env, uv managed python executable first, opt in to system python packages only a reasonable package manager with lockfiles and transitive dependency versions uv.lock, check. I think base pip also has transitive dependencies, though, and has since 2020? steps towards hermetic builds with less linking against system libraries and dependencies I know there's build isolation for dependencies in uv, I'm not sure it solves the problem you have What is it you mean by package org namespaces?
- echelon 1y ago
  And yet `uv` isn't widely used. None of the ML projects I'm frequenting utilize it. > What is it you mean by package org namespaces? eg. `google/protobuf`. An organization would parent all of its packages under its namespace. > uv is virtual env, uv managed python executable first, opt in to system python packages only A project should blow up if you attempt to use system python. It should not work. `python main.py` should handle all of this for you. An ideal Python would work like Rust's cargo. And there would be only one way to use it. You keep seeing this come up because it's still a systemic issue with the ecosystem. Python needs to enforce this top down.
  - zahlman 1y ago
    > An organization would parent all of its packages under its namespace. If you're talking about what you write in the code to import it, nothing prevents anyone from doing this. They just don't, because PyPI is a free-for-all by design. If you're talking about names used on PyPI, see https://peps.python.org/pep-0752/ https://peps.python.org/pep-0752/. But this is not a language feature. > A project should blow up if you attempt to use system python. It should not work. Why? > `python main.py` should handle all of this for you. How could it, given the issues you've identified? > You keep seeing this come up because it's still a systemic issue with the ecosystem. Python needs to enforce this top down. A very large fraction of Python users (whom you'll likely never hear from because they have their own ways of sharing code amongst themselves) actively don't want that kind of enforcement.
throw2022110401 1y ago
> Python needs a version 4 to make a clean break The tragedy of Python 3 is that they made the community go through a billion dollar migration but didn't tackle any of the hard stuff. And the reason they didn't was the Perl 6 debacle. So it's all Larry Wall's fault.
- echelon 1y ago
  Python 3 took the exact same path as Larry Wall's Perl 6. But unlike Perl, it was able to come out largely unscathed. Python could do with more major version upgrades, but small scoped upgrades that only change tiny, manageable pieces. Forcing a good package manager on all Python developers would be a good candidate for this.
wiseowise 1y ago
> Less "batteries included" so people lean more on packages and enforcing good practices with packages. No, just no. If anything, Python needs more batteries built-in.

dimgl 1y ago

Sounds like trading one problem for another

mikert89 1y ago
idk maybe im old, but most of the high scale serious systems i have seen are in a language like java or c++. big important python systems are mostly from startups that succeeded and have trouble migrating off
spruce_tips 1y ago
checkout java 23. it has come a long way

999900000999 1y ago

It's fine for very very small projects. I have a couple of small tools which work well. One is basically a 200 loc script that coverts files. The moment you need multiple files, the project is probably big enough where you really need a strong type system. Java and C# fit extremely well for this. Both have caught up in terms of ease of use. The latest .net let's you run a C# file individually like a bash script. The gift and curse of python is that it's really easy to do a lot. So you can be sloppy , just tossing stuff in, up until issues start to arise. Next thing you know you have a giant code base no one has any chance of understanding. Still, it's a great first language. You can make small tools within a month. C isn't nearly as forgiving. If you love the Python syntax, Nim is here.

FpUser 1y ago
>"Still, it's a great first language. You can make small tools within a month. C isn't nearly as forgiving." If C and Python are the only options I would strongly vote for C being the first. It will weed out those who are unfit. Myself I use many languages including Python but I started programming by entering machine codes in hex. Obviously I do not do it now but I think it did benefit me in general.
- 999900000999 1y ago
  Not everyone is going to become a Staff Engineer at Google. Python can help a bartender write a small application to track her stock for example. In fact with a bit of computer vision this can work very well. I originally just wanted to make small games, I was hacking together sloppy JavaScript. I don't like gate keeping. The future is probably even a higher level language than Python. Maybe an embedded llm that sorta decides what to do at runtime.
  - FpUser 1y ago
    I was talking about teaching programming on pro level. If one just wants to play anything goes. Whatever they feel like. >" I don't like gate keeping." I hate it too. Cheers. >"higher level language than Python" I do not see Python as a high level language. Sure it is not assembly but that's about it in my opinion.