Live data from Hacker News

Python programming is drowning in red tape

stefanoborini.com

161–170 of 183 posts

Re: Python programming is drowning in red tape

#161

Earlier quoted context omitted.

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

I care about writing clean and simple code in an easy way. I found that the node ecosystem with npm packages allows me to do this very well.

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.

Re: Python programming is drowning in red tape

#162

Earlier quoted context omitted.

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

I care about writing clean and simple code in an easy way. I found that the node ecosystem with npm packages allows me to do this very well. 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, objec…

> json.load(fp, , cls=None, object_hook=None, parse_float=None, parse_int=None, parse_constant=None, object_pairs_hook=None, kw)

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.

Re: Python programming is drowning in red tape

#163

Earlier quoted context omitted.

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

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?

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.

Re: Python programming is drowning in red tape

#164
post #38

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

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/ 1] http://www.bradoncode.com/blog/2015/08/26/javascript-semi-co...

> I wouldn't necessarily say if something is popular, it is also good.

Black is popular because it is good.

Re: Python programming is drowning in red tape

#165
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…

> I'm going to be downvoted for even admitting this?

Note that you're not downvoted anymore. Early downvotes are usually balanced out quite quickly if your comment is sincere and thoughtful.

Re: Python programming is drowning in red tape

#166

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, espe…

If you put some parens around the query you can get a nicer and still pep8 compliant formatting

https://stackoverflow.com/a/11920726

Re: Python programming is drowning in red tape

#167

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... Also if this developer wasn't so obsessed with bikeshedding, they could just edit the one bit of formatting…

It seems like they had an issue, they came up against a fairly standard response from an open source community, and then had several public hissy fits about it. > 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…

This is why I leave IntelliJ to the default code style settings for Java; they’re good enough, and I have more important things to do.

Re: Python programming is drowning in red tape

#168
post #68

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... Also if this developer wasn't so obsessed with bikeshedding, they could just edit the one bit of formatting…

> Reopen the issue right now or I am forking. This is comic gold.

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.

Re: Python programming is drowning in red tape

#169
post #8

Earlier quoted context omitted.

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

I have to disagree regarding asyncio. If existing code uses it that you need to interface with, your sensible options are basically to rewrite all of your code to use asyncio, or try a hacky third-party library that'll try to bridge them. 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…

> I have to disagree regarding asyncio. If existing code uses it that you need to interface with, your sensible options are basically to rewrite all of your code to use asyncio, or try a hacky third-party library that'll try to bridge them.

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.

Re: Python programming is drowning in red tape

#170
post #67
post #25

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

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 is 40 commits behind and 0 ahead. Meaning the OP didn't do any public work yet.

Wrong repo: https://github.com/stefanoborini/blacker
Post reply on HN