On Thu, 2023-01-19 at 09:47 +1300, dn via Python-list wrote: > The longer an identifier, the more it 'pushes' code over to the right > or > to expand over multiple screen-lines. Some thoughts on this are > behind > PEP-008 philosophies, eg line-limit.
I sympathize with this issue. I've pushed the line limit to 96, which in my case removed this pain point. My argument—though subjective—is that we have wide screens now, and it's quite unlikely production code will be accessed through a vintage VT-100 terminal or printed on a 80- column dot-matrix printer. That said, even if you stick to PEP-8 proper, `black` does most of the formatting work, and it seems to do a reasonable job despite longer module identifiers. > In the body of the code, if every time an external identifier is used > it > must be prefixed by a full 'path', the cognitive "burden" shifts from > the aspect highlighted (above), to a reading-burden. Thus, (in > extreme > cases) moving towards a 'wall of text' problem. I tend to agree this can be a problem in some cases, but I think those can be made manageable. For brevity's sake, I import often-used data types directly into the module's name space. It's far more rare that I try to abbreviate a module name; common ones like importing pandas as pd is a good counterexample. > In using TDD, code is constructed module-by-module (not necessarily > a > Python Module). So, when it comes time to call > avMedia.fetch_the_file() > [sic] there is little thinking about the "avMedia" bit. The emphasis > is > on the function-name, and it's parameters. 'I need that file so that > I > can ...'. I'm not entirely sure what you mean by not a Python module. Even in test modules, I would only import what's required. If it turns out `fetch_the_file` is called dozens of times or more, I would have no qualm about importing it directly into the test module's namespace so that it doesn't need to be prefixed at all. -- https://mail.python.org/mailman/listinfo/python-list
