4 ms·

Yeah, there are now 3 competitors and they all written in Rust: - zuban - ty (from ruff team) - pyrefly One year ago, we had none of them, only slow options

by f311a 1y ago

Yeah, there are now 3 competitors and they all written in Rust: - zuban - ty (from ruff team) - pyrefly One year ago, we had none of them, only slow options.

jerrygenser 1y ago
Basedpyright is not rust but it's a fork of pyright with added features that are otherwise locked in vscode
- f311a 1y ago
  It's written in Typescript, which is a super weird choice.
  - huflungdung 1y ago
    [dead]
  - wiseowise 1y ago
    Wasn’t pyright made specifically for VSCode? That would explain TS.
    - f311a 1y ago
      Yes, but why they did not write it in a compiled language? Pyright is pretty slow in large code bases and takes a lot of RAM. Javascript can be faster than python in some cases, but Python is so easily extendable with C,C++, Cython, Rust. They could use Python with one of the compiled language.
      - IshKebab 1y ago
        Because they wanted it to be usable on the web, and I guess WASM wasn't where it is right now when they started.
- drcongo 1y ago
  It's also horrible for fasle positives unless your project happens to be the exact same setup as the maintainers' - I had to turn off the actual type checking on it. I've since moved wholesale to the Ty alpha and it feels a hell of a lot smarter.
  - JimDabell 1y ago
    It also inherits the unfortunate attitude of Pyright that it will warn against idiomatic Python (EAFP) in favour of non-idiomatic Python (LBYL): https://github.com/microsoft/pyright/issues/1739 https://github.com/microsoft/pyright/issues/1739 https://docs.python.org/3/glossary.html#term-EAFP https://docs.python.org/3/glossary.html#term-EAFP https://docs.python.org/3/glossary.html#term-LBYL https://docs.python.org/3/glossary.html#term-LBYL
    - kstrauser 1y ago
      Eww, what? I hadn’t seen that before. Yikes, I hope the situation’s improved. I’d be butting into that continually.
    - deleted 1y ago
      [deleted]
    - maleldil 1y ago
      Sometimes dynamic Python idioms are incompatible with typed Python. I personally think that's fine, since I consider static typing a significant improvement overall.
      - JimDabell 1y ago
        This isn’t. They actually fixed that bug. Then they changed their minds and backed the fix back out again because they don’t think you should write Python that way: > I think EAFP is a very unfortunate and ill-advised practice. They want you to not write the idiomatic Python: try: foo = bar["baz"]["qux"] ... except KeyError: ... …and instead write the non-idiomatic version: if "baz" in bar and "qux" in bar["baz"]: foo = bar["baz"]["qux"] ... else: ... If this were a linter then I would accept that it is going to be opinionated. But this is not a linter, it’s a type checker. Their opinions about EAFP are irrelevant. That’s idiomatic Python.
- jon-wood 1y ago
  I'm sorry, I can't take seriously any piece of software which decided to prefix the previous version's name with "based". I'm aware this is a me problem.
  - cruffle_duffle 1y ago
    Hah. I love the name. It implies that whatever the original “pyright” was doing wasn’t keepin’ it real. This new version, it’s “based” so it must be somehow more “real” and “grounded” and “legit”. All I know is it is much more strict about stuff than pylance was. Also a me problem!
  - wiseowise 1y ago
    Definitely this. I commend author of BPyright, but clown (?) avatar, unknown identity of maintainer, and name of the fork rub me off wrong way.
