this post was submitted on 22 Feb 2024
28 points (91.2% liked)

Python

6412 readers
3 users here now

Welcome to the Python community on the programming.dev Lemmy instance!

📅 Events

PastNovember 2023

October 2023

July 2023

August 2023

September 2023

🐍 Python project:
💓 Python Community:
✨ Python Ecosystem:
🌌 Fediverse
Communities
Projects
Feeds

founded 1 year ago
MODERATORS
28
submitted 9 months ago* (last edited 9 months ago) by [email protected] to c/python
 

Context

Being a full stack developer, I have decent experience with both python and Typescript. I often use python for API development and I have been trying to write code that is pep-484 compliant (aka fully typed). However, often I get the feeling that if I was using TypeScript it would be much easier.

That got me wondering why there isn't a fully typed language that compiles to python.

I am aware of some arguments, so I am going to get the conversation started by providing my thoughts on them.

ts2python

ts2python is a TypeScript to python compiler.

Unfortunately, it covers only a small subset of python's capabilities. I am not sure why this hasn't been adopted and/or expanded to cover more of python's capabilities, but I can see possible issues with some python features that are not supported by TypeScript like context managers or operator overloading.

Still wondering if it would be possible to extend the TypeScript compiles so it would support such features?

pep-484

pep-484 describes how to provide type hints for python, it's not ideal but good enough that don't have to invent a new language.

IMO that's a trap, pep-484 (and other typing related peps) are not a good enough solution, on the contrary sometimes they are straight up misleading.

For example, consider the stubs for comparisons with built-in types, you would notice that they are defined as __op__(self, other: Any) -> bool: ... which is not correct as when other implements __opposite_op__ that is called instead of builtin.__op__, and it's return value may be of a different type.

Typing tools have not caught up with it, right now only pyright has full compliance with pep-484 (and other typing related peps). For that reason, SQLAlchemy had to introduce more than a couple of workarounds so MyPy can understand what's is happening behind the scenes, even for features that are pep-484 compliant.

Use Another Language

Python was never meant to be fully typed, and they make it clear.

True, but there are a bunch of libraries unique to python that make it a mandatory choice for many tasks. Things are changing and other options become available, but it's going to take time until there is another viable alternative.

Conclusion

Interested to read your thoughts.

  1. Is there another reason typing support hasn't advanced?
  2. Are you satisfied with typing support for python?
  3. Are you transitioning to another language?
  4. Are you aware of any new and exciting typing tools?

Of course, if typing is not an issue for you, that's okay, every software has different constraints.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 12 points 9 months ago* (last edited 9 months ago)

WOW! https://github.com/modularml/mojo

Been looking for something like this, thanks a lot!!!!

Edit: Had a quick look at the docs. Mojo's initial build was published Sep2022, it's fairly young, but seems to be getting a lot of attention (on GitHub they have the same number of stars as mypy 🤯).

For anyone interested, their roadmap is an interested read. They seem to be taking a step-by-step approach, trying first to nail down core features first before moving to stuff like python inter-op and syntactic sugar.

Mojo still doesn’t support classes, the primary thing Python programmers use pervasively! This isn’t because we hate dynamism - quite the opposite. It is because we need to get the core language semantics nailed down before adding them. We expect to provide full support for all the dynamic features in Python classes, and want the right framework to hang that off of.

The "why mojo" section give a lot of background too. They are implementing an ML-IR compiler, which is really promising for optimization (think all the goodies we could use from LLVM).