Live data from Hacker News

“Python's batteries are leaking”

pyfound.blogspot.com

261–270 of 420 posts

Re: “Python's batteries are leaking”

#261

I like python, its a nice simple language that you can use to pump out a proof of concept real quick with little hassle, but for full on production I avoid it. But I think this is a larger trend in programming, in my opinion the majority of programmers are super lazy. Everyone is in a mad dash to get the cool new thing out so they just slap a bunch of dependencies on it and damn the consequences of developer debt dow…

"Laziness" is a terrible explanation for broad system characteristics, such as the fact that many software people end up building messy MVPs. If an explanation boosts your ego, there is a decent chance it is flawed or incomplete.

You can have a messy MVP, I always start with some half baked MVP. But if you roll with that as your product you're shooting yourself in the foot a million times down the line. MVP should be the discovery phase and then after you know and understand the problem you should just build the thing from scratch. It saves you a bunch of pain down the road. If it took you 1 or 2 months to build the MVP it will take you half or less that time to recreate it from scratch. You understand the problem completely and most of it will be you just retyping from memory say in data oriented design rather than object oriented. So really there is not too much effort required after you have defined the problem and solution. So yeah, it has nothing to do with ego, it's just a reality of working on projects other people's companies will be relying on.

Re: “Python's batteries are leaking”

#262
post #192

I like python, its a nice simple language that you can use to pump out a proof of concept real quick with little hassle, but for full on production I avoid it. But I think this is a larger trend in programming, in my opinion the majority of programmers are super lazy. Everyone is in a mad dash to get the cool new thing out so they just slap a bunch of dependencies on it and damn the consequences of developer debt dow…

Python was one of the first languages I learned. Recently started using Go a little, and it does feel better but it just takes longer for me to write (probably because it's newer to me too). At work, people want things quickly. I'd love to be able to spend my time writing things properly in Go, but it's just not as quick and easy as Python is.

This is entirely anecdotal, but my experience has been that many people espouse the speed of Python development when in fact they put out sloppy, non-production ready code that needs a ton of extra review, effort, and sprints to get up to snuff. I often find myself producing higher quality, production ready Python code than those who cling to it like a safety blanket and complain non-stop about how "slow" languages like C#, Go, and TypeScript make them.

On top of that, I believe that I am able to produce production ready code in other languages even faster than Python! Particularly when it comes to doing refactors for exploratory architecture in early POC/MVP; love the tooling assists so I'm not drowning in "is not a functions" and other dumb stuff while I'm working on hammering out interfaces, abstractions, and other structure.

Granted, I have almost certainly not worked with the best Python programmers, or the best programmers that happen to only use Python to put it another way. But looking at Python itself, the languishing ecosystem and stdlib, and every large OSS Python project, what does that even look like?!

So, I would say that yes it has a lot to do with familiarity and comfort... I'm very suspicious of people who insist on using Python and have little familiarity with anything else.

Re: “Python's batteries are leaking”

#263

Earlier quoted context omitted.

What they need is an Apache Commons or Guava of Python. They're both defacto part of the standard java library.

I try to avoid Guava because they have a habit of making incompatible breaking changes, and because so many libraries depend on it, it's likely to cause version conflicts. The way Apache Commons puts the major version in the package is much better in that regard.

I have not experienced this running guava 16-23 in various apps. Maybe incompatible but they're good about security patches for old versions. I have never seen a version conflict between guava releases

Re: “Python's batteries are leaking”

#264

Wow this is not the conduct I expect from a language creator. I don’t care if you’re Albert Einstein. Humility and being able to take criticism is far more admirable to me.

I think he was probably frustrated by Python 2 support. If twisted has 50% userbase in Python 2 that don't upgrade and requiring more volunteer time on Python 2 just handcuffs language development on Python 3. Python 2 has been deprecated for long time and if people still want free Python 2 support I think it's just indigenous to the language contributors to spend their already constraint free time on Python 2.

Re: “Python's batteries are leaking”

#265
post #84

Earlier quoted context omitted.

The problem with third-party libraries is that it's impossible to know which ones are "standard" and which ones are copycat hobby projects in various states of disrepair. And in the worst case you can pick a library, get a day or two into using it, and discover it has a show-stopper limitation. I recently hacked together some Python to process MIDI files. Should I have used this: https://pypi.org/project/MIDIUtil/ or…

In a perfect world everything would be in the stdlib, everything would be well-integrated, everything would serve every use case, and everything would be well-maintained by engaged and motivated maintainers. For some kinds of libraries, you can sacrifice a whole bunch of those constraints and still have it make sense to host it in the stdlib. I'm fine if the JSON library is slow or inflexible if it covers a bunch of…

To add to net/http not being very competitive performance wise within Go's language peer group, the stdlib file system walking methods took liberties in baking in assumptions without escape hatches that nerf the performance unnecessarily for a lot of heavy-lift use cases. Go definitely has a few shortcomings in the otherwise fantastically useful stdlib.

Re: “Python's batteries are leaking”

#267
post #18

Earlier quoted context omitted.

You want pyca/cryptography. The last thing in the world you want is a standard crypto library that no experts are enthusiastic about maintaining. Golang had an unfair advantage here, because the language team included cryptography engineers. It would be weird if most languages had the same kind of crypto in their stdlibs. I think there is in general nothing wrong with a language ecosystem where key parts of the whole…

The problem with third-party libraries is that it's impossible to know which ones are "standard" and which ones are copycat hobby projects in various states of disrepair. And in the worst case you can pick a library, get a day or two into using it, and discover it has a show-stopper limitation. I recently hacked together some Python to process MIDI files. Should I have used this: https://pypi.org/project/MIDIUtil/ or…

You can have curation outside the standard library, without incurring all the costs of moving libraries into the standard library.

Re: “Python's batteries are leaking”

#268

Earlier quoted context omitted.

I'm glad Windows 10 has OpenSSH now: > Microsoft Windows [Version 10.0.17763.437] > (c) 2018 Microsoft Corporation. All rights reserved. > > ssh -V > OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

I've found the built-in Windows 10 ssh client has trouble with tunneling, so I still use the ssh client included with git.

netsh interface portproxy add v4tov4 listenport=8001 connectport=80 connectaddress=1.1.1.1

Re: “Python's batteries are leaking”

#269

> Brown called out the XML parser and tkinter in particular for making the standard library larger and harder to build, burdening all programmers for the sake of a few Tkinter needs to go...There is very little reason except for the legacy ones, why it needs to be there still...

If Tkinter goes, then Python is dead to me. I use Python for small dep-free single file GUIs for small projects meant to be used by people who have Python installed but can't be bothered to go through an installation checklist. Tkinter is great for that and is the only reason I bother using Python for anything.

Pardon me, but why wouldnt you be able to just run an old python if tkinter came out of the stdlib, or even just package it with whatever you are distributing?

Re: “Python's batteries are leaking”

#270
post #248

Earlier quoted context omitted.

> If I fight the battle to get centralized IT to install Python, I now have a guaranteed set of standard libraries as well. I'm never going to get permission to install anything other than default. Ever. Can you explain this more? What kind of place do you work? I've had some experience with large, bureaucratic companies, but nothing ever so far as "you can't install any other libraries."

Where I work, there is currently a push to get python on the computers that manage physical equipment operation. These computers are not allowed to connect to the internet, and have extremely limited connectivity to the rest of the business network. Installing anything new on them requires risk assessments like you wouldn't believe, since the consequences of malicious code could easily hit 10s of millions of dollars…

Maybe a stupid question but can you ship code on the machine? If you can, what is stopping you from including the source of the library that you're trying to 'install'?
Post reply on HN