Python seems to have started with 'why do those other languages have all this trash' and then spent the time since then learning why and coming up with worse versions.

I use python a lot these days, and like it, but it's pretty funny seeing stuff like the above and type hints.

I hate not knowing what types a function takes and returns.

> Python seems to have started with 'why do those other languages have all this trash' and then spent the time since then learning why and coming up with worse versions.

This seems true to me too. Examples:

* if __name__ == "__main__": main()

* Private members being marked by convention with leading underscore (e.g. def _foo()) instead of being a language feature

* @staticmethod as a decorator instead of being a language feature

* Duck typing vs. abstract base classes

* Static type hints got retrofitted to the language gradually, one feature at a time

* Reference-counted garbage collection seems to be more deterministic than tracing garbage collection and ensures that unreachable resources have their finalizers run as soon as possible... except it's not true

* Having a GIL instead of being truly multi-threaded from day one

* Various OOP concepts that are much better explained in Java than Python: __eq__(), __hash__(), monitor wait() and notify(), object finalizers, thread safety, weak references

* Distinction between str and bytes. This is the biggest change from Python 2 to 3 and caused a lot of incompatibilities. Java separated String and byte[] from the start (though the use of UTF-16 is unfortunate).

The whole switch/pattern matching thing is a true abomination borne from: Well, things in statement position can't be expressions (or however Pythonistas might phrase it), so clearly switch/pattern matching must be a statement... It's such an own goal and undermines the main point of pattern matching.

(I do realize that there was opposition on this, but that the Clearly Wrong side won out is baffling.)

Same principle behind Python's crippled lambdas.

Yeah, it's a shame for Python. I am extremely impressed that Java 14's switch expression ( https://openjdk.org/jeps/361 ) is a generalization of the switch statement (since Java 1.0); it's like they took a page from Rust's language design. I have found the switch expression to be quite useful in my work.

Probably from ML/Haskell, but yes :)

Your quibbles show either a) a fundamental misunderstanding of Python or b) are just flat out incorrect.

> * * if __name__ == "__main__": main()

So, don't use it. Python is frequently run as a scripting language (something Java is fundamentally bad at) and this stems from that. All it does is box logic off when a file is being run directly vs imported. It's a user convention and not a language one....ignore it if you hate it so.

> * Private members being marked by convention with leading underscore (e.g. def _foo()) instead of being a language feature

This is all very well explained in the PEP. The quick run down, Python doesn't do anything to hide logic from users. Contracts are just conventions and python treats it that way; so the developer can say "you shouldn't use this directly, here's a notation to let you know", but nothing will stop a developer from doing what they want. In Java they'll just write a wrapper class, inherit the base class, and expose that logic. Or worse, fork the library just to edit the class' functionality in some minor way. In Python they'll just call it directly.

> * @staticmethod as a decorator instead of being a language feature

@staticmethod is a built-in, it is a language feature. It just doesn't follow your preferred syntax.

> * Duck typing vs. abstract base classes

You can do both in Python:

https://docs.python.org/3/library/abc.html

