6 ms·

How are people writing large programs in Python? Isn’t the lack of compiler type checking making it difficult? And what about lack of access modifiers? People a

How are people writing large programs in Python? Isn’t the lack of compiler type checking making it difficult? And what about lack of access modifiers? People aren’t bothered by this? 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.

jgibson 8y ago
Access modifiers are something that I only ever find to get in the way. I've recently moved to Java from Python for work. The underscore convention in python works fine for hiding stuff from the general public namespace, but its still there if you want to explore how some code or module works. Java really annoys me because I can't access implementation details when I'm trying something out in an interactive shell or debugger, even if I'd never access a private/protected variable in production code
- oddity 8y ago
  The point of access modifiers is to get in the way. They're ways of allowing developers of one part of the source to control what the path of least resistance is for the users of that code. 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.
  - cheez 8y ago
    `foo._a` accessible outside `Foo` but it makes code look gross and means you're doing something wrong. `foo.__a` accessible only inside `Foo` I think it works.
    - culturedsystems 8y ago
      > `foo.__a` accessible only inside `Foo` It's not all that inaccessible. Try: class C: def __init__(self): self.__private = 'Is it private?' c = C() c._C__private Double underscore names aren't so much about access control (because access control isn't strongly enforced) as about limiting name collisions (by including the class name in the underlying field name).
      - dragonwriter 8y ago
        Specifically, it's about avoiding collision of "private" names via inheritance.
  - bodas 8y ago
    If you are working with a large team, you need a statically typed language. Access modifiers are the least of your problems, the lack of refactoring support is a much bigger problem.
    - oddity 8y ago
      I agree, but I was focusing on a single aspect and explaining why its value might not be apparent to the parent commenter. Really, the same argument can be adapted to other contentious features of popular static languages.
  - Izkata 8y ago
    > 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 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.
- leshow 8y ago
  Personally, internal mutation is something you should avoid in general. Pretty hard to avoid in OO languages though.
oddity 8y ago
Easy. They write code. Code "works". Cool, ship it. Oh what's that? It has lots of bugs? How much money is it going to make us if we fix them? Eh, maybe we'll get to it. /s 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.
bnchrch 8y ago
I think programmers often misinterpret what’s hard about building large projects. 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.
- StavrosK 8y ago
  As a Python developer, I love type annotations on function signatures because they're great, up-to-date documentation. I don't care so much about them being checked, I care that they make the function much easier to read and reason about.
  - speedkills 8y ago
    If they weren’t checked, how would you know they are up to date?
    - StavrosK 8y ago
      I don't care how they're updated, I just care that they are. If that's by checking, it's fine by me.
- deleted 8y ago
  [deleted]
mistahchris 8y ago
Some of the biggest web services are written with Python. There are tradeoffs, just like everything else. I happen to work for a company with a gigantic python codebase. It would be a hell of a lot easier to refactor our systems if we were in a statically typed system, but we work around this by having shitloads of tests. Tradeoffs. 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.
kjeetgill 8y ago
Agreed. I love both (you can check my post history) but literally the most basic thing trips me up beyond a certain size/scope of programs: typos. Having a little structure that an IDE can leverage makes mountains of difference. 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.
ospider 8y ago
> Isn’t the lack of compiler type checking making it difficult? There is type hinting. > And what about lack of access modifiers? There is @property decorators
dragonwriter 8y ago
> How are people writing large programs in Python? Isn’t the lack of compiler type checking making it difficult? 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.
amai 8y ago
That is why we have python type hints: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html Not as good as a real static type system with compiler, but still helpful for documenting the code and tools for static code analysis.
PurpleRamen 8y ago
With unittests, proper planning and stern discipline. Access-control and typecheckers exist, but they are optional.

jgibson 8y ago

Access modifiers are something that I only ever find to get in the way. I've recently moved to Java from Python for work. The underscore convention in python works fine for hiding stuff from the general public namespace, but its still there if you want to explore how some code or module works. Java really annoys me because I can't access implementation details when I'm trying something out in an interactive shell or debugger, even if I'd never access a private/protected variable in production code

oddity 8y ago
The point of access modifiers is to get in the way. They're ways of allowing developers of one part of the source to control what the path of least resistance is for the users of that code. 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.
- cheez 8y ago
  `foo._a` accessible outside `Foo` but it makes code look gross and means you're doing something wrong. `foo.__a` accessible only inside `Foo` I think it works.
  - culturedsystems 8y ago
    > `foo.__a` accessible only inside `Foo` It's not all that inaccessible. Try: class C: def __init__(self): self.__private = 'Is it private?' c = C() c._C__private Double underscore names aren't so much about access control (because access control isn't strongly enforced) as about limiting name collisions (by including the class name in the underlying field name).
    - dragonwriter 8y ago
      Specifically, it's about avoiding collision of "private" names via inheritance.
- bodas 8y ago
  If you are working with a large team, you need a statically typed language. Access modifiers are the least of your problems, the lack of refactoring support is a much bigger problem.
  - oddity 8y ago
    I agree, but I was focusing on a single aspect and explaining why its value might not be apparent to the parent commenter. Really, the same argument can be adapted to other contentious features of popular static languages.
- Izkata 8y ago
  > 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 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.
leshow 8y ago
Personally, internal mutation is something you should avoid in general. Pretty hard to avoid in OO languages though.

oddity 8y ago

Easy. They write code. Code "works". Cool, ship it. Oh what's that? It has lots of bugs? How much money is it going to make us if we fix them? Eh, maybe we'll get to it. /s 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.

bnchrch 8y ago

I think programmers often misinterpret what’s hard about building large projects. 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.

StavrosK 8y ago
As a Python developer, I love type annotations on function signatures because they're great, up-to-date documentation. I don't care so much about them being checked, I care that they make the function much easier to read and reason about.
- speedkills 8y ago
  If they weren’t checked, how would you know they are up to date?
  - StavrosK 8y ago
    I don't care how they're updated, I just care that they are. If that's by checking, it's fine by me.
deleted 8y ago
[deleted]

mistahchris 8y ago

Some of the biggest web services are written with Python. There are tradeoffs, just like everything else. I happen to work for a company with a gigantic python codebase. It would be a hell of a lot easier to refactor our systems if we were in a statically typed system, but we work around this by having shitloads of tests. Tradeoffs. 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.

kjeetgill 8y ago

Agreed. I love both (you can check my post history) but literally the most basic thing trips me up beyond a certain size/scope of programs: typos. Having a little structure that an IDE can leverage makes mountains of difference. 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.

ospider 8y ago

> Isn’t the lack of compiler type checking making it difficult? There is type hinting. > And what about lack of access modifiers? There is @property decorators

dragonwriter 8y ago

> How are people writing large programs in Python? Isn’t the lack of compiler type checking making it difficult? 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.

amai 8y ago

That is why we have python type hints: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html Not as good as a real static type system with compiler, but still helpful for documenting the code and tools for static code analysis.

PurpleRamen 8y ago

With unittests, proper planning and stern discipline. Access-control and typecheckers exist, but they are optional.