Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mypy 1.6

mypy-lang.blogspot.com

Post reply on HN
Print view View original

101–110 of 114 posts

Re: Mypy 1.6

#101

Post by aleksanb »

rand_r wrote: post #87
aleksanb wrote: post #70

Earlier quoted context omitted.

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 f…

Did you manage to get MyPy + Django to work together usefully? I tried the plugin you mentioned but it still seemed stymied by the dynamic nature of Django (reverse relations, etc), so I gave up on it. If it’s actually possible to live in typed nirvana with Django I’ll bang my head against the wall some more. We’re using Django 3.2 btw + FactoryBoy. Actually there’s a number of annoyingly dynamic Python libraries out…

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
.

Re: Mypy 1.6

#102

Post by diarrhea »

guappa wrote: post #93
diarrhea wrote: post #75

Earlier quoted context omitted.

I had started using mypy a couple years ago and simply never looked back at the decision. I perceived pyright as a Microsoft-specific tool, and waved it off, as mypy seemed the blessed and eventually converged-upon target. Turns out that’s wrong so far. Tons of people advocating for the latter. I quickly looked at the two repos. Pyright has 30 open issues. Mypy is at 2200. That is a simplistic metric, but an immense…

I guess mypy has 10x more users as well. People who use pyright use an IDE and they aren't likely to report a bug. https://pypistats.org/packages/mypy https://pypistats.org/packages/pyright

Ah okay, thanks for the context. The projects are quite close in terms of GitHub stars, 11k vs 16k.

Re: Mypy 1.6

#103

Post by bjornasm »

cbb330 wrote: post #83
bjornasm wrote: post #82

Earlier quoted context omitted.

So the thousands of developers using Python either doesn't know their own best or are just in perpetual pain in their use of python? There isn't the slight possibility that your view on what is a useable programming language in production is subjective and not objective?

Yep! I think all of those repos will either proverbially die a hero or live long enough to see themselves as a villain. And thats because of the fundamental tradeoff of dynamic typing vs static typing. That part no one can disagree on. The only disagreeable part I believe I'm saying is where does the dynamic typing scale limit happen. As a polyglot developer, working a lot with junior developers, I can say that dynam…

What compells seasoned developers to keep using python if these flaws are so obvious, though?

Re: Mypy 1.6

#104

Post by jpk »

guappa wrote: post #92
KolmogorovComp wrote: post #14

Is anyone still using mypy, and if so why? I have replaced it by pyright [0] for a while now, and not looking back. It’s been a faster, more powerful replacement with (in my case), zero downside. [0]: https://github.com/microsoft/pyright

apt install pyright E: Unable to locate package pyright apt install mypy mypy is already the newest version (1.6.0-1).

  poetry add pyright
:)

Re: Mypy 1.6

#105

Post by cbb330 »

bjornasm wrote: post #103
cbb330 wrote: post #83

Earlier quoted context omitted.

Yep! I think all of those repos will either proverbially die a hero or live long enough to see themselves as a villain. And thats because of the fundamental tradeoff of dynamic typing vs static typing. That part no one can disagree on. The only disagreeable part I believe I'm saying is where does the dynamic typing scale limit happen. As a polyglot developer, working a lot with junior developers, I can say that dynam…

What compells seasoned developers to keep using python if these flaws are so obvious, though?

its comfortable, easy, appealing in the short term. just like why people overeat their junk food.

there's this common idea in management that new grads, SREs, "less experienced devs", can jump in and contribute. it's a falacy because the code becomes unmaintainable without a large investment (more unittests, refactoring the "buggy" code blocks with mypy type annotations, some SME who continues fixing prod bugs). a Python developer will shove their head in the sand with repl'ing, testing after deploy, and settle with this dev/ex while being completely unaware of the benefits of compiler errors and warnings.

Python has the same level of complexity as another language but you'll only see all of that dirty baggage in production as runtime exceptions.

Re: Mypy 1.6

#106

Post by cbb330 »

rixed wrote: post #88
cbb330 wrote: post #83

Earlier quoted context omitted.

Yep! I think all of those repos will either proverbially die a hero or live long enough to see themselves as a villain. And thats because of the fundamental tradeoff of dynamic typing vs static typing. That part no one can disagree on. The only disagreeable part I believe I'm saying is where does the dynamic typing scale limit happen. As a polyglot developer, working a lot with junior developers, I can say that dynam…

What would happen to our 10x advantage if every tech would suddenly believe you and leave scripting languages in the toy box?

by no means is go/java/rust/c++ a silver bullet. it is a way to raise the bar for debugging, reliability, support. it is more effective than bundling python with 5 other type bandaids. in the medium/long term, lets guess at 2 KLoC or >3 person team, these typed langs will result in faster feature development and lower issues in production.

Re: Mypy 1.6

#107

Post by randomdata »

sgarland wrote: post #80
randomdata wrote: post #50

Earlier quoted context omitted.

> but the larger purpose of the code is obscured in all the "if err != nil" weeds. That's the difference between script and system programming. When writing scripts, one is only concerned about carrying out a certain task and if anything goes wrong the whole thing can bail. Systems are more robust. When things go wrong they cannot just fail. They need to recover gracefully and do something meaningful in the failed st…

Python has excellent exception handling, and its corollary to if err != nil would be try/except blocks everywhere. That said, I hate Go for unrelated reasons, and love Python.

Go's exception handling (panic/recover) is very much like most other languages with exception handling, including Python. It is there to use when you have exceptions.

But we're talking about expected failure (network failure, hardware failure, etc.), not exceptional cases (programmer error). You would not want to carry 'expecteds' on exception handlers. Different tools for different jobs.

That said, systems transcend Go. The discussion isn't about Go, or Python, specifically.

Re: Mypy 1.6

#108

Post by randomdata »

pjmlp wrote: post #98
zelphirkalt wrote: post #86

Earlier quoted context omitted.

TCO is available if I want it? How? Do you mean writing a slow decorator, that performs some stack magic and that I need to add everywhere? Does it cover all the cases? Like mutually tail recursive functions? Abusing the walrus operator — Well, it is abuse then and hard to read. I actually mean: https://www.gnu.org/software/guile/manual/html_node/Paramete...

It isn't as if Go provides those features, which was the suggested alternative to Python.

It was suggested that neither Go nor Python would be chosen if language features are what you are after. Pointing out that both lack a certain feature only reiterates why one would not chose either of them.

Re: Mypy 1.6

#109

Post by guappa »

jpk wrote: post #104
guappa wrote: post #92

Earlier quoted context omitted.

apt install pyright E: Unable to locate package pyright apt install mypy mypy is already the newest version (1.6.0-1).

poetry add pyright :)

I tend to stick to things that are available in apt, so that my software is possible to distribute.

Re: Mypy 1.6

#110

Post by guappa »

diarrhea wrote: post #102
guappa wrote: post #93

Earlier quoted context omitted.

I guess mypy has 10x more users as well. People who use pyright use an IDE and they aren't likely to report a bug. https://pypistats.org/packages/mypy https://pypistats.org/packages/pyright

Ah okay, thanks for the context. The projects are quite close in terms of GitHub stars, 11k vs 16k.

Stars are meaningless. There are bots putting them at random to look like legit accounts and sell them to projects.
Post reply on HN