10 ms·

Python 3 progress so far: [x] Async. [x] Optional static typing. [x] Threading. [ ] JIT. [ ] Efficient dependency management.

by nine_k 2y ago

janice1999 2y ago
Not sure what this list means, there are successful languages without these feature. Also Python 3.13 [1] has an optional JIT [2], disabled by default. [1] https://docs.python.org/3.13/whatsnew/3.13.html https://docs.python.org/3.13/whatsnew/3.13.html [2] https://peps.python.org/pep-0744/ https://peps.python.org/pep-0744/
- jolux 2y ago
  The successful languages without efficient dependency management are painful to manage dependencies in, though. I think Python should be shooting for a better package management user experience than C++.
  - yosefk 2y ago
    If Python's dependency management is better than anything, it's better than C++'s. Python has pip and venv. C++ has nothing (you could say less than nothing since you also have ample opportunity for inconsistent build due to mismatching #defines as well as using the wrong binaries for your .h files and nothing remotely like type-safe linkage to mitigate human error. It also has an infinite number of build systems where each system of makefiles or cmakefiles is its own build system with its own conventions and features). In fact python is the best dependency management system for C++ code when you can get binaries build from C++ via pip install...
    - wiseowise 2y ago
      > If Python's dependency management is better than anything, it's better than C++'s. That’s like the lowest possible bar to clear.
      - yosefk 2y ago
        Agreed, but that was the bar set by the comment I was replying to, which claimed Python doesn't clear it.
      - vulnbludog 2y ago
        On bro
    - stavros 2y ago
      That was the entire point, that C++ is the absolute worst.
      - dgfitz 2y ago
        I pip3 installed something today. It didn’t work, at all. I then yum installed a lib and headers, it worked well. C++ on an msft platform is the worst. I can’t speak for Mac. C++ on a linux is quite pleasant. Feels like most of the comments like yours are biased for un-stated reasons.
        stavros 2y ago
        If I had a penny for every time I gave up on compiling C++ software because there's no way to know what dependencies it needs, I'd be a millionaire. Python at least lists them.
        dgfitz 2y ago
        If I had a penny every time I heard something like that on sites like this, I’d be a billionaire :)
        ahartmetz 2y ago
        Is that because the compiler failed with "foo.h not found" or the build system said "libfoo not found"? CMake is most common and it will tell you. Worst case it's difficult to derive the package name from the name in the diagnostic. It's not great, but usually not a big deal neither IME. Typically a couple of minutes to e.g. find that required libSDL2 addon module or whatever, if there is that kind of problem at all.
        stavros 2y ago
        Yes it is, and it's usually such a big deal for me that I just don't use that software. I don't have time to go through a loop of "what's the file name? What package is it in? Install, repeat". This is by far the worst experience I've had with any language. Python has been a breeze in comparison.
    - andmkl 2y ago
      C++ has apt-get etc. because the libraries do not change all the time. Also, of course there are vcpkg and conan. Whenever you try to build something via pip, the build will invariably fail. The times that NumPy built from source from PyPI are long over. In fact, at least 50% of attempted package builds fail. The alternative of binary wheels is flaky.
      - viraptor 2y ago
        > C++ has apt-get That's not a development dependency manager. System package management is a different kind of issue, even if there's a bit of overlap. > because the libraries do not change all the time That's not true in practice. Spend enough time with larger projects or do some software packaging and you'll learn that the pain is everywhere.
  - Galanwe 2y ago
    Not sure this is still a valid critic of Python in 2024. Between pip, poetry and pyproject.toml, things are now quite good IMHO.
    - Arcanum-XIII 2y ago
      All is well, then, one day, you have to update one library. Some days later, in some woods or cave, people will hear your screams of rage and despair.
      - Galanwe 2y ago
        Been using python for 15 years now, and these screams were never heard. Dev/test with relaxed pip installs, freeze deployment dependencies with pip freeze/pip-tools/poetry/whateveryoulike, and what's the problem?
        neeleshs 2y ago
        same here. Been using python/pip for 10+ years and this was never a problem. In the java world, there is jar hell, but it was never a crippling issue, but a minor annoyance once a year or so. In general, is dependency management such a massive problem it is made to be on HN? Maybe people here are doing far more complex/different things than I've done in the past 20 years
        mixmastamyk 2y ago
        Guessing that folks who write such things are lacking sysad skills like manipulating paths, etc. It does take Python expertise to fix other issues on occasion but they are fixable. Why I think flags like ‘pip —break-system-packages’ are silly. It’s an optimization for non-users over experienced ones.
    - arp242 2y ago
      I guess that depends from your perspective. I'm not a Python developer, but like many people I do want to run Python programs from time to time. I don't really know Rust, or Cargo, but I never have trouble building any Rust program: "cargo build [--release]" is all I need to know. Easy. Even many C programs are actually quite easy: "./configure", "make", and optionally "make install". "./configure" has a nice "--help". There is a lot to be said about the ugly generated autotools soup, but the UX for people just wanting to build/run it without in-depth knowledge of the system is actually quite decent. cmake is a regression here. With Python, "pip install" gives me an entire screen full of errors about venv and "externally managed" and whatnot. I don't care. I just want to run it. I don't want a bunch of venvs, I just want to install or run the damn program. I've taken to just use "pip install --break-system-packages", which installs to ~/.local. It works shrug. Last time I wanted to just run a project with a few small modifications I had a hard time. I ended up just editing ~/.local/lib/python/[...] Again, it worked so whatever. All of this is really where Python and some other languages/build systems fail. Many people running this are not $language_x programmers or experts, and I don't want to read up on every system I come across. That's not a reasonable demand. Any system that doesn't allow non-users of that language to use it in simple easy steps needs work. Python's system is one such system.
  - est 2y ago
    Deps in CPython are more about .so/.dll problem, not much can be done since stuff happens outside python itself.
  - __MatrixMan__ 2y ago
    Python's dependency management sucks because they're audacious enough to attempt packaging non-python dependencies. People always bring Maven up as a system that got it right, but Maven only does JVM things. I think the real solution here is to just only use python dependency management for python things and to use something like nix for everything else.
    - adgjlsfhk1 2y ago
      Julia's package manager (for one) works great and can manage non Julia packages. the problem with python's system is that rejecting semver makes writing a package manager basically impossible since there is no way to automatically resolve packages.
      - woodruffw 2y ago
        Could you clarify what you mean? pip and every other Python package installer is absolutely doing automatic package resolution, and the standard (PEP 440) dependency operators include a compatible version operator (~=) that's predicated on SemVer-style version behavior.
    - pletnes 2y ago
      This is what we used to have and it was much worse. Source: lived that life 10-15 y ago.
      - __MatrixMan__ 2y ago
        15y ago I was using apt-get to manage my c++ dependencies with no way of keeping track of which dependency went with which project. It was indeed pretty awful. Now when I cd into a project, direnv + nix notices the dependencies that that project needs and makes them available, whatever their language. When I cd into a different project, I get an entirely different set of dependencies. There's pretty much nothing installed with system scope. Just a shell and an editor. Both of these are language agnostic, but the level of encapsulation is quite different and one is much better than that other. (There are still plenty of problems, but they can be fixed with a commit instead of a change of habit.) The idea that every language needs a different package manager and that each of those needs to package everything that might my useful when called from that language whether or not it is written in that language... It just doesn't scale.
  - galdosdi 2y ago
    The shitshow that is python tooling is one of the reasons I prefer java jobs to python jobs when I can help it. Java got this pretty right years and years and years earlier. Why are python and javascript continuing to horse around playing games?
