Shulou(Shulou.com)06/02 Report--

This article focuses on "whether Python is a strongly typed language or a weakly typed language". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn whether Python is a strongly typed language or a weakly typed language.

1. Types of movement and movement and types of strength and weakness

Many readers should be familiar with dynamic and static types, but many people will confuse them with strong and weak types, so we need to clarify the concept first.

Both sets of types are specific to programming languages, but focus on different core issues.

For the concept of "dynamic type", its core question is "when do you know which type a variable is"?

Generally speaking, statically typed languages determine variable types at compile time, while dynamically typed languages determine variable types at run time.

For example, the function "int func (int a) {…}" is defined in some languages, and you can be sure at compile time that you know that its parameters and return values are of type int, so it is a static type, while typical languages, such as Python, define the function with "def func (a):..." The type of parameter and return value is not known, and the type of parameter and return value is finally determined only when the function is called at run time, so it is a dynamic type.

For the concept of "strong and weak types", the core question is "do different types of variables allow implicit conversion"?

Generally speaking, few (reasonable) implicit type conversions of compilers are strongly typed languages, while more (excessive) implicit type conversions are weakly typed languages.

For example, "1000" + 1 in Javascript will get the string "10001", while "1000"-1 will get the number 999. that is, the compiler implicitly converts two different types of objects according to the circumstances of use, but in a similar way, it will report type errors in strongly typed languages. (the conversion of numbers and strings is excessive, and some reasonable conversions will be mentioned below.)

According to the above definition, someone drew a classification diagram of common programming languages:

According to the strong and weak type dimensions, it can be summarized as follows:

Strong typing: Java, C #, Python, Ruby, Erlang (plus GO, Rust).

Weak types: C, C++, Javascript, Perl, PHP, VB...

2. The concept of strong and weak types in the past

The concept of dynamic and dynamic type is basically accepted by everyone, however, the concept of strong and weak type has a lot of controversy in question and answer community, technical forum and academic discussion. It will not be listed here.

Why is there so much controversy?

One of the main reasons is that someone has mixed it with the type of movement and movement.

The most obvious example is an interview that Guido van Rossum participated in in 2003, which happened to be about Strong versus Weak Typing:

But it is obvious that they are only talking about the difference between the types of movement and movement.

The interview also quoted James Gosling, the father of Java, and we can see from his statement that what he said about "strong and weak types" is actually the distinction between dynamic and static types.

Another classic example is that Dennis Ritchie, the father of the C language, once said that C is a "strongly typed but weakly checked" language. If compared to the previous definition, he actually refers to "static type weak type".

Why are these bosses confused?

In fact, the reason is also very simple, that is, at that time, there was no clear distinction between the type of movement and the type of strong and weak! In other words, the type of strength at that time refers to the type of movement and movement.

Wikipedia gives the definition of strong types in the 1970s, which can basically be reduced to the static types mentioned earlier:

In 1974, Liskov and Zilles defined a strongly-typed language as one in which "whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function." [3] In 1977, Jackson wrote, "In a strongly typed language each data area will have a distinct type and each process will state its communication requirements in terms of these types." [4]

The first few fathers of programming languages should hold similar ideas.

However, the bosses also realized that the concept of "strong and weak type" at that time was not fully accurate, which is why Dennis Ritchie was described as "strong type but weak check", and in the interview, Guido also emphasized that Python should not be called weak type, but rather run-time type (runtime typing).

But in those early days, the strong and weak type was basically equated with the movement type, and this idea still affects a lot of people today.

3. The current concept of strong and weak types

The early classification of programming languages is actually a mixture of movement and strength, but they are not one-to-one correspondence and overlap, and are not enough to express the differences between programming languages, so a clearer / richer definition is needed.

Some people have put forward the distinguishing dimensions such as "type safety" and "memory safety", and there are also static check types and dynamic check types, which have a certain intersection with strong and weak types.

Until the emergence of a 2004 comprehensive academic paper "Type Systems" (from Microsoft Research, author Luca Cardelli), specializing in different types of systems of programming languages:

In this paper, there is a brief summary of the strength check (that is, the type of strength) as follows:

Strongly checked language: A language where no forbidden errors can occur at run time (depending on the definition of forbidden error).

Weakly checked language: A language that is statically checked but provides no clear guarantee of absence of execution errors.

The key is the intensity of the program's check for untrapped errors. In some places that have actually gone wrong, weak-type programs do not capture, such as some pointer calculation and conversion in C language, while the first few of the "Ten Commandments for C programmers" are caused by weak types.

In this paper, the definition of these concepts is relatively abstract, because most of the uncaught errors (untrapped errors) are caused by implicit type conversion, so we evolve the definition in the first section, taking implicit type conversion as the judgment criterion.

Nowadays, it is common for many people to regard "tolerance for implicit type conversion" as the classification standard of strong and weak types (although not comprehensive enough, and there are some different voices).

Wikipedia, for example, regards implicit typing as one of the main features of weak typing:

A weakly typed language has looser typing rules and may produce unpredictable results or may perform implicit type conversion at runtime.

For example, take Python as an example. The mainstream view of the community is that it is a strongly typed language, and the criterion for judging it is implicit type conversion.

There are many examples, such as Python's official wiki, which specifically answers Why is Python a dynamic language and also a strongly typed language and gives four answers to characterize Python's "dynamic strong typing":

