If you decide to design your own language, there are thousands of sort of amateur language designer pitfalls.
Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another’s code; too little and expressiveness is endangered.
It’s easy to make mistakes that only come out much later, after you’ve already implemented a lot of code. You’ll realize Oh I should have used a different type of data structure. Start over from scratch.
There is an incredibly large spectrum of possible causes for program bugs, including simple typos, “thinkos,” hidden limitations of underlying abstractions, and outright bugs in abstractions or their implementation.
If you’re talking about Java in particular, Python is about the best fit you can get amongst all the other languages. Yet the funny thing is, from a language point of view, JavaScript has a lot in common with Python, but it is sort of a restricted subset.
In my daily work, I work on very large, complex, distributed systems built out of many Python modules and packages. The focus is very similar to what you find, for example, in Java and, in general, in systems programming languages.
My own perception of that is somewhat colored by where people ask my advice, which is still, of course, about changes to Python internals or at least standard libraries.
I would guess that the decision to create a small special purpose language or use an existing general purpose language is one of the toughest decisions that anyone facing the need for a new language must make.
Modern programs must handle Unicode – Python has excellent support for Unicode, and will keep getting better.
Mark Hammond is working in this area, with Windows Scripting Host. It is definitely an area where Python fits almost perfectly. That’s quite independent from Java, actually.
I have this hope that there is a better way. Higher-level tools that actually let you see the structure of the software more clearly will be of tremendous value.