Hacker Newsnew | past | comments | ask | show | jobs | submit | maleldil's commentslogin

Has the developer tooling been fixed? Doesn't it use an ephemeral environment? How do editors/LSPs know where to get dependency information?

Is there a world in the near future where Americans aren't buying oil or oil-derived products, regardless of the price?

I hope you understand you are part of a very, very small minority.

You can source the virtualenv like normal.

It's usually not "noob" students. Big conferences require reviewers to have at least one (usually more) published paper in major venues. For students, this usually means they went through the process of being the first author on a few papers.

GP suggested a life ban. Maybe suspend for 6 months instead? That's a long time without publishing in the current publish-or-perish academia.

> Maybe suspend for 6 months instead?

Suspend for 6 months from a conference that is held yearly?


I wasn't thinking about ICML specifically. My mind was on the ARR.

Ideally, the errors shouldn't be returned as-is, but wrapped with context instead. If that context doesn't matter for you, you can have your editor wrap the if instead, which helps a lot.

ty and zuban also don't give an error. pyright and pyrefly do.

We provide this diagnostic in ty (https://docs.astral.sh/ty/reference/rules/#possibly-unresolv...), but it's disabled by default because it can have false positives in many scenarios where the code works at runtime (this is true also in the type checkers that enable it by default). A typical example is code like

  def _(flag: bool):
    if flag:
      x = True
    ...
    if flag:
      read(x)
But it's easy to turn the rule on if you want it:

  [tool.ty.rules]
  possibly-unresolved-reference = "error"

Why not? Have mypy/pyright/pryefly/ty type errors break CI. If you're starting a new project, there's no reason you shouldn't.

> Have mypy/pyright/pryefly/ty type errors break CI.

Only if types are present.

> If you're starting a new project, there's no reason you shouldn't. Most dependencies would still be untyped.


> Only if types are present.

Make sure they are. Set no implicit any in your type checker, and use a linter to ensure every function has type annotations.

> Most dependencies would still be untyped

Most is a big exaggeration. I understand it's dependent on the domain, but only a small subset of the ones I use in my projects are untyped, and you can write typed wrappers when necessary.

Also, perfect is the enemy of the good. I'd rather have a 90% typed codebase and work around untyped dependencies than abandon the idea at all.


> don’t sing along to the music

What's wrong with that?


inconvenient for the purposes of recording, sounds like

Audiences in Tokyo aren’t quite to make it easier to record. It just so happens that audiences in Tokyo tend to be quiet, so the recordings of the Tokyo shows tend to end up the clearest.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: