Python is actually “two languages” now, use it and take off immediately!

[CSDN editor’s note] Some people in the industry believe that today’s Python can be regarded as “two very similar programming languages ​​with the same name”. These two languages ​​can be called untyped Python and typed Python.

Original address: https://ift.tt/zmY8lnQ

Unauthorized reprinting is prohibited!

Author | Tin Translator | Deng Xiaojuan

Produced | CSDN (ID: CSDNnews)

As we all know, Python added support for “type hints” in version 3.6+. These “type hints” can be said to be a new syntax for declaring the type of a variable. Editors and some tools can provide better support by declaring the type of the variable.

But in fact, this new capability has created a small split in the Python community: Some people are completely uninterested in type hints, wary that the Python language seems to enter a new field; Excited about the potential of Type Tools and can’t wait to try it out. And the vast majority of people are in the middle, not entirely clear where and how to use “type hints” better.

Some people in the industry believe that today’s Python can be regarded as “two very similar programming languages ​​with the same name”. These two languages ​​can be called untyped Python and typed Python. Although the two languages ​​share a very large common ground, they are fundamentally different in the way they help developers solve problems.

Business logic code is more compatible with typed Python

Everyone knows that there are infrastructure codes and business logic codes in the code. Then we can imagine a mode of thinking about code:

• Infrastructure code is powerful code that exposes easy-to-use interfaces and is responsible for solving difficult and tricky problems, such as talking to browsers (Flask) talking to databases (Django ORM, SQLAlchemy), dependency injection frameworks (incant), Serialize(cattrs) or define classes(attrs, dataclasses);

• Business logic code is boring, but it allows you to solve problems, complete tasks and sprints in your daily work;

• The point of infrastructure code is to enable and empower business logic code that provides real value to companies, users, or anyone who uses what you write;

• The infrastructure code is the libraries you are using, and the business logic code is the code you write and deploy.

It’s worth noting that this way of thinking about code, like all abstractions, is flawed. A library you use may be a simple layer between other libraries, and thus have all the characteristics of business logic code; if you are a typical software developer, your working code base will basically have you for this code base. Infrastructure code written. Even so, the above way of thinking about software can still be applied most of the time, which is convenient for us to understand the code.

It is often not possible for infrastructure code to be fully type hinted internally. At least not in Python’s type system, and probably never will be powerful enough to support the types of operations that libraries like cattrs and attrs require. One of the biggest advantages of untyped Python is that the available infrastructure code can provide an amazing and powerful API, so, both then and now, untyped Python is very friendly to infrastructure code. Untyped Python is not very friendly to business logic code, which is why many software developers often complain about the difficulty of maintaining large Python-based systems.

The business logic code is often much simpler than the underlying code structure, and there are now hundreds, if not millions, of codebases that use SQLAlchemy or Django in an easy way. Because of this, business logic code and typed Python are a good match: such as moving an entire class of bugs from runtime to type-checking time, ease of refactoring, which is crucial to a healthy codebase life cycle; and powerful editor support, including auto-completion and robust listing of references, good code navigation; and a reduced need for tests, which greatly increase the amount of code that needs to be written and maintained. It supports object-oriented. In many cases, using object-oriented programming will make the code easier to expand and more maintainable.

So how do you get the combination of business logic code and typed Python to work?

First, we need the infrastructure code not to be type hinted internally, but rather to provide interfaces to types at code boundaries. This is exactly where the ecosystem is headed, as is the case with SQLAlchemy 2.0 and newer generation web frameworks like FastAPI. Also, as the Python type system matures, it will enable a class of infrastructure code to be fully typed.

This is a good thing for developers. Just imagine, once you know one of typed/untyped Python, it’s relatively easy for you to learn the other, at least compared to learning a completely different language. And learning it will greatly enhance the abilities of the developers themselves.

The advent of typed Python is a good thing

Someone may ask: Is there a code that is not only suitable for infrastructure code, but also makes business logic code more scalable/maintainable? Although I dare not assert, industry insiders say that it is almost impossible for a language like Python. You can refer to the situation in other languages:

• JavaScript also seems to have a split with TypeScript, as opposed to infra and business logic code. It should be similar to the case of Python;

• Java can be regarded as an out-and-out business logic language, which explains its popularity in the industry well, but the interfaces of all libraries are relatively stretched. It can basically be considered that Java is actually two languages, but the infrastructure Java is very difficult to operate. That’s why if a person says he wrote an ORM in Python, people may be very excited to see it; but if a person says he wrote an ORM in Java, many people may look at it like a madman. them;

• Rust has a very interesting approach to dealing with infrastructure code, they have a powerful macro system. Think of Rust macros as a different infrastructure language on top of Rust. Arguably, the way it fits into (typed) Rust is particularly elegant.

Overall, the emergence of typed Python is a good thing for the community, and untyped Python is not going away either. We just need to understand the correct positioning of each type and work hard to combine them effectively so that we can use them better.

The text and pictures in this article are from CSDN