GTP 2y ago
I don't get how this optional static typing works. I had a quick look at [1], and it begins with a note saying that Python's runtime doesn't enforce types, leaving the impression that you need to use third-party tools to do actual type checking. But then it continues just like Python does the check. Consider that I'm not a Python programmer, but the main reason I stay away from it is the lack of a proper type system. If this is going to change, I might reconsider it. [1] https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html
- deleted 2y ago
  [deleted]
- wk_end 2y ago
  The interpreter does not and probably never will check types. The annotations are treated as effectively meaningless at runtime. External tools like mypy can be run over your code and check them.
  - cwalv 2y ago
    It checks types .. it doesn't check type annotations. Just try: $ Python >>> 1 + '3'
- davepeck 2y ago
  Third party tools (mypy, pyright, etc) are expected to check types. cpython itself does not. This will run just fine: python -c "x: int = 'not_an_int'" My opinion is that with PEP 695 landing in Python 3.12, the type system itself is starting to feel robust. These days, the python ecosystem's key packages all tend to have extensive type hints. The type checkers are of varying quality; my experience is that pyright is fast and correct, while mypy (not having the backing of a Microsoft) is slower and lags on features a little bit -- for instance, mypy still hasn't finalized support for PEP 695 syntax.
- zitterbewegung 2y ago
  Optional static typing is just like a comment (real term is annotation) of the input variable(s) and return variable(s). No optimization is performed. Using a tool such as mypy that kicks off on a CI/CD process technically enforces types but they are ignored by the interpreter unless you make a syntax error.
alfalfasprout 2y ago
The conda-forge ecosystem is making big strides in dependency management. No more are we stuck with the abysmal pip+venv story.
- falcor84 2y ago
  I definitely like some aspects of conda, but at least pip doesn't give me these annoying infinite "Solving environment" loops [0]. [0] https://stackoverflow.com/questions/56262012/conda-install-takes-forever-stuck-as-sat-solver https://stackoverflow.com/questions/56262012/conda-install-t...
  - setopt 2y ago
    That issue is fixed by using the libmamba resolver: https://www.anaconda.com/blog/a-faster-conda-for-a-growing-community https://www.anaconda.com/blog/a-faster-conda-for-a-growing-c...
ramses0 2y ago
You forgot: [X] print requires parentheses
- nine_k 2y ago
  Fair. But it was importable from __future__ back in 2.7.
- vulnbludog 2y ago
  Idk why but python 2 print still pops up in my nightmares lol on bro
- zarzavat 2y ago
  print was way better when it was a statement.
VeejayRampay 2y ago
the efficient dependency management is coming, the good people of astral will take care of that with the uv-backed version of rye (initially created by Armin Ronacher with inspirations from Cargo), I'm really confident it'll be good like ruff and uv were good
- noisy_boy 2y ago
  rye's habit of insisting on creating a .venv per project is a deal-breaker. I don't want .venvs spread all over my projects eating into space (made worse by the ml/LLM related mega packages). It should atleast respect activated venvs.
  - nine_k 2y ago
    A venv per project is a very sane way. Put them into the ignore file. Hopefully they also could live elsewhere in the tree.
  - VeejayRampay 2y ago
    well that's good for you, but you're in the minority and rye will end up being a standard anyway, just like uv and ruff, because they're just so much better than the alternatives
  - fastasucan 2y ago
    I think uv's use of a global cache means that having several .venv with the same packages is less of a problem.
agumonkey 2y ago
I'm eager to see what a simple JIT can bring to computing energy savings on python apps.
- KeplerBoy 2y ago
  I'd wager the energy savings could put multiple power plants out of service. I regularly encounter python code which takes minutes to execute but runs in less than a second when replacing key parts with compiled code.
whoiscroberts 2y ago
Optional static typing, not really. Those type hints are not used at runtime for performance. Type hint a var as a string then set it to an init, that code still gonna try to execute.
- zarzavat 2y ago
  > Those type hints are not used at runtime for performance. This is not a requirement for a language to be statically typed. Static typing is about catching type errors before the code is run. > Type hint a var as a string then set it to an int, that code still gonna try to execute. But it will fail type checking, no?
  - mondrian 2y ago
    The critique is that "static typing" is not really the right term to use, even if preceded by "optional". "Type hinting" or "gradual typing" maybe. In static typing the types of variables don't change during execution.
    - zarzavat 2y ago
      If there’s any checking of types before program runs then it’s static typing. Gradual typing is a form of static typing that allows you to apply static types to only part of the code. I’m not sure what you mean by variables not changing types during execution in statically typed languages. In many statically typed languages variables don’t exist at runtime, they get mapped to registers or stack operations. Variables only exist at runtime in languages that have interpreters. Aside from that, many statically typed languages have a way to declare dynamically typed variables, e.g. the dynamic keyword in C#. Or they have a way to declare a variable of a top type e.g. Object and then downcast.
      - neonsunset 2y ago
        'dynamic' in C# is considered a design mistake and pretty much no codebase uses it. On the other hand F# is much closer to the kind of gradual typing you are discussing.
nhumrich 2y ago
Python 3.12 introduces a little bit of JIT. Also, there is always pypy. For efficient dependency management, there is now rye and UV. So maybe you can check all those boxes?
- nine_k 2y ago
  Rye is pretty alpha, uv is young, too, and they are not part of "core" Python, not under the Python Foundation umbrella (like e.g. mypy is). So there's plenty of well-founded hope, but the boxes are still not checked.

Python 3 progress so far: [x] Async. [x] Optional static typing. [x] Threading. [ ] JIT. [ ] Efficient dependency management.

by nine_k 2y ago

Python 3 progress so far: [x] Async. [x] Optional static typing. [x] Threading. [ ] JIT. [ ] Efficient dependency management.

janice1999 2y ago

Not sure what this list means, there are successful languages without these feature. Also Python 3.13 [1] has an optional JIT [2], disabled by default. [1] https://docs.python.org/3.13/whatsnew/3.13.html https://docs.python.org/3.13/whatsnew/3.13.html [2] https://peps.python.org/pep-0744/ https://peps.python.org/pep-0744/

jolux 2y ago
The successful languages without efficient dependency management are painful to manage dependencies in, though. I think Python should be shooting for a better package management user experience than C++.
- yosefk 2y ago
  If Python's dependency management is better than anything, it's better than C++'s. Python has pip and venv. C++ has nothing (you could say less than nothing since you also have ample opportunity for inconsistent build due to mismatching #defines as well as using the wrong binaries for your .h files and nothing remotely like type-safe linkage to mitigate human error. It also has an infinite number of build systems where each system of makefiles or cmakefiles is its own build system with its own conventions and features). In fact python is the best dependency management system for C++ code when you can get binaries build from C++ via pip install...
  - wiseowise 2y ago
    > If Python's dependency management is better than anything, it's better than C++'s. That’s like the lowest possible bar to clear.
    - yosefk 2y ago
      Agreed, but that was the bar set by the comment I was replying to, which claimed Python doesn't clear it.
    - vulnbludog 2y ago
      On bro
  - stavros 2y ago
    That was the entire point, that C++ is the absolute worst.
    - dgfitz 2y ago
      I pip3 installed something today. It didn’t work, at all. I then yum installed a lib and headers, it worked well. C++ on an msft platform is the worst. I can’t speak for Mac. C++ on a linux is quite pleasant. Feels like most of the comments like yours are biased for un-stated reasons.
      - stavros 2y ago
        If I had a penny for every time I gave up on compiling C++ software because there's no way to know what dependencies it needs, I'd be a millionaire. Python at least lists them.
        dgfitz 2y ago
        If I had a penny every time I heard something like that on sites like this, I’d be a billionaire :)
        ahartmetz 2y ago
        Is that because the compiler failed with "foo.h not found" or the build system said "libfoo not found"? CMake is most common and it will tell you. Worst case it's difficult to derive the package name from the name in the diagnostic. It's not great, but usually not a big deal neither IME. Typically a couple of minutes to e.g. find that required libSDL2 addon module or whatever, if there is that kind of problem at all.
        stavros 2y ago
        Yes it is, and it's usually such a big deal for me that I just don't use that software. I don't have time to go through a loop of "what's the file name? What package is it in? Install, repeat". This is by far the worst experience I've had with any language. Python has been a breeze in comparison.
  - andmkl 2y ago
    C++ has apt-get etc. because the libraries do not change all the time. Also, of course there are vcpkg and conan. Whenever you try to build something via pip, the build will invariably fail. The times that NumPy built from source from PyPI are long over. In fact, at least 50% of attempted package builds fail. The alternative of binary wheels is flaky.
    - viraptor 2y ago
      > C++ has apt-get That's not a development dependency manager. System package management is a different kind of issue, even if there's a bit of overlap. > because the libraries do not change all the time That's not true in practice. Spend enough time with larger projects or do some software packaging and you'll learn that the pain is everywhere.
