Live data from Hacker News

Python programming is drowning in red tape

stefanoborini.com

111–120 of 183 posts

Re: Python programming is drowning in red tape

#111
post #46

> 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 tha…

Just think of it like a license. If you publish code, you should stick a license on it, so it's clear if/how other people can use it. If you publish a project, you should stick a code of conduct on it, so if any assholes show up, you can link them to something as you tell them to go away. For most developers, these can be glanced at and ignored "yeah, BSD again, great" / "contributors covenant again, blah blah". Having things like this is basically a requirement for getting N>5 when N is the number of developers working on the project, so just pick something sane.

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.

Re: Python programming is drowning in red tape

#112
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.

Re: Python programming is drowning in red tape

#113
post #28

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.

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.

https://xkcd.com/927/

A bit to the topic - what's wrong with good old:

  python -m venv env
  env/bin/pip install 

?

Re: Python programming is drowning in red tape

#114
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!

Re: Python programming is drowning in red tape

#115

Earlier quoted context omitted.

Why do you believe that providing hints to which is the type of a variable is something that makes the language barroque and complicated?

not the OP but I share the sentiment. On a syntax level simply because it adds types, and one of the joys of writing a dynamic language is that you don't have types filling so much of your code. 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…

> On a syntax level simply because it adds types, and one of the joys of writing a dynamic language is that you don't have types filling so much of your code.

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.

Re: Python programming is drowning in red tape

#116
post #65
post #46

> 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 tha…

A lot of these are added because "open" source authors these days depend on their corporate masters. Adding a CoC provides one with: 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…

The 1. assumes that engineers like going to meetings to have 'easy' work and I honestly never met one that would prefer spending a month in meetings and writing docs over almost anything else.

Re: Python programming is drowning in red tape

#117
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.

Re: Python programming is drowning in red tape

#118

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 resembl…

> hardly resembles the easy-to-understand language I fell in love with back in 2006. 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.

> ditching Python on account of it being too complex

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

Re: Python programming is drowning in red tape

#119
post #86

Earlier quoted context omitted.

Interestingly, the question whether this particular choice of code formatting in black adheres to pep8 is still an ongoing discussion[1][2][3][4]. Guido, for example, thinks that black's choice is not compatible with pep8 and I think he described the situation quite well on Python's Discourse[5]: > 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…

Thanks for the pointers, I stand corrected. OP could continue this debate if that’s his passion. I bow out. 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…

> so that I don’t need to have these pointless arguments

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

[1] https://news.ycombinator.com/item?id=19941119

Re: Python programming is drowning in red tape

#120
post #96

Earlier quoted context omitted.

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.

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…

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

Post reply on HN