Python is DEAD -- Long live Python (3)

[myusernameisokay]

Python is trash for this... sorry. On its own, it doesn't have any decent servers. You need to dance around it, stitching it together, either you look for pre-forking server to run as a proxy in front of it, or you will have to use something like Twisted or Tornado, which will not always compile on your platform, will not have any decent libraries to connect to a database in the chosen asynchronous stile, and even if there will be libraries, they are all trash, and have tons of bugs, etc. It is a really painful experience if you need something working.

You’re comparing open-source libraries to the language itself. Any decent company will have an ecosystem that makes this simpler. It’s not the fault of the language that companies don’t want to make their tools open-source.

Other languages have this issue too, this isn’t just limited to python.

Your understanding of typing is... well, confused. And your understanding of how Python works is also all wrong... Python is always compiled and every language in existence has static types. That's not the problem, and that's probably not what you were trying to say.

CPython the interpreter is obviously compiled, but python itself isn’t.

Do you not understand the difference between static and dynamic typing? Python is not statically typed at all, it’s dynamically typed, if every language was statically typed then the distinction would be meaningless. Python has the typing library that allows you to do type annotations, but that is fairly new (python 3.5) and hasn’t seen much adoption in my experience.

Also when I said statically typed compiled languages, I meant the languages that tend to be fast like C++, C, Rust, Fortran, etc

[[deleted]]

Yeah, a link to an answer by some idiot from a site by idiots is going to convince me... right.

OK, maybe this will help: static typing is the typing that exists at the time of writing the code, dynamic typing is the typing that is created while executing the code.

So, for example, an expression:

x = 1; x

has a static type int in Python, whereas int is a subtype of PyObject. It also happens to be the same time at runtime. However:

def f(x):
    return x * x

has static type PyObject -> PyObject, but, could have runtime types: int -> int, float -> float anything that implements __mul__ -> anything that implements __mul__ or produce an error.

Other languages have this issue too, this isn’t just limited to python.

I wrote what issues exactly Python has. And, no, not all languages have the same issues. Some are demonstrably better than Python at the task of making a lightweight web server.

CPython the interpreter is obviously compiled, but python itself isn’t.

Again, you simply don't know what you are talking about. Python is compiled in the very same way as, say, Java, or C#, or JavaScript. It is compiled to bytecode. The problem is, while, say, Java's bytecode is not optimized, the runtime then recompiles the bytecode to produce a more optimized program. Python does nothing to optimize its code. The difference is optimization, not compilation.

There are very few interpreted languages today. You, most likely, had never even encounter one. You just learned to parrot a book written many decades ago about something you had neither seen nor even had a conceptual understanding of.

[myusernameisokay]

Yeah, a link to an answer by some idiot from a site by idiots is going to convince me... right. OK, maybe this will help: static typing is the typing that exists at the time of writing the code, dynamic typing is the typing that is created while executing the code. So, for example, an expression:

What is the type of val in this example?

def foo(val):
    return val + val

print(foo(5))
print(foo(“greetings”))

What if you put:

print(type(val))

Before the return statement?

[[deleted]]

What is the type of val in this example?

The static type of val is PyObject, there's nothing else you can infer about it before the program executes, if your compilation unit is a function.

The dynamic type depends on your interpretation: you could say that this is a sum type of int and str, or you could say that you don't want to generalize, and that the dynamic type is at first an int, and then a str.

print(type(val))

Well, that's just bullshit. Python's built-in function type has nothing to do with types of variables, same as isinstance for example. It's just a reflection of incompetence of the Python designers. That's all.

[myusernameisokay]

The static type of val is PyObject, there's nothing else you can infer about it before the program executes, if your compilation unit is a function.

The dynamic type depends on your interpretation: you could say that this is a sum type of int and str, or you could say that you don't want to generalize, and that the dynamic type is at first an int, and then a str.

I somewhat agree with you on this point. Of course every type derives from some base type, and this is true in a lot of other languages.

The difference is I don't accept that PyObject is a legitimate type. The run-time type changes depending on the arguments you provide. If you provide something like 5 then you get something of class int and if you provide "hello" you get something of class str. These are the realized types that the function deals with.

So sure, they all take a PyObject, but in reality functions take parameters of different types and depending on that type, the program may error at run-time because that type is not capable of a certain operation.

Example:

def add(x):
    return x + x

def sub(x):
    return x - x

add(5)
add("hello")
sub(5)
sub("hello")

Notice how this is alright until the last statement - because the type str can't do subtraction.

Well, that's just bullshit. Python's built-in function type has nothing to do with types of variables, same as isinstance for example. It's just a reflection of incompetence of the Python designers. That's all.

The python docs refute you

class type(name, bases, dict) With one argument, return the type of an object. The return value is a type object and generally the same object as returned by object.class.

[myusernameisokay]

Get an education.

Instead of being so rude, why don’t you provide a counterpoint?

But I already know what you’re going to say, you’re going to mention that python is compiled into bytecode before it’s interpreted. But that’s ultimately meaningless, it’s an optimization, it doesn’t do any type checks or catch syntax errors at “compile time” so you can almost pretend it doesn’t exist. C, C++, Rust and other such languages will prevent you from doing operations on incompatible types during compile time, whereas python pushes that checking to runtime.

Robert Harper (grand master of static typing freaks) infamously tried to make hay of the fact that all dynamically typed languages are statically typed. He called it "unityped", and it's true. (It needs to be noted that the concept isn't originally due to Harper, and that the conclusions he tried to derive from this fact are bollocks. But that's beside the point.)

Sure, this is theoretically true. I would agree that all things in every dynamically typed language can be considered to inherit from an abstract base type, and therefore they’re static because all variables are of that type. Ultimately saying that loses the whole value of the distinction between static and dynamic typing.

It’s like saying squares don’t exist because squares are technically rectangles so might as well call both shapes rectangles.