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

Breaking up with Python

cedwards.xyz

Post reply on HN
Print view View original

131–140 of 179 posts

Re: Breaking up with Python

#131

Post by c7DJTLrn »

agolio wrote: post #18

> Python’s documentation sucks I can't agree with this. I have always had a very good experience with python documentation. One can use the built-in "help" function which works seamlessly with the docstring feature of the language. The complaint in the blog post seems to refer to the UI of the website missing a table of contents for functions. Yeah sure they could add that but I don't see it as a big point. > Python’…

>Don't all of these use pip under the hood?

The point is that every extra tool you need to work on a project is another thing you need to get installed and working. It's another thing that will rot over time. In 5 years it might be totally unusable and broken.

When I clone a project, I want to be productive with it as quickly as possible.

Re: Breaking up with Python

#132

Post by pdonis »

maxerickson wrote: post #130
pdonis wrote: post #62

Earlier quoted context omitted.

> the urllib module that he links to it's not the best thing ever I think the reason it (and the http modules in general) has never been improved is that even when Python was young, there were better third party packages out there, but no single one of them ever got to the point where the Python devs would consider making it part of the standard library. Particularly when it comes to servers, there have always been m…

There was some reorganization for Python 3: https://jeremyhylton.blogspot.com/2008/06/ I think there's quite a lot of use of requests that would be fine with 'urllib.request.urlopen(...)'.

This might be true; I think the client code in the Python stdlib is much closer to production usable than the server code.

Re: Breaking up with Python

#133

Post by justsomehnguy »

kcartlidge wrote: post #97
justsomehnguy wrote: post #42

Earlier quoted context omitted.

In my experience PowerShell fits well as a toe-dipping language. It allows to solve the menial tasks someone with no programmng experience usually needs to solve, can interact with HTTP/REST-like APIs, sometimes has the modules for a popular solutions, is object oriented, lax on the indentation *smirk*.

> In my experience PowerShell fits well as a toe-dipping language. Ugh. Sorry, I've not really got anything constructive ( destructive? ) to say in support of that other than (a) in practical terms it isn't a transferrable skill beyond Windows, (b) the Naming-Conventions-OfThings is both awful and verbose, and (c) I've never had a use case where more than a handful (at most) of my fellow devs would be happy to work w…

a) thats only for modules designed to interact with Windows features. Sure, Get-ADComputer doesn't work on Linux, but... by default Python doesn't work with a ton of things which are available through the wast library of Python modules. Same deal with PS, you can't interact with Snipe-it or Netbox by deaful... but there are modules for that.[0]

Basics works everywhere. In my personal experience I often found myself in a situation where I'm spending a lot of time wrestling with *nix shell (especially finding workarounds for the differences between Debian/Ubuntu and RH/CentOS/Rocky) instead of spending 5 minutes on PS script which would would everywhere, just supply the distro specific paths.

b) not a problem in the real life. Come on, you don't sprn you time writing the paths, you just TAB them - same thing with PS, except it works on cmdlet names AND their parameters, out of the box, on any platform. Ubuntu has it now by default (for some supported things), RH-like - not.

c) well they probably had a more familiar to them tool on their hands already

YMMV, of course, but the thing is what you are being constructive here, with explicitly stating things you don't kno2 or understand.

[0] and there are Py modules for that too, but they are not the part of the default install too

Re: Breaking up with Python

#134

Post by cedws »

jgb1984 wrote: post #126
iainctduncan wrote: post #55

What is such low effort post doing here? I use Python way less than I used to, but this is just unfounded whining. And imagining js is better on those points... omfg.

I came here to say the same. The author clearly has only a very superficial knowledge of python (and a large distaste for it). Throughout my studies and career I've written c, c++, java, javascript, perl, bash, python and a little bit of go. Python for me is by far my favorite and most productive language. Expressive syntax, an unmatched wealth of useful libraries and most importantly: when I come back to code I wrot…

>The author clearly has only a very superficial knowledge of python (and a large distaste for it)

I wouldn't make assumptions like that. I've worked with production Python codebases. In fact, until recently I was working as a DevOps Engineer in a hedge fund building much bigger, more complex systems than a typical CRUD backend. I worked hands on with some of the Python repositories and it was extremely painful simply because of the nature of Python.

Re: Breaking up with Python

#135

Post by agolio »

nhchris wrote: post #123
agolio wrote: post #104

Earlier quoted context omitted.

You are quite right it is not just compilation that sets Python apart from C++, that was a bit of a simplification on my part. There is also tools such as Cython and numba (JIT) which use various techniques to compile Python code btw. But I am generally in favour of switching to a high performance language or writing in C++ and then importing in Python at that point, personal preference again... Interesting to read a…

> You are quite right it is not just compilation that sets Python apart from C++, that was a bit of a simplification on my part. That's how I understood your post. Sorry if my post came off as a correction - it was not meant as such, but as a question (not specifically about Python or C++): How does a language benefit from not having the option to compile it? What restrictions does the requirement to be able to produ…

It makes debugging and R&D really easy.

For example say I have a script:

  data = slow_computation()
  metrics = produce_metrics(data)
Now later I want to play with some metrics and experiment a bit I can do that in the interactive shell (running with python -i file.py will run the script as normal but leave a python interpreter open at the end with all the variables kept alive)

When I am happy with my experimentation results, say, I have found something interesting about the data and written a new function cool_metric(metrics) I can commit it to the script at the end

  data = slow_computation()
  metrics = produce_metrics(data)
  cool_metric = cool_metric(metrics)
