Live data from Hacker News

Python Is Eating the World

zdnet.com

521–530 of 993 posts

Re: Python Is Eating the World

#521

Earlier quoted context omitted.

The only problem with that is it's hard to keep the dependencies up to date. Pip-tools solves this problem.

Why do you want to update your dependencies if they work? Isn't the whole point of dependency management to avoid using different versions of dependencies than the ones they have been tested on?

Security fixes, performance enhancements, new features. There are many reasons. But the point is you update in a controlled manner. You don't just push the latest version of everything out on to prod, but you also don't keep pushing the same version that worked a year ago.

Re: Python Is Eating the World

#522

Earlier quoted context omitted.

I've always seen it like this: Not everyone builds reproducible software with Python (or in general) and how you handle dependencies can vary. Python leaves it open how you do it: globally installed packages, local packages, or a mix of both. In the end, it needs to find the import in the PYTHONPATH, so there's no magic involved, and there are multiple robust options to choose from. So instead of bashing Python for n…

> Python leaves it open how you do it Are you saying “There’s more than one way to do it”?

Yes :-) It's fair to say Python's approach to dependency management doesn't follow the Zen of Python, but there's a simple way documented in the tutorial: https://docs.python.org/3/tutorial/venv.html

Re: Python Is Eating the World

#523
I like a lot of things in python, but unfortunately, everytime I happen to use anything which uses python, there's a good chance it won't work on my environment. And so I'm very surprised how python can be so successful if it doesn't actually work. I literally fix my env for some tool A, only to make it incompatible with tool B. And I can't believe I'm alone.

Re: Python Is Eating the World

#524
post #471

Earlier quoted context omitted.

Isn't it also just as much about Python is having it's day, granted a day long in the waiting but many langs go through this (Ruby, PHP) and then it tapers off and the next language has it's day. Probably Go will be the next hotness in 5 years.

> Probably Go will be the next hotness in 5 years. I think it will be difficult to grow a large ecosystem for a language with very poor FFI performance [0] in the long run. Golang's poor FFI performance is the number 1 reason I wouldn't use it for my own projects. [0]: https://github.com/dyu/ffi-overhead

People gripe about the strangest things.

After using Go almost exclusively for about 18 months I have had to interface with existing C libraries exactly zero times.

Re: Python Is Eating the World

#525

Earlier quoted context omitted.

I think ruby is alive and well for a lot of startups. I do think it is being squeezed on three sides though. * From javascript. If you have a app like front end, you are going to use js. Why not have the whole stack be js and have your developers use only one language. * From python for anything web + data science. Again, why not have your whole stack be in one language? * From lack of hype. Rails is still evolving,…

"From JavaScript" also includes another side: When your frontend is in JS, your backend can be a simple REST API. And building a REST API requires much less framework than building a server-side-rendering webapp does, so it's tempting to use Go or Rust or whatever you like.

Agreed. I still think that ruby is great for jamming out an API (far better in terms of development speed than go or rust) but a lot of the great gems that can speed up development assume server side rendering. That plus the fact that go/rust/whatever are probably more "interesting" and faster (at runtime) than ruby is an additional obstacle (for ruby!).

Re: Python Is Eating the World

#526

Holy Crap! What a lot of irrational, hyperbolic hate for Python. I think everybody should spend their first couple of years working in Fortran IV on IBM TSO/ISPF. No dependency management because you had to write everything yourself. Or maybe [edit: early 90's] C or C++ development where dependency management meant getting packages off a Usenet archive, uudecoding and compiling them yourself after tweaking the config…

I think it's pretty disappointing that most of the top comments don't talk about the interview with Guido himself over the history of Python. Tangentially related discussion is one of the appeals of HN but I think it's a bit out of control here.

Well in just glad this is the top comment, as Python really is taking over the world for a reason.

And of all the bugs I have written in recent memory, not one came down to a lack of static typing. They were due simply to logic errors, flawed assumptions, misunderstood requirements, and good old race conditions. The static typing zealots like to think if it compiles is must be perfect, however this is a mirage. Unit tests in Python can compensate quite well for lack of static typing.

Re: Python Is Eating the World

#527

Holy Crap! What a lot of irrational, hyperbolic hate for Python. I think everybody should spend their first couple of years working in Fortran IV on IBM TSO/ISPF. No dependency management because you had to write everything yourself. Or maybe [edit: early 90's] C or C++ development where dependency management meant getting packages off a Usenet archive, uudecoding and compiling them yourself after tweaking the config…

[deleted]

Re: Python Is Eating the World

#528

Earlier quoted context omitted.

It's not that bad if you use the right tools. The two main options are an all-in-one solution like poetry or pipenv, and an ensemble of tools like pyenv, virtualenvwrapper, versioneer and pip-tools. I prefer the latter because it feels more like the Unix way. Why should Python have some "official" method to do this? Flexibility is a strength, not a weakness. Nobody ever suggests that C should have some official packa…

> Flexibility is a strength, not a weakness. "There should be one-- and preferably only one --obvious way to do it.": https://www.python.org/dev/peps/pep-0020/

They almost rescinded that in PEP 357 and ultimately did so in PEPs 468/469. PEP -23 updated the standard library to match, but not until 3.9.1.a. Until then, beware the various blog posts you'll find on Google talking about this concept on 1.x.

Re: Python Is Eating the World

#529

Earlier quoted context omitted.

Agreed. I really don't understand all these buckets filth being poured on Python in this thread. It's a first language I worked with in my life that just clicked with my brain and doesn't just drain me. I would take a Python job over a Java/C/C++/Go/Rust any day. There's some languages that could pull me away from Python (Nim, Crystal) but they're nowhere popular enough to move wholesale to them.

I've worked in so many languages and environments in my career and Django/python/virtualenv has to be one of the least painful. I tried Rails which is very similar but feels "inside out", a good friend of mine loves Rails and hates Django and has the exact same feeling about Django. That's kind of my point, you may like other environments better, such as React/Node/NPM but that doesn't mean Python is a horror show. I…

How stable is python to run a full trading / quantitative algorithm on?

I feel there are benefits for every language. I am just curious if super stable and scalable conditions can be met on python.

Re: Python Is Eating the World

#530
post #495

Earlier quoted context omitted.

Famous one: > There are two kind of languages: the ones everybody hates, and the ones nobody uses.

Slightly wrong. Here's the original: "There are only two kinds of languages: the ones people complain about and the ones nobody uses." Bjarne Stroustrup's FAQ: Did you really say that?. Retrieved on 2007-11-15.

This is spot on. In my current workplace we use Clojure, and Clojure has many of the same problems in package management as Python does (no lockfile, no easy way to create reproducible builds, no way to declare range of dependencies unless you use version pin, etc. etc.).

However, I never saw any complaints about Clojure package management in any topic about Clojure here.

Post reply on HN