Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python programming is drowning in red tape

stefanoborini.com

Post reply on HN
Print view View original

61–70 of 183 posts

Re: Python programming is drowning in red tape

#61

Post by meowface »

lmm wrote: post #28
j88439h84 wrote: post #20

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.

Pretty much, but Poetry is slowly emerging as the winner, I think. There is no good solution, but if you're starting a new project, Poetry is probably your best bet.

Re: Python programming is drowning in red tape

#62

Post by j88439h84 »

lmm wrote: post #28
j88439h84 wrote: post #20

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.

Well, look again. Poetry is a good tool.

Re: Python programming is drowning in red tape

#63

Post by 0az »

jordic wrote: post #32
blondin wrote: post #14

Earlier quoted context omitted.

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

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)

Honestly, after trying MyPy for a bit, I'm probably going to gradually type. There's some metaprogramming constructs (notably certain class decorators) that are not expressible in the type system, for one. This makes packages like environ-config unusable.

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.

Re: Python programming is drowning in red tape

#65

Post by alqrx »

echelon wrote: 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 introduced in "open" source because corporate money destroys it.

Re: Python programming is drowning in red tape

#66

Post by anyfoo »

jordic wrote: post #29
oefrha wrote: 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’…

100% agree with you. So happy with black and pytest. - The formatting he is proposing for multiple args on a function with double tabs it's wired... O_O - Same argument on mypy, if I want to type all variables, I perhaps will be happy doing it in go or rust.. python is dynamic :) - pytest - balck works so fine with vscode (pycharm will work if he disables linting code on every keystroke... )haha

mypy kept python viable for me. I was working on a pretty complicated hw interface, which also used a lot of async/await. Even without what was basically my own coroutine implementation, there were just complicated (but not unusually so!) types in general. You know, just dicts of tuples of lists of tuples and the like.

At what felt like the 1000th runtime problem because of some type confusion somewhere (or just forgetting "await", which is essentially a no-op, since you got a promise that you threw away), and a lot of these problems happening much later than where the actual bug in the code was, I was ready to throw in the towel and bid python--and all other dynamic languages--good bye.

So I decided to try out mypy as some kind of last hurrah, and it paid out immediately. Adding the types went pretty quickly, and after that numerous problems were caught by the type checker, instead of manifesting as some obscure runtime problem down the way.

Re: Python programming is drowning in red tape

#67

Post by stinos »

oefrha wrote: 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.

Re: Python programming is drowning in red tape

#68

Post by oefrha »

micimize wrote: post #41

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.

Re: Python programming is drowning in red tape

#69

Post by cakeofzerg »

mehrdadn wrote: post #31
cakeofzerg wrote: post #17

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

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

Yeah nothing beats Visual Studio. More productive in C# for most things, but cant beat python for data science/ML.

Re: Python programming is drowning in red tape

#70

Post by joshuaavalon »

petersellers wrote: post #15
pdonis wrote: 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…

> 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. The problem is that other people might use those features and you also might have to read the code created by those people.

The problem for me is other people not using it. When I call another library, there is no type hint and the documentation is poor.

You can only read the code and guess the type yourself.

Post reply on HN