
Python programming is drowning in red tape - _630w
https://stefanoborini.com/python-programming-redtape-and-blacker/
======
oefrha
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.

~~~
stinos
_it’s not like I’m gonna use his fork_

Probably shouldn't no, no use: the article is from february 3, meanwhile the
fork
[https://github.com/stefanoborini/black](https://github.com/stefanoborini/black)
is 40 commits behind and 0 ahead. Meaning the OP didn't do any public work
yet.

~~~
carlosperate
Wrong repo:
[https://github.com/stefanoborini/blacker](https://github.com/stefanoborini/blacker)

~~~
stinos
Good find, I stand corrected.

------
micimize
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-565383...](https://github.com/psf/black/issues/1178#issuecomment-565383116)

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
> Reopen the issue right now or I am forking.

This is comic gold.

~~~
ashtonkem
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.

------
AlexandrB
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...

~~~
blondin
> Type-annotated, asyncio-enabled Python hardly resembles the easy-to-
> understand language I fell in love with back in 2006.

true.

i am all for types in general and for types annotations in python. but i have
seen some heavily type-annotated python code lately and i don't think that's
where we want to be.

we are starting to look like a heavily templatized cpp code.

~~~
jordic
Don't mix things, guy! \- asyncio it's one thing: From my point of view it's
amazing... makes python be able to compete with nodejs or go.. (not so hard,
if you work also on the browser)

\- mypy: that's another story, but it's also optional, use it if you want...
(my opinion, like in typescript, if I want types I will do it with go or rust)

~~~
nine_k
Good luck finding a pandas or scipy implementation for go or rust :-/

~~~
philipov
"BlackJack strives to be a full featured crate for general data processing.

Long term goal is to create a lightweight Pandas equivalent by and for the
Rust community, but with slight differences in focus..."

[https://docs.rs/black-jack/0.1.0/blackjack/](https://docs.rs/black-
jack/0.1.0/blackjack/)

EDIT: That one looks like it's not being worked on actively. Here's a reddit
thread with more ideas. Weld looks interesting.

[https://www.reddit.com/r/rust/comments/apo66e/dataframes_wha...](https://www.reddit.com/r/rust/comments/apo66e/dataframes_what_do_you_need/)

[https://www.weld.rs/](https://www.weld.rs/)

And Arrow looks like a new project Wes McKinney is contributing to.

[http://arrow.apache.org/](http://arrow.apache.org/)

------
streblo
> 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
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
> Beautiful is better than ugly.

~~~
Drakar1903
Things in this industry are divided into those that get complained about and
those that get forgotten.

------
etaioinshrdlu
> 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.

~~~
firefwing24
Author didn't even take the time to look at what pre-commit does.

~~~
underyx
And acts as if their project won't work unless they add a code of conduct?

------
nerdbaggy
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.

~~~
raverbashing
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
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
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
_> 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
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?

~~~
rbanffy
On my 11 inch I use a single pane. On the 15" it works well when the laptop is
on my lap, but less so when it's on the desk but, then, it has two larger
monitors, one horizontal and one vertical, so I can still use the two-pane
arrangement (typical use is program and test files side by side).

I cut my teeth on the Apple II+, with 40 columns. I agree that 40 columns
would be silly, but keeping the text column narrow so that eyes don't need to
move too much helps a lot. It's a readability trick used in print since ever.
From my position, the horizontal screen spans about 60 degrees, which feels
excessive. By the time my eyes marched from left margin to right margin, I
already forgot what I was looking for.

------
tartoran
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.

------
benatkin
"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
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.

------
halfdan
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
> _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.

------
l0b0
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.

------
dsign
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 :-(

------
cakeofzerg
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
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
Yeah nothing beats Visual Studio. More productive in C# for most things, but
cant beat python for data science/ML.

------
gardenrewind
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
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.

------
kingrolo
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
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.

------
shmolyneaux
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.

------
echelon
> 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.

~~~
justin66
> And when there are assholes, can't we handle everything on a case-by-case
> basis, as it arises?

Don't interpret this comment as support or lack of support for codes of
conduct (I honestly don't have an opinion about the topic). This is just an
observation: there are multiple species of attention-seeking internet troll
who want _very, very much_ for you to treat their absurd behavior "on a case
by case basis."

> I'm going to be downvoted for even admitting this? That's why I debated even
> posting. I don't like operating like this.

The mob is handling our comments on a case by case basis!

~~~
omginternets
>This is just an observation: there are multiple species of attention-seeking
internet troll who want very, very much for you to treat their absurd behavior
"on a case by case basis."

In my experience the exact opposite is true. Most trolls want to argue the
finer language of a CoC, and waste everyone's time in a pseudo-legal battle.

"Case-by-case" doesn't mean you have to spend a lot of time. It just means
you're asking yourself "is this person being disruptive" as opposed to being
compelled to argue technicalities in order to justify your actions as a
moderator.

~~~
justin66
I'm talking beyond my expertise here - I've never been involved in a CoC
argument, but I have witnessed a lot of trolling - but it seems to me like the
same guy who would be happy to argue endlessly about the trouble he's caused
and the punishment or censorship that's being meted out on a case by case
basis would also be happy to argue endlessly about a code of conduct and its
application. Just please pay attention to him!

I sort of suspect the same applies to the third parties who like to whinge
about how moderation is being done.

> "Case-by-case" doesn't mean you have to spend a lot of time. It just means
> you're asking yourself "is this person being disruptive" as opposed to being
> compelled to argue technicalities in order to justify your actions as a
> moderator.

Even I have seen the "you handled this one way last month, why are you
treating this guy differently today?" arguments. I imagine if you're willing
to discuss your decisions at all, you're going to be forced to argue
technicalities, if you're infested by the kind of people who like to argue
technicalities.

~~~
omginternets
>I'm talking beyond my expertise here - I've never been involved in a CoC
argument, but I have witnessed a lot of trolling

If by "argument" you mean "flame-war", then I suppose I'm right there with
you. I've _seen_ many, but participated in zero.

Still, I think I've observed some regularities. One such regularity is that
flame-wars and CoC-trolling almost always take place in communities that treat
their CoCs as some sort of constitution, and believe these conflicts should be
resolved in a simili-court-of-law.

This is why I continue to oppose CoCs on the grounds that they're ideological
tools, in practice. In my estimation, the whole _point_ of pushing CoCs on
open source projects is to get them to think in terms of legal process, at
which point they can be harassed into behaving a certain way. This is all done
on the false premise that internet communities should be run like first-world
democracies.

>Even I have seen the "you handled this one way last month, why are you
treating this guy differently today?" arguments.

>I imagine if you're willing to discuss your decisions at all, you're going to
be forced to argue technicalities.

That's the brilliant thing - you're _not_ forced to argue technicalities. In
fact, you're not forced to give _any_ explanation (though that's rarely the
best policy, in practice). This isn't a court of law.

Anyway this is just ... like ... my opinion, man. Others can disagree with me
and still be reasonable. As I said in another comment, I don't run any popular
OSS communities, but if I do, I don't think I'll use a CoC. And I don't think
that will prevent me from enforcing good behavior.

(P.S.: I've just reread this comment and it struck me as a bit abrasive and
argumentative. I've made a few changes, but please be assured of my courteous
intent!)

------
tcbasche
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.

------
cachestash
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.

------
CrLf
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
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.

------
salex89
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.

------
tree3
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.

------
danpalmer
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!

------
wisemanwillhear
> 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.

------
laingc
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.

------
therealmojado
> 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
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
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.

------
Qantourisc
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.

------
geofft
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.)

------
liquidify
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++.

------
beshrkayali
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).

------
WhyNotHugo
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.

------
INTPenis
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.

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

------
ganafagol
"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.

------
z3t4
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.

------
arvinsim
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
Do you want black to be the standard? If you share your code with others,
that's how you're currently voting!

------
mesaframe
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.

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

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

------
j88439h84
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.

~~~
lmm
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.

~~~
trymas
[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
Its behaviour isn't reproducible unless you've frozen your dependencies, and
once you've frozen them it becomes very difficult to upgrade any of them. And
if your project is itself a library then freezing is basically not viable, so
every developer is testing with a slightly different set of dependency
versions.

This combines poorly with the fact that venvs are stateful and easy to get
mixed up. If you accidentally run the pip install for project A in the
terminal window for project B, then you have quite possibly permanently fucked
up that venv - there's no reliable way to roll back to the previous state -
and if you regenerate it from scratch then, per the previous point, you'll
probably get different versions of your transitive dependencies. If your tests
were previously passing and now fail - or, worse, were previously failing and
now pass - then you're gonna have to abandon whatever you were previously
doing for an unknown length of time and deal with this.

Beyond that, those two commands (already twice as many as I'd like) don't tell
you anything about how to run unit tests or package up your application for
distribution, so you've got a bunch more commands to memorise, which tend to
vary between one project and another because how to do those things also
changes every two years. And since venv and pip were only included in quite
recent versions of Python, if you've got some projects that are using older
versions too then you have to memorise a couple more sets of commands for that
stuff as well. The whole thing's such a mess that it almost makes docker seem
like a sensible idea.