- Galanwe 2y ago
  Not sure this is still a valid critic of Python in 2024. Between pip, poetry and pyproject.toml, things are now quite good IMHO.
  - Arcanum-XIII 2y ago
    All is well, then, one day, you have to update one library. Some days later, in some woods or cave, people will hear your screams of rage and despair.
    - Galanwe 2y ago
      Been using python for 15 years now, and these screams were never heard. Dev/test with relaxed pip installs, freeze deployment dependencies with pip freeze/pip-tools/poetry/whateveryoulike, and what's the problem?
      - neeleshs 2y ago
        same here. Been using python/pip for 10+ years and this was never a problem. In the java world, there is jar hell, but it was never a crippling issue, but a minor annoyance once a year or so. In general, is dependency management such a massive problem it is made to be on HN? Maybe people here are doing far more complex/different things than I've done in the past 20 years
      - mixmastamyk 2y ago
        Guessing that folks who write such things are lacking sysad skills like manipulating paths, etc. It does take Python expertise to fix other issues on occasion but they are fixable. Why I think flags like ‘pip —break-system-packages’ are silly. It’s an optimization for non-users over experienced ones.
  - arp242 2y ago
    I guess that depends from your perspective. I'm not a Python developer, but like many people I do want to run Python programs from time to time. I don't really know Rust, or Cargo, but I never have trouble building any Rust program: "cargo build [--release]" is all I need to know. Easy. Even many C programs are actually quite easy: "./configure", "make", and optionally "make install". "./configure" has a nice "--help". There is a lot to be said about the ugly generated autotools soup, but the UX for people just wanting to build/run it without in-depth knowledge of the system is actually quite decent. cmake is a regression here. With Python, "pip install" gives me an entire screen full of errors about venv and "externally managed" and whatnot. I don't care. I just want to run it. I don't want a bunch of venvs, I just want to install or run the damn program. I've taken to just use "pip install --break-system-packages", which installs to ~/.local. It works shrug. Last time I wanted to just run a project with a few small modifications I had a hard time. I ended up just editing ~/.local/lib/python/[...] Again, it worked so whatever. All of this is really where Python and some other languages/build systems fail. Many people running this are not $language_x programmers or experts, and I don't want to read up on every system I come across. That's not a reasonable demand. Any system that doesn't allow non-users of that language to use it in simple easy steps needs work. Python's system is one such system.
- est 2y ago
  Deps in CPython are more about .so/.dll problem, not much can be done since stuff happens outside python itself.
- __MatrixMan__ 2y ago
  Python's dependency management sucks because they're audacious enough to attempt packaging non-python dependencies. People always bring Maven up as a system that got it right, but Maven only does JVM things. I think the real solution here is to just only use python dependency management for python things and to use something like nix for everything else.
  - adgjlsfhk1 2y ago
    Julia's package manager (for one) works great and can manage non Julia packages. the problem with python's system is that rejecting semver makes writing a package manager basically impossible since there is no way to automatically resolve packages.
    - woodruffw 2y ago
      Could you clarify what you mean? pip and every other Python package installer is absolutely doing automatic package resolution, and the standard (PEP 440) dependency operators include a compatible version operator (~=) that's predicated on SemVer-style version behavior.
  - pletnes 2y ago
    This is what we used to have and it was much worse. Source: lived that life 10-15 y ago.
    - __MatrixMan__ 2y ago
      15y ago I was using apt-get to manage my c++ dependencies with no way of keeping track of which dependency went with which project. It was indeed pretty awful. Now when I cd into a project, direnv + nix notices the dependencies that that project needs and makes them available, whatever their language. When I cd into a different project, I get an entirely different set of dependencies. There's pretty much nothing installed with system scope. Just a shell and an editor. Both of these are language agnostic, but the level of encapsulation is quite different and one is much better than that other. (There are still plenty of problems, but they can be fixed with a commit instead of a change of habit.) The idea that every language needs a different package manager and that each of those needs to package everything that might my useful when called from that language whether or not it is written in that language... It just doesn't scale.
- galdosdi 2y ago
  The shitshow that is python tooling is one of the reasons I prefer java jobs to python jobs when I can help it. Java got this pretty right years and years and years earlier. Why are python and javascript continuing to horse around playing games?

GTP 2y ago

I don't get how this optional static typing works. I had a quick look at [1], and it begins with a note saying that Python's runtime doesn't enforce types, leaving the impression that you need to use third-party tools to do actual type checking. But then it continues just like Python does the check. Consider that I'm not a Python programmer, but the main reason I stay away from it is the lack of a proper type system. If this is going to change, I might reconsider it. [1] https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html

deleted 2y ago
[deleted]
wk_end 2y ago
The interpreter does not and probably never will check types. The annotations are treated as effectively meaningless at runtime. External tools like mypy can be run over your code and check them.
- cwalv 2y ago
  It checks types .. it doesn't check type annotations. Just try: $ Python >>> 1 + '3'
