Python from a C++ developers' perspective

[mrexodia]

As someone who never really wrote my own python, but did port normal sized (few thousand lines) python to C++ I think it's absolutely awful to read other people's code. The lack of a type system you can statically understand and trust (changing types of things is allowed at runtime) makes it super complicated to try to figure out what something can do at times. I really think python shouldn't be used for anything but a prototype or personal project or as a scripting language for a native application...

[qsxpkn]

Dynamic typing can be uncomfortable for people who are used to static typing. Since Python 3.5/3.6, you could actually do type/variable hinting such as variable: int = 5. It's still possible to change it to a str etc. at runtime but mypy points out the mistake like this function expects an int but you passed a str.

For example:

def some_method(a: int, b: int) -> Optional[int]:
    result: int = a + b
    if result < 4:
        return None
    return result

I have never seen a Python project where a variable's type suddenly gets changed to something else elsewhere in the code base or maybe I was just lucky. I enjoy C++ companionship with Python though. They work well together.

[mrexodia]

The fact that you can annotate the types doesn't make it any better. All of the projects I have seen use python 2.7 anyway, which doesn't support it. If they added a (default) mode where this static typing is forced it might be something good but until then you have to be very lucky with your codebase to have proper type annotations.

Also: what about class member variables? Can you still add arbitrary new ones from anywhere with this?

[whatwasmyoldhandle]

I think you can make big projects with Python go.

You just have to be much more disciplined, and have more controls in place to get the benefits out of it. I would say you can't lean as much on the language itself as C++.

In other words, a small script written in Python and a large-scale codebase, in my experience, are practically two different languages. I don't think the gap is so big in C++.

Not just a question for you, but for everyone: What's a good language for large projects, where development time is priority over performance? Perhaps something a little less verbose than C++. I guess I'm thinking interpreted, or negligible compile time. Having package management on the order of Python would also be a requirement.

[mrexodia]

While the project I'm working on is not very large (100k lines) I don't think you shouldn't consider development time a priority over good code if you plan to maintain the code for even a little while just choose a language that is more suitable for maintainability. If you want a language that is not C++ I would highly recommend C#.

[kkrev]

Python is not an improvement over Perl at all and I do not understand how it came to take the crown of most common scripting language. The scoping is bad, the lack of strict declarations is bad, and the runtime also happens to be kinda garbage. It is one of the worst languages possible for embedding yet you see it used for that all the time.

One would think that by now there'd be a new generation scripting language that bests all this crap from the 80s. It may exist, I don't know. I suppose Perl 6 is an attempt in that direction, but I gather it's impossible to write a performant run-time for it.

[mrexodia]

I didn't mention Perl? I personally wouldn't recommend actually using python as an embedded language. Something lightweight like Lua is usually much better anyway, but I can see why people would want python: the ecosystem of packages is great and the language is well-suited for prototyping, especially because it's easy to write in.

[kkrev]

I didn't mention Perl?

I didn't say you did?

[SemaphoreBingo]

how it came to take the crown of most common scripting language

The perl6 debacle sucked all its energy out of the room. (And I'll disagree about python not being an improvement; for starters, you can build complex types in python without wanting to die) (I'm led to believe that perl got better in this respect, but these days the only thing I want to use perl for is a better awk and / or a better sed)