4 ms·

As a person who has to maintain such systems, I really hate this aspect of Python.

by yen223 9y ago

Waterluvian 9y ago
I empathize. But I'm not convinced sloppy python is any worse than any other language used sloppily. Your beef is likely with the reality of doing business and shipping a real product.
- yen223 9y ago
  The effort required to unwind these technical debts is actively inhibiting our ability to deliver real value. That's the reality we've got. Sloppy Python is particularly bad, because Python gives you a massive footgun to play with. Like you could write functions that radically alter its behaviour depending on where it's getting called - that's similar to the hack that the parent post was talking about. It's easy to build systems that are coupled in really weird and unexpected ways, and that makes reasoning about code much harder than it needs to be.
  - ageofwant 9y ago
    The reality is that Python provided you with a paying job, because it carried you to where you are. The effort and sheer dumb luck involved in keeping a business alive to the point that some dev can complain about technical debt is a very underappreciated luxury. Not that you are wrong, just saying...
  - scaryclam 9y ago
    That's not really the languages fault though. I've seen some amazingly bad Java, Python, JavaScript, PHP and bash. Be cross that technical debt was introduced and not paid back rather than at the tools used to do it.
    - ghusbands 9y ago
      Most languages don't facilitate directly accessing the variables of other stack frames. Of the languages you listed, only Python does that (though bash has equivalent terrible bits), so that in particular _is_ Python's fault.
SerLava 9y ago
In other words, not everyone involved is consenting to the things they're doing at runtime.
- progval 9y ago
  it's also a pain for compilers
  - stochastic_monk 9y ago
    If Python is interpreted, what’s the pain? Do you mean static compilers like Cython/pybind11/Boost.Python, or JIT compilers?
  - gt_ 9y ago
    What does this mean?
    - progval 9y ago
      It's hard to make optimizations, because you cannot make a lot of assumptions ahead of time on how the code is going to run. For instance, one can override most of the builtin functions like len().
      - gt_ 9y ago
        I am curious how this effects the compiler in particular?Does the compiler measure this in some way and respond with different behavior? Or is it already designed less efficient to account for these types of operations? Or a mixture of both and/or more nuanced hurdles? Thanks for any info you can provide.
        progval 9y ago
        Python 3.6 added a version field to dictionnaries. As all variables are looked up in dictionnaries (aka namespaces), a compiler can replace a call to a builtin by a test of the version of the builtins dict (aka a guarde), which chooses between an optimized version and the "naive" code. Further reading: https://www.python.org/dev/peps/pep-0509/ https://www.python.org/dev/peps/pep-0509/

As a person who has to maintain such systems, I really hate this aspect of Python.

by yen223 9y ago

As a person who has to maintain such systems, I really hate this aspect of Python.

I empathize. But I'm not convinced sloppy python is any worse than any other language used sloppily. Your beef is likely with the reality of doing business and shipping a real product.

yen223 9y ago
The effort required to unwind these technical debts is actively inhibiting our ability to deliver real value. That's the reality we've got. Sloppy Python is particularly bad, because Python gives you a massive footgun to play with. Like you could write functions that radically alter its behaviour depending on where it's getting called - that's similar to the hack that the parent post was talking about. It's easy to build systems that are coupled in really weird and unexpected ways, and that makes reasoning about code much harder than it needs to be.
- ageofwant 9y ago
  The reality is that Python provided you with a paying job, because it carried you to where you are. The effort and sheer dumb luck involved in keeping a business alive to the point that some dev can complain about technical debt is a very underappreciated luxury. Not that you are wrong, just saying...
- scaryclam 9y ago
  That's not really the languages fault though. I've seen some amazingly bad Java, Python, JavaScript, PHP and bash. Be cross that technical debt was introduced and not paid back rather than at the tools used to do it.
  - ghusbands 9y ago
    Most languages don't facilitate directly accessing the variables of other stack frames. Of the languages you listed, only Python does that (though bash has equivalent terrible bits), so that in particular _is_ Python's fault.

SerLava 9y ago

In other words, not everyone involved is consenting to the things they're doing at runtime.

progval 9y ago
it's also a pain for compilers
- stochastic_monk 9y ago
  If Python is interpreted, what’s the pain? Do you mean static compilers like Cython/pybind11/Boost.Python, or JIT compilers?
- gt_ 9y ago
  What does this mean?
  - progval 9y ago
    It's hard to make optimizations, because you cannot make a lot of assumptions ahead of time on how the code is going to run. For instance, one can override most of the builtin functions like len().
    - gt_ 9y ago
      I am curious how this effects the compiler in particular?Does the compiler measure this in some way and respond with different behavior? Or is it already designed less efficient to account for these types of operations? Or a mixture of both and/or more nuanced hurdles? Thanks for any info you can provide.
      - progval 9y ago
        Python 3.6 added a version field to dictionnaries. As all variables are looked up in dictionnaries (aka namespaces), a compiler can replace a call to a builtin by a test of the version of the builtins dict (aka a guarde), which chooses between an optimized version and the "naive" code. Further reading: https://www.python.org/dev/peps/pep-0509/ https://www.python.org/dev/peps/pep-0509/