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

151–160 of 183 posts

Re: Python programming is drowning in red tape

#151

Post by EdwardDiego »

prewett wrote: post #91
EdwardDiego wrote: post #54

Earlier quoted context omitted.

Type annotations help catch common errors, and they help humans. Maybe it's not as pretty but as someone who often have to read Python, it really helps me understand what the contract is of a function I'm looking at.

As a big fan of statically typed languages, I agree with you on the utility. Especially after having worked on a large Python projects a few years ago and having to spend a lot of time figuring out what, exactly I could do with a argument named “session”. But when you start turning your dynamically types languages into an ugly statically typed one, maybe we should just admit that we’re using the wrong tool for the jo…

That's a thought.

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.

Re: Python programming is drowning in red tape

#152

Post by LeonidasXIV »

joshuaavalon wrote: post #70
petersellers wrote: post #15

Earlier quoted context omitted.

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

So just like any other dynamically typed language?

Re: Python programming is drowning in red tape

#153

Post by oefrha »

tonyedgecombe wrote: post #45
jordic wrote: post #35

Earlier quoted context omitted.

And what's the problem on having some type hints on some func signatures?) You can read python exactly the same way (with and without type hints)....

It's just one more thing you have to get to learn. 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.

Unlike ES6 classes, you absolutely can ignore type hints (and they're easy to ignore). In fact they're basically inline comments, and the interpreter ignores them too.

Re: Python programming is drowning in red tape

#154

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

Re: Python programming is drowning in red tape

#155

Post by lmm »

trymas wrote: post #113
lmm wrote: post #28

Earlier quoted context omitted.

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 ?

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.

Re: Python programming is drowning in red tape

#156

Post by underyx »

firefwing24 wrote: post #59
etaioinshrdlu wrote: post #7

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

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

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

Re: Python programming is drowning in red tape

#157

Post by jordic »

anyfoo wrote: post #66
jordic wrote: post #29

Earlier quoted context omitted.

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

Most of the problems you mention could also be solved with a good test suit... I'm not against mypy.. but after working near two years with typescript.. if I have to type I prefer to do it with compiled things...

Re: Python programming is drowning in red tape

#158

Post by jordic »

tonyedgecombe wrote: post #45
jordic wrote: post #35

Earlier quoted context omitted.

And what's the problem on having some type hints on some func signatures?) You can read python exactly the same way (with and without type hints)....

It's just one more thing you have to get to learn. 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.

Anyway es6 classes it's just a proper way of doing Oop in js.. the prototypal thing it's so ugly...

Re: Python programming is drowning in red tape

#159

Post by silveraxe93 »

kingrolo wrote: post #105

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

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.

Re: Python programming is drowning in red tape

#160

Post by koonsolo »

_ZeD_ wrote: post #140
koonsolo wrote: post #87

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.

ahahahah now you are telling me that the node ecosystem and the tooling and pre/post compilation/translation phases are simpler than python? (and I'm not talking about the languages themself)

Compilation? I write a JS file and then do node myfile.js...
Post reply on HN