There's also the ability to drop in breakpoints where you can then have the full python shell available, can break out of the debugger into an interactive shell if you want, or can modify a variable and then continue the script as normal. I think you can do that with GDB for instance but it's not quite as flexible if I am not mistaken?

so if I have

  def some_buggy_function(args):
      data = analyse(args)
      breakpoint()
      new_data = further_analyse(data)
that can be quite powerful in making debugging easy

Re: Breaking up with Python

#136

Post by haaryball »

For me the greatest pain point with Python is that you are never sure about what any line of code does, because basically everything can be redefined.

It might not be a big issue in a small script, but as soon as you get a biggish codebase, with mixins or magical utilities written a couple of years ago by a developer who in the meantime left, it takes hours just to track the control flow in the mess of patched methods, dunder stuff calling nested supers, etc.

To say nothing of big frameworks like DRF. There isn't even an agreed-on way to mark methods that are overridden from a base class.

Plus, simply changing the order of imports can violently change the semantics of the exact same code.

A fetish for hidden magic, state everywhere, and basically global coupling of code vastly override the supposedly simple syntax: it might be easy to read, but it is impossible to understand, locally.

Re: Breaking up with Python

#137

Post by pdonis »

pdonis wrote: post #70
atomicnumber3 wrote: post #35

I don't disagree with any of his points, actually, and agree with almost all of them. The standard library has some holes - though I think that's true everywhere. I don't know that eg Ruby or java don't have holes either. I do think the packaging Story in python is nuts. Why does gem just work for Ruby but python's story is such a disaster? Though imo my modern advice is "just use poetry and ignore everything else".…

> I do think the packaging Story in python is nuts. That is one of my three big gripes with Python. The other two are the horrible way the 2 to 3 transition was managed and the GIL. But none of those has driven me to switch to another language, nor do I expect it to. Go seems to be this author's alternative of choice; perhaps if my one goal in life was to write a production network backend without using any dependenc…

> write a production network backend without using any dependencies

In this regard, I find it interesting that the following is currently on the HN front page:

https://news.ycombinator.com/item?id=34179426

TL/DR: Go's network sockets set TCP_NODELAY by default, which is, the article argues, a very bad idea.

Re: Breaking up with Python

#138

Post by pdonis »

dijit wrote: post #41

my friend made a write up before about the inadequecies of python: https://dustri.org/b/friends-dont-let-friends-write-producti... Personally, I’ve been pretty happy with python, I think it works wonderfully as a glue language (like bash); I.E: you shouldn’t write a lot of it, you should use it for plumbing. Its fantastic for that.

> my friend made a write up before about the inadequecies of python

To be honest, this seems like even less of a balanced criticism than the article this overall discussion is based on. A more balanced summary of the valid points might be: "Python has issues that you will probably trip over in certain kinds of applications". Which is true of every language.

> I think it works wonderfully as a glue language

It also works very well as an application language, just not for all types of applications. Which, again, is true of every language.

Re: Breaking up with Python

#139

Post by kcartlidge »

justsomehnguy wrote: post #133
kcartlidge wrote: post #97

Earlier quoted context omitted.

> In my experience PowerShell fits well as a toe-dipping language. Ugh. Sorry, I've not really got anything constructive ( destructive? ) to say in support of that other than (a) in practical terms it isn't a transferrable skill beyond Windows, (b) the Naming-Conventions-OfThings is both awful and verbose, and (c) I've never had a use case where more than a handful (at most) of my fellow devs would be happy to work w…

a) thats only for modules designed to interact with Windows features . Sure, Get-ADComputer doesn't work on Linux, but... by default Python doesn't work with a ton of things which are available through the wast library of Python modules . Same deal with PS, you can't interact with Snipe-it or Netbox by deaful... but there are modules for that.[0] Basics works everywhere. In my personal experience I often found myself…

I appreciate the response; as I say, YMMV. I did feel a little misunderstood at the end of that response, though, so I'll clarify.

> explicitly stating things you don't kno2 or understand

I've done Windows development since 3.1 (and .Net since 2001) so in that time I've written a lot of PowerShell. I'm not offering uninformed second-hand opinions.

For (a) I'd argue that the lack of adoption outside Windows makes it de-facto not really a transferrable skill, even though it does run elsewhere. For (b) so what if it is easy to autocomplete? It doesn't make it any less ugly/verbose. For (c) yes, that was exactly my point. Stuff needs to be maintainable, and if fellow devs have other more familiar tooling then using that tooling is usually more appropriate.

If PowerShell is for you, great. I don't feel the need to convince you otherwise; in your situation maybe it is. But sometimes a difference of opinion is just that - a difference of opinion, and not ignorance of the subject matter.

Re: Breaking up with Python

#140

Post by soganess »

c7DJTLrn wrote: post #125
zeroCalories wrote: post #33

People joke that Python programming is 'pip install solution', but it's honestly not too far from the truth. Until Go, Rust, or whatever fancy new language can match the wealth of well maintained libraries that Python has, I don't see it ever getting replaced for the quick scripting that the author talks about.

Author here. The Go ecosystem is extremely rich. Are you familiar with it? I would say it is at least as rich as Python's, if not more.

I'd like to see the receipts on your statement.

Easy examples I use every day: ML and Quantum Computing libraries.

There is a depth to the Python ecosystem that can't be matched anywhere else.

Honestly, I'm sure I will get a ton of flack for this, but I really dislike Python. I use it every day and have for years and not only has it failed to grow on me (like most languages do), I've learned to dislike it more with each year. That said, I'm locked in. Outside of Python the libraries available are abandoned research projects or hobby tools, at least when it comes to my areas of focus.

Post reply on HN