For example, the classification of strong and weak types is also specifically mentioned in Chapter 11 of the fluent Python. (its term is "rarely implicitly typed", which is quite rigorous, but it also mistakenly classifies C++ as strongly typed.)

4. Is Python a strongly typed language?

On the topic of "whether Python is a strong type or not", there are many misunderstandings besides the mainstream view.

On the one hand, some people mix strong and weak types with dynamic and dynamic types, which has historical reasons, which have been analyzed earlier.

Another equally important reason is that some people equate weak typing with "no implicit type conversion at all", which is not true.

In fact, the concept of strong and weak types contains part of relativism, and there may also be implicit type conversions in strongly typed languages.

For example, the Rust language designs a powerful type system to implement the "memory safe" design philosophy, but it also has implicit type conversions (automatic dereferencing).

The question is: what kind of implicit type conversion is within a reasonable range? And are some superficial implicit type conversions really implicit type conversions?

Going back to the example of Python, we can analyze several typical uses.

For example, "test" * 3, a string "multiplication" operation, although it is a two-type operation, does not involve implicit type conversion.

For example, type 10; x = "test" successively assigns different types of values to a variable. On the surface, the type of x has changed, which can be judged by type (x). However, the type in Python is bound to the value (right binding), not to the variable.

The variable x is exactly a variable name, a label bound to the actual variable, and it has no type. What type (x) determines is not the type of x itself, but the type of object that x points to, just as the built-in function id (x) calculates not the address of x itself, but the address of the actual object.

For example, there is no implicit type conversion between the addition of 1 + True and Boolean types. Because the Boolean type in Python is actually a subclass of the integer type, it is the same type! (if in doubt, please refer to PEP-285)

For example, the addition of integer / Boolean values to floating-point numbers does not require explicit type conversions in Python. However, its implementation process is actually using the digital _ _ add__ () method, everything in Python is an object, and digital objects have their own methods. (not necessarily in other languages)

In other words, the arithmetic operation between numbers is actually a process of function call, which is essentially different from the arithmetic operation in other languages.

In addition, although different digital types vary greatly at the computer storage level, in human eyes, they are the same type (broadly divided), so even if implicit type conversion occurs, it is logically acceptable.

Finally, there is another example, that is, the truth judgment of Python after if/while, which I have analyzed before, which converts other types of objects into Boolean values.

However, it is actually just the result of a function call (_ _ bool__ () and _ _ len__ ()), which is a reasonable result of calculation, and does not belong to implicit cast, and is not in the category of untrapped errors.

So, strictly speaking, no type conversion occurred in the previous five examples. The examples of floating point and truth judgment are intuitively type conversions, but they are actually Python features that are controllable, expected, and do not damage the original type.

To say the least, if you relax the meaning of "implicit type conversion", you will think that implicit type conversion has occurred in the latter two examples, but they are implemented through rigorous function calling procedures, and there will be no forbidden errors, so they are still strongly checked types.

5. Other related questions the meaning of the concept and the performance in Python are analyzed in detail in the previous article. Next, for the sake of logic and topic integrity, we need to answer a few small questions:

(1) can "implicit type conversion" be used as the basis for the classification of strong and weak types?

A clear definition of classification should be based on "Type Systems", which has a set of classifications for different error, and the strong and weak types are actually the processing categories for forbidden errors. Implicit type conversion is its obvious feature, but it is not all, nor is it the only basis for judgment.

In order to facilitate understanding, this paper uses this main feature to classify strong and weak types, but to emphasize that strong types are not without implicit type conversions, but there may be few and reasonable implicit type conversions.

(2) if other interpreters make Python support extensive implicit type conversions, is Python still a strongly typed language?

The standard specification of language is like the law, and the interpreter is the law enforcer. If there is a wrong interpretation of law enforcement, then the law is still the same law, and the wrong law enforcement behavior should be corrected; if there is something wrong with the law itself (causing ambiguity and contradiction in interpretation, or should be abandoned), then the law should be amended to ensure its certainty (either strong type or weak type).

(3) Why is Javascript a weak type?

Because it has a lot of implicit type conversions, very complex, very excessive! For example, the result of 123 + null in Javascript is 123123 + {} and the result is the string "123 [object Object]".

In addition, its double equal sign "=" may have multiple implicit type conversions in addition to basic comparison operations, for example, the result determined by true== ['2'] is false, while the result of true== ['1'] is true, and the results of [] =! [] and [undefined] = = false are both true.

(4) is C++ a weakly typed language?

As mentioned earlier, C++ is classified as strongly typed in "smooth Python", but in fact it should be classified as weakly typed. C++ type conversion is a very complex topic, @ Sister Yingyu Lou once wrote a series of articles to do a systematic discussion, article address: how to overcome the complex type conversion in C++?, a detailed explanation of C++ 's implicit type conversion and function overloading! who says C++ 's forced type conversion is difficult to understand?

6. Summary the concept of strong and weak types has a lot of controversy on the Internet, not only in Python, but also in languages such as CumberCraft +.

In fact, academically, this concept has long been clearly defined, and in fact it has been accepted by many people.

Most of those opposing voices are because of conceptual mixing, because they ignore another dimension that classifies languages; at the same time, there is also a noteworthy reason that strong typing cannot be considered to be "completely unimplicitly typed" or "as long as there is no xxx implicit typing".

At this point, I believe you have a deeper understanding of "Python is a strongly typed language or a weakly typed language". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.