davepeck 2y ago
Third party tools (mypy, pyright, etc) are expected to check types. cpython itself does not. This will run just fine: python -c "x: int = 'not_an_int'" My opinion is that with PEP 695 landing in Python 3.12, the type system itself is starting to feel robust. These days, the python ecosystem's key packages all tend to have extensive type hints. The type checkers are of varying quality; my experience is that pyright is fast and correct, while mypy (not having the backing of a Microsoft) is slower and lags on features a little bit -- for instance, mypy still hasn't finalized support for PEP 695 syntax.
zitterbewegung 2y ago
Optional static typing is just like a comment (real term is annotation) of the input variable(s) and return variable(s). No optimization is performed. Using a tool such as mypy that kicks off on a CI/CD process technically enforces types but they are ignored by the interpreter unless you make a syntax error.

alfalfasprout 2y ago

The conda-forge ecosystem is making big strides in dependency management. No more are we stuck with the abysmal pip+venv story.

falcor84 2y ago
I definitely like some aspects of conda, but at least pip doesn't give me these annoying infinite "Solving environment" loops [0]. [0] https://stackoverflow.com/questions/56262012/conda-install-takes-forever-stuck-as-sat-solver https://stackoverflow.com/questions/56262012/conda-install-t...
- setopt 2y ago
  That issue is fixed by using the libmamba resolver: https://www.anaconda.com/blog/a-faster-conda-for-a-growing-community https://www.anaconda.com/blog/a-faster-conda-for-a-growing-c...

ramses0 2y ago

You forgot: [X] print requires parentheses

nine_k 2y ago
Fair. But it was importable from __future__ back in 2.7.
vulnbludog 2y ago
Idk why but python 2 print still pops up in my nightmares lol on bro
zarzavat 2y ago
print was way better when it was a statement.

VeejayRampay 2y ago

the efficient dependency management is coming, the good people of astral will take care of that with the uv-backed version of rye (initially created by Armin Ronacher with inspirations from Cargo), I'm really confident it'll be good like ruff and uv were good

noisy_boy 2y ago
rye's habit of insisting on creating a .venv per project is a deal-breaker. I don't want .venvs spread all over my projects eating into space (made worse by the ml/LLM related mega packages). It should atleast respect activated venvs.
- nine_k 2y ago
  A venv per project is a very sane way. Put them into the ignore file. Hopefully they also could live elsewhere in the tree.
- VeejayRampay 2y ago
  well that's good for you, but you're in the minority and rye will end up being a standard anyway, just like uv and ruff, because they're just so much better than the alternatives
- fastasucan 2y ago
  I think uv's use of a global cache means that having several .venv with the same packages is less of a problem.

agumonkey 2y ago

I'm eager to see what a simple JIT can bring to computing energy savings on python apps.

KeplerBoy 2y ago
I'd wager the energy savings could put multiple power plants out of service. I regularly encounter python code which takes minutes to execute but runs in less than a second when replacing key parts with compiled code.

whoiscroberts 2y ago

Optional static typing, not really. Those type hints are not used at runtime for performance. Type hint a var as a string then set it to an init, that code still gonna try to execute.

zarzavat 2y ago
> Those type hints are not used at runtime for performance. This is not a requirement for a language to be statically typed. Static typing is about catching type errors before the code is run. > Type hint a var as a string then set it to an int, that code still gonna try to execute. But it will fail type checking, no?
- mondrian 2y ago
  The critique is that "static typing" is not really the right term to use, even if preceded by "optional". "Type hinting" or "gradual typing" maybe. In static typing the types of variables don't change during execution.
  - zarzavat 2y ago
    If there’s any checking of types before program runs then it’s static typing. Gradual typing is a form of static typing that allows you to apply static types to only part of the code. I’m not sure what you mean by variables not changing types during execution in statically typed languages. In many statically typed languages variables don’t exist at runtime, they get mapped to registers or stack operations. Variables only exist at runtime in languages that have interpreters. Aside from that, many statically typed languages have a way to declare dynamically typed variables, e.g. the dynamic keyword in C#. Or they have a way to declare a variable of a top type e.g. Object and then downcast.
    - neonsunset 2y ago
      'dynamic' in C# is considered a design mistake and pretty much no codebase uses it. On the other hand F# is much closer to the kind of gradual typing you are discussing.

nhumrich 2y ago

Python 3.12 introduces a little bit of JIT. Also, there is always pypy. For efficient dependency management, there is now rye and UV. So maybe you can check all those boxes?

nine_k 2y ago
Rye is pretty alpha, uv is young, too, and they are not part of "core" Python, not under the Python Foundation umbrella (like e.g. mypy is). So there's plenty of well-founded hope, but the boxes are still not checked.