aleksanb's comments

To repeat an earlier comment of mine from the launch of uv on hn (tl; dr: these new type checkers never support django):

The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code.

The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods.

I wish more python tooling took the TS approach of "what's in the wild IS the language", as opposed to a "we only typecheck the constructs we think you SHOULD be using".

The way these type checkers get fast is usually by not supporting the crazy rich reality of realworld python code.

The reason we're stuck on mypy at work is because it's the only type checker that has a plugin for Django that properly manages to type check its crazy runtime generated methods.

I wish more python tooling took the TS approach of "what's in the wild IS the language", as opposed to a "we only typecheck the constructs we think you SHOULD be using".

Looking forward to other games finally getting rid of all the digital currency indirection.

Most newer blizzard games will get a lot better due to this!

Agree with this.

All type checkers other than mypy (e.g. pyright, intellij) have ignored the level of plugin support necessary to make django work well, and so they are DOA for any large existing django codebase. Unless ruff decides to support such a dynamic interface as mypy's, it'll fare no better.

We use mypy with [django-stubs](https://github.com/typeddjango/django-stubs) which works ok nowadays.

There was an effort to create a typechecking plugin interface for dataclass-style transforms for python type checkers, but what was merged was so lacking that one couldn't even make something close to django-stubs with it.

I bought my 3900x just under 5 years ago. Norwegian consumer protection laws give me 5 years where the producer is required to fix any defects that came with the product.

As this bug now has become known to always have been there, i could probably force amd to replace my 3900x if they don't provide software patches.

Has anyone else attempted a similar RTM for software defects?

This is required by law in the eurozone and has been for some years now.

Users must be able to get their own data exported, in some useful format.

It's quite useful on ci, and as a `make mypy` can run before pushing up your code, but for interactive errors we all use pyright, which is a bit of a letdown because you don't get autocomplete for fields and models accessed through reverse relation managers etc, pyright doesn't know about them. Many packages ship types nowadays, so the type coverage isn't too bad for us right now.

Here's our plugin setup in mypy.ini in case this helps (Django 4.2 + drf 3.14)

  [mypy]
  plugins =
      mypy_django_plugin.main,
      mypy_drf_plugin.main
  ignore_missing_imports = True
  follow_imports = silent
  no_implicit_optional = True
  warn_unused_ignores = True
  check_untyped_defs = True
  disallow_untyped_defs = True
  disallow_untyped_calls = True
  warn_unreachable = True
  strict_equality = True
  allow_redefinition = True
  show_error_codes = True
  mypy_path = stubs
  
  [mypy.plugins.django-stubs]
  django_settings_module = 'mycompany.settings'

with packages:

  mypy==1.6.0
  django-stubs==4.2.4
  django-stubs-ext==4.2.2
  djangorestframework-stubs==3.14.3

with this horror of a regex in make (because you'll get drowned in wrong type errors in all of the untype files, and errors get shown from imports even if you don't care about that imported file), add more file targets as necessary:

  FILES_TO_MYPY = $(shell ls mycompany/\*/validators.py mycompany/\*/services.py mycompany/\*/selectors.py mycompany/\*/managers.py | sort | uniq)

  # 1)We have to grep out django-manager-missing like this until the following bug
  # is fixed: https://github.com/python/mypy/issues/12987.
  # 2) We grep out the line of `Found 95 errors in 16 files (checked 83 source
  # files)` that now appears as we use follow-imports: silent, because there's a
  # bug where errors from imported modules are counted against the total even
  # though they aren't emitted. If any real errors appear we get them as a
  # separate line anyways.
  .PHONY: mypy
  mypy:
   @{ MYPY_FORCE_COLOR=${NOT_CI} $(VENV)/bin/mypy --config-file mypy.ini $(FILES_TO_MYPY) 2>&3 | grep -v 'django-manager-missing\|errors in'; } 3>&1 | tee $(HYRE_TESTS_OUTPUT_PATH)/mypy.stdout.txt

This allows you to get proper errors for things like

  model = MyModel.objects.get()
  othermodel = model.othermodel_set.first()
  reveal_type(othermodel)  # correctly revealed to note: Revealed type is "Union[mycompany.importpath.models.OtherModel None]"

and even errors on typos like

  model = MyModel.objects.get()
  othermodel = model.ooooothermodel_set.first()  # revealed as MyModel has no attribute ooooothermodel_set, perhaps you ment othermodel_set
.

Pyright doesn't work with Django, as Django's so dynamic that it requires a plugin to infer all types correctly. Sadly, even mypy with plugins is a mess to get set up in vscode, especially if you want it to use the same config as you use for ci checks from the command line.

We use mypy + [django-stubs](https://github.com/typeddjango/django-stubs) (in a huge Django + drf project at day job) which includes a plugin for mypy allowing it to recognize all reverse relations and manager methods. Mypy is still really rough around the edges. The cli args are poorly documented, and how they correspond to declarations in a mypy.ini / pyproject.toml is mysterious. Match-statements still have bugs even a year after release. Exclusion of untyped / partially typed files and packages we've had to solve with grep filtering mypy's output for our whitelisted set of files, as it's been unable to separate properly between errors you care about (in your own codebase) and errors in others code (dependencies, untypable dynamic python packages etc).

The largest issue IMO is that mypy tried to adapt a java / OOP style way of type system onto python, instead of recognizing the language's real power within duck typing and passing structural types around. Typescript chose the right approach here, modelling javascript the way it is actually written, favoring structural over nominal typing, instead of the archaic and now left-behind way of Java-style OOP that has influenced mypy.

There was a recently accepted PEP which allowed for limited dataclass transforms, enough to cover the @attr.s usecase for both mypy and pyright, but nowhere near expressive enough to cover django's models and ORM sadly. It's probably impossible / undesirable to allow for such rich plugins, so i see the future for proper pluginless typing to be more akin to how pydantic / normal dataclasses solve typing, by starting with a specification of the types, deriving its runtime implementation, instead of plugins having to reverse the type representation of a custom DSL.

I had the same reaction and am now also subscribed.

- low profile, fantastic

- not full size. Numpads only get in the way!

- mechanical keys

- rotary encoder. Useful for everything! Fl studio, moving pixels in vegas, audio knob etc.

- i don’t mind the font, but perhaps a version without any typography would be nice.

I hope they’ll ship to Norway.

Come to zulip! We switched our company to zulip wholesale after covid forced work from home onto everyone, and wow, talk about a force multiplier.

Luckily the demoscene graphics showcase platform https://www.dwitter.net still enforces the 140 character limit! Keepon making those webgl canvas graphics!

Project co-author here. Check out our demo submission to Revision made with nin, "What Are You Syncing About", here: http://arkt.is/what-are-you-syncing-about/

View in chrome with webgl on for the best experience, or on your iPhone if you have a newer one!

Shameless astroturfing: I love zombocam; the only limit is myself!

My democrew (Ninjadev) has used this technique for multiple WebGL/Javascript productions over the last few years now.

You can see the final packed .PNG results here: Crankwork Steamfist https://stianj.com/crankwork-steamfist/, Everything is Fashion https://stianj.com/fashion/, and Inakuwa Oasis http://arkt.is/inakuwa-oasis/.

The tool used for creating both the demos and the packed .PNG is made by us and available on GitHub here https://github.com/ninjadev/nin/.

The setup seems rather similar to https://github.com/arut/nginx-rtmp-module which I've used in the past. Perhaps they've bundled it with Nginx Plus without crediting the original authors? The project has a bit too permissive license for my taste.

Me and a group of friends at NTNU spent the last three months implementing self-designed and working GPU from scratch in VHDL on a Xilinx Spartan 6 FPGA. At the same time as this, we also implemented fully working multi-cycle and pipelined MIPS CPUs for the same FPGA.

All of us came from software backgrounds, never having touched any hardware description language.

To get started I'd recommend reading Computer organization and design by Patterson and Hennessy (http://www.amazon.com/Computer-Organization-Design-Fifth-Edi...).

For the VHDL part, all we had available was this small basic VHDL compendium (not sure if I can redistribute it), open source github repositories from friends and classmates, as well as the always helpful vhdlguru.blogspot.com

So i'll reccomend following one of the open lecture series posted above :)

Hello HN! We, a group of summer interns at Nordic Semiconductor, have made an Internet of Things-enabling platform based on ARM's mbed technology. We make it easy to rapidly prototype and develop Bluetooth LE enabled devices - get up and running in under 10 lines of code, written directly in the browser.

We hope to create a community around BLE devices where developers share their ideas designs with each other. Everything is open-source, of course, with lots of supporting materials, together with companion apps for both Android and iOS.