Python programming is drowning in red tape
stefanoborini.com
stefanoborini.com
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.
- 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
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.
Probably shouldn't no, no use: the article is from february 3, meanwhile the fork https://github.com/stefanoborini/black is 40 commits behind and 0 ahead. Meaning the OP didn't do any public work yet.
> So the root of this argument is that Black produces code that isn’t always in compliance with PEP 8. I say this is fine – if you use Black you don’t need PEP 8 to tell you how to format your code. (PEP 8 is still useful for other things like naming things.)
> Black optimizes for a different goal than PEP 8; PEP 8 optimizes for readability while Black sometimes compromises readability in order to satisfy other goals such as minimizing lines changed as code evolves.
> I don’t want to compromise PEP 8 though.
[1]: https://github.com/psf/black/issues/48
[2]: https://github.com/psf/black/issues/1178
[3]: https://github.com/psf/black/issues/1336
[4]: https://github.com/PyCQA/pylint/issues/289
[5]: https://discuss.python.org/t/pep-8-clarify-if-multiline-argu...
Meanwhile, I’ll happily enforce black where I can so that I don’t need to have these pointless arguments, although I personally strongly disagree with many of its decisions. I also have no problem contributing to whatever non-blackened projects, including CPython itself (contributed quite a few patches over the years), which is probably the final word on PEP8.
This. I can't believe how much time is lost in such discussions. To paraphrase cjbprime from 11 months ago [1], "nobody likes what the code-formatter does to their code, but everybody likes what it does to their coworker's."
But that's of course a bikeshed.
At any rate, if black's formatting does break PEP8 (as a downthread commenter rebuts), I would think it's weird that black doesn't have a --pep8-correct flag or something for people who do want PEP-compliant stuff. Certainly black can go its own way, but if people are going to consider it "the blessed python code formatter", it should have a mode that actually conforms to the python standard for formatting.
But hey, ultimately it's the black maintainer's choice.
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.
This is comic gold.
Not to bring back that whole maintainer vs contributors discussion, but this is a solid example of entitlement some contributes feel.
EDIT: It also gives "I code stuff and try to crash in creative ways." in his profile a somewhat different meaning.
> Personally, I much prefer black's indentation scheme. I also like spending as little time as possible agonizing over minutia like this.
The strain of bothering over this stuff just isn't worth my time either - I have actual work to do, and the tools tend to just do what I need them to. If they don't, I move on.
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...
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.
There are massive differences between languages, though. I think I might use close to 70% of Objective-C's or Java's features regularly, while I can't even hope to use 50% of C++'s.
The problem is that other people might use those features and you also might have to read the code created by those people.
I have the same problem with classes in JavaScript. You can't ignore them and stick to prototypes nor ignore prototypes and stick to classes. What should have been a simplification has turned out to make things more complex.
You can only read the code and guess the type yourself.
I'm personally not a fan of it (I'm still a gevent proponent; Go seems to be doing fine with a green thread model), but a lot of libraries I use are written with it, so it's pretty annoying for me. That and the dependency/package story are the two things that've made me seriously consider switching to a different language. (The article's complaints about things like pre-commit and isort are pretty silly and irrelevant, IMO, though it would be nice if there was something official like "go fmt".)
So far the benefits still outweigh the costs for me, compared to other languages, but I predict a better, cleaner, and more performant successor to Python may come this decade. If it does, I think I might become an early adopter.
Yes, this is true. I don't think there's a lot of existing code using it at this point since it's still a fairly new feature. But of course that will change as time goes on.
> I'm personally not a fan of it
I haven't tried it yet in an actual project, but my initial reactions just looking at the specifications and examples were mixed. I like the idea of the await keyword to label call sites where your code might be suspended, but I don't like having "async" cluttering up function definitions, for loops, and with statements. The way generators were handled when they were first introduced in Python 2 was much cleaner IMO: one new keyword, yield, and any function that had that keyword in it automatically became a generator. I don't see why a similar rule couldn't have been implemented for the await keyword: any block with await in it automatically becomes an async block.
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.
- 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)
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/
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...
And Arrow looks like a new project Wes McKinney is contributing to.
But most importantly, `def foo(lst: list, idx: int):` is fine in 95% of cases. Most of the time, you don't need to go full Java, full verbosity. Document the most important elements - you're taking in a list and an int - and move on.
Which was my main concern when type-hints were added
Give a hand to the strong-typed people and they will take the whole arm.
They will take Python as "now it's like Java" and will push it all the way through.
(Though yeah templates in C++ turn the ugliness to 11)
Not to mention Python is "strongly-typed". But it doesn't require variables to have a pre-determined type and doesn't do compile time type checks by itself.
Is the point where your Python codebase needs type hinting to be readable a signal that you've hit the dynamic language/complexity impedance mismatch?
Or is it a sign that your code's readability could be better?
Your "session" remark reminds me of trying to understand the Ruby IMAP library when the only documentation was autogenerated API docs, I had to follow one variable through the entire stack to figure out what it's original type and thus capability, was.
I taught myself to code in Python, and find that well-written Python makes sense without types (tooling support aside), but then being honest, most of the Python code I meet professionally, is barely okay written.
I guess it's like Java, industrial programming code needs a type system to make code written averagely understandable, but not so much of a type system that you spend your time fighting obscure compiler errors.
Since I started using them, the number of runtime errors coming out from my own code has been drastically reduced.
Of course one can always go overboard with those `Generic[T]` hints. Though this is a problem of the tool user, not the tool.
But at the same time, for serious industry work, those features do come in handy when you do need them.
I think this is why to some extent you never hear that much good of the old tried and tested languages. They always feel bloated, disorganized, confusing, with too much cruft, and yet it's all that which make them what they are.
But much more important to me, on a semantic level. Late binding of all things is a feature of dynamic languages, not a bug. I have no idea why we're trying to force a static typing mindset onto a dynamic language.
I wish we could all remember that the original idea of OO is that objects interpret the messages they receive, not external typecheckers.
Then good that you don't have to do that. Type hinting in python is optional and it's unlikely that this will ever change.
> I have no idea why we're trying to force a static typing mindset onto a dynamic language.
Because python ist not a toy-language anymore. It's used for big projects too, and for them features like this are very neccessary.
I've worked on multi-million line dynamic codebases in settings that require robustness and correctness (telecommunications/Erlang) and it's an absolute ridiculous idea that one needs type checking to build industry standard codebases and architecture.
The Java/C++ paradigm is not the only software paradigm to built correct software.
Fellow "old man" reporting for duty.
I see a similar set of problems with both Python and JavaScript today (and with various other languages as well, but IME Python and JS are the worst offenders). Both have proven to be useful for various applications. Each started with quite a distinctive style. There were plenty of warts in each case, but overall the "feel" of each language was well understood, and there was a certain simplicity about them that made them accessible to new programmers or to programmers who primarily used other languages. However, over time, people have applied the kitchen sink approach to both language and tooling.
Functional programming is all the rage, and these languages have lambdas (albeit very clumsy ones), so let's all write lots of FP-style code in them! Except you can't, because they are horrible for writing FP-style code, because they lack FP features, they lack efficient and clear syntax for FP idioms, and they do not provide some of the guarantees that benefit FP.
Similarly, a lot of programmers are realising that static typing has its merits when you're trying to build serious software at scale, so let's all add type annotations and start marking up our code! Except that both the existing type systems and idiomatic use of these languages are built around dynamic behaviour, so they lack powerful tools for constructing new types, and they lack efficient and clear syntax for specifying static types, and they lack comprehensive type inference, and the continued presence of dynamic typing means you can't prove a lot of otherwise useful properties of your code anyway.
The amount of tooling expected to do even basic development with these languages today is absurd. Professional-quality programming ought to need no more than a compiler/interpreter, a decent editor and a decent source control system to be productive. On the next level, we might find a tool to automate running tests and reporting the results, a debugger and a profiler; I count these as secondary because it should really be possible to work reasonably well without them but they can make common tasks significantly more efficient and/or accurate. The lack of a package manager tool in both of these lists is not an accident.
I think just as much of today's programming industry has forgotten about the benefits of stability, backward and forward compatibility, and standardisation in the software we make, we have also forgotten about them in our own tools. Do we really need 27 new frameworks for building web apps this year? Is having 41 libraries to do basic unit testing that each use slightly different syntax and vary in <5% of the features they provide really worth the added complexity in the ecosystem? How on earth does JS not have a decent standard library yet?
Maybe it's time to slow down, and make carefully considered choices about the tools and libraries we use in our work, instead of instinctively reaching for that package manager and installing... well, let's be honest, most of the time we don't really know exactly what we're installing, do we?
I used to love Python back in those days. Even did a big project with multiple developers in it.
Then I didn't use it for a while and came back for some easy scripting. I was absolutely horrified how complex things are right now. Ditched it and doing my scripting with node.js.
> chooses NodeJS
Congratulations on picking a language with even more weird pitfalls and edge cases?
JS is not what I’d call a simple, straightforward language.
I had that same feeling in the 2.4-2.5 days of Python. But now it was really hard to find simple API's.
Let me give you an example about parsing JSON. This is the Python way:
json.load(fp, , cls=None, object_hook=None, parse_float=None, parse_int=None, parse_constant=None, object_pairs_hook=None, kw)
Seriously, how F(&#$%@ING complex can you make the thing?
This is Javascript:
JSON.parse(text[, reviver])
Ah, that's the way I like it :)
But hey, if you want all that argument power, no problem for me. I'm a simple programmer, liking simple things. And that was my point, Python has lost its simple ways. The JavaScript language might have some weird shit, but I don't care about that because I can stay far away from it. I care about simple programming.
It looks like you copied that from https://docs.python.org/3/library/json.html
Those are all optional parameters, if you don't need them it's just:
json.load(fp)
Which, to the best of my knowledge will behave just like the JS version.
Perhaps I'm just ignorant as to why you would use what's typically a web server for the purposes of scripting
I'm all with this, but you can pretty much use python without touching these at all. They have a niche business use cases. E.g., when you work on large projects and you want to catch some errors to not be in the runtime.
async was very needed to be able to write performant web servers such as nodejs.
I'm not using python as i used to, and i think the language is getting more complex, and i'd definitely vow for more fundamental changes to the runtime. But if you ignored all of that, python is still remain python. And when your business logic gets more complex, it is imperative your code becomes more complex and you get to discover and use more "language advanced features". The good thing they are available, they are not perfect, but they can be of a good help.
yessss... because a pair of parentesys are too much... I always hated that I couldn't pass "print" as a callback, or the weird >> syntax to write on stderr
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.
That is what this post is advocating for, his own fork of black.
In particular I understand that there are wrong ways to complain (and possibly the author is guilty of them), but this specific blog felt over the top and emotional (something I sympathize after unrelated experiences in failing to understand how to organize an Poly/ML project) but not unfair.
Frankly, after having been out of the Python ecosystem for a long time, I'm surprised that something like black ever gained traction, if it really has strayed in any significant sense from pep8.
The entire reason you have been able to ignore stupid formatting debates like this for so long is because of things like pep8 and strict definitions of what entails "Pythonic" code.
What happened?
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.
My reaction exactly.
“When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP.”
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.
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
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.
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 ;)
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.
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?
> 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.
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.
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:
<select
value={fruit}
onChange={({target: {value}}) => setFruit(value)}
>
<option value="apple">Apple</option>
<option value="orange">Orange</option>
<option value="banana">Banana</option>
</select>
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.
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.
Screw the old way. It sucked.
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.
I think that a good thing. Formatting discussions are important (arguably), but it should be decoupled from a specific 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.
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.
I must live under a bush.
I once attended a tech meetup held at the headquarters of a FAANG. As we were waiting for the presentation to start, they projected their a link to their code on conduct for the meeting.
I tried to visit the link. It gave a 404. Apparently it hasn’t been working for some time. Nobody noticed.
Ironically, the meetup was about site reliability engineering.
Edit: in all fairness I’ve seen a good tech group destroyed over a dumb battle about their code of conduct.
1) At least one month of meetings, drafts and otherwise easy "work".
2) Increasing one's personal brand and marketability inside the corporation and on Twitter.
3) Increasing one's non-meritocratic influence inside the project.
So we are back to the title of this submission: Red tape is introduced in "open" source because corporate money destroys it.
It seems like it could be useful for large and socially important projects with many contributors IMO but I'm not sure why <10 contributor projects pick up on the habit.
I do find conversations about codes of conduct particularly exhausting, akin to GPLv2 vs GLPv3 licensing debates. And usually an excessive interest in these things is a red flag.
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!
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.
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.
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!)
I think this is a case where a minority of people care very deeply, both about the core issue and about proselytizing it. The rest of us are a silent majority who, like you, are rubbed the wrong way by the whole situation but don't care enough to make a fuss.
To add to your point, here's what boggles my mind with this new CoC frenzy: you can enforce good behavior, even without a CoC.
I don't have any popular open source projects under my stewardship, but if that ever happens, I don't think I'm going to add add a CoC. This is because, in my estimation:
1. They're political tools. The people who visibly push for their widespread use tend to have a revanchist attitude with respect to diversity, inclusion and social equality. They see CoCs as a symbolic action in a turf war, not unlike spray-painting a gang symbol in an alley.
2. As you yourself have noted, it puts people on the defensive. It makes them think before posting...but for all the wrong things. It's stifling.
3. I can still ban disruptive or toxic assholes. I don't need a fake constitution to grant me those powers. See point #1.
Note that you're not downvoted anymore. Early downvotes are usually balanced out quite quickly if your comment is sincere and thoughtful.
Hello, I received a complaint from an important member that you were not following the CoC and they have given me sufficient evidence of your inappropriate behaviour. For anonymity reasons, I can't provide information on who it was or what the evidence is but as of now, you have been ...xyz
Sincerely, thrwaway69
(/s)
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.
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.
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.
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.
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!
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.
Really? What about laws? Do you think they exist because it is assumed that everybody is a rapist and a burglar?
"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.
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.
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.
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/ - 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.)
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.
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.
...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.
I personally use black but I wouldn't mind other standards as long as I don't have to pick and choose anymore.
For packaging a Python project, that tool is Poetry. Pipenv, virtualenv, setup.py, venv, setup.cfg, are all outmoded.
A bit to the topic - what's wrong with good old:
python -m venv env
env/bin/pip install <whatever>
?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.
There's only so many iterations you can have through the cycle before "no this is the last one!" isn't plausible any more.