5 ms·

I love the speed advantage of pyrefly over (based)pyright but so far it doesn't seem to highlight as much as pyright does, for example it doesn't catch unreacha

I love the speed advantage of pyrefly over (based)pyright but so far it doesn't seem to highlight as much as pyright does, for example it doesn't catch unreachable code like this: def fn(x: str): if x is None: x = "123" # pyright flags that as unreachable code, pyrefly does not Autocomplete for modules also doesn't work for me yet: import os os. # I'll get `ABC, `Any`, `AnyStr`, `AnyStr_co`, `BinaryIO`, ... Looking forward to have a fast language server for python though, pyright is way too slow for large projects.

veber-alex 1y ago
Yeah I have a similar experience with ty. Looks like none of these new type checkers are ready yet.
- f311a 1y ago
  Ty has autocomplete for imports, but it's hidden behind a toggle right now. They are still working on it. They index all the modules and functions, so you can just type the function name and it will suggest the correct import and insert it.
parhamn 1y ago
Whats the expected error in the example you gave? That x can't be none because it was received as a str?
- boxed 1y ago
  Or that x is unused?
- pawelkobojek 1y ago
  Exactly - something along the lines of "Statement is unreachable".
- robertlagrant 1y ago
  Yes, exactly. x would have to be str | None to be reachable.
- wiz21c 1y ago
  isn't it perfectly valid to pass None to that function ? It's not like python enforces types at runtime nor at compile time. Right ?
  - Austizzle 1y ago
    It's not valid from a typing perspective, but python will let you. If you want to disregard types though then none of this matters anyway and you won't get much benefit from these tools
  - yesb 1y ago
    Sure, it's valid python to do that. By that logic you could also pass an int. But the context of this post is that you're using a static type checker.
giancarlostoro 1y ago
It's funny because in other typed languages a string can be null because of string being a reference type as opposed to a value type. I think Python type hints make more sense than C# does in this respect, which gives me a chuckle (two of my favorite languages and the untyped one makes more sense with types). That said, not sure if you already have but I would add a github issue / ticket reporting your issue to raise awareness to the devs.
- _flux 1y ago
  In some other typed languages, that is. E.g. in C++, OCaml, Haskell, F#, Kotlin, and Rust (a non-exhaustive list) you can have non-nullable strings, and other objects.
  - asplake 1y ago
    It’s worth noting that even though the runtime allows nulls (i.e. None) anywhere, Python type checkers do distinguish between optional and mandatory types.
  - scuff3d 1y ago
    In Zig you have to mark variables as nullable when they are declared. If you try to assign null to any variable that doesn't have it marked as such the program won't compile. Any nullable type has to be unwrapped before accessing the value, or again, won't compile.
- Scarblac 1y ago
  All Python types are reference types. The reference to None isn't included in the str type. There's no way to get an actual null reference, afaik. Variables always have some value, possibly None. (not sure what happens if you set a reference to null from C - a crash, probably?)
- kstrauser 1y ago
  A quibble: Python is strongly typed. It’s not un-typed in any reasonable sense of the word. It’s dynamically typed, though: type information is on objects, not on the names referring to them.
kinto 1y ago
Hey, Pyrefly developer here, thanks for trying us out! Thanks for bearing with us with these issues you're experiencing while we're still in alpha. We're planning on adding unreachable code diagnostics soon (github issue [here](https://github.com/facebook/pyrefly/issues/1292 https://github.com/facebook/pyrefly/issues/1292)). These come for free with Pyright so we don't want to regress features. I'm happy to help diagnose/fix your autocomplete issue: it should work on modules. If you want to provide details here, on [discord](https://discord.gg/Cf7mFQtW7W https://discord.gg/Cf7mFQtW7W), or as a Github issue (github/discord preferred) we'll fix it for you + anyone else with the problem.
- pawelkobojek 1y ago
  I absolutely understand this is still alpha so I kind of assumed these are expected. Frankly, that's why I haven't submitted an issue -- I assumed it's going to be fixed at some point. I'll go ahead and make an issue on GitHub, thanks.

veber-alex 1y ago

Yeah I have a similar experience with ty. Looks like none of these new type checkers are ready yet.

f311a 1y ago
Ty has autocomplete for imports, but it's hidden behind a toggle right now. They are still working on it. They index all the modules and functions, so you can just type the function name and it will suggest the correct import and insert it.

parhamn 1y ago

Whats the expected error in the example you gave? That x can't be none because it was received as a str?

boxed 1y ago
Or that x is unused?
pawelkobojek 1y ago
Exactly - something along the lines of "Statement is unreachable".
robertlagrant 1y ago
Yes, exactly. x would have to be str | None to be reachable.
wiz21c 1y ago
isn't it perfectly valid to pass None to that function ? It's not like python enforces types at runtime nor at compile time. Right ?
- Austizzle 1y ago
  It's not valid from a typing perspective, but python will let you. If you want to disregard types though then none of this matters anyway and you won't get much benefit from these tools
- yesb 1y ago
  Sure, it's valid python to do that. By that logic you could also pass an int. But the context of this post is that you're using a static type checker.

giancarlostoro 1y ago

It's funny because in other typed languages a string can be null because of string being a reference type as opposed to a value type. I think Python type hints make more sense than C# does in this respect, which gives me a chuckle (two of my favorite languages and the untyped one makes more sense with types). That said, not sure if you already have but I would add a github issue / ticket reporting your issue to raise awareness to the devs.

_flux 1y ago
In some other typed languages, that is. E.g. in C++, OCaml, Haskell, F#, Kotlin, and Rust (a non-exhaustive list) you can have non-nullable strings, and other objects.
- asplake 1y ago
  It’s worth noting that even though the runtime allows nulls (i.e. None) anywhere, Python type checkers do distinguish between optional and mandatory types.
- scuff3d 1y ago
  In Zig you have to mark variables as nullable when they are declared. If you try to assign null to any variable that doesn't have it marked as such the program won't compile. Any nullable type has to be unwrapped before accessing the value, or again, won't compile.
Scarblac 1y ago
All Python types are reference types. The reference to None isn't included in the str type. There's no way to get an actual null reference, afaik. Variables always have some value, possibly None. (not sure what happens if you set a reference to null from C - a crash, probably?)
kstrauser 1y ago
A quibble: Python is strongly typed. It’s not un-typed in any reasonable sense of the word. It’s dynamically typed, though: type information is on objects, not on the names referring to them.

kinto 1y ago

Hey, Pyrefly developer here, thanks for trying us out! Thanks for bearing with us with these issues you're experiencing while we're still in alpha. We're planning on adding unreachable code diagnostics soon (github issue [here](https://github.com/facebook/pyrefly/issues/1292 https://github.com/facebook/pyrefly/issues/1292)). These come for free with Pyright so we don't want to regress features. I'm happy to help diagnose/fix your autocomplete issue: it should work on modules. If you want to provide details here, on [discord](https://discord.gg/Cf7mFQtW7W https://discord.gg/Cf7mFQtW7W), or as a Github issue (github/discord preferred) we'll fix it for you + anyone else with the problem.

pawelkobojek 1y ago
I absolutely understand this is still alpha so I kind of assumed these are expected. Frankly, that's why I haven't submitted an issue -- I assumed it's going to be fixed at some point. I'll go ahead and make an issue on GitHub, thanks.