The concepts aren't mutually exclusive or even directly related. Java just happens to be bad at one of them, due to it's weirdly non-effective (for a VM'd language, at least) reflection system; so you think it's bad.

> * Static type hints

You're complaining about reflective programming and then complaining about a feature that essentially exists because you can't reflect. It's circular.

> * Reference-counted garbage collection seems to be more deterministic than tracing garbage collection and ensures that unreachable resources have their finalizers run as soon as possible... except it's not true.

GC arguments have run for decades and everyone has their opinions.

> * Having a GIL instead of being truly multi-threaded from day one

Python was created in 1989. Java was created in 1996. Can you guess what major change in computer history was happening around the latter's time?

Everything was GIANT-locked when Python was designed, unless it was specifically intended for SMP mainframes. The entirety of the FreeBSD operating system had a GIANT lock on it at the time, for instance. Linux didn't even exist. Mac OS and Windows both were fundamentally single threaded and cooperatively multitasked. Commercial Unices that supported SMP were only ~4-5 years old and a very small niche.

You might as well be complaining about "why didn't the x86 architecture just have 64-bit capabilities from the outset?"

> * Various OOP concepts that are much better explained in Java than Python: __eq__(), __hash__(), monitor wait() and notify(), object finalizers, thread safety, weak references.

In other words: "it's not Java, so it's bad".

Java is a pure-OO language; Python is a procedural language with OO as an optional feature. To that end, it exposes OO-features in an optional manner versus forcing you to use them against your will.

So if the basis of all your arguments is "OO is better in Java", well the the response is "yeah I'd hope so, since you have no other choice as it's the fundamental paradigm". Guess what? Haskell is much better at functional programming than Java; that also doesn't make a valid argument about whether either is good or bad.

> * Distinction between str and bytes. This is the biggest change from Python 2 to 3 and caused a lot of incompatibilities. Java separated String and byte[] from the start (though the use of UTF-16 is unfortunate).

Java was developed 7 years later and during a time that Unicode was becoming the standard over ASCII. Python was designed when everything was still ASCII and Unicode a mere glint to the general computer science realm.

As you pointed out, even Java made a bad decision here due to their premature adoption of the standards (as any modern designed language is quick to point out).

And your reply is half right, half wrong. Let me address the wrong parts.

> Duck typing vs. abstract base classes / You can do both in Python

I'm saying that the original intent of Python was duck typing, but then people realized that abstract base classes play an important role - e.g. isinstance() testing, static type annotations. So they still ended up where Java started.

> Static type hints / I don't even know what that means.

I'm saying that Python was designed with no type annotations on variables (though values did have types), and then they realized that people wanted this feature... and ended up where C/C++/Java/C# have been all along. Python became "enterprisey".

And then, Python implemented type hints rather badly from 3.0 through 3.10 and beyond. It doesn't include types in the official documentation, so now you have to guess what open() returns (it's typing.BinaryIO/typing.TextIO). It doesn't have an official type checker, instead relying on third-party tools like mypy. It moved items between typing and collections.abc. It requires `from future import __annotations__` for non-trivial programs. It changed typing.List to just list in 3.9. It introduced the | (union) operator in 3.10. And a bunch more little things I can't recall; it just had a bad out-of-the-box experience and kept tweaking things over the decade. Documenting generics and especially protocols in Python takes effort.

> Python was created in 1989. Java was created in 1996

Wrong. Java was created in 1991, and the first version released in 1996. https://en.wikipedia.org/wiki/Java_(programming_language)

Python 1 was released in 1994, and 2 in 2000. They had their chance to make breaking changes. https://en.wikipedia.org/wiki/History_of_Python

While you're right that Python predates Java, it's not by as many years as claimed.

> Various OOP concepts that are much better explained in Java than Python

To exemplify, here is how you figure out how to override `==`: https://docs.python.org/3/library/stdtypes.html#comparisons , https://docs.python.org/3/reference/expressions.html#express... . Notably, there is no documentation for object.__eq__().

Here is the Java version: https://docs.oracle.com/en/java/javase/23/docs/api/java.base...

Now for __hash__() / hashCode(), the Java version is clearer: https://docs.python.org/3/reference/datamodel.html#object.__... , https://docs.oracle.com/en/java/javase/23/docs/api/java.base...

Python __del__ is buried in the "Data model" page: https://docs.python.org/3/reference/datamodel.html#object.__... . Java's finalize() is easily found on Object: https://docs.oracle.com/en/java/javase/23/docs/api/java.base... . Furthermore, Joshua Bloch's book "Effective Java" has a chapter titled "Avoid finalizers and cleaners" that explains in detail why finalizers are problematic.

Python explains a lot less about weakref than Java: https://docs.python.org/3/library/weakref.html , https://docs.oracle.com/javase/8/docs/api/java/lang/ref/pack...

> Java is a pure-OO language

Extremely wrong. Java has primitive numeric types, which do not have methods or fields, and undergo painful boxing/unboxing conversions to interoperate with the OO world. Whether the performance benefits are worth it or not is debatable, but what's not debatable is that Java is not pure OOP. Some say that Java is a bad copy of Smalltalk, which I heard is fully object-oriented.

> Python is a procedural language with OO as an optional feature

Wrong. Every Python value is an object that can be inspected (dir(), .__dict__, etc.). And in the CPython API, every Python value is a PyObject*. I have ample grounds to believe that Python is more OO than Java.

>Wrong. Java was created in 1991, and the first version released in 1996.

Gosling and others started working on it in 1991, but does it really matter? First public release is when you can learn about it and borrow ideas. It doesn’t make your point less valid, of course - Java made a lot of hype back then.

> Python 1 was released in 1994, and 2 in 2000. They had their chance to make breaking changes. https://en.wikipedia.org/wiki/History_of_Python

You're purposefully fudging dates to make the argument more favorable to your point. If you want to argue initial source release, then you can maybe make the point for 0.9:

> In February 1991, Van Rossum published the code (labeled version 0.9.0) to alt.sources

And say that Python had it's initial release just slightly before Java had begun design specs. But Python was in use before that and Rossum had developed the initial version well before that (again, 1989):

> The programming language Python was conceived in the late 1980s,[1] and its implementation was started in December 1989[2] by Guido van Rossum

It's ironic that you're trying to make that same argument for Java and dismissing it for Python, when Python was very much in public use pre-1.0 and Java was not (outside of internal teams).

> Wrong. Every Python value is an object that can be inspected (dir(), .__dict__, etc.). And in the CPython API, every Python value is a PyObject*. I have ample grounds to believe that Python is more OO than Java.

I feel like, just based on this point, you've done nothing more than open the CPython source code and searched for "object". This naming was in place well before Python even had any of the OO-functionality that exists today (new-style classes derived from the Object type). If you're going to argue for "old-style" classes being OO in any way but name, you're probably going to fundamentally disagree with any OO fundamentalists, the designers of Python itself, and the Java community/designers. You might as well argue that structs with function pointers in C make it an OO-language, as that's functionally all they are.

PyObject doesn't correlate to a Python class/Object. It's a container data structure to allow for their duck/dynamic typing. Object is a type of PyObject; but it contains an additional layer of functionality to make it a Python Object (specifically PyMethodObject and PyTypeObject, and their correlative functionality). Again, to allow for the reflection/introspection and GC that you so bemoan; and due to the lack of C generics at the time (or really, even today). Being able to introspect a type has nothing to do with it's "OO-ness", although it can be very useful in such languages (such as C#).

As to your other point, sure...using "pure" was probably going too far. But by that same argument, even Haskell isn't pure-functional (nor do any really exist) due to it's need to interface with IO. But Java is about 90% there and strives for it. Python most definitely isn't nor does it make any intentions to do so.

Again, fudging the history/facts/topics to try and make your point. It's not worth discussing with someone who so fundamentally converses in bad faith. Especially since I'm making no claims to which is better, just outlining the flaws in your complaints. I really don't care about "better" languages.

In my humble and correct (trumping anyone else's) opinion, they are both garbage.

You're not wrong... but for different reasons :)

you don't need it until you get to importing modules.

hello world in python is literally just print("hello world!")

You don't even need it afterward, unless you want a file to be both an importable module and an executable script.

Arguably you could be a happy Python programmer without this capability.

I never understood why people bother with this when writing their python main file, which is never going to be imported because it doesn't make sense in the first place.

REPL-based development. You might be developing a script, but notice a bug. If you import your script as a module, you can run the function you’re debugging, figure out what’s wrong, edit the file, and then reimport the module (using importlib.reload).

Okay, that's quite convincing, thanks!

Because I dislike interspersing executable statements at module level with function definitions. I’d rather have all code live inside functions and have one main entry point for the script. It’s just a personal preference, nothing wrong with not doing that though.

But you could have a single main() call without the if statement, couldn't you?

Isn't that hugely elaborate compared to languages where top level statements are a function, functions return their last statement, and the return value of the entry function is sent to stdout unless invoked in special ways? That print() around the "hello world!" does not appear any less superfluous than all the public static void you can throw at a javac 1.0

You mean a language like... Python?

  >>> 'hello world'
  'hello world'

Exactly like that (well, almost exactly: if python includes the quotes then it's not really equivalent to print()).

The point was that by including that print(), people already do say yes to including "like you'd do in a real program" ceremony in their supposedly minimal examples.