For programs less than 500 lines, I have no issues with Python, but it feels to me like Python just isn’t suited for large-scale programming in the way C#, Java, Go, or Rust are.
It’s not correctness it’s communication. A type checker will save you from small errors but well written and easily understandable code will save you from a lot more.
Not saying readability is harder in c# java go or rust just that the type system doesn’t help with it that much.
I'm sure a more competent typist wouldn't have these issues but it trips me up constantly just in dev. Tests protect this from hitting prod.
The extra refactor support just isn't there compared to java.
I don't think python is good for large systems, but for companies, it's hard to get to that point without something that you can prototype quickly with.
The real productivity win here is that you can hire a bunch of junior engineers out of university for "cheap" that "know" python. After all, why would you train a new hire in a different language for a few weeks or months when that would take a huge amount of time in startup-verse? /s?
It's important to note that the largest push for things like type checking and access control in dynamically-typed, shared-mutable-everything languages are coming from the companies that built themselves quickly on these languages and now need to deal with scaling.
If you expose everything, someone will write code that depends against it and make it harder for you to improve or change it in the future. Tossing in roadblocks helps guide users to the better long-term path.
It doesn't really matter for small teams, but it's essential for large ones without aggressive (and difficult) enforcement of contract between team members.
`foo.__a` accessible only inside `Foo`
I think it works.
It's not all that inaccessible. Try:
class C:
def __init__(self):
self.__private = 'Is it private?'
c = C()
c._C__private
> It doesn't really matter for small teams
Doesn't even have to be your team. We encountered this by way of a major library, celery.
I forget all the details, but celery was importing something else (name started with a "k", I think), and that was importing an underscore-prefixed function from uuid. Somewhere between python versions 2.7.8 and 2.7.13, the implementation of uuid changed and that import failed.
Python 2 and 3 both have AOT static type checkers available (this is essentially “pre-compile-time”). Presumably those for whom not having this would be a problem use it.
> And what about lack of access modifiers?
It's an issue, but use of the conventional underscore prefix makes mitigation via code review fairly simple.
Not as good as a real static type system with compiler, but still helpful for documenting the code and tools for static code analysis.
There is type hinting.
> And what about lack of access modifiers?
There is @property decorators