Hacker News Reader

Comment by pawelkobojek | Hacker News Reader

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.

View on HN

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)). 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), or as a Github issue (github/discord preferred) we'll fix it for you + anyone else with the problem.

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.

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.

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.

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.

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.

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?)

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.

If you use the nullable types compiler option in C# (which defaults to enabled for new projects) then you need to declare you string as string? for it to be nullable :)

Yes, but you also need to turn the warning into an error for it to be actually usable, because .NET team didn't want to break the ecosystem, plenty of Assemblies out there didn't cared to update themselves.

I still have to disable nullable types in some delivery projects.

The billion dollar mistake.

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

Or that x is unused?

Exactly - something along the lines of "Statement is unreachable".

Yes, exactly. x would have to be str | None to be reachable.

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 ?

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

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.

Yeah I have a similar experience with ty.

Looks like none of these new type checkers are ready yet.

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.

Reply on news.ycombinator.com