5 ms·

Why is Python So Aggravating? That's a question that bugs me. I can't believe the level of obviousness of the things that are wrong. That is because we write c

Why is Python So Aggravating? That's a question that bugs me. I can't believe the level of obviousness of the things that are wrong. That is because we write complex code. Things like direct access to data members (which is 'pythonic'!) are cruel blows to software productivity for complex code. Ugh, Ugh, let me count the ways: No compiler to check the code. The other day I dumped 800 extra lines into a file as a typo. Many, many duplicate functions. Of our whole test suite, how many tests failed? One!!! Ugh. This is not even to mention the topics of Black.Holes.In.Your.Code because you can't tell what types the functions receive. I really think python is driven by non-programmers who consume rather than produce complex code and the teachers who teach these people. I believe the problems will increase over time. Does anyone know the story of Hack at Facebook? I heard the lead developer give a talk once. Be afraid.

flavio81 9y ago
> This is not even to mention the topics of Black.Holes.In.Your.Code because you can't tell what types the functions receive. Use aptly named parameters, always, add assert() statements for type checking whenever you feel mistakes could happen. I can bet, based on my experience, that it's much "safer" (less error-prone) to use a language that allows calling functions with named parameters (where the order of parameters doesn't matter and you know exactly which parameter are you sending a value into), than a language like C++ or Java which has a static typing system but has no named parameteres, plus depends on argument order to call a function. You should try using Python in this way.
- cleandreams 9y ago
  We do that. Try developing a complex code base with a medium sized team. It becomes very hard to make changes!!! You just need compiler support, IMHO. Python offers ease and fun, and that has led to an explosion of functionality. But there is a tradeoff. And at some point we will hit that wall, as an industry.
  - mahyarm 9y ago
    Just use kotlin or golang. You get a modern language and you get types. And you still have java libraries with kotlin. I totally understand the lack of typing & static compilation making things painful once you reach a scale where you can't put the codebase in your head. Asserts, unit tests and variable names are poor substitutes. As an interm solution have you tried converting your internal python code to be fully typed with 'optional types'?
    - flavio81 9y ago
      >golang. You get a modern language Go is far from a modern language, being more like a mutant, crippled subset of Algol-68, which, as the name says, dates from 1968...
wyldfire 9y ago
Keep in mind that there's python development practices which might be adequate to solve your problems. > Things like direct access to data members I think you're complaining about (lack-of-) encapsulation. Between methods, functions, and properties, there's ample opportunity for encapsulation. The convention is for internal-use-only members to be prefixed with an underscore. > No compiler to check the code. In fact there are many static checkers. pylint, pyflakes, etc. > This is not even to mention the topics of Black.Holes.In.Your.Code because you can't tell what types the functions receive. In fact, you can use type hints [1] to do this. > The other day I dumped 800 extra lines into a file as a typo. Many, many duplicate functions. Of our whole test suite, how many tests failed? One!!! Ugh. This isn't quite explicit enough for me to understand. You unintentionally redefined a function multiple times in the same file, and your test suite caught the error. You think that instead Python should've refused to execute/import this module w/redefined functions? Hmm, I suppose it's a very uncommon need to redefine functions but it's not uncommon to assign a function to a file-scope name. Also keep in mind that both pylint and pyflakes detect this mistake. [1] https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html
- dom0 9y ago
  > I'm not sure that you've taken the time to understand python development practices. I think this tone is misplaced here.
  - wyldfire 9y ago
    I think you are inferring more tone than was intended but I will edit it because it could be considered rude.

flavio81 9y ago

> This is not even to mention the topics of Black.Holes.In.Your.Code because you can't tell what types the functions receive. Use aptly named parameters, always, add assert() statements for type checking whenever you feel mistakes could happen. I can bet, based on my experience, that it's much "safer" (less error-prone) to use a language that allows calling functions with named parameters (where the order of parameters doesn't matter and you know exactly which parameter are you sending a value into), than a language like C++ or Java which has a static typing system but has no named parameteres, plus depends on argument order to call a function. You should try using Python in this way.

cleandreams 9y ago
We do that. Try developing a complex code base with a medium sized team. It becomes very hard to make changes!!! You just need compiler support, IMHO. Python offers ease and fun, and that has led to an explosion of functionality. But there is a tradeoff. And at some point we will hit that wall, as an industry.
- mahyarm 9y ago
  Just use kotlin or golang. You get a modern language and you get types. And you still have java libraries with kotlin. I totally understand the lack of typing & static compilation making things painful once you reach a scale where you can't put the codebase in your head. Asserts, unit tests and variable names are poor substitutes. As an interm solution have you tried converting your internal python code to be fully typed with 'optional types'?
  - flavio81 9y ago
    >golang. You get a modern language Go is far from a modern language, being more like a mutant, crippled subset of Algol-68, which, as the name says, dates from 1968...

wyldfire 9y ago

Keep in mind that there's python development practices which might be adequate to solve your problems. > Things like direct access to data members I think you're complaining about (lack-of-) encapsulation. Between methods, functions, and properties, there's ample opportunity for encapsulation. The convention is for internal-use-only members to be prefixed with an underscore. > No compiler to check the code. In fact there are many static checkers. pylint, pyflakes, etc. > This is not even to mention the topics of Black.Holes.In.Your.Code because you can't tell what types the functions receive. In fact, you can use type hints [1] to do this. > The other day I dumped 800 extra lines into a file as a typo. Many, many duplicate functions. Of our whole test suite, how many tests failed? One!!! Ugh. This isn't quite explicit enough for me to understand. You unintentionally redefined a function multiple times in the same file, and your test suite caught the error. You think that instead Python should've refused to execute/import this module w/redefined functions? Hmm, I suppose it's a very uncommon need to redefine functions but it's not uncommon to assign a function to a file-scope name. Also keep in mind that both pylint and pyflakes detect this mistake. [1] https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html

dom0 9y ago
> I'm not sure that you've taken the time to understand python development practices. I think this tone is misplaced here.
- wyldfire 9y ago
  I think you are inferring more tone than was intended but I will edit it because it could be considered rude.