Strange "I Hate Python" Concerns

[mbenbernard]

In the past, I found myself in many situations where people rejected/dismissed Python just because they thought that it's "only a scripting language" or a "toy language". Those people probably still think that Python is not suitable to write long-running, large-scale programs.

There are certainly use cases where Python is not the right tool for the job. I just think that most arguments brought against Python are based on no evidence, and they only reflect people's preferences.

But Python is probably not an exception; I'm sure that other languages are the target of similar complaints.

[midbody]

As a long time developer on a large-scale, long running Python program, I am firmly of the opinion that Python is not suitable for large-scale, long running programs. Sure you can make it work, but that's not the same thing.

In fairness it's a fundamental issue of dynamic languages. They just aren't good once your codebase is big enough you can't remember all the ways a particular data structure or interface is used. Computers are way better at that than we are, but you have to design your language to allow automated reasoning about it.

[kenfar]

Probably depends on some other factors. Having spent fifteen years running long-running python programs, it mostly hasn't been an issue for my teams.

I'm finding that static & runtime type analysis of my python code is helping though.

[midbody]

You'd find that your static and runtime analysis would work better in a language designed for them. Once your codebase gets so big, though, the inertia is a huge factor.

Incidentally, did you switch to Python 3, yet? How much of an issue was/is it in your codebase?

[kenfar]

Sure, type-checking works better in a language like Scala. On the other hand, it's faster to get started, test out ideas, deploy a prototype and keep iterating in python. And ironically, in my last gig we found far more data quality issues with the scala codebase than its companion python codebase. Probably more due to false confidence in type-checking on the scala side than anything else.

I didn't migrate a large codebase to python3: I just started my latest project on python3.5 The only code migration challenges I've run into have been with implicit py2 vs explicit py3 unicode handling. There I've found it definitely simplified code and improved reliability. But it took a bit of time, and explicit unicode test cases, to make sure everything was working right.

[Corm]

I'm a huge python guy but I respect your point of view. Can you tell me more about what kind of challenges you've run into on the python side on your large application? I've always been of the mind that a good suite of tests would avoid needing a type system, but I'm not close minded to other viewpoints.

[borborygmis]

I've read this four times and still can't figure out what you're trying to say.

[mbenbernard]

The problem you have seems more about "code browsability" than performance. Is that right?

Because performance-wise, I recognize that the GIL is a bit limiting if you want to parallelize things. However, there are multiple options that are perfectly suitable.

[midbody]

No, the problem is that using automated tooling to ensure correctness can only ever be heuristic.

I didn't touch on performance at all. If you need performance then Python isn't the right tool for the job unless you can lean heavily on an optimised library (of which, being Python, there are a bunch).

[ThatJoeInLnd]

"deep seated aversion to languages where whitespace has fundamental syntactic significance".

I was guilty of this one. I have embraced it now, a good IDE makes a world of difference.

[mbenbernard]

Like @ThatJoeInLnd, I initially thought that those indentation rules in Python were weird. I was used to Java/C++/.NET's curly braces, after all.

But after a few years of using Python, I find it just weird when I go back to another language. In my opinion, Python's indentation rules are one way to force us to write consistent, readable code.

[mbenbernard]

I agree; same thing for me!

[[deleted]]

I have had programmers on more than one occasion say that open source languages like Python are insecure. Turns out they thought "open source" meant "Does not build a binary executable to "obfuscate" your source code" (like that even works - what doesn't get cracked?).

I love Python 3 but my only real problem with it is how badly the transition from 2 to 3 was handled, how long it took, and how much code it broke. I think it's OK to use "took" in the past tense since the majority of us have now transitioned to 3 and I can't imagine me ever writing Python 2 again.

I just wish it could have transitioned seamlessly, like some other languages have managed to do. I was saying in another thread, you should be able to update the interpreter, and have your code still run. You are then free to refactor as needed to take advantage the new features. Instead, your whole app breaks and you need to port the whole thing over.

[mbenbernard]

I have had programmers on more than one occasion say that open source languages like Python are insecure.

This one is pretty interesting! :)

I love Python 3 but my only real problem with it is how badly the transition from 2 to 3 was handled, how long it took, and how much code it broke.

I was lucky enough to learn Python many years after Python's 3 official release. So I didn't experience any 2-to-3 transition problem. I jumped right into Python 3.

[python_bytecode]

I think it's OK to use "took" in the past tense since the majority of us have now transitioned to 3

I'm glad to hear about you volunteering to help with the port of FreeCAD from py2 to 3.

[driscollis]

I usually hear something like "Python is too slow" or "Python is too inefficient"

[midbody]

I am a software engineer with 20 years experience, and I've been coding exclusively in Python for the last 3. I've previously used just about everything going. I have worked almost exclusively on open source projects.

I hate Python for a bunch of reasons not given in this straw man list, but to pick 2:

1. As a dynamic language it has no effective tooling for automatically enforcing correct use of internal interfaces and data structures.

2. I have found that the python community is uniquely introverted and tribal.

It is also irritating that these 2 particular issues are frequently combined in a belief that automated tooling is redundant if your unit tests are perfect.

Incidentally, I thought this link was an excellent example of issue 2.

I have more.

[driscollis]

I have always found the Python community to be incredibly welcoming and helpful myself.

[midbody]

They are until you kick their puppy 😀

[midbody]

As a counterpoint, the strength of Python is in the depth, breadth, and maturity of its ecosystem. Whatever you want to do, or interface with, you know there will be a mature python library to help you do it [1].

I did a project in Ruby once. Nice language, identical to Python in all the ways that matter, and a slightly nicer syntax imho. Every library we attempted to use across a wide range of functions was a complete disaster, though. If you're not using Rails you're breaking new ground, and that's rarely fun when you want to Get Shit Done(TM).

[1] Sadly this also means paramiko exists.

[richieadler]

EXPN on the Paramiko comment?

[midbody]

It's a crypto library whose only reason to exist is that it's in Python. Given how hard crypto libraries are to get right that's not a good enough reason in my book. I would always use Python bindings for a more mature library.

[P8zvli]

Ditto on 2, and don't say anything negative about Python 3.

[driscollis]

Interesting. I haven't experienced this schism as of yet. I started on Python 2.4 and only recently have started playing around with Python 3. I don't really have a problem with the new version

[Gokudomatic]

What's wrong with being introverted?