9 ms·

Python programming is drowning in red tape

182 points by _630w 6y ago

nerdbaggy 6y ago
Line length is such a hard problem to solve. I wish there was a way to be like don’t allow more than 95% percent of my lines to be longer than X. I run into this in Django a lot with my chained ORM queries. The usually tend to be like 10-15 chars to long. And in this case you have to line break on the parameters or on a ‘.’ which is ugly as well. While not related to Python, I feel like whenever I write JS code, especially Vue I have a terrible time with line length.
- mandaputtra 6y ago
  Agree, I use Vue, Angular and yeah ~ line length pretty much big with formatter,
- runawaybottle 6y ago
  It’s an almost impossible problem to solve in JS because breaking up html templates becomes even harder to read.
- raverbashing 6y ago
  Yes My personal preference regarding line lengths: 80 chars are not enough. And even pep8 says that "foolish consistency is the hobgoblin of little minds" So try being under 80 chars but sometimes you can't. Also don't break a line that's like 85 chars if it will just make it more ugly I'm glad Prospector by default doesn't enforce "the cult of 80 chars" dogma
  - rbanffy 6y ago
    God made the VT52 with 80 columns for a reason. ;-) Now, seriously, that's a matter of taste. I like 80 because it allows me to have two files open side by side on my laptop with a readable font size. As we grow older, what's "readable" changes.
    - raverbashing 6y ago
      I keep hearing these arguments but to me they sound like a romantic attachment to the past. There's no intrinsic quality in using 80 columns besides historical legacy. But hey we can also keep using the size of body parts as measurement units as well, or we can evolve. :) The 2 column use case is useful, but to be honest, rare. I just tested it here and I still need a big monitor and a "medium" font size for 2x80 to work (not too bad on the vision side, but not too great neither). But it is easy for that point to become moot ;)
      - boomlinde 6y ago
        > I keep hearing these arguments but to me they sound like a romantic attachment to the past. If you think that "I like 80 because it allows me to have two files open side by side on my laptop with a readable font size." sounds like a romantic attachment to the past you should probably just read it over and over again until it doesn't.
        raverbashing 6y ago
        Did you read the 2nd paragraph? Just to be sure, I just tested on my notebook screen (13"): 2x80 doesn't fit with a comfortable font size for me, so maybe we should start using 70 chars?
        boomlinde 6y ago
        I did read the second paragraph, which makes the first paragraph all the more confusing. First you utterly dismiss the argument on an unreasonable basis, and then in the second paragraph you acknowledge that it's useful to be able to do that. > Just to be sure, I just tested on my notebook screen (13"): 2x80 doesn't fit with a comfortable font size for me, so maybe we should start using 70 chars? Sure, YMMV. Even when that turns out to be too small for you, less text per line in the editor leaves more horizontal space for something else, for example a file browser sidebar or a terminal. I've done 2x80 on netbooks for what its worth, but the font size that required probably wouldn't be comfortable to me today.
  - ccmcarey 6y ago
    The quote is from Emerson
  - kd5bjo 6y ago
    My aim these days is usually around 70 chars, plus whatever the block indentation is. That way, I can always move the editor viewport to the right to keep the local region on the screen.
- NegativeLatency 6y ago
  If you put some parens around the query you can get a nicer and still pep8 compliant formatting https://stackoverflow.com/a/11920726 https://stackoverflow.com/a/11920726
- dplgk 6y ago
  How about line wrapping in the text editor?
AlexandrB 6y ago
As a long time Python fan, I find the current state of the language frustrating. Tools like black and poetry are nice, but are not part of the standard library. Yet they seem to be required by every popular project out there. (Also, black’s formatting is quite ugly, as noted in this blog post) Meanwhile, the language itself is increasingly baroque and complicated. Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006. Perhaps this is just an “old man yells at cloud” moment...
- pdonis 6y ago
  > Tools like black and poetry are nice, but are not part of the standard library. If black does non-PEP 8 formatting, as the article says, then I would not expect it to be in the standard library, since PEP 8 formatting is the Python standard. > the language itself is increasingly baroque and complicated I don't find current Python 3 any more baroque or complicated than Python 2.7. In fact I have plenty of Python code that runs just fine, unmodified, under both interpreters. And I have plenty of other Python code that only needs from __future__ import print_function to run unmodified under both interpreters. That's not to say I think there are no issues with current Python 3; just that I wouldn't describe those issues as "the language is increasingly baroque and complicated". See further comments below. > Type-annotated, asyncio-enabled Python hardly resembles the language I fell in love with back in 2006. You don't have to use these features if you don't want or need them. Nobody uses 100% of any language's features, and the subset that is used can be very different from person to person. I don't see that as a problem. I did see the way the Python 3 transition was handled as a big problem, but that's water under the bridge now and the issues that gave many people headaches during the transition were pretty much resolved by Python 3.3. The two big problems I see with current Python 3 are memory usage and the GIL. Python 3 objects take more memory than Python 2 objects did; for programs that create a lot of objects that can be an issue. (To be fair, many such programs are numerical simulations that can take advantage of the many optimizations in the NumPy and SciPy libraries.) There seems to be work in progress on supporting multiple interpreters running in the same Python process, which would fix the GIL issue, but it's too soon to see if that will really address the issues surrounding the GIL.
tartoran 6y ago
Piles and piles of red tape specific to python, but the same theme seems to manifest itself in other mainstream programming ecosystems: .net and java, node and so on. This unfriendly affliction isn't tied to a specific programming language, any programming language could be abused in different ways and the same goes with the ecosystem. I think young ecosystems tend to be attractive just because there isn't too much noise. It's just like starting on a new project versus joining one, unless the existing project is very well organized and maintained and properly tradeoff balanced. This is an art too.
- deleted 6y ago
  [deleted]
etaioinshrdlu 6y ago
> As I adventured in this petty task, it’s worth nothing the amount of red tape required to setup a python project today. You need: I have never used most of those tools and I've been knee deep in Python for ~4 years. Go look at some of your favorite pypi libraries, chances are they are using a small fraction of those tools as well. The author is making things overly complicated, but it's all self-inflicted. Just code and be happy.
- pdonis 6y ago
  > The author is making things overly complicated, but it's all self-inflicted. My reaction exactly.
- nerdbaggy 6y ago
  The PEP8 style guide even says don’t use it if “When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP.” https://www.python.org/dev/peps/pep-0008/ https://www.python.org/dev/peps/pep-0008/
- firefwing24 6y ago
  Author didn't even take the time to look at what pre-commit does.
  - underyx 6y ago
    And acts as if their project won't work unless they add a code of conduct?
dsign 6y ago
I always wonder where are all these spoiled kids who have no deadlines and bike-shed ad-infinitum about the spaces around every single token live :-(
streblo 6y ago
> It was bikeshedding at its worst It's ironic that discussions about formatting are taking up so much mindshare in the python community. For years all you'd hear was that whitespace significance was a sign of the lowliness of python. Meanwhile, tons of people were ignoring the bikeshedding and getting things done. Now it's one of the most widely used languages in existence. The kinds of people that are focused on issues like formatting never seem to be focused on the things that actually matter - being productive and being able to get things done. That's what has always mattered about python, and what has always made it excellent.
- DeepYogurt 6y ago
  I completely agree. Who cares if black is ugly? It's a standard which is easy to automate. Want a better standard? Make it. Until then black works.
  - swinglock 6y ago
    > Beautiful is better than ugly.
    - Drakar1903 6y ago
      Things in this industry are divided into those that get complained about and those that get forgotten.
  - afiori 6y ago
    > Want a better standard? Make it. That is what this post is advocating for, his own fork of black.
    - fastball 6y ago
      Yes, but in this case it was all bark with no bite. The author has made 0 commits to his fork since forking (in Feb).
      - 6y ago
halfdan 6y ago
The author starts by criticising a bike-shedding mentality and then goes on to make bike-shedding arguments. They complain about the non-pep8 compliance, show what pep8 would look like and then argue that there's a better way.. As another commenter pointed out: This is all self-inflicted. Personally, I don't care how things are formatted, I just want it to be consistent.
- segfaultbuserr 6y ago
  > They complain about the non-pep8 compliance, show what pep8 would look like and then argue that there's a better way.. It did not suggest a "better" way, just the PEP-8 way. It first complains about the non-PEP-8-compliance formatting, then shows a simpler PEP-8 example, and finally shows what will the initial code look like according to PEP-8.
cakeofzerg 6y ago
I freelance in both python and C#, python used to get the job done in 200 lines vs C# at 500, now its 300|300 and the C# is easier to read
- mehrdadn 6y ago
  Line count can be a misleading way to measure C# length given there are so many braces on their own lines. But also, the thing is, if you're coding in like Visual Studio, you often don't even type so many of the characters -- the IDE does it for you. So I guess the question I would instead ask is: which one did you feel more productive in? (Including everything from IDE startup time to debugging.)
  - cakeofzerg 6y ago
    Yeah nothing beats Visual Studio. More productive in C# for most things, but cant beat python for data science/ML.
geofft 6y ago
Honestly, this is one of the things I really appreciate about the development workflow at $dayjob. Our Python build process is fairly custom for what amounts to historical reasons, but when you create a new Python project, you get automated builds and tests on all the OSes you care about (through our central build and test farm), a way of declaring dependencies (that has nothing to do with pipenv/poetry/etc., but whatever), flake8 enabled by default easy toggles for mypy and black if you want them, a standard way of doing code reviews, a standard way of doing releases, etc. - simply because it's possible to assume shared infrastructure and shared defaults. When you're writing open-source code, you don't have any shared infrastructure or defaults to assume, so you have to find some infrastructure (e.g. GitHub + Travis) and you have to basically include all the infrastructure configuration in your project, possibly through adding a bunch of dev-dependencies that set things up the way you want. It'd be interesting to think about how to abstract this further so you don't have to think about that many things. Some possible inspirations: - https://travis.debian.net/ https://travis.debian.net/ - if you have a Debian package on GitHub, and you want automated tests, you just grab the .travis.yml file from here and a script written by someone else will set up builds and tests in Docker containers. It does rely on Debian having a standardized way of specifying build rules, dependencies, and tests and a standardized layout of packages, though. But most Python packages have a pretty standard layout, too, and you can imagine having things like isort/flake8/nose/etc. be installed only in CI and not explicitly listed in your code. - Rust, I think, makes this a little easier because there's a high-quality packaging system, test runner, formatter, and doc generator all in the standard Rust tools. While Rust-the-language has a standard library that's much emptier than, say, Python's, rustc comes with way more developer tools than Python does. That means that you don't need to install custom tools to handle most of this because it's assumed that people are using the standard ones. (This does, of course, rely on the tools actually being high-quality, and as a young language, Rust has an unfair advantage in watching Python and so many other languages try to figure out what works well and what doesn't. You'd have an easier time in Python if you stuck to distutils and easy_install, but on the other hand, you'd have to use distutils and easy_install.)
minimaxir 6y ago
It’s a shame that no one measures productivity by LOC anymore, otherwise with black I would be the most productive engineer ever. :)
j88439h84 6y ago
All the "wait no" alternative tool suggestions are silly. There's a best tool. For packaging a Python project, that tool is Poetry. Pipenv, virtualenv, setup.py, venv, setup.cfg, are all outmoded.
- Humphrey 6y ago
  Yes, Poetry is best-in-class package manager. I liked the idea of Pipenv, but in practice it just didn't work well. FYI, Poetry is just a fancy tool for managing your virtualenvs
- lmm 6y ago
  Every two years I've looked at Python again and been told that the horrible mess I saw last time is obsolete, there's a good tool now that fixes all the problems. Every time it's just been an even bigger mess with one more tool on top.
  - meowface 6y ago
    Pretty much, but Poetry is slowly emerging as the winner, I think. There is no good solution, but if you're starting a new project, Poetry is probably your best bet.
    - deleted 6y ago
      [deleted]
  - j88439h84 6y ago
    Well, look again. Poetry is a good tool.
  - trymas 6y ago
    https://xkcd.com/927/ https://xkcd.com/927/ A bit to the topic - what's wrong with good old: python -m venv env env/bin/pip install <whatever> ?
    - lmm 6y ago
shmolyneaux 6y ago
Python runs the gamut. You can make small scripts that automate simple tasks and you can make huge websites that service millions of people a day. As projects get bigger, they can adopt tools to help them manage the complexity of the project. These tools make complex projects simpler without complicating simple things. Personally, I wouldn't want to use Python on a large project without these tools.
oefrha 6y ago
I don’t love black’s formatting, but this article is just wrong. 1. Black’s formatting of function arguments does not break PEP8, because the closing parenthesis is one level of indentation back, breaking the continuation. (I don’t even need to check linked threads. Dude is wrong and must have been told so. He doesn’t want to listen, fine. Fork as he wishes, but it’s not like I’m gonna use his fork over Łukasz Langa’s just because he’s tired arguing.) 2. “Piles and piles of red tape”: half are generic project or generic GitHub project stuff, optional of course (oh and black is there so that you don’t need editorconfig). The Python specific stuff? - mypy? If you drank the koolaid and now dogmatically type check all your code whether warranted or not. Me? Still enjoying dynamic typing. (Don’t get me wrong, I use mypy judiciously.) - nose, pytest, unittest, etc.? Sorry you have a choice! - Finally, I haven’t even heard of bumpversion and setuptools_scm and I’ve been scraping by pushing out releases after releases. I guess you’ll always find a way to pile on the red tapes if you’re enamored with stupid tooling to begin with. 3. Don’t see any “My experience with forking black”, only saw a few talking points, including useless ones like “Remove the ‘for humans’ garbage”. Guess it’s not written yet. Btw, if a “massive” 3000 line module (lol) chokes up your editor, maybe it’s time to get a better one.
- jordic 6y ago
  100% agree with you. So happy with black and pytest. - The formatting he is proposing for multiple args on a function with double tabs it's wired... O_O - Same argument on mypy, if I want to type all variables, I perhaps will be happy doing it in go or rust.. python is dynamic :) - pytest - balck works so fine with vscode (pycharm will work if he disables linting code on every keystroke... )haha
  - anyfoo 6y ago
    mypy kept python viable for me. I was working on a pretty complicated hw interface, which also used a lot of async/await. Even without what was basically my own coroutine implementation, there were just complicated (but not unusually so!) types in general. You know, just dicts of tuples of lists of tuples and the like. At what felt like the 1000th runtime problem because of some type confusion somewhere (or just forgetting "await", which is essentially a no-op, since you got a promise that you threw away), and a lot of these problems happening much later than where the actual bug in the code was, I was ready to throw in the towel and bid python--and all other dynamic languages--good bye. So I decided to try out mypy as some kind of last hurrah, and it paid out immediately. Adding the types went pretty quickly, and after that numerous problems were caught by the type checker, instead of manifesting as some obscure runtime problem down the way.
liquidify 6y ago
I have felt like it is way to complicated to do certain things in python... primarily relating to building and packaging large scale code. But, for what I use it for (mostly scripting) it is wonderful. I use it locally, right from the IDE mostly. I almost never call things I make with it from the command line because they are usually single use or low use scripts. Things that I like enough to build into more usually get re-written in c++.
ebg13 6y ago
OP behaves like a giant tool and a baby both in this blog post and more importantly in the Github issue report ( https://github.com/psf/black/issues/1178 https://github.com/psf/black/issues/1178 ). Therefore... > My problem with the above formatting is that the list of arguments and the body of the function are now at the same indentation level. OP weirdly complains here that equal scopes shouldn't be equally indented, and, let's be clear, declared function arguments are the same scope as the function body. > My point is that the proper way to indent the above code is... OP is dumb and wrong and should feel bad for missing the first section of PEP8 right after the introduction. It's titled "A Foolish Consistency is the Hobgoblin of Little Minds". OP's proposed "correct" way is to arbitrarily leapfrog an indentation level and then backtrack. Personally I think that makes OP a bad person. As an adherent of The One True Brace Style (K&R), I find OP's proposal to be super ugly and much harder to read than Black's style. > PEP8 recommends PEP8 can recommend anything it wants. That particular recommendation is bad and not based on anything other than Guido's personal preference. It's fine for Guido to have preferences, but OP should feel bad for _demanding_ it. > I decided to do the unthinkable: fork it It's open source software on github. Forkability is literally the point. > *I don’t know if you ever saw the code of black. It..." ...gets the job done well and is therefore extremely popular? Yes.
- searchableguy 6y ago
  I wouldn't necessarily say if something is popular, it is also good. Notable examples include mini packages from npm, lint and styling configs for eslint and prettier. Some of those[0] enforce no semicolon rule which can introduce edge cases and errors because [1]js parser will automatically insert semicolons. 0] https://standardjs.com/ https://standardjs.com/ 1] http://www.bradoncode.com/blog/2015/08/26/javascript-semi-colon-insertion/ http://www.bradoncode.com/blog/2015/08/26/javascript-semi-co...
  - ebg13 6y ago
    > I wouldn't necessarily say if something is popular, it is also good. Black is popular because it is good.
arvinsim 6y ago
I would appreciate it very much if Python would have a standard language formatter ala `go fmt` to end the bikeshedding. I personally use black but I wouldn't mind other standards as long as I don't have to pick and choose anymore.
- drewm1980 6y ago
  Do you want black to be the standard? If you share your code with others, that's how you're currently voting!
micimize 6y ago
Hard forking a project to make use of the hard work the maintainers put in to it, then writing a post doing nothing but insulting those maintainer's decisions / preferences, is not a good look. Neither is throwing temper tantrums in issue threads: https://github.com/psf/black/issues/1178#issuecomment-565383116 https://github.com/psf/black/issues/1178#issuecomment-565383... Also if this developer wasn't so obsessed with bikeshedding, they could just edit the one bit of formatting code and republish. That way they could even rebase off of upstream if they wanted. Personally, I much prefer black's indentation scheme. I also like spending as little time as possible agonizing over minutia like this.
- oefrha 6y ago
  > Reopen the issue right now or I am forking. This is comic gold.
  - deleted 6y ago
    [deleted]
  - ashtonkem 6y ago
    The Black maintainers have the patience of the saints; I would’ve just responded with a curt “ok, good” and locked the discussion at that point.
- beshrkayali 6y ago
  The dude writes "Black violates pep8 recommendation" in his title (notice recommendation), yet, feels strong enough to say "This is a bug. Period." after threatening with a fork (lol?). Not to bring back that whole maintainer vs contributors discussion, but this is a solid example of entitlement some contributes feel.
  - ashtonkem 6y ago
    It’s also an example of disastrous negotiation. You can’t threaten to do something that doesn’t negatively effect people; they won’t care.
- 6y ago
mesaframe 6y ago
I remember using PyCharm and I believe it had a better formatter. On the other hand, I don't really like black. But, as the article said it's recommended by the Python guys.
echelon 6y ago
> a CODE_OF_CONDUCT, because we assume preemptively that you are a racist homophobic asshole, and we have to cover our bases. This one is a new personal pet peeve. I'm not a racist homophobe--I'm a good person. And though it doesn't give me any authority to speak on the matter, I'm bi and I've dated all sorts of people. I don't like to be presumed to be an asshole (or presume that others may be), and I'm offended that we have to treat adults like this as part of a new social contract. Can't we just be good to one another? And when there are assholes, can't we handle everything on a case-by-case basis, as it arises? By putting this into every single project, it feels like we're building an ivory tower that ignores the social progress we've made in the last century. It's disrespectful and patronizing to mature adults to presume how they might behave. I don't like to think of people as great ape descendants, but this kind of thing reminds me we're just animals, fighting and name calling. I don't like that. I don't like how it makes me feel. Software is an achievement of human intellect, and I don't like to be reminded of our flaws. Not in the root of every software project I want to grok or contribute to. I'm not so close-minded to rule out changing my mind on this matter, but I'm perplexed and, as I admitted before, slightly annoyed. I really want to hear others' opinions on this. I'm not trying to trivialize anyone's experiences. I missed whatever original conversations there were on this matter and I want to express both how I feel and that I want to know more. edit: I'm going to be downvoted for even admitting this? That's why I debated even posting. I don't like operating like this.
- draw_down 6y ago
  Ah jeez, have we really not beaten this topic to death already? Cmon
- oefrha 6y ago
  Come on, I hate this as much as you do, but we don’t need yet another flamewar over this with canned responses.
  - echelon 6y ago
    > Come on, I hate this as much as you do, but we don’t need yet another flamewar over this with canned responses. I must live under a bush.
pelasaco 6y ago
I'm still using autopep8 and I'm fine with that.. why such a drama?
benatkin 6y ago
"black can kick and scream and its proponent can say that the frowny face is all they need but they are wrong. They are wrong visually, and they are wrong according to pep8. End of story." The "frowny face" is ): which in Python is all over the place, but hopefully you don't notice it, and if you do, you don't care. I find it to be sufficient separation between the arguments and the code. It's too bad the author doesn't, but that doesn't change it for me or other devs that are comfortable with it. This: def very_important_function( template: str, *variables, file: os.PathLike, engine: str, header: bool = True, debug: bool = False, ): """Applies `variables` to the `template` and writes to `file`.""" with open(file, "w") as f: is similar to this, which has caught on in React with Prettier: <select value={fruit} onChange={({target: {value}}) => setFruit(value)} > <option value="apple">Apple</option> <option value="orange">Orange</option> <option value="banana">Banana</option> </select> The fact that people like it in multiple languages means it's definitely an uphill battle to go back to indenting it further.
- fastball 6y ago
  The current project I'm working on is Python+Black for backend and React+Prettier for frontend and I've really enjoyed the consistency / not worrying about formatting.
winddude 6y ago
Yea except spaces suck for indentation. Tabs 100% for the win. Suck it.
ganafagol 6y ago
"So after arguing about this topic on the black issue reporting, seeing that people kept not reading what was the core of the issue" ...and shortly after ... "It hurts my eyes to see it. They might have a justification but I don’t care. " That's where I stopped reading.
gardenrewind 6y ago
Long-time python programmer: we could do a better job with bootstrapping projects. `create-react-app` and `create-probot-app` set up complete projects for ya. How great would it be to have a project skeleton with black + poetry + mypy with everything hooked together?
- shimst3r 6y ago
  Do you know cookie cutter? https://cookiecutter.readthedocs.io/en/1.7.0/ https://cookiecutter.readthedocs.io/en/1.7.0/ There are a lot of task specific templates that can be adjusted and open sourced if needed.
laingc 6y ago
At the risk of flinging ad hominems, reading his history with the maintainers of black he comes across as quite demented. Even if he were right - which I don’t think he is - I wouldn’t use software maintained by someone that unstable.
Qantourisc 6y ago
You know what I lack most in this entire discussion and github conversation/bug ? Basic boundaries. If someone says "no thank you". You can maybe try to ask if there is any wiggle room, or good will possible. But if there isn't, then that's the end of it. Leave the other person in peace. If you don't like it, then fork it (if allowed). Or get your needs met another way. But trying to enforce them on someone else is not very respectable. And if someone continues to try and bother you into doing what you want. You say no one last time, and stop communicating.
cachestash 6y ago
Seriously, some people get annoyed over the most trivial of matters. Write your code, make sure it works well and then go outside for a bicycle ride.
therealmojado 6y ago
> a CODE_OF_CONDUCT, because we assume preemptively that you are a racist homophobic asshole, and we have to cover our bases. Really? What about laws? Do you think they exist because it is assumed that everybody is a rapist and a burglar?
- mjburgess 6y ago
  Laws are enforced and mostly provide an institutional system to deal with redress (for victims) and safety (for society). ie., the judiciary, legislature and police force are the mechanism of the law and why it exists. It's not an activity in parliaments declaring their moral beliefs. "Codes of Conduct" in this vein are just virtue signalling. They appease the martyr-type looking to publicly shame a community for fringe members. Publicly stating your morality, I'd say, is a pretty good guide to identifying hypocrites who value praise for seeming moral above being moral. This is evident to most people and to most people in history (see, eg., jesus about people praying in the street). Often being one of the first lessons in psychology taught to children. The problem for social media is that the vast majority of people who realise this do not like/comment/subscribe. So you end up with toxic echo chambers of praise-seekers, while everyone else rolls their eyes.
  - therealmojado 6y ago
    What are you smoking? Codes of conduct are enforced too. You can get kicked out of a conference or community if you don't stick to the rules. There may be some martyr-type people, but there are as well people with real experiences with harassment or discrimination.
beshrkayali 6y ago
This is actually useful, it's a detailed point-by-point example of how not to complain about (or suggest a contribution to) something (open-source or not).
kingrolo 6y ago
I use black by default across all our projects now and I'm all for it, but it does seem kind of ironic that whilst the main selling point of black is to take away these kind of code style discussions there seem to have been way more of them since black came to popularity :) I do expect it'll just be fine once everyone's got used to it. Maybe its a consequence of a tool like this coming into existence on a language with such a long history already.
- silveraxe93 6y ago
  I don't think it increased the amount of discussions, just centralised it. Before it would happen between developers in the same repo, now it's all in the same place. I think that a good thing. Formatting discussions are important (arguably), but it should be decoupled from a specific project.
z3t4 6y ago
Instead of re-formatting your code, have the editor automatically reformat visually for those that want such and such formatting. Kinda like editors that handle word wrap, they word wrap the lines without inserting new-lines in the source.
tree3 6y ago
When I saw "red tape" and "PEP 8", I thought this article was going in a different direction... But nope, the writer is instead vehemently defending PEP 8, which is a arbitrary standard that no one is required to follow. Who cares if <insert formatter> does <insert thing>, PEP 8 isn't the word of God.
INTPenis 6y ago
I like the 80 character width limit and I like having structure. I tend to measure my resolution by how many python files I can open next to each other in vim. But when methods take a lot of arguments I just use key word arguments. I know this is bad because it's less visible but as long as you document all the arguments I don't see the issue. It looks good, it fits the code style which eases readability. It's pythonic.
danpalmer 6y ago
There's a flip side to this: all of these tools are strictly optional to execute Python code. This means that I can write a one off script to achieve a thing once and the overhead is tiny compared to many languages. I can do it in almost any editor, likely with no toolchain setup at all. Now, do I want that to be easier to edit in a large team? I'll introduce a formatter/linter. Do I want to publish it on PyPI? Then I'll introduce packaging tools. Do I want to test it? Then I'll introduce a testing tool. Do I want to test multiple language versions? Then a build matrix tool... Yes, to set up a perfect, gold-plated, fully automated, open-source Python package takes a fair bit of effort, but you don't need it on day one. There are many open-source contributors who will happily propose introducing these things and add them for you!
CrLf 6y ago
I'm a firm believer that good code should be consistent in its style, but that consistency should not prevent the programmer from communicating intent via subjective style choices. I'm OK with following someone else's (be it an individual code owner or a team's) style rules even when I strongly disagree with them (my personal style opinions have even changed on occasion because of this). I find code linting really useful (and even critical) to make the above two statements work well in practice. Having said this, "black" makes me not care about the code I write. It makes me feel like I'm serving under a robotic dictator whose sole purpose is purging any trace of subjective readability in the name of consistency. This makes my code worse in ways well beyond style issues. It makes me want to abandon professional programming in python altogether. Just to make it absolutely clear: I'm not talking about it's style choices, just how inflexible and inhuman it is. It's style choices would be another discussion. And no, littering code with comments preventing it from reformatting specific sections of code isn't the solution.
- fastball 6y ago
  I have had the opposite experience. Black has been liberating for me, in that I can just worry about writing the code / worrying about the actual business logic, and Black handles all the formatting for me. I used to worry far too much about whether this style was more readable than that style, which in the end is less important than almost everything else, as long as one of them is actually readable. Now I am free. No automatic system is going to be perfect. Black might have edge-cases where a different style would be more readable, but that is true for any formatter. Using an opinionated (non-configurable) one means that I spend 0 time on config (not a useful way to spend time imo) and that my code will be consistent with the code of many others.
deleted 6y ago
[deleted]
tcbasche 6y ago
Someone needs to chill. I've been working with Python projects for nearly 5 years and you only ever use a subset of the tools. And let's face it, for the most part Python has needed some sort of formality in the project setup, as it's a free-for-all for how you can set up a project. The other point is - the need section for a project? Just seems unnecessarily snarky. Case in point: > bumpversion, because I am too lazy to put a single file with a version number, and sphinx is too hard to setup to fetch this version number. Maybe the team kept forgetting to bump the version number and this removed some mental overhead? No-one is stopping you getting out there and just coding. There's always an ecosystem surrounding a language, maybe just embrace just how huge and ubiquitous using Python has become, and get out there and write some code.
l0b0 6y ago
15 years ago I might've agreed with this. The current project I'm working on checks many of OP's boxes: Black, isort, flake8, mypy (although even with a strict configuration we've not had to use generic types yet), pre-commit linting hook, CI, Poetry (because Pipenv was too painful and screw pip's hatred for checksums) and pytest. And by the sound of it, OP would be more than happy to get rid of mandatory code reviews and near-100% code coverage. But the devs are happy, more importantly the client is really happy, and after two years we're still moving fast, merging several features most days with minimal regressions. Screw the old way. It sucked.
salex89 6y ago
In my experience, anything longer than 1500 lines chokes PyCharm. And I can't blame it, it's still the best Python editor. Everything else feels like writing in Notepad. It's the only tool that can actually helps you navigate/organise/autocomplate/whatever in large Python project, which is a must for this goddamn language.
natch 6y ago
The gall of using full justify to complain about a formatting issue... big facepalm.
WhyNotHugo 6y ago
This guys starts criticizing the standard four-space handing-bracket indentation used in python, since he seems to prefer using 8-spaces in some cases so that his IDE can auto-fold code (even though it's more human-readable) I'm sure for every language, some IDE has issues with the most popular code formatting style. Fix the IDE, not the language. Sounds like an very opinionated rant, rather than anything objective/technical.
wisemanwillhear 6y ago
> setuptools_scm, because our versions must change at every new commit. I don't get many of these points. For example, at the company I'm about to leave, we worked just fine both manually versioning as well as using tools like versioneer/setuptools_scm. We made it easy to fire up new projects using a dual template/boilerplate repo strategy. Infrastructure like this is in a boilerplate repo and almost entirely setup for new projects from the start. New projects fork a template project and do a small number of basic steps (like naming the project, etc.). Both the template and project repos are update from the boilerplate Git repo as we make updates to the infrastructure--a simple Git remote setup.

182 points by _630w 6y ago

Line length is such a hard problem to solve. I wish there was a way to be like don’t allow more than 95% percent of my lines to be longer than X. I run into this in Django a lot with my chained ORM queries. The usually tend to be like 10-15 chars to long. And in this case you have to line break on the parameters or on a ‘.’ which is ugly as well. While not related to Python, I feel like whenever I write JS code, especially Vue I have a terrible time with line length.

mandaputtra 6y ago
Agree, I use Vue, Angular and yeah ~ line length pretty much big with formatter,
runawaybottle 6y ago
It’s an almost impossible problem to solve in JS because breaking up html templates becomes even harder to read.
raverbashing 6y ago
Yes My personal preference regarding line lengths: 80 chars are not enough. And even pep8 says that "foolish consistency is the hobgoblin of little minds" So try being under 80 chars but sometimes you can't. Also don't break a line that's like 85 chars if it will just make it more ugly I'm glad Prospector by default doesn't enforce "the cult of 80 chars" dogma
- rbanffy 6y ago
  God made the VT52 with 80 columns for a reason. ;-) Now, seriously, that's a matter of taste. I like 80 because it allows me to have two files open side by side on my laptop with a readable font size. As we grow older, what's "readable" changes.
  - raverbashing 6y ago
    I keep hearing these arguments but to me they sound like a romantic attachment to the past. There's no intrinsic quality in using 80 columns besides historical legacy. But hey we can also keep using the size of body parts as measurement units as well, or we can evolve. :) The 2 column use case is useful, but to be honest, rare. I just tested it here and I still need a big monitor and a "medium" font size for 2x80 to work (not too bad on the vision side, but not too great neither). But it is easy for that point to become moot ;)
    - boomlinde 6y ago
      > I keep hearing these arguments but to me they sound like a romantic attachment to the past. If you think that "I like 80 because it allows me to have two files open side by side on my laptop with a readable font size." sounds like a romantic attachment to the past you should probably just read it over and over again until it doesn't.
      - raverbashing 6y ago
        Did you read the 2nd paragraph? Just to be sure, I just tested on my notebook screen (13"): 2x80 doesn't fit with a comfortable font size for me, so maybe we should start using 70 chars?
        boomlinde 6y ago
        I did read the second paragraph, which makes the first paragraph all the more confusing. First you utterly dismiss the argument on an unreasonable basis, and then in the second paragraph you acknowledge that it's useful to be able to do that. > Just to be sure, I just tested on my notebook screen (13"): 2x80 doesn't fit with a comfortable font size for me, so maybe we should start using 70 chars? Sure, YMMV. Even when that turns out to be too small for you, less text per line in the editor leaves more horizontal space for something else, for example a file browser sidebar or a terminal. I've done 2x80 on netbooks for what its worth, but the font size that required probably wouldn't be comfortable to me today.
- ccmcarey 6y ago
  The quote is from Emerson
- kd5bjo 6y ago
  My aim these days is usually around 70 chars, plus whatever the block indentation is. That way, I can always move the editor viewport to the right to keep the local region on the screen.
NegativeLatency 6y ago
If you put some parens around the query you can get a nicer and still pep8 compliant formatting https://stackoverflow.com/a/11920726 https://stackoverflow.com/a/11920726
dplgk 6y ago
How about line wrapping in the text editor?

AlexandrB 6y ago

As a long time Python fan, I find the current state of the language frustrating. Tools like black and poetry are nice, but are not part of the standard library. Yet they seem to be required by every popular project out there. (Also, black’s formatting is quite ugly, as noted in this blog post) Meanwhile, the language itself is increasingly baroque and complicated. Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006. Perhaps this is just an “old man yells at cloud” moment...

pdonis 6y ago
> Tools like black and poetry are nice, but are not part of the standard library. If black does non-PEP 8 formatting, as the article says, then I would not expect it to be in the standard library, since PEP 8 formatting is the Python standard. > the language itself is increasingly baroque and complicated I don't find current Python 3 any more baroque or complicated than Python 2.7. In fact I have plenty of Python code that runs just fine, unmodified, under both interpreters. And I have plenty of other Python code that only needs from __future__ import print_function to run unmodified under both interpreters. That's not to say I think there are no issues with current Python 3; just that I wouldn't describe those issues as "the language is increasingly baroque and complicated". See further comments below. > Type-annotated, asyncio-enabled Python hardly resembles the language I fell in love with back in 2006. You don't have to use these features if you don't want or need them. Nobody uses 100% of any language's features, and the subset that is used can be very different from person to person. I don't see that as a problem. I did see the way the Python 3 transition was handled as a big problem, but that's water under the bridge now and the issues that gave many people headaches during the transition were pretty much resolved by Python 3.3. The two big problems I see with current Python 3 are memory usage and the GIL. Python 3 objects take more memory than Python 2 objects did; for programs that create a lot of objects that can be an issue. (To be fair, many such programs are numerical simulations that can take advantage of the many optimizations in the NumPy and SciPy libraries.) There seems to be work in progress on supporting multiple interpreters running in the same Python process, which would fix the GIL issue, but it's too soon to see if that will really address the issues surrounding the GIL.

tartoran 6y ago

Piles and piles of red tape specific to python, but the same theme seems to manifest itself in other mainstream programming ecosystems: .net and java, node and so on. This unfriendly affliction isn't tied to a specific programming language, any programming language could be abused in different ways and the same goes with the ecosystem. I think young ecosystems tend to be attractive just because there isn't too much noise. It's just like starting on a new project versus joining one, unless the existing project is very well organized and maintained and properly tradeoff balanced. This is an art too.

deleted 6y ago
[deleted]

etaioinshrdlu 6y ago

> As I adventured in this petty task, it’s worth nothing the amount of red tape required to setup a python project today. You need: I have never used most of those tools and I've been knee deep in Python for ~4 years. Go look at some of your favorite pypi libraries, chances are they are using a small fraction of those tools as well. The author is making things overly complicated, but it's all self-inflicted. Just code and be happy.

pdonis 6y ago
> The author is making things overly complicated, but it's all self-inflicted. My reaction exactly.
nerdbaggy 6y ago
The PEP8 style guide even says don’t use it if “When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP.” https://www.python.org/dev/peps/pep-0008/ https://www.python.org/dev/peps/pep-0008/
firefwing24 6y ago
Author didn't even take the time to look at what pre-commit does.
- underyx 6y ago
  And acts as if their project won't work unless they add a code of conduct?

dsign 6y ago

I always wonder where are all these spoiled kids who have no deadlines and bike-shed ad-infinitum about the spaces around every single token live :-(

streblo 6y ago

> It was bikeshedding at its worst It's ironic that discussions about formatting are taking up so much mindshare in the python community. For years all you'd hear was that whitespace significance was a sign of the lowliness of python. Meanwhile, tons of people were ignoring the bikeshedding and getting things done. Now it's one of the most widely used languages in existence. The kinds of people that are focused on issues like formatting never seem to be focused on the things that actually matter - being productive and being able to get things done. That's what has always mattered about python, and what has always made it excellent.

DeepYogurt 6y ago
I completely agree. Who cares if black is ugly? It's a standard which is easy to automate. Want a better standard? Make it. Until then black works.
- swinglock 6y ago
  > Beautiful is better than ugly.
  - Drakar1903 6y ago
    Things in this industry are divided into those that get complained about and those that get forgotten.
- afiori 6y ago
  > Want a better standard? Make it. That is what this post is advocating for, his own fork of black.
  - fastball 6y ago
    Yes, but in this case it was all bark with no bite. The author has made 0 commits to his fork since forking (in Feb).
    - 6y ago

halfdan 6y ago

The author starts by criticising a bike-shedding mentality and then goes on to make bike-shedding arguments. They complain about the non-pep8 compliance, show what pep8 would look like and then argue that there's a better way.. As another commenter pointed out: This is all self-inflicted. Personally, I don't care how things are formatted, I just want it to be consistent.

segfaultbuserr 6y ago
> They complain about the non-pep8 compliance, show what pep8 would look like and then argue that there's a better way.. It did not suggest a "better" way, just the PEP-8 way. It first complains about the non-PEP-8-compliance formatting, then shows a simpler PEP-8 example, and finally shows what will the initial code look like according to PEP-8.

cakeofzerg 6y ago

I freelance in both python and C#, python used to get the job done in 200 lines vs C# at 500, now its 300|300 and the C# is easier to read

mehrdadn 6y ago
Line count can be a misleading way to measure C# length given there are so many braces on their own lines. But also, the thing is, if you're coding in like Visual Studio, you often don't even type so many of the characters -- the IDE does it for you. So I guess the question I would instead ask is: which one did you feel more productive in? (Including everything from IDE startup time to debugging.)
- cakeofzerg 6y ago
  Yeah nothing beats Visual Studio. More productive in C# for most things, but cant beat python for data science/ML.

geofft 6y ago

Honestly, this is one of the things I really appreciate about the development workflow at $dayjob. Our Python build process is fairly custom for what amounts to historical reasons, but when you create a new Python project, you get automated builds and tests on all the OSes you care about (through our central build and test farm), a way of declaring dependencies (that has nothing to do with pipenv/poetry/etc., but whatever), flake8 enabled by default easy toggles for mypy and black if you want them, a standard way of doing code reviews, a standard way of doing releases, etc. - simply because it's possible to assume shared infrastructure and shared defaults. When you're writing open-source code, you don't have any shared infrastructure or defaults to assume, so you have to find some infrastructure (e.g. GitHub + Travis) and you have to basically include all the infrastructure configuration in your project, possibly through adding a bunch of dev-dependencies that set things up the way you want. It'd be interesting to think about how to abstract this further so you don't have to think about that many things. Some possible inspirations: - https://travis.debian.net/ https://travis.debian.net/ - if you have a Debian package on GitHub, and you want automated tests, you just grab the .travis.yml file from here and a script written by someone else will set up builds and tests in Docker containers. It does rely on Debian having a standardized way of specifying build rules, dependencies, and tests and a standardized layout of packages, though. But most Python packages have a pretty standard layout, too, and you can imagine having things like isort/flake8/nose/etc. be installed only in CI and not explicitly listed in your code. - Rust, I think, makes this a little easier because there's a high-quality packaging system, test runner, formatter, and doc generator all in the standard Rust tools. While Rust-the-language has a standard library that's much emptier than, say, Python's, rustc comes with way more developer tools than Python does. That means that you don't need to install custom tools to handle most of this because it's assumed that people are using the standard ones. (This does, of course, rely on the tools actually being high-quality, and as a young language, Rust has an unfair advantage in watching Python and so many other languages try to figure out what works well and what doesn't. You'd have an easier time in Python if you stuck to distutils and easy_install, but on the other hand, you'd have to use distutils and easy_install.)

minimaxir 6y ago

It’s a shame that no one measures productivity by LOC anymore, otherwise with black I would be the most productive engineer ever. :)

j88439h84 6y ago

All the "wait no" alternative tool suggestions are silly. There's a best tool. For packaging a Python project, that tool is Poetry. Pipenv, virtualenv, setup.py, venv, setup.cfg, are all outmoded.

Humphrey 6y ago
Yes, Poetry is best-in-class package manager. I liked the idea of Pipenv, but in practice it just didn't work well. FYI, Poetry is just a fancy tool for managing your virtualenvs
lmm 6y ago
Every two years I've looked at Python again and been told that the horrible mess I saw last time is obsolete, there's a good tool now that fixes all the problems. Every time it's just been an even bigger mess with one more tool on top.
- meowface 6y ago
  Pretty much, but Poetry is slowly emerging as the winner, I think. There is no good solution, but if you're starting a new project, Poetry is probably your best bet.
  - deleted 6y ago
    [deleted]
- j88439h84 6y ago
  Well, look again. Poetry is a good tool.
- trymas 6y ago
  https://xkcd.com/927/ https://xkcd.com/927/ A bit to the topic - what's wrong with good old: python -m venv env env/bin/pip install <whatever> ?
  - lmm 6y ago

shmolyneaux 6y ago

Python runs the gamut. You can make small scripts that automate simple tasks and you can make huge websites that service millions of people a day. As projects get bigger, they can adopt tools to help them manage the complexity of the project. These tools make complex projects simpler without complicating simple things. Personally, I wouldn't want to use Python on a large project without these tools.

oefrha 6y ago

I don’t love black’s formatting, but this article is just wrong. 1. Black’s formatting of function arguments does not break PEP8, because the closing parenthesis is one level of indentation back, breaking the continuation. (I don’t even need to check linked threads. Dude is wrong and must have been told so. He doesn’t want to listen, fine. Fork as he wishes, but it’s not like I’m gonna use his fork over Łukasz Langa’s just because he’s tired arguing.) 2. “Piles and piles of red tape”: half are generic project or generic GitHub project stuff, optional of course (oh and black is there so that you don’t need editorconfig). The Python specific stuff? - mypy? If you drank the koolaid and now dogmatically type check all your code whether warranted or not. Me? Still enjoying dynamic typing. (Don’t get me wrong, I use mypy judiciously.) - nose, pytest, unittest, etc.? Sorry you have a choice! - Finally, I haven’t even heard of bumpversion and setuptools_scm and I’ve been scraping by pushing out releases after releases. I guess you’ll always find a way to pile on the red tapes if you’re enamored with stupid tooling to begin with. 3. Don’t see any “My experience with forking black”, only saw a few talking points, including useless ones like “Remove the ‘for humans’ garbage”. Guess it’s not written yet. Btw, if a “massive” 3000 line module (lol) chokes up your editor, maybe it’s time to get a better one.

jordic 6y ago
100% agree with you. So happy with black and pytest. - The formatting he is proposing for multiple args on a function with double tabs it's wired... O_O - Same argument on mypy, if I want to type all variables, I perhaps will be happy doing it in go or rust.. python is dynamic :) - pytest - balck works so fine with vscode (pycharm will work if he disables linting code on every keystroke... )haha
- anyfoo 6y ago
  mypy kept python viable for me. I was working on a pretty complicated hw interface, which also used a lot of async/await. Even without what was basically my own coroutine implementation, there were just complicated (but not unusually so!) types in general. You know, just dicts of tuples of lists of tuples and the like. At what felt like the 1000th runtime problem because of some type confusion somewhere (or just forgetting "await", which is essentially a no-op, since you got a promise that you threw away), and a lot of these problems happening much later than where the actual bug in the code was, I was ready to throw in the towel and bid python--and all other dynamic languages--good bye. So I decided to try out mypy as some kind of last hurrah, and it paid out immediately. Adding the types went pretty quickly, and after that numerous problems were caught by the type checker, instead of manifesting as some obscure runtime problem down the way.

liquidify 6y ago

I have felt like it is way to complicated to do certain things in python... primarily relating to building and packaging large scale code. But, for what I use it for (mostly scripting) it is wonderful. I use it locally, right from the IDE mostly. I almost never call things I make with it from the command line because they are usually single use or low use scripts. Things that I like enough to build into more usually get re-written in c++.

ebg13 6y ago

OP behaves like a giant tool and a baby both in this blog post and more importantly in the Github issue report ( https://github.com/psf/black/issues/1178 https://github.com/psf/black/issues/1178 ). Therefore... > My problem with the above formatting is that the list of arguments and the body of the function are now at the same indentation level. OP weirdly complains here that equal scopes shouldn't be equally indented, and, let's be clear, declared function arguments are the same scope as the function body. > My point is that the proper way to indent the above code is... OP is dumb and wrong and should feel bad for missing the first section of PEP8 right after the introduction. It's titled "A Foolish Consistency is the Hobgoblin of Little Minds". OP's proposed "correct" way is to arbitrarily leapfrog an indentation level and then backtrack. Personally I think that makes OP a bad person. As an adherent of The One True Brace Style (K&R), I find OP's proposal to be super ugly and much harder to read than Black's style. > PEP8 recommends PEP8 can recommend anything it wants. That particular recommendation is bad and not based on anything other than Guido's personal preference. It's fine for Guido to have preferences, but OP should feel bad for _demanding_ it. > I decided to do the unthinkable: fork it It's open source software on github. Forkability is literally the point. > *I don’t know if you ever saw the code of black. It..." ...gets the job done well and is therefore extremely popular? Yes.

searchableguy 6y ago
I wouldn't necessarily say if something is popular, it is also good. Notable examples include mini packages from npm, lint and styling configs for eslint and prettier. Some of those[0] enforce no semicolon rule which can introduce edge cases and errors because [1]js parser will automatically insert semicolons. 0] https://standardjs.com/ https://standardjs.com/ 1] http://www.bradoncode.com/blog/2015/08/26/javascript-semi-colon-insertion/ http://www.bradoncode.com/blog/2015/08/26/javascript-semi-co...
- ebg13 6y ago
  > I wouldn't necessarily say if something is popular, it is also good. Black is popular because it is good.

arvinsim 6y ago

I would appreciate it very much if Python would have a standard language formatter ala `go fmt` to end the bikeshedding. I personally use black but I wouldn't mind other standards as long as I don't have to pick and choose anymore.

drewm1980 6y ago
Do you want black to be the standard? If you share your code with others, that's how you're currently voting!

micimize 6y ago

Hard forking a project to make use of the hard work the maintainers put in to it, then writing a post doing nothing but insulting those maintainer's decisions / preferences, is not a good look. Neither is throwing temper tantrums in issue threads: https://github.com/psf/black/issues/1178#issuecomment-565383116 https://github.com/psf/black/issues/1178#issuecomment-565383... Also if this developer wasn't so obsessed with bikeshedding, they could just edit the one bit of formatting code and republish. That way they could even rebase off of upstream if they wanted. Personally, I much prefer black's indentation scheme. I also like spending as little time as possible agonizing over minutia like this.

oefrha 6y ago
> Reopen the issue right now or I am forking. This is comic gold.
- deleted 6y ago
  [deleted]
- ashtonkem 6y ago
  The Black maintainers have the patience of the saints; I would’ve just responded with a curt “ok, good” and locked the discussion at that point.
beshrkayali 6y ago
The dude writes "Black violates pep8 recommendation" in his title (notice recommendation), yet, feels strong enough to say "This is a bug. Period." after threatening with a fork (lol?). Not to bring back that whole maintainer vs contributors discussion, but this is a solid example of entitlement some contributes feel.
- ashtonkem 6y ago
  It’s also an example of disastrous negotiation. You can’t threaten to do something that doesn’t negatively effect people; they won’t care.
6y ago

mesaframe 6y ago

I remember using PyCharm and I believe it had a better formatter. On the other hand, I don't really like black. But, as the article said it's recommended by the Python guys.

echelon 6y ago

> a CODE_OF_CONDUCT, because we assume preemptively that you are a racist homophobic asshole, and we have to cover our bases. This one is a new personal pet peeve. I'm not a racist homophobe--I'm a good person. And though it doesn't give me any authority to speak on the matter, I'm bi and I've dated all sorts of people. I don't like to be presumed to be an asshole (or presume that others may be), and I'm offended that we have to treat adults like this as part of a new social contract. Can't we just be good to one another? And when there are assholes, can't we handle everything on a case-by-case basis, as it arises? By putting this into every single project, it feels like we're building an ivory tower that ignores the social progress we've made in the last century. It's disrespectful and patronizing to mature adults to presume how they might behave. I don't like to think of people as great ape descendants, but this kind of thing reminds me we're just animals, fighting and name calling. I don't like that. I don't like how it makes me feel. Software is an achievement of human intellect, and I don't like to be reminded of our flaws. Not in the root of every software project I want to grok or contribute to. I'm not so close-minded to rule out changing my mind on this matter, but I'm perplexed and, as I admitted before, slightly annoyed. I really want to hear others' opinions on this. I'm not trying to trivialize anyone's experiences. I missed whatever original conversations there were on this matter and I want to express both how I feel and that I want to know more. edit: I'm going to be downvoted for even admitting this? That's why I debated even posting. I don't like operating like this.

draw_down 6y ago
Ah jeez, have we really not beaten this topic to death already? Cmon
oefrha 6y ago
Come on, I hate this as much as you do, but we don’t need yet another flamewar over this with canned responses.
- echelon 6y ago
  > Come on, I hate this as much as you do, but we don’t need yet another flamewar over this with canned responses. I must live under a bush.

pelasaco 6y ago

I'm still using autopep8 and I'm fine with that.. why such a drama?

benatkin 6y ago

"black can kick and scream and its proponent can say that the frowny face is all they need but they are wrong. They are wrong visually, and they are wrong according to pep8. End of story." The "frowny face" is ): which in Python is all over the place, but hopefully you don't notice it, and if you do, you don't care. I find it to be sufficient separation between the arguments and the code. It's too bad the author doesn't, but that doesn't change it for me or other devs that are comfortable with it. This: def very_important_function( template: str, *variables, file: os.PathLike, engine: str, header: bool = True, debug: bool = False, ): """Applies `variables` to the `template` and writes to `file`.""" with open(file, "w") as f: is similar to this, which has caught on in React with Prettier: <select value={fruit} onChange={({target: {value}}) => setFruit(value)} > <option value="apple">Apple</option> <option value="orange">Orange</option> <option value="banana">Banana</option> </select> The fact that people like it in multiple languages means it's definitely an uphill battle to go back to indenting it further.

fastball 6y ago
The current project I'm working on is Python+Black for backend and React+Prettier for frontend and I've really enjoyed the consistency / not worrying about formatting.

winddude 6y ago

Yea except spaces suck for indentation. Tabs 100% for the win. Suck it.

ganafagol 6y ago

"So after arguing about this topic on the black issue reporting, seeing that people kept not reading what was the core of the issue" ...and shortly after ... "It hurts my eyes to see it. They might have a justification but I don’t care. " That's where I stopped reading.

gardenrewind 6y ago

Long-time python programmer: we could do a better job with bootstrapping projects. `create-react-app` and `create-probot-app` set up complete projects for ya. How great would it be to have a project skeleton with black + poetry + mypy with everything hooked together?

shimst3r 6y ago
Do you know cookie cutter? https://cookiecutter.readthedocs.io/en/1.7.0/ https://cookiecutter.readthedocs.io/en/1.7.0/ There are a lot of task specific templates that can be adjusted and open sourced if needed.

laingc 6y ago

At the risk of flinging ad hominems, reading his history with the maintainers of black he comes across as quite demented. Even if he were right - which I don’t think he is - I wouldn’t use software maintained by someone that unstable.

Qantourisc 6y ago

You know what I lack most in this entire discussion and github conversation/bug ? Basic boundaries. If someone says "no thank you". You can maybe try to ask if there is any wiggle room, or good will possible. But if there isn't, then that's the end of it. Leave the other person in peace. If you don't like it, then fork it (if allowed). Or get your needs met another way. But trying to enforce them on someone else is not very respectable. And if someone continues to try and bother you into doing what you want. You say no one last time, and stop communicating.

cachestash 6y ago

Seriously, some people get annoyed over the most trivial of matters. Write your code, make sure it works well and then go outside for a bicycle ride.

therealmojado 6y ago

> a CODE_OF_CONDUCT, because we assume preemptively that you are a racist homophobic asshole, and we have to cover our bases. Really? What about laws? Do you think they exist because it is assumed that everybody is a rapist and a burglar?

mjburgess 6y ago
Laws are enforced and mostly provide an institutional system to deal with redress (for victims) and safety (for society). ie., the judiciary, legislature and police force are the mechanism of the law and why it exists. It's not an activity in parliaments declaring their moral beliefs. "Codes of Conduct" in this vein are just virtue signalling. They appease the martyr-type looking to publicly shame a community for fringe members. Publicly stating your morality, I'd say, is a pretty good guide to identifying hypocrites who value praise for seeming moral above being moral. This is evident to most people and to most people in history (see, eg., jesus about people praying in the street). Often being one of the first lessons in psychology taught to children. The problem for social media is that the vast majority of people who realise this do not like/comment/subscribe. So you end up with toxic echo chambers of praise-seekers, while everyone else rolls their eyes.
- therealmojado 6y ago
  What are you smoking? Codes of conduct are enforced too. You can get kicked out of a conference or community if you don't stick to the rules. There may be some martyr-type people, but there are as well people with real experiences with harassment or discrimination.

beshrkayali 6y ago

This is actually useful, it's a detailed point-by-point example of how not to complain about (or suggest a contribution to) something (open-source or not).

kingrolo 6y ago

I use black by default across all our projects now and I'm all for it, but it does seem kind of ironic that whilst the main selling point of black is to take away these kind of code style discussions there seem to have been way more of them since black came to popularity :) I do expect it'll just be fine once everyone's got used to it. Maybe its a consequence of a tool like this coming into existence on a language with such a long history already.

silveraxe93 6y ago
I don't think it increased the amount of discussions, just centralised it. Before it would happen between developers in the same repo, now it's all in the same place. I think that a good thing. Formatting discussions are important (arguably), but it should be decoupled from a specific project.

z3t4 6y ago

Instead of re-formatting your code, have the editor automatically reformat visually for those that want such and such formatting. Kinda like editors that handle word wrap, they word wrap the lines without inserting new-lines in the source.

tree3 6y ago

When I saw "red tape" and "PEP 8", I thought this article was going in a different direction... But nope, the writer is instead vehemently defending PEP 8, which is a arbitrary standard that no one is required to follow. Who cares if <insert formatter> does <insert thing>, PEP 8 isn't the word of God.

INTPenis 6y ago

I like the 80 character width limit and I like having structure. I tend to measure my resolution by how many python files I can open next to each other in vim. But when methods take a lot of arguments I just use key word arguments. I know this is bad because it's less visible but as long as you document all the arguments I don't see the issue. It looks good, it fits the code style which eases readability. It's pythonic.

danpalmer 6y ago

There's a flip side to this: all of these tools are strictly optional to execute Python code. This means that I can write a one off script to achieve a thing once and the overhead is tiny compared to many languages. I can do it in almost any editor, likely with no toolchain setup at all. Now, do I want that to be easier to edit in a large team? I'll introduce a formatter/linter. Do I want to publish it on PyPI? Then I'll introduce packaging tools. Do I want to test it? Then I'll introduce a testing tool. Do I want to test multiple language versions? Then a build matrix tool... Yes, to set up a perfect, gold-plated, fully automated, open-source Python package takes a fair bit of effort, but you don't need it on day one. There are many open-source contributors who will happily propose introducing these things and add them for you!

CrLf 6y ago

I'm a firm believer that good code should be consistent in its style, but that consistency should not prevent the programmer from communicating intent via subjective style choices. I'm OK with following someone else's (be it an individual code owner or a team's) style rules even when I strongly disagree with them (my personal style opinions have even changed on occasion because of this). I find code linting really useful (and even critical) to make the above two statements work well in practice. Having said this, "black" makes me not care about the code I write. It makes me feel like I'm serving under a robotic dictator whose sole purpose is purging any trace of subjective readability in the name of consistency. This makes my code worse in ways well beyond style issues. It makes me want to abandon professional programming in python altogether. Just to make it absolutely clear: I'm not talking about it's style choices, just how inflexible and inhuman it is. It's style choices would be another discussion. And no, littering code with comments preventing it from reformatting specific sections of code isn't the solution.

fastball 6y ago
I have had the opposite experience. Black has been liberating for me, in that I can just worry about writing the code / worrying about the actual business logic, and Black handles all the formatting for me. I used to worry far too much about whether this style was more readable than that style, which in the end is less important than almost everything else, as long as one of them is actually readable. Now I am free. No automatic system is going to be perfect. Black might have edge-cases where a different style would be more readable, but that is true for any formatter. Using an opinionated (non-configurable) one means that I spend 0 time on config (not a useful way to spend time imo) and that my code will be consistent with the code of many others.

deleted 6y ago

[deleted]

tcbasche 6y ago

Someone needs to chill. I've been working with Python projects for nearly 5 years and you only ever use a subset of the tools. And let's face it, for the most part Python has needed some sort of formality in the project setup, as it's a free-for-all for how you can set up a project. The other point is - the need section for a project? Just seems unnecessarily snarky. Case in point: > bumpversion, because I am too lazy to put a single file with a version number, and sphinx is too hard to setup to fetch this version number. Maybe the team kept forgetting to bump the version number and this removed some mental overhead? No-one is stopping you getting out there and just coding. There's always an ecosystem surrounding a language, maybe just embrace just how huge and ubiquitous using Python has become, and get out there and write some code.

l0b0 6y ago

15 years ago I might've agreed with this. The current project I'm working on checks many of OP's boxes: Black, isort, flake8, mypy (although even with a strict configuration we've not had to use generic types yet), pre-commit linting hook, CI, Poetry (because Pipenv was too painful and screw pip's hatred for checksums) and pytest. And by the sound of it, OP would be more than happy to get rid of mandatory code reviews and near-100% code coverage. But the devs are happy, more importantly the client is really happy, and after two years we're still moving fast, merging several features most days with minimal regressions. Screw the old way. It sucked.

salex89 6y ago

In my experience, anything longer than 1500 lines chokes PyCharm. And I can't blame it, it's still the best Python editor. Everything else feels like writing in Notepad. It's the only tool that can actually helps you navigate/organise/autocomplate/whatever in large Python project, which is a must for this goddamn language.

natch 6y ago

The gall of using full justify to complain about a formatting issue... big facepalm.

WhyNotHugo 6y ago

This guys starts criticizing the standard four-space handing-bracket indentation used in python, since he seems to prefer using 8-spaces in some cases so that his IDE can auto-fold code (even though it's more human-readable) I'm sure for every language, some IDE has issues with the most popular code formatting style. Fix the IDE, not the language. Sounds like an very opinionated rant, rather than anything objective/technical.

wisemanwillhear 6y ago

> setuptools_scm, because our versions must change at every new commit. I don't get many of these points. For example, at the company I'm about to leave, we worked just fine both manually versioning as well as using tools like versioneer/setuptools_scm. We made it easy to fire up new projects using a dual template/boilerplate repo strategy. Infrastructure like this is in a boilerplate repo and almost entirely setup for new projects from the start. New projects fork a template project and do a small number of basic steps (like naming the project, etc.). Both the template and project repos are update from the boilerplate Git repo as we make updates to the infrastructure--a simple Git remote setup.