arccy 1y ago
it'll be like python package managers and js web frameworks.... a new one every quarter
- vovavili 1y ago
  uv works so well for the vast majority of scenarios that I don't really see a demand for further innovation in the Python package manager domain.
  - insane_dreamer 1y ago
    it still needs to add handling for binaries (the one thing conda can do that uv can't)
  - arccy 1y ago
    yeah we all heard that story every 3 months with all the previous package managers. until there's adoption by an overwhelming majority of projects, it isn't really settled yet.
    - wiseowise 1y ago
      I’ve literally never heard that much buzz and excitement about Python tool before. And I’ve seen them all. All of them had some big issue that prevented it from getting mainstream. Either it was slow, or didn’t work with existing workflow, or had complex configuration, or something that prevented gradual adoption. uv is universally praised as the second coming Christ in Python world (and for a good reason). So no, I doubt there will be something else. Not only you need to be better than uv, you also need to have community momentum.
      - pjmlp 1y ago
        Using Python in one form or the other since Python 1.6, there is always some buzz for whatever tool now and then.
tialaramex 1y ago
Speed is one of those "Quantity has a quality all its own" things. We use very fast tools in a qualitatively different way, even though all that changed was how long it takes in seconds. It is interesting that nobody was writing these tools in C or in C++. There are obvious ergonomic reasons, but perhaps also it matters that Rust cares a lot more about types than either of those languages.
- f311a 1y ago
  It's just very hard to write such systems in C/C++. Even all these Rust versions are segfaulting and panicking quite a lot. So many corner and edge cases that can be found in Python code, and the memory handling is also hard. The author of Zuban started writing it back in 2020 or 2021, so it took him more than 4 years to complete it. And he is the author of Jedi, so he had prior experience already.
  - tialaramex 1y ago
    I get why they'd panic, but why have enough segfaults that you noticed? So, I went and read the code. Zuban seems to have a bunch of scary "I'm not sure if this is correct" unsafe blocks, which to me would be a red flag. I mean, it's better that there's a comment expressing the doubt, but my experience is that if you're not sure whether it's correct, it's probably not correct.
    - estebank 1y ago
      While acknowledging the risk of causing a pile-on (which I don't want!), would it be possible to have a link to them or a description of what the unsafe blocks accomplish? I'm intrigued if they are for performance or API ergonomics, if they are due to limitations of the borrow checker, the stdlib or crate dependencies. For anyone reaching for unsafe, there are in many cases either an existing API (split_at_mut comes to mind). For others, using zero-copy or bytemuck instead of unsafe is a good idea too. None of that is to say "never write unsafe", unsafe existing is pretty much one of the reasons for Rust to be :)

by f311a 1y ago

Yeah, there are now 3 competitors and they all written in Rust: - zuban - ty (from ruff team) - pyrefly One year ago, we had none of them, only slow options.

jerrygenser 1y ago

Basedpyright is not rust but it's a fork of pyright with added features that are otherwise locked in vscode

f311a 1y ago
It's written in Typescript, which is a super weird choice.
- huflungdung 1y ago
  [dead]
- wiseowise 1y ago
  Wasn’t pyright made specifically for VSCode? That would explain TS.
  - f311a 1y ago
    Yes, but why they did not write it in a compiled language? Pyright is pretty slow in large code bases and takes a lot of RAM. Javascript can be faster than python in some cases, but Python is so easily extendable with C,C++, Cython, Rust. They could use Python with one of the compiled language.
    - IshKebab 1y ago
      Because they wanted it to be usable on the web, and I guess WASM wasn't where it is right now when they started.
drcongo 1y ago
It's also horrible for fasle positives unless your project happens to be the exact same setup as the maintainers' - I had to turn off the actual type checking on it. I've since moved wholesale to the Ty alpha and it feels a hell of a lot smarter.
- JimDabell 1y ago
  It also inherits the unfortunate attitude of Pyright that it will warn against idiomatic Python (EAFP) in favour of non-idiomatic Python (LBYL): https://github.com/microsoft/pyright/issues/1739 https://github.com/microsoft/pyright/issues/1739 https://docs.python.org/3/glossary.html#term-EAFP https://docs.python.org/3/glossary.html#term-EAFP https://docs.python.org/3/glossary.html#term-LBYL https://docs.python.org/3/glossary.html#term-LBYL
  - kstrauser 1y ago
    Eww, what? I hadn’t seen that before. Yikes, I hope the situation’s improved. I’d be butting into that continually.
  - deleted 1y ago
    [deleted]
  - maleldil 1y ago
    Sometimes dynamic Python idioms are incompatible with typed Python. I personally think that's fine, since I consider static typing a significant improvement overall.
    - JimDabell 1y ago
      This isn’t. They actually fixed that bug. Then they changed their minds and backed the fix back out again because they don’t think you should write Python that way: > I think EAFP is a very unfortunate and ill-advised practice. They want you to not write the idiomatic Python: try: foo = bar["baz"]["qux"] ... except KeyError: ... …and instead write the non-idiomatic version: if "baz" in bar and "qux" in bar["baz"]: foo = bar["baz"]["qux"] ... else: ... If this were a linter then I would accept that it is going to be opinionated. But this is not a linter, it’s a type checker. Their opinions about EAFP are irrelevant. That’s idiomatic Python.
jon-wood 1y ago
I'm sorry, I can't take seriously any piece of software which decided to prefix the previous version's name with "based". I'm aware this is a me problem.
- cruffle_duffle 1y ago
  Hah. I love the name. It implies that whatever the original “pyright” was doing wasn’t keepin’ it real. This new version, it’s “based” so it must be somehow more “real” and “grounded” and “legit”. All I know is it is much more strict about stuff than pylance was. Also a me problem!
- wiseowise 1y ago
  Definitely this. I commend author of BPyright, but clown (?) avatar, unknown identity of maintainer, and name of the fork rub me off wrong way.

arccy 1y ago

it'll be like python package managers and js web frameworks.... a new one every quarter

vovavili 1y ago
uv works so well for the vast majority of scenarios that I don't really see a demand for further innovation in the Python package manager domain.
- insane_dreamer 1y ago
  it still needs to add handling for binaries (the one thing conda can do that uv can't)
- arccy 1y ago
  yeah we all heard that story every 3 months with all the previous package managers. until there's adoption by an overwhelming majority of projects, it isn't really settled yet.
  - wiseowise 1y ago
    I’ve literally never heard that much buzz and excitement about Python tool before. And I’ve seen them all. All of them had some big issue that prevented it from getting mainstream. Either it was slow, or didn’t work with existing workflow, or had complex configuration, or something that prevented gradual adoption. uv is universally praised as the second coming Christ in Python world (and for a good reason). So no, I doubt there will be something else. Not only you need to be better than uv, you also need to have community momentum.
    - pjmlp 1y ago
      Using Python in one form or the other since Python 1.6, there is always some buzz for whatever tool now and then.

tialaramex 1y ago

Speed is one of those "Quantity has a quality all its own" things. We use very fast tools in a qualitatively different way, even though all that changed was how long it takes in seconds. It is interesting that nobody was writing these tools in C or in C++. There are obvious ergonomic reasons, but perhaps also it matters that Rust cares a lot more about types than either of those languages.

f311a 1y ago
It's just very hard to write such systems in C/C++. Even all these Rust versions are segfaulting and panicking quite a lot. So many corner and edge cases that can be found in Python code, and the memory handling is also hard. The author of Zuban started writing it back in 2020 or 2021, so it took him more than 4 years to complete it. And he is the author of Jedi, so he had prior experience already.
- tialaramex 1y ago
  I get why they'd panic, but why have enough segfaults that you noticed? So, I went and read the code. Zuban seems to have a bunch of scary "I'm not sure if this is correct" unsafe blocks, which to me would be a red flag. I mean, it's better that there's a comment expressing the doubt, but my experience is that if you're not sure whether it's correct, it's probably not correct.
  - estebank 1y ago
    While acknowledging the risk of causing a pile-on (which I don't want!), would it be possible to have a link to them or a description of what the unsafe blocks accomplish? I'm intrigued if they are for performance or API ergonomics, if they are due to limitations of the borrow checker, the stdlib or crate dependencies. For anyone reaching for unsafe, there are in many cases either an existing API (split_at_mut comes to mind). For others, using zero-copy or bytemuck instead of unsafe is a good idea too. None of that is to say "never write unsafe", unsafe existing is pretty much one of the reasons for Rust to be :)