Python Is Eating the World | Hacker News Reader

Python Is Eating the World

zdnet.com

879 pointsgilad957 comments

Python has a lot of problems that really slow down development, but they are all fixable.

The biggest issue, in my opinion, is in dependency management. Python has a horrible dependency management system, from top-to-bottom.

Why do I need to make a "virtual environment" to have separate dependencies, and then source it my shell?

Why do I need to manually add version numbers to a file?

Why isn't there any builtin way to automatically define a lock file (currently, most Python projects just don't even specify indirect dependency versions, many Python developers probably don't even realize this is an issue!!!!!)?

Why can't I parallelize dependency installation?

Why isn't there a builtin way to create a redistributable executable with all my dependencies?

Why do I need to have fresh copies of my dependencies, even if they are the same versions, in each virtual environment?

There is so much chaos, I've seen very few projects that actually have reproducible builds. Most people just cross their fingers and hope dependencies don't change, and they just "deal with" the horrible kludge that is a virtual environment.

We need official support for a modern package management system, from the Python org itself. Third party solutions don't cut it, because they just end up being incompatible with each other.

Example: if the Python interpreter knew just a little bit about dependencies, it could pull in the correct version from a global cache - no need to reinstall the same module over and over again, just use the shared copy. Imagine how many CPU cycles would be saved. No more need for special wrapper tools like "tox".

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 not shoveling down an opinion on you, it's up to the developers to choose which tools they want to use.

If they don't choose one and are unable to freeze their dependencies, it's not a Python problem, but IMO lack of skill and seniority.

You can have both: provide a sane default for most users and allow people to roll their own.

The reason why Python gets extra criticism for this is because it likes to tell people that there should be one obvious way to do it and that it comes with batteries included yet it's dependency management system is just crap and doesn't follow that at all.

> Python leaves it open how you do it

Are you saying “There’s more than one way to do it”?

The solution to this is Poetry. https://poetry.eustace.io

It's good. Projects should use it.

> curl ... | python

Ah goddamnit.

868 lines, including os.rmtree calls and stuff.

Also installable via pip, but... "not recommended", and:

    [RuntimeError]                                                            
    Poetry was not installed with the recommended installer. 
    Cannot update automatically.

I agree. Most of the issues the parent mentions have been solved with poetry and pipenv.

And if you need "to create a redistributable executable with all your dependencies". You can either use pyinstaller [0] or nuitka [1] both of which are very actively maintained/developed and continually improving.

[0]: https://github.com/pyinstaller/pyinstaller [1]: https://github.com/Nuitka/Nuitka

Poetry is definitely an improvement.

Anyone considering it for production usage should note that package installs in the current versions are much slower than pip or Pipenv. This might affect your CI/CD.

Could you give some details as to why it's better than other more commonly used tools (pip, venv, ...)?

Looking at the home page it's not immediately obvious to me. For example, the lock file it creates seems to be the equivalent of writing `pip freeze` to the requirements file. I see a quick mention of isolation at the end, it seems to use virtual environments, does it make it more seamless? What's the advantage over using virtualenv for example?

Thanks! Didn't realize this existed.

NO THANKS

Python's dependency hell is what made me first look at Julia. I develop on Windows (someone has to :) ), and it was just impossible to get all of the numerical libraries like pydstool, scipy, FEniCS, Daedalus, etc. playing nicely together... so I gave Julia a try. And now the only time I have issues getting a package to run are Julia packages which have a Python dependency. Python is a good language, but having everything in one language and binary-free is just a blessing for getting code to run on someone else's computer.

Julia really is nice in this way. It is nice to see the package manager that actually works for me unlike a lot of what I try with pip.

Visual Studio Code brings some tooling to make it easier to work with code running in Docker container.

>Most people just cross their fingers and hope dependencies don't change

Is there anything wrong with pip freeze > requirements.txt and then pip install -r requirements.txt ? This would install the exact versions

I've had a good experience with pip-tools (https://github.com/jazzband/pip-tools/) which takes a requirements.in with loosely-pinned dependencies and writes your requirements.txt with the exact versions including transitive dependencies.

If you have "foo==0.1" installed, and foo has the dep "bar~=0.2" (current vers of bar 0.2.1).

Then bar releases version 0.2.2

So your deps want bar 0.2.1, but foo now wants bar 0.2.2

This breaks your pip install.

EDIT: there are a few other gotchas (please respond to this post if you know of any more)

e.g. from https://medium.com/knerd/the-nine-circles-of-python-dependen...

"If two of your dependencies are demanding overlapping versions of a library, pip will not necessarily install a version of this library that satisfies both requirements" e.g. https://github.com/pypa/pip/issues/2775

This is what I've always done. Develop using a few dependencies, freeze, continue development with reproducible builds. It has always included the sub-dependencies in the list so, as far as I can tell, this works great for that case...

It's not functional for library dependencies, where you still need to manage the setup.py instead. Only useful for end-user application dependencies.

I think he is referring to indirect dependencies

It catches way too much. IPython, black and the testing libraries are _not_ a part of my actual dependencies and shouldn't be installed in production. A good UI for a dependency manager at the very least distinguishes between dev and production context, and ideally lets me define custom contexts.

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

saddened to see this poorly constructed comment berating python at the top of this thread. the author seems to have some personal issues with the language given the generally frustrated tone of the comment. the entire comment could have just been 1 line "We need official support for a modern package management system, from the Python org itself." which would be consumed as constructive feedback by all readers with the right context. but somehow the author chooses to "vent" adding unnecessary drama to something that does not get in the way of writing high quality production grade python apps (general purpose, web, ai or otherwise)

there is no language that is devoid of shortcomings - so to any new (<3 yrs exp) python users, please ignore the above comment entirely as it has no bearing on anything practical that you are doing/will do. and all experienced python users know that there are ways to work around the shortcomings listed here and beyond.

this is my psa for the python community!

> the entire comment could have just been 1 line "We need official support for a modern package management system, from the Python org itself."

I personally would consider this to be a strictly worse comment because it does not go into detail about what’s lacking like the parent comment does.

Package management isn't a personal issue. Deploying python applications alongside their dependencies is far more difficult than it needs to be.

>there is no language that is devoid of shortcomings

So we should just silence all criticism like a dictatorship?

>as it has no bearing on anything practical that you are doing/will do.

Are you saying no python user has to deploy their application ever? If that's what you really mean then your comment is just pure trolling.

> the author seems to have some personal issues with the language given the generally frustrated tone of the comment

What "personal issues" do you think the author has? The frustrated tone comes from the frustrations the author explicitly outlines; unless you think this shouldn't be so, you are turning this into an ad-hom.

> the entire comment could have just been 1 line "We need official support for a modern package management system, from the Python org itself."

Why? because you don't appreciate the detail on why we need such a thing? These issues certainly get in the way of producing production apps; not in the sense that they make it impossible, but they make the process harder and slower than it needs to be.

How about you address what was invalid in the comment instead of asking to ignore it

I actually quite liked that post. I use python maybe once a year or less, and don't enjoy the experience. That post distinguished some of the details which in my rare usage I see simply as a gloopy mess.

Once again python is a great language, but the language itself is not the core issue with python

It is funny - half of the real desire/need for containers comes back to these sorts of issue with both node and Python. And then they bring in their own different challenges.

I have been programming with node for the last 3 years and I never had any dependency issues with node (at least for 3rd party dependencies). I cannot say that with python that requires using some tool be it docker or virtualenv to isolate them from the already installed ones.

Node's dependency managers npm/yarn just copy the versioned dependencies from their cache folder into the local node_modules folder and remove transitive dependencies duplicates when possible by flattening them into node_modules.

I understand what you are saying but "Python has a lot of problems" is not really a list of "only" dependency management issues.

Once your project is setup, dependency management is what you do once in two weeks perhaps. Rest is just writing code.

Having such a basic part of a programming language be awful is inexcusable. It's not just that it takes a lot of time; even if it took no extra time, you're still wasting extra space on your computer, risking breakage on external updates, and compromising security because you can't even tell what code you're running.

Pipenv has felt to me like a pretty solid solution. It's not perfect but it's a lot better than the other options.

Last time I gave it a go, I found it was pretty strongly welded to virtualenv, rather than using Python's own (much less problematic) venv. I came away less than enthused as a result.

(To be fair, modifying it to use venv is... non-trivial).

Pipenv has a good approach to management, similar to npm, but the implementation is buggy. It gained popularity by being recommended very early on in the official python documentation while being misleadingly advertised as production-ready.

If you look at the issues section in its github repo, you'll see that there are some pretty basic bugs there which are very annoying or disruptive. Moreover it seems the author has almost left the boat and a handful of contributors have to tidy things up.

Just to illustrate my point. I think a package manager that takes a few minutes to install a single tiny package, or don't prevent you from adding non-existing packages (e.g. spelling mistake), or doesn't let you install a new package without trying to upgrade all other packages isn't really production-ready. These are known issues since November last year.

It is not as good as Poetry.

from poetry docs: https://github.com/sdispater/poetry/blob/master/README.md#de...

Let's take an example:

  pipenv install oslo.utils==1.4.0

will fail with this error:

  Could not find a version that matches pbr!=0.7,!=2.1.0,<1.0,>=0.6,>=2.0.0

while Poetry will get you the right set of packages

Is there a model dependency management system for some other language that addresses all these issues?

Dependency hell is everywhere.

> Dependency hell is everywhere.

Excuse me, but as a long time Python user I have to disagree. I started using Rust two years ago and Rust’s dependency managment is easily the best thing I ever saw (keep in mind that I didn’t see everything, so there is a chance there are better things out there).

The project-/dependency-manager Cargo¹ is more “pythonic” than anything Python ever came up with and where others mumbled ”dependency hell is everywhere” the Rust people seem to have thought something like: ”there must be a way to do this properly”.

The whole thing gives me hope for Python, but angers me everytime I start a new python project. Poetry is good, but there should be an official way to do this.

It saddens me to see, that some people seem to just have given up on dependency managment alltogether and declared it unsolvable (which it is not, and probably never has been).

¹: https://doc.rust-lang.org/cargo/index.html

Rust's cargo, JS's yarn and the grand daddy of them all Ruby's bundler address all these issues. Even newer versions of Gradle support a workflow where you specify the versions you know you want and just on everything else, including transitive dependencies, down.

Python is uniquely ill-suited for dependency management compared to many other languages. For some reason dependencies are installed into the interpreter itself (I know what I just said is very imprecise/inaccurate but I think it gets the point across).

In JS, which also has a single interpreter installed across the system (or multiple if you use nvm), the packages aren't installed "directly" into the interpreter, which removes the need for things like virtual-envs, thus making life a lot easier. I wish Python did something like this.

That being said, pipenv is making things easier. However, I think pipenv is a workaround more fundamental problems.

It's not a "model," but if you're able to 1) use fewer dependencies 2) use stable dependencies 3) use dependencies with fewer dependencies, it helps with dependency hell. I've even made commits to projects to reduce their dependency count.

I find rust with cargo and go with go-modules to be pretty nice to work with.

Does it have to be?

I have found that I would rather code my own versions of some libraries so I have control over it. Even if there is some extra long term maintenance and some up front dev costs, it's paid off already a number of times.

maven for java

Solution ?

Use Nix.

> nix-shell -p python3Packages.numpy python3Packages.my_important_package

It solves every problem you quoted before.

Or something that works with PyPI directly https://news.ycombinator.com/item?id=20672329

Docker is one option. Don't worry about sorting out that mess, just clone the whole operating system. sigh

> The biggest issue, in my opinion, is in dependency management. Python has a horrible dependency management system, from top-to-bottom.

Yup, I love Python over my current language in my job(JS/TS).

But I really dislike handling conflicts using pip, requirements.txt and virtualenv.

So much so that I will take JS node_modules over it.

Dependency management system is a definite problem but making executables is downright horrible or even impossible.

I agree that builtin tools suck for dependency management.

However a lot of the issues that you mentioned (such as lock file and transitive dependencies) can be handled by pipenv, which should be the default package manager

Poetry is way way better imho. https://poetry.eustace.io

Portage solves a few of these. http://michael.orlitzky.com/articles/motherfuckers_need_pack...

Python was a scripting language. All those problems are caused by people using it like something it isn't. Python has way outlived it's usefulness and it's about time we move on to something better.

Do you think that language exists right now? I can't think of a good alternative.

I recently found this: https://dephell.org/docs/

I seems to have some neat functionality wrt dep handling (and I'd never really heard of it before).

The virtualenv thing just galls me. Sure, pipenv aped rbenv - appropriately, I might add - but until they supplant virtualenv as the recommended way to have separate environments, I'll pass.

> Why isn't there a builtin way to create a redistributable executable with all my dependencies?

There is and it's called docker. The other issues could indeed be fixed with something like poetry.

.NETs solution to this was the project file, a configuration file that lists the compiler version, framework version, and dependencies (now including NuGet packages and their versions).

> The biggest issue, in my opinion, is in dependency management. Python has a horrible dependency management system, from top-to-bottom.

I agree, although a lot of it has to do that there's so much misinformation about the web, and many articles recommending bad solutions. This is because python went through many packaging solutions. IMO the setuptools one is the one that's most common and available by default. It has a weakness though, it started with people writing setup.py file and defining all parameters there. Because setup.py is actually a python program it encourages you to write it as a program and that creates issues, setuptools though for a wile had a declarative way to declare packages using setup.cfg file, you should use that and your setup.py should contain nothing more than a call to setup().

> Why do I need to make a "virtual environment" to have separate dependencies, and then source it my shell?

Because chances are that your application A uses different versions than application B. Yes this could be solved by allowing python to keep multiple versions of the same packages, but if virtualenv is bothering you you would like to count on system package manager to keep care of that, and rpm, deb don't offer this functionality by default. So you would once again have to use some kind of virtualenv like environment that's disconnected from the system packages.

> Why do I need to manually add version numbers to a file?

You don't have to, this is one of the things that there's a lot of misinformation about how to package application. You should create setup.py/cfg and declare your immediate dependencies, then you can optionally provide version _ranges_ that are acceptable.

I highly recommend to install pip-tools and use pip-compile to generate requirements.txt, that file then works like a lock file and it is essentially picking the latest versions within restrictions in setup.cfg

> Why isn't there any builtin way to automatically define a lock file (currently, most Python projects just don't even specify indirect dependency versions, many Python developers probably don't even realize this is an issue!!!!!)?

Because Python is old (it's older than Java) it wasn't a thing in the past.

> Why can't I parallelize dependency installation?

Not sure I understand this one. yum, apt-get etc don't parallelize either because it's prone to errors? TBH I never though of this as an issue, because python packages are relatively small and it installs quickly. The longest part was always downloading dependencies, but caching solves that.

> Why isn't there a builtin way to create a redistributable executable with all my dependencies?

Some people are claiming that python has a kitchen sink and that made it more complex, you're claiming it should have even more things built in, I don't see a problem, there are several solutions to package it as an executable. Also it is a difficult problem to solve, because Python also works on almost all platforms including Windows and OS X.

> Why do I need to have fresh copies of my dependencies, even if they are the same versions, in each virtual environment?

You don't you can install your dependencies in system directory and configure virtualenv to see these packages as well, I prefer though to have it completly isolated from the system.

> There is so much chaos, I've seen very few projects that actually have reproducible builds. Most people just cross their fingers and hope dependencies don't change, and they just "deal with" the horrible kludge that is a virtual environment.

Not sure what to say, it works predictable to me and I actually really like virtualenv

> We need official support for a modern package management system, from the Python org itself. Third party solutions don't cut it, because they just end up being incompatible with each other.

setuptools with declarative setup.cfg is IMO very close there.

> Example: if the Python interpreter knew just a little bit about dependencies, it could pull in the correct version from a global cache - no need to reinstall the same module over and over again, just use the shared copy. Imagine how many CPU cycles would be saved. No more need for special wrapper tools like "tox".

There is a global cache already and pip utilizes it even withing an virtualenv. I actually never needed to use tox myself. I think most of your problems is that there are a lot of bad information about how to package a python app. Sadly even the page from PPA belongs there.

I think people should start with this: https://setuptools.readthedocs.io/en/latest/setuptools.html#...

Yes it still has some of the problems you mentioned, but it fixes some others.

Python is the WORST language (except for all the rest)

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 package manager. Instead the developers build a build system for their project. After a while every project seems to get its own unique requirements so trying to use a cookie-cutter system seems pointless.

The virtual env is really the thing that has stopped me from using python. It's a lovely language but the tooling around it needs a lot of help. I'm sure it will get there though. I mean if the js folks can do it, certainly python can.

One thing people overlook with interpreted languages is the environmental impact in terms of extra electricity used.

Remember NOT to jump into Python for your new product if don't know Python. If you are developing for a young startup, have time crunch, then stick to what you know.

IF you do not have a language, or know Python a bit, then pick Python. Here are some of the reasons why I stick to Python (young startup/web APIs):

  - OOPs is not too strict (might give a headache to some folks)
  - Mixins, lambda, decorators, comprehensions - Pythonic ways make me feel productive easily
  - Create a data Model, drop into a shell, import and try things
  - Can do that on a live server
  - Do the same with Controllers, or anything else actually
  - really nothing fancy needed
  - Command line processing, SSH, OS integration, etc. has so many great libs
  - Python Dict someone looks like JSON (this is purely accidental but useful)
  - Debugger support even in free IDE like PyCharm Community Ed is great
  - Integration to a world of services is so easy, even ones you do not commonly see
  - Documentation - many libs have consistent structure and that helps a LOT
  - Really large community, perhaps only smaller than Java
  - The even larger group of people using Python in all sorts of domains from Biotech to OS scripts

What I would like improved in the language would be an even longer list. Every language has a list like that, but when you are focused on being scrappy and building a product, yet making sure that software quality does not take a big hit, Python helps a lot.

> Remember NOT to jump into Python for your new product if don't know Python. If you are developing for a young startup, have time crunch, then stick to what you know.

Are you saying this as a general maxim (don't try to learn a new tech under pressure) or because of characteristics specific to Python, that make it worse in such a situation than any other language/ecosystem?

I know it's only a one off anecdote but two developers in my team who previously didn't know python used it for a small time-critical project and it was a brilliant success.

The main point I am trying to make is that not all of us are language experts. I absolutely know the vital role that language experts play and that we need to solve the issues. But companies need to build in the meanwhile. Python is easier to learn, this is why it is such a popular language in Universities.

I am not a high IQ person to even grip some of the nitty-gritty underpinnings of a language. But should that stop me from building a product?

In the end, I need a language that is easy to pick-up, be productive, has its heart in the right place. A young Python programmer can web scrap easily or plug into Ansible or so many other things. If you know of another language that would make more practical sense and still be easy to pick-up, I would switch.

That's not how you pick a language. See if the field you're trying to program is well supported and has good libraries and pick that language.

Differences in languages themselves, I'm sure you can get used to and is far easier to cope with than lack of decent lib/tool/googleability.

Reading this got me thinking and I wonder if other people feel like me about this, so I'm going to share it. This is not serious, but not entirely unserious...

I try to be a good sport about it, but every time I write python I want to quit software engineering. It makes me angry how little it values my time. It does little for my soured disposition that folks then vehemently lecture me about the hours saved by future barely-trained developers who will ostensibly have to come and work with my code. Every moment working with python (and that infernal pep-8 linter insisting 80 characters is a sensible standard in 2019) increases my burnout by 100x.

I try to remind myself that we're trying to make the industry less exclusive and more welcoming to new developers and "old" isn't necessarily "good" (in fact, probably the opposite), but damn I just don't understand it.

It used to be that I could focus on other languages (Erlang, Nemerle, F#, Haskell, Ocaml, even C++) and sort of balm myself. But now, I can't even overcome the sinking feeling as I read the Julia statistics book that I'm going to be dragged back to Python kicking and screaming in the morning, so why even bother?

And frustratingly: it's one of the few languages with decent linear algebra libraries. And that means it's one of the few languages with good ML and statistics support. So it's very hard not to use it because when you want to cobble together something like a Bayesian model things like PyMC or Edward actually give you performance that's obnoxiously difficult to reproduce.

This is what the industry wants and evidently a lot of people are okay with it, but to me it's misery and I can't work out why people seem to like it so much.

I am about to hit a decade of python experience. I work with it daily, all my major codebases are written in it.

I hate it.

It has an ok object system which is possibly its only redeeming quality. I found Racket about 4 years ago, and any new project that I work on will be in Racket or CL.

I could go on at length about the happy path mentality of python and the apologists who are too ignorant of other people's use cases to acknowledge that maybe there might be some shortcomings.

The syntactic affordances are awful and you can footgun yourself in stupidily simple ways when refactoring code between scopes. Python isn't really one language it is more like 4, one for each scope and type of assignment or argument passing, and all the sytactic sugar just makes it worse.

Not to mention that packaging is still braindead. I actually learned the Gentoo ebuild system because pip was so unspeakably awful the moment you stepped away from the happy path.

Blub blub blub, someone help I'm drowning in mediocrity.

It seems to value my time quite highly, as I can achieve most things more quickly and easily in Python than any other language I know.

Can you be more specific about how it increases your burnout? Is it the language, or someone forcing you to use that linter and settings?

> and that infernal pep-8 linter insisting 80 characters is a sensible standard in 2019

I don't know why 80 characters is a problem. I don't use the linter but I enforce this rule religiously with a couple of exceptions (long strings comes to mind). It forces me to think heavily about the structure of the code I'm writing. If I'm nesting so deeply, something has gone wrong. If I've got a ton of chained methods or really lengthy variables, it forces me to rethink them.

This also has the advantage of being able to put 4 files next to each other with full visibility. Vertical space is infinite, horizontal space isn't. It's probably a good idea to use it.

Disclaimer, I am a data scientist

I feel the complete opposite. I really enjoy working with python over any other language. R does linear models and time series better and matlab has its charm, but overall I prefer python. Python is so easy to read and quick to program in. I am so glad I am not in the Java/C++ world anymore, but I know people in different roles have to deal with different issues.

Re. linting, I'd highly recommend Black with whatever line length you want - it'll reliably reformat your code, and once you lose the urge to reformat while typing it's fantastic. It's like deleting a bunch of useless mental code. And the code reviews are even better: include a linting step (ideally with isort) in CI and you can avoid 95% of formatting comments.

Over-sensitive individuals are hard to please and often unhappy. That's more of a personality flaw than a flaw with the current state of software engineering.

If there's one thing wrong with our profession is a lack of ethics and accreditation - we're essentially letting random people build critical infrastructure and utilities.

We don't have a tooling problem, in fact we have too many tools.

I see so many people (especially on HN) fixating on tools, dissecting programming languages, editors and libraries into their most minute parts and then inevitably finding faults in them, disavowing them and swearing that other tools X, Y and Z are purer and worthier.

If you want to stop hating software and improve your burn out, stop caring about irrelevant stuff.

I know I’m responding to opinion but: developer productivity isn’t one of the pitfalls of Python.

Yes I agree that if you’re using Python for a large scale project involving lots of developers its not the best; but that’s because it doesn’t have a good type system.

You can’t work out why people like it so much because of this misconception. The languages that you gave as examples most definitely do _not_ value your productivity, it values correctness as enforced by a type system and refactoring needed for large projects.

Definitely feel the same.

The way I think about it is that Python is a strong local optimum in a space that has a massively better optimal solution really close by. But it's nearly impossible to get most people's algorithms to find the real optimum because Python's suboptimal solution is "good enough". And the whole software industry (and in some ways, by extension, all of humanity ... to be over melodramatic) is suffering for it.

There is great saying that Python is the second-best language for everything and it might be true. Where Python excels is that you have good-enough libraries and support almost everything. All other languages have some pain points where they shine very brightly in some areas but they have very bad or non-existing libraries and support to other areas.

```--max-line-length=120``` passed to flake8 will switch it to 120. Use another number for a different length.

Things like max line length should be something your org or your fellow contributors decide on, not something dictated to you no matter what the language.

> folks then vehemently lecture me about the hours saved by future barely-trained developers who will ostensibly have to come and work with my code.

It seems you are really complaining about having to write code which is maintainable by others than yourself?

Stop using flake8. The original PEP 8 document doesn't even recommend 80 characters anymore.

Pylint and mypy and black are way more useful.

i fully agree with you. it has a stubbornness about it and not in a good way like the stubbornness you might find in lisp, scheme, and sml derivatives. i have had to write python on only a few side projects, but it was miserable, as you say. not only is the language all over the place and embarrassingly slow, the ecosystem is as well. i tried getting an application someone left when they left running on windows 10, and it was basically a null effort without a complete rewrite, upgrade to 3.x, and upgrading/replacing GUI libraries.

if i had to write python as a day job, i would quit. i have said it before, but python is the new c++, helping people everywhere write brittle, unmaintainable code.

I'm sympathetic that Python is relatively not a great language, but IMHO an 80-character line limit is quite reasonable. It's easier to read on smaller screens, easier to view side-by-side diffs, and tends to force you to break up your code more.

That said, this shouldn't be a lint, it should just be enforced by a formatting tool as a format-on-save setting. It just destroys all the wasted arguments about formatting and the wasted time trying to manually line up code.

Do you think this is at least partly due to one usually being frustrated by your "official" work? Or would you prefer something like Java?

I can imagine other people's code in Python frustrating myself, but if it is only my own code base then Python is a rewarding language for me.

Yeah, I'm a bit sick of Python. We have some internal utilities written in it and while developers could manage all the dependencies and everything, we kept having problems with getting everything working on the machines of our electronics techs.

Gradually pretty much everything has been rewritten in C++ (with Qt GUI framework). Way easier to be able to have a setup program (using free InnoSetup) that just extracts the eight or so DLLs required in the same folder as the EXE and that's it.

We just use Python for a bit of prototyping and data crunching here and there now.

> it's 2019

use an auto-linter - black is what most seem to be using

and stop using flake8/pylint directly, try prospector with sensible --sensitivity

I write python professionally and honestly, who cares about the 80 character limit? Just ignore it! :)

Thanks for posting. I've wondered if it's just me or does anyone else want to leave software engineering because of Python's dominance. There's no arguing against it either because as this thread shows, "I like it for my use case, look at these libraries that let you get X and Y done SOOOO easy, so it must be great for everything."

I don't know why you hate it so much TBH.

It is a language, better than MatLab/R/SPSS, which come before it.

I honestly don't think it is that bad. And they are many people don't care from a programming language perspective, they need to just finish the functionality.

I look at developer surveys sometimes when I'm trying to decide what to learn next. According to the 2018 stack overflow survey, 68% of python users would like to use it again in the future [1].

The surveys never tell me why though. What do people like or dislike about python? I know it has a lot of libraries people love (scikit-learn, tensorflow come to mind)

[1] https://insights.stackoverflow.com/survey/2018/#most-loved-d...

I would rather wish Golang eat the world than Python, just because the practicality of python becomes questionable when performance is key.

In my previous startup in India, I trained unskilled personnel to become decent python developers to work on our product; everything was fine till the product grew exponentially and we had to optimise every nook and corner of it to better serve the customers and save on server bills.

So we had to optimise our application with Cython to meet the demands. So, when training someone to code if we use Python as a language; we should follow up with the disclaimer "You will learn to code faster than most other languages, but you cannot use this knowledge to build something at scale (i.e at-least when budget is of concern, when you are not instagram)".

In comparison, Golang excels in both form and function. It is just as easy to teach/learn as python and doesn't need the aforementioned disclaimer. Web services are a breeze to write and is built for scale.

I understand that there are criticisms against the language design of Go, some are valid and most are just because it was made by Google but none questioning the scalability of Go applications.

I’m really glad to hear someone else voice these frustrations. I’ve really tried to embrace Python and everyone tells me how great it is. I feel like a failure as a developer but I dislike it so much I quit a job, that switched to Python as the primary language, and took a year off from development. I’m pretty much a polyglot as far as languages go but Python riles me.

It sounds like you're bothered by its syntax or lack of sophisticated type system etc. But it's just a tool, not a amusement park.

> why people seem to like it so much?

> cobble together something like a Bayesian model things like PyMC or Edward actually give you performance that's obnoxiously difficult to reproduce

And this, across many domains

Finally, someone typed what I was thinking.

>that infernal pep-8 linter insisting 80 characters is a sensible standard in 2019

So change the limit or disable that check. If someone is keeping you from doing that they're the one who's insisting on 80 characters, not the language. Who uses any linter without making some changes to its default settings?

I was smart and lucky enough to switch from Python to Clojure and from Javascript to Clojurescript. I am not even sure anymore what have I liked about Python back then. I know for sure - those who really like Python probably haven't given a heartfelt try to Clojure, Haskell or Racket.

(and that infernal pep-8 linter insisting 80 characters is a sensible standard in 2019) increases my burnout by 100x

I've yet to encounter a python linter where you can't pick and choose which rules to ignore. This is a first one to go. Annoying PEP for sure, but https://pypi.org/project/black/ almost completely eliminates your issue.

There is a lot of hype and "they are using it too" mentality as well I think. I am working on control software which, if it crashes or even takes a tiny bit too long to issue a command, could cause the company big financial loss. I was forced to do it in python "because everyone else is using python".

Every moment working with python (and that infernal pep-8 linter insisting 80 characters is a sensible standard in 2019)

It's a very sensible standard. There's a reason most books are taller than they are wide. The fact that we have bigger screens now doesn't change it.

it's funny because a few people ended up using python as a prototyping tool to find better approaches to then rewrite in cpp or else. Somehow in that regard it saved them tons of time.

You can configure Pep8/Flake8 to ignore subset of rules. You might wanna look into that. Also, automatically executing it might be your preference, or not.

This is the top comment? Not very useful.

Well in my world, the other language is Java, not Haskell. Alone in this?

Fortran has great linear algebra libraries.

What I find worse about Python than other languages is the lack of tooling and a relatively small collection of libs - many of which are half way done. In a last assignment, we decided Python is at most a hobby language. Python is great for machine learning because most research was conducting using this language, and as such, tooling is available. I would use it at most as an API exposing ML but that's pretty much it.

If only its package management were as easy as its syntax...

I wish pip worked the same way as npm: -g flag installs it globally, otherwise it creates a local "python_modules" folder I can delete at any time. And optionally I can save the dependency versioning info to some package.json...

Instead, pip is a nightmarish experience where it fails half the time and I have no idea where anything is being installed to and I'm not sure if I'm supposed to use sudo or not and I'm not sure if I'm supposed to use pip or pip3, etc.

Here's a simple but less-than-completely-documented way to keep Python package management under control:

1. Don't install anything globally. Don't pip install --user, definitely don't sudo pip install.

2. For each project you want to work on, create a venv. Yes, there are tools for this, but the base venv tool is totally fine. (venv should be included in your Python, but a few distributors like Debian put it in a separate package - install it from them if needed.) Use python3 -m venv ~/some/directory to create a venv. From here on out

3. As a first step, upgrade pip: ~/some/directory/bin/pip install -U pip.

4. Install things with ~/some/directory/bin/pip install.

5. Run Python with ~/some/directory/bin/python.

Slightly advanced move: make a requirements.txt file (you can use .../bin/pip freeze as a starting point) and use .../pip install -r requirements.txt. That way, if you get any sort of package resolution error, you can just delete your venv and make a new one. (Downloads are cached, so this isn't super annoying to do.)

A "project" can either be actual Python development, or just a place to install some Python programs and run them out of the resulting bin/.

(Edit: Yes, I know about activate, see the replies below for why I don't recommend it. With these rules, you get to say "Never ever type pip, only .../bin/pip", which is a good safety measure.)

Use virtualenv. Always.

Python 3 comes with it as "python -m venv". Once in the virtualenv, you don't have to worry about the various pip forms and effects, you can just pio install.

You can get fancier than that of course, but that's what works with stock python, on all OS.

Meanwhile, all the python developers who have started doing any Js work are saying “I wish npm worked as easy as pip/virtualenv”...

It really isn’t that difficult, it’s just different. Different always seems wrong, at first.

Exactly. NPM gets a lot of hate but lockfiles and local install by default is great. The default mode should not be global installation. Also imo virtual environments aren't amazing. Having some mode you have to remember to flip on that changes essentially the semantics of your pip commands seems a little brittle. Tools that work on top of pip and venv like Pipenv or Poetry seem a lot better.

Just use Poetry. https://poetry.eustace.io

This isn't even the start of the problems with pip and pypi. If I install pylibtiff, it embeds a copy of an old libtiff which is binary incompatible with the libraries on my system. I have to build it from source, then it works just fine. But I can't inflict this level of brokenness on my end users.

This applies to many packages embedding C libraries, including numpy, hdf5 and all the rest. There has been minimal thought put into binary compatibility here, meaning that it's a lottery if it works today, or will break in the future.

I couldn't agree more with this. I was forced into doing some UI coding and although I could never full embrace js, the package management aspects (esp having the sane default of not installing packages globally) were definitely superior to python.

That's what virtualenvs are for. Admittedly they're not a perfect solution but the tooling is quite good nowadays.

Use Conda envs!

I agree but is it intentional? Seems like a lot of folks rail about how npm works (not just because of the "micro package" philosophy)

Is there any particular bottleneck towards getting this to work with Python? Would not a simple pip wrapper be enough for the task?

What you are describing is a virtualenv and a requirements.txt file. There are tons of other options for Python that do the same thing.

Packaging is definitely recognized as an issue; e.g. here: https://cecinestpasun.com/entries/where-do-you-see-python-in...

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

I'm not saying Python is perfect, but if it's causing your burnout/destroying your love of programming/ruining software development you seriously need some perspective.

Here's some rational "hate" for Python then.

I just returned to Python for the first time in a little while to collaborate on a side project and ran into a few tricky-to-debug errors that caused a fair bit of lost time. Know what the errors were?

In one case, I was iterating over the contents of what was supposed to be a list, but in some rare circumstances could instead be a string. Instead of throwing a type error, Python happily went along with it, and iterated over each character in the string individually. This threw a wrench into the works because the list being iterated over was patterns, and when you apply a single character as a pattern you of course match much more than you're expecting.

And another one, I typoed a variable name as groups_keys instead of group_keys (or vice-versa, I don't remember). Instead of just throwing an error, Python happily went along with it, used an uninitialized value, and then all the logic broke.

There's entire classes of errors you can cause yourself in Python that aren't possible in stronger, statically-typed languages. For a large project, I'd pick the old and boring Java over Python every time.

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 had to learn Fortran IV for my first job. Am I allowed to hate Python?

Are you assuming everyone complaining here is young, and this is their first language? Consider that maybe they're complaining because they've used older languages they liked more.

Often, not having a feature is preferable to having a feature designed or implemented poorly.

Well I actually feel betrayed...

Python 1.4 was an awesomely simple programming environment and I pretty much immediately fell in love with it. Then features were added. Now it is a whole home improvement store full of kitchen sinks.

I think that programming is a sort of theological process. Popular languages attract ideas. Unfortunately, in the case of Python, those ideas were not effectively filtered and now we have an expression of as many ideas as can possibly fit. The ultimate design by committee...

I suspect that the recent excitement about assignment expressions is really a kind of straw that broke the camels back. The problem isn't just this one feature, it's the sum of them.

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.

I cut my teeth in FORTRAN IV (on RSX-11M). I lived through the archie days of uuencoded fragments to build my C environment, supplemented by DECUS tapes. Those were good old days.

I use Python 3 these days for a lot of stuff. It's pretty good.

These are better days. We all have complaints, but on the whole, things are not too bad.

I think for the most part that when nothing meets your expectations, it may be that your expectations need to be adjusted.

People don't realize what a revelation Python 1.x was back in the day. Around 97 or so I was tasked with porting a giant mathematica program for calculation diffraction grating efficiencies into something which ran open source (there was no free mathematica engine for running scripts pack then). Back then, that meant either C or Fortran. Sure, stuff like Perl existed; nobody thought of it as a real interpreter that could be used to construct complicated things any more than Awk was. When I realized Hugunin over at Livermore had done lapack extensions for Python (whatever numpy was called back then) ... well this massive job was done in a week and worked the first time.

The winning thing python had that nothing else had at the time was it was social, it was readable, and there was generally only one way to do things: the right way. It no longer has the latter quality, and the preferred coding style in it seems to be java-ish OO-spaghetti, but it's still pretty good.

That said, these days, I resent every damn time I have to use it. It's eating data science, more or less because pandas and scikit is ... mostly good enough, and because unlike R it's .... mostly good enough to deploy in an enterprise application. But if you're working on the exploratory side of data science, Python is shit compared to R. Doesn't have the tooling, doesn't have native facilities, and is vastly more long winded. All the attempts to make Python more ... X ... are probably a mistake also. You're taking a beautifully simple tool and making it more exotic and complex. It's like trying to use Matlab to build webservers.

Famous one:

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

I'm a somewhat older programmer, and I've worked with a variety of languages (C, OCaml, C++, Scheme, Go, Java...). I think all of them are great in their own way and there's a lot to be learned with all of them.

I started to use Python quite recently and I really like it. It is a well-designed language with high-level abstractions that are really fun to use. I like the pervasive use of iterators, the 'everything is an object' philosophy, the minimalist syntax, the build-in datatypes...

That being said, I feel that the dynamic types show their limits when projects getter big. I use linters and static type annotations but I find refactoring very error-prone and there's a point where I don't really trust my programs.

"It is a poor workman who blames his tools — the good man gets on with the job, given what he's got, and gets the best answer he can."

—Richard W. Hamming[0]

I have rarely "chosen" to use Python at work, but it has never failed to get the job done.

[0] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2041981/

Are you saying that python is good for the 90s? VB6 was good for the 90s. But that's not really relevant to what language to use now.

Why would you rationally compare something that exists and lives today, in the form it has today - with something from early 90s? In what world is that an objective comparison?

Back in my day we had to walk 20 miles to get to school -- uphill both ways!

As if the only way to gauge quality is to forever compare to the technologies of the past. Python was a great improvement on its peers in its heyday, but people, technologies and philosophies have changed since its inception and there is nothing wrong with wanting something more. That's how progress is made.

I find programming in Python dull and a little mind numbing. Sure, maybe Python was an okay choice 20 years ago, but the world has left it behind at this point. It’s lack of functional programming constructs, very few data structures in the stdlib, terrible performance, worthless statement vs expression semantics, no multi threading, no macros, etc.

Instead of evolving into something okay, Python is pretty much the same broken language as it’s always been, run by a guy who is openly hostile to PL theory, FP, and any major changes to Python whatsoever.

If you ever need/want to use Python, do yourself a favor and use Racket instead. Racket is better than Python in every single way (unless you are doing data science with Python, in which case fine keep using it).

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.

Sounds like the author of the article has never been involved in the Javascript community.

Yeh I recall working on MAP/Reduce using Fortran/ PL1G (1980's) we had to build an entire suite of JCL programs to mange every thing including build / deploy.

I don't agree at all. Your comment basically says: "It used to suck badly. So don't complain it sucks now.". I think dynamic typing is the bane of good software and we as an industry should try to actively discourage new code to be written in dynamically typed languages.

That's not to say that Python doesn't have it's place. But I see it more as a programming language for small utilities no more then 2k loc in length.

To understand the hate, you have to realise that no one likes being forced into using a particular technology. Especially one that is more of a lowest common denominator and ignores much of the progress in programming language research over the last 40-50 years (e.g. expressive static type systems, and Python still markets itself as "strongly typed").

Why do you think that Python should be compared to Fortran? Why not Rust or Julia? If we compared everything to worse humanity would not progress at all. I have spent 10 years on Python and I sympathize with some of the criticism below here pretty much. I wish Rust or Julia will replace it for data crunching soon.

I love python as a scratch pad for playing around with code, but I don’t think I would put anything into production written in it. It’s just too hard to debug and maintain and deploy once it gets to even a medium amount of complexity.

Interactive python and Jupiter notebooks are an absolute joy to work with though.

Don't forget COBOL

Better yet, punch cards.

I hate hammers with soft grip handles, but my current job is forcing me to use one. They're so mean. I prefer hammers with wood handles.

Oooh look, there's a hammer over there with a modern handle. I want that. I don't like wood anymore.

https://conan.io/ https://vcpkg.readthedocs.io/en/latest/

You were saying about C/C++ package management?

I don't think its hyperbolic. If so many people are complaining then we have a issue. I have tried to learn Python but every time I did, some things kept turning me off.

- First indentation was a issue for me but I looked past it and went ahead to give another go at Python.

- Even the best in class IDE suffer to give any kind of insight into python code.

- Two versions: At my workplace we use Python 2. I prefer to learn newer version but don't have choice. When Python 3 came out they should have initiated deprecation of Python 2 but that does not seem to be the case. Tonnes of libraries are still in Python 2. They should have maintain language backward compatible instead of fragmenting the entire community.

- So many ways to do a thing. This is subjective but I need a language which gives predictable performance for given piece of code. Go does this. There's usually one way of doing things and only one way. No need to know nooks and crannies of the language nor there is such a thing in Go

According to people who work with a lot of programmes teaching coding, the reason python is so appealing to new coders is the syntax. Particularly the lack of braces, the indents, the nice keywords, that make reading code much easier to a newcomer.

Having taught both python and JavaScript, I can tell you that the former is far far less confusing to newcomers than the latter. Imagine explaining the problem with equality comparison or prototypes in JS to someone who just learnt what an IF statement is.

The reason I agree that python will dominate programming for decades to come is the batteries included and pythonic approach that enables people to do cool things with just a few lines of code. As a result of the above, the ecosystem has reached critical mass. For most tasks there’s a library that does that, and it’s good, and it’s easy to use, and the developer of the library usually doesn’t expect you to understand their opinionated philosophy to use it.

I love the python convention of putting a minimal example on the homepage of a library.

You’re not going to get your average developer to appreciate the beauty of Lisp or the value of static typing. They want their ML to work, or their graphics to display, that’s all. Ends not means, almost entirely, for most people who aren’t full-time programmers.

Let’s not hate on a language that opens up programming to the world, unless we want to be gatekeepers. If you want to maintain an air of superiority, just learn Lisp or Haskell or C++ and write code that’s “deeper” into the tech labyrinth. Programming will probably specialise into “end user programming” and “Service and system programmers”. Embrace the democratisation of coding.

> Particularly the lack of braces

Since most of my professional experience is with C like syntax languages, I don't get how the lack of braces is an advantages, quite the opposite in my limited experience with Python.

Braces define scope unequivocally, they are easy to visually parse and don't care whether you are using tabs or spaces or even if you, loud gasp, mix them. Furthermore, you can copy and paste, say for loop from a method to another method and it will work. In Python you might have to faff about with spaces (I'm sure there must be IDEs that solve this problem but it was no fun on vim or even notepad++)

> Ends not means, almost entirely, for most people who aren’t full-time programmers.

And for many who are. Maybe not on our main projects, but at least for helper tools, side projects etc.

The part that Python really bothers me, as someone who had write Python for almost 10 years, and right now doing it professionally, though personally I don't consider myself a Python developer rather than a Python senior user, is actually obvious to nail down, and frustratingly, difficult to handle.

SLOW. The sin of all. I don't want to make other arguments with people who just come to repeat 'Oh you can make it fast, you are doing it the wrong way'. Sorry, I have heard that 100 times, now is sounds like bug-as-feature excuse to me.

Sorry, but Python is just slow. All the stuff people might bring up is just trying everything to bypass Python itself. Multiprocessing is hell to work with, buggy and unpredictable. Cython is OK but it is not Python.

Python's slowness is like cancer, and terminally so. Down deep, it is because its overtly flexible/loose type system, the never-going-away GIL, and prematurely exposing of C-API makes it almost impossible to optimize without breaking the existing compatibility.

And most importantly, I don't think it is solvable, truth is the patches are so integrated, people already forget what problem they tried to fix in the first place and just live with it.

But it will haunt Python in long term though, people will be struggling with Python in performant production until they start reimagining a world that without Python. Maybe a better Python in that sense.

Same here. I've used Python daily or almost daily for the last ~10 years (thankfully I've used other languages too).

I've architected reliable systems on top of it but it was obvious to me almost from the get-go that Python is a terrible language. I credit my previous years of programming in Lisp that trained my mind to see through the Python mirage.

One issue is that veneer of Python user friendliness that lures people, usually those who are new to programming or don't have extensive experience with _multiple_ languages, in.

The major issue for me is that Python lacks internal consistency and is based on a inverted-design (meaning, no design really) that accumulated over the years and stinks. This makes it really easy for people to use Python and write unmaintenable code but also very hard for them to find out how to write good code. The hallmark of a terrible language is making good code hard to write.

As far as specifics, I think the module system is a joke, the packaging even worse, the REPL is not really a REPL (in the Lisp sense), ctypes is bad and has 100 different ways you can hang yourself with, there are tons of gotchas in the language and standard library that if you haven't memorized [usually by running into them], they will bite you hard, the GIL ties my hands, iterator/generator obsession makes for really bad code messes if people take it seriously and start poorly designing their APIs around it, absence of proper lexical scope, statements are not expressions and led to gross hacks like PEP 572... I could keep going for days.

Python is really the PHP of the 2010 generation.

Python's success is richly deserved. The fact that it has been a long time coming (Python is almost 30 years old!) is an indication of the amount of sheer effort involved, and should give heart for all those working on building up the next generation of languages.

Since this forum is likely to have some folks looking towards the future, I found interesting a couple of talks by Python veteran Armin Ronacher [1, 2]. Watching that presentation makes me wonder whether I should think of this in the context of "Worse is better". That said, Python's runtime introspection is such a killer feature that it's difficult to explain how empowering it feels for someone who is relatively new to programming.

[1]: How Python was Shaped by leaky Internals -- https://www.youtube.com/watch?v=qCGofLIzX6g

[2]: A Python for Future Generations -- https://www.youtube.com/watch?v=IeSu_odkI5I

It's so refreshing to not see anyone here whining about Python forcing them to indent their code properly. The kind of people who think that's a PROBLEM instead of a FEATURE really should not be ever writing any new code, and instead should be punished by forcing them to maintain other people's code written with that same lazy misguided attitude, until they recognize how self indulgent, inconsiderate, and disrespectful that is not just to other people who have to read their code, but also to themselves.

The same kind of people criticize Lisp for having too many parenthesis, then go on to write unintelligible shell scripts, Perl and C++ code chock full of skewbald menageries of sigils and punctuation bound together with a towering inferno of precedence rules, terribly worse than Lisp's "too many parenthesis".

The best, brightest and most informed/experienced people who do not think it is a good idea for significant whitepace to be the determiner of syntactic nesting do not hold that position because they would like to inflict badly formatted code on their maintainers. You've invented a stupendously silly strawman.

As much of a fan of Python's syntax as I am, there are real problems with whitespace-sensitive syntax.

It's not that it's hard to parse or necessarily to write.

The trouble is that generic tooling around text is really bad, especially various websites and chat boards still haven't figured it out.

Code is a way to share ideas, which was one of GvR's key insights. People share a ton of code in discussions and such and WSS makes it a bear; even here I have to tediously type in four spaces to share a snippet of Python.

> The kind of people who think that's a PROBLEM instead of a FEATURE really should not be ever writing any new code, and instead should be punished by forcing them to maintain other people's code written with that same lazy misguided attitude, until they recognize how self indulgent, inconsiderate, and disrespectful that is not just to other people who have to read their code, but also to themselves.

Having gotten worked up like this myself plenty of times, I think you're treating someone doing a bad job as an injustice to you.

Unless there's a malign intent, it's simply not. And elevating it to an injustice is creating stress and strife for yourself (which you're venting here) that you don't need.

I am a novice programmer who started with python and have recently been using javascript, where I use auto-indent-on-save.

Coming back to python is annoying because it's harder to make sure code is at the right indent level than to use { }.

In fact writing this comment inspired me to find this: https://github.com/mathialo/bython

I consider it a must that code should be correctly indented, no matter the language. What I have issue with is relying on whitespace to represent scope etc. With .sass files I've had too many occasions where moving the content around between editors has completely borked the file, and without braces it's tedious to correct the indentation. This is mostly the fault of text editors trying to be "smart" about indentation, and failing miserably, but it's a pain I'd rather not exist.

Most IDEs have a shortcut to format code.

In over 12 years, as mostly a C# developer, I've only seen one person not use the standard indentation style and this was because he was a junior who didn't know that you could format the code with a shortcut.

edit:

I should point out that it was always rejected at PR time, it just took me a few PRs to realise what the problem was

And by mentioning it your ruined the pleasant reading.

In general JavaScript is eating the world.

Python still dominates in numerical computing and JavaScript hasn't been able to make a single dent. Because nobody wants to write

    a.mul(k).add(b)

rather than

    k * a + b

    a.set([i,j], b)

rather than

    a[i,j] = b

JavaScript's lack of operator overloading is keeping Python alive.

Python also has integers that feel part of the language, rather than being segregated from normal numbers in case anybody uses integers by accident.

> JavaScript's lack of operator overloading is keeping Python alive.

right...

- https://www.scipy.org/

- https://news.ycombinator.com/item?id=20661311

You’re spot on… As someone who uses Node/JS for most of my projects, I was actually surprised at how easy math is in python. I was given a homework assignment with the ability to use whatever language I wanted, so I picked JS. After hours wasted trying to do math with large numbers, I switched to python because others seemed to have success with it. Needless to say, I finished the assignment an hour or so after that. (Note, I would still use Node over python for an API any day of the week, personal preference)

Yes, Yes, Yes. I remember when I translated Bitcoin Python code to JavaScript, I was frustrated. Operator overloading is not available in JavaScript. By default JavaScript only supports 32 bit number. You have to use BigInt or use 3rd party library like big-integer. There is no default support for module exponentiation. And many more.

TensorFlow.js is actually very nice to work with: it seems to be well supported and comes with many quality examples.

You're enormously overstating the influence of JS on things outside of the JS ecosystem.

There's also the C FFI. Syntax is important, but so is being able to integrate with BLAS/LAPACK.

What stood out to me, reading the comments, is how among the first few comments I read there were 4 comments from people with decades of experience writing python professionally. Each stating their dislike for the language and citing entirely different parts of the language as its biggest problem.

Personally, I'm primarily a C++ programmer with about a decade of professional experience in C++. I also used to do daily work in C# for a few years. For me, python is a language which I use for making simple command line tools, for processing input and clobbering together different tools. I use it to build interfaces which streamline certain workflows. Essentially, I use it as a more powerful replacement for bash or batch. For that purpose, I find that the language works wonders and is quick and easy to work with.

The problem is that when they did the big Python 3 transition they didn't fix the real pain points (with the exception of string types), many of the things they fixed were not a problem, or worse they removed things that were actually useful. Such as the infamous print statement.

So now they can never fix the real problems, because everybody is so traumatised by the Python 3 transition.

I'll also say that the rate of development of Python is incredibly slow, slower than even JavaScript's TC39 if that's possible. I waited my whole Python career to get format string interpolation.

Python is not eating the world so much as becoming the new Excel. It has a pretty easy learning curve for people who are not programmers. It has pretty good built in tooling. A domain expert, who is not a programmer, can put together pretty impressive models and visualizations relatively quickly.

However, like with Excel, there are serious issues regarding reproducibility, performance, and long term maintenance.

One who writes a program is a programmer irrespective of being a domain expert or not.

If you write code in Excel you are an Excel programmer.

That's all good and fine until you want this model you built with tooling you barely understand to be deployed. Then your gross data scientist spaghetti code gets handed off to some one who actually has the skills to turn it into a robust deployable code base.

I love that Python has brought a lot of people into programming and that it makes it relatively easy for domain experts to do advanced analytics. However, another side of me wishes that there were a less user friendly language being used for data analysis so that it would force all of these people to actually learn to code half-way decently.

For what it's worth, I have none of the issues the currently top voted comments describe. Dependency hell (apt does that for me), closer to burnout any time I work with it, would rather work with C++ (a language with a completely different purpose)? If the author of the article had written this, people would fall over themselves to say how wrong they are. Nearly everyone who tried Python loves it. From this thread you'd think we're talking about Visual Basic for Applications.

There is a reason Python is one of the most popular languages. PHP was popular because it's quick and dirty, but Python is popular because people love working with it. The arguments in this thread are beyond me. (They're also unsubstantiated, but if I ask for substantiation I'm sure someone can rationalize some reasons to dislike any language, so that's pointless.)

One thing very interesting about Python is how gradual the ride up has been. Perl dominated then sputtered. Java shot up and hit the ceiling. C# is mostly limited to Windows, JavaScript mostly to the web. Ruby stole the spotlight for a few years and then faltered mysteriously. Others found their niche. But Python just keeps chugging along slowly gaining ground almost everywhere like a tortoise to multiple hyped-up hares.

Am I correct when I assume that most of the people hating on Python here are using it for medium or big projects?

I feel like the dev community figured this out ages ago: Statically typed languages are easier to read, harder to write, dynamically typed languages are easier to write, harder to read (and also harder to refactor).

For small projects (scripts, prototypes, etc), you don't care about readability, you just want it to be as easy to write as possible. Python really shines here.

For bigger projects, using Python is painful, but that's also the case with pretty much any other dynamic language..

Looks like a lot of folks are using the wrong tool for the job. Reminds me of that onion article about chastising a dog for being a dog. Found it:

https://www.theonion.com/dog-chastised-for-acting-like-dog-1...

Considering Python can power the largest web sites (Netflix, Instagram), I don’t understand why there’s so much use of much more complicated platform/languages (eg java, .net)?

Note: I am an amateur which is likely the reason for my ignorance.

A lot of stuff powered "by Python" is in practice powered by multi-language infrastructures, which can be pretty complex. For example, the Python ecosystem for data science is mostly implemented under the hood in a mix of C, C++, and Fortran, with high-level Python bindings, due to a mixture of legacy reasons and pure Python being too slow. Obviously lots of people still like the end result, but saying this kind of software is in Python is only half the story.

- Language design characteristics like static typing and a general lack of support for "magic" can help maintain order in large, long-term, many-contributor codebases.

- The JVM and CLR are both significantly faster and less resource intensive than CPython for a lot of workloads.

- Java and .NET library ecosystems are mature and extensive. Python 2's ecosystem was also mature and extensive, but the community is in the process of throwing it away.

- The real heavy lifting for media transcoding, storage, and serving is certainly not done in Python. Python is acting as orchestration glue for C/C++ programs there, which is a role it does well.

Someone I know made the observation that Python doesn't scale well with code complexity and team size. Statically tyed languages like Java give you a lot of guardrails, and IDEs make it easy to navigate around code, so it's easier for larger teams with larger projects to safely reason about things.

Difficult problems remain difficult no matter what language you use.

Also, there's a real cost to everything being dynamically typed in large systems. Humans can't keep all the program types in their brain, and having the compiler help you out is kind of a big deal.

Java and .NET are no more or less "complicated" than Python or PHP or any other language/stack. The most suitable language for any app/service is what the founding team knows very well.

You can do anything in anything. Everything boils down to trade offs for the problem or company at hand.

I can say with Java and .NET shops, it's usually because the company has heavily invested in Java and .NET infrastructure, process, automation, tooling, monitoring, etc. If there are certifications involved, I also know for a fact that Microsoft feeds big discounts on expensive products (SQL Server) depending on how many employees you have with Microsoft Certifications.

It becomes a self feeding system. You're already invested so much in the stack that the choice of using something else is far more complicated than language comparisons. It's one of the reasons that there are so many language options available that run on the JVM that can take advantage of all of that investment without forcing the devs to write raw Java (Groovy, Scala, Clojure, Kotlin, etc).

Python is pretty slow. If you can rewrite your stuff in Java or Go or something else that runs faster you can save half your servers at least. At a certain size that's a lot of money.

A great deal of Netflix is Java, which is why a great deal of OSS Java libs were written by Netflix.

> I don’t understand why there’s so much use of much more complicated platform/languages (eg java, .net)?

What language is Python implemented in? Is it Python, or something else? This tells you that even the implementors of Python don't think Python is suited for everything.

Definitely EVE Online's MMO secret weapon is Python: https://www.eveonline.com/article/stackless-python-2.7 - as well as its numerous ecosystem utilities like Pyfa, Evernus, used by tens of thousands per day.

I would not use Eve-Online as an example of performance.

Once it gets to a few thousand concurrent users they have to drastically slow down the server tick rate. It's like playing a turn-based strategy game at that point.

*Disclaimer: I quit Eve awhile ago.

There ware a time when I wondered if I should learn Ruby or Python. These days, unless I'm going to be a Rails dev, hands-down Python.

There was a time (more than a decade ago) when I wondered if I should learn Perl or Python. Unfortunately I picked Perl, subsequently forgot it and learned Python instead.

Ruby is a nicer language for general scripting, ie “better bash,” as that’s what it was originally designed for. It’s also a bit faster, and has a vastly better / simpler package management system.

Python does have great scientific / math libraries, and is worth knowing.

One nice thing is the two languages are so similar that it’s pretty easy to switch between them and use whichever fits the bill.

I was a Ruby programmer for a long time, but I think the world has moved on. Nowadays, I want a language with some type checking, and Ruby is extremely hostile to any kind of static analysis. Rails was pretty exciting as a replacement for how we built websites in the perl/php era, but now that React has taken over, Rails feels weirdly bloated. I would probably choose Typescript for basically everything now.

Reading all the comments here I have the impression that there are 2 groups of programmers:

There's one group that uses Python regularly and which is getting their stuff done right now.

And there is the other group which has time to complain about Python.

In my opinion, the biggest problem facing Python is still concurrency. The mitigation efforts still look to me like Perl's 'bolted on' implementation of object orientation. Python should have gotten rid of the GIL during the 2 to 3 transition. It may have also been an opportune moment to introduce optional typing and maybe even optional manual memory management, making it useful to develop almost all kinds of software. Write a WASM backend and it could have even been used for front end development.

Now there is Julia that has concurrency.

Julia, because it's much newer also seems to have dependency management built in as well.

Surely a lot of people who write numerical software are going to either look at or switch to Julia for these reasons.

There have been attempts to replace the GIL with locks on individual lists, dictionaries etc but they came out a wash performance wise. Perhaps this can change with gc.freeze and the new dictionary structure.

The 2 to 3 transition was already too difficult.

It now has optional typing.

This makes feel a bit sad/somber, because a lot of people are missing out on the exhilarating power of using advanced powerful type systems. I wish the ML community had picked up a few notes from Python, and built an Ocaml-like language with beginner-friendly Pythonic syntax (Reason comes close). I wrote about this here in the past (https://news.ycombinator.com/item?id=15549101); quoting myself below:

I'm a big fan of strong static type systems. I believe type-safety increases code quality significantly. I used to think several years ago, that the main benefit of strong static typing was code safety / eliminating a whole class of bugs. But I've changed my opinion. I now think the biggest benefit is that it makes the code a lot easier for other people to read and understand.

I mean I have multiple personal projects where I've used Python (which is a dynamically typed language), but these are small one-off projects. But I think when working in a team, especially a large team, having types becomes a huge thing. Having types for objects is especially useful. Having types forces you to think more clearly about the structure of your data.

It's really sad when I see `foo(bar)`, and I have no idea what the type of `bar` is, and if it's an object, I have no idea what fields `bar` has. I have to simply guess the structure of the various implicit types by looking at the code (sigh). It makes the code difficult to read, and rather unpleasant to work on. Not to mention, all the multitude of bugs that come from duck/dynamic typing.

I don't think good statically typed languages are hard to use at all. Type inference has spread everywhere that the old argument of having to repeat your types doesn't hold anymore. TypeScript, Flow (JavaScrpt), Haskell, languages from the ML family are really good at type inference. Even the `auto` type inference in C++17 was better than I'd expected.

If dynamic typing continues to grow in popularity, I don't want to even begin to fathom the number of large projects that are going to built, which will suffer from a avalanche of TypeError-class bugs that could have easily been avoided with static typing. One encouraging sign I've seen in the Python world is that optional static typing is reluctantly being adopted in many circles. There was mypy for a while, and now, there's a new type checker called Pyre (written in Ocaml). I find hope in these little things.

I've been told that my choice of python was poor numerous times. 'Do java/.net' etc. is something I've heard all throughout my career. I use python because it doesn't work against me - It's not the best language but I think its definitely the most versatile. I love python and it will be around for another decade I guarantee it.

Python and JavaScript

Ease of use trumping advanced features every time

Ease of use and advanced features are not polar opposites.

I do a lot of geospatial work and Python bindings for GDAL [1] are godsend. In 10 lines of code, I can read shapes stored in different projections and file formats; load, reproject and merge them into an in-memory SQLite database; do all sorts of complex geospatial operations on them using spatial extensions, and save results to a file.

I'd spend half a day writing C++ code that Python abstracts away into very few commands. It's a joy to work with, and I struggle to see any downsides.

[1] https://en.wikipedia.org/wiki/GDAL

WRT to Python at least, the skill range is more impressive than the low bar. High-skill programmers can do some pretty advanced things with it, and those advanced things can still be easy to use by lower skilled programmers.

I've come back from Ruby as the default scripting language to Python. Over the years, the accumulated Python scripts are much more consistent and easier to read than aged Ruby script. Ease of use, sure. But the language itself I would argue is much better thought-out and consistent. Now, only if it has better type and dependency management ...

Both have plenty of advanced features; it's constraints that dynamic languages struggle with.

The number of views of questions on Stack Overflow is a bad metric to measure language popularity. This metric combines popularity and complexity/unintuitiveness. If a language is half as popular but twice as complex (or unintuitive) as another language, then it will get the same number of questions and same number of views.

If the language is becoming more fragmented; more different kinds of frameworks and tools then it will translate to more questions on stack overflow. Fragmentation of the language is not necessarily a good (or bad) thing but it has nothing to do with the popularity of the language.

But definitely the JavaScript ecosystem is pretty homogeneous at the moment (ReactJS or VueJS on the front end and Node.js on the backend).

If you hate python, just write whatever your hearts desires. There is no use in saying "oh python does not let me know when a variable I expect to be list is string", well yes, it is a dynamically typed language, please learn the difference between dynamically and statically typed languages before hating on any language. As a bonus, you can check if a value is list or string and throw your own error, python is versatile, although it probably would be an antipattern and you should go back to writing C. If you love the good old days of Fortran, then I am sure many Financial Institutions and Aerospace industry or old school mathematicians would love to have you.

I would argue that Pythons biggest issue is performance, which translates in large applications directly into costs. You will need more machines to scale and you will need more power per operation compared to other programming languages.

see here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I think Python makes sense for prototyping and stuff like Jupyter Notebooks. But once mature and going into production I recommend porting stuff to something faster like Java or even Javascript nowadays.

Let's count the minutes until someone comes saying "but you can just write C and bind it to Python", completely missing the point.

While I use more than just Python in my work, it remains my go-to toolset for a range of tasks. For instance, Python offers the best interactive programming experience of any language today. You can step through code flow and inspect values with great ease. This is particularly valuable during prototyping, as you are getting a handle on interactions between your application and third party dependencies. Further, as designs take shape, you can quickly assemble a proof of concept and learn how to address a problem or design. Python can be used with little or any inheritance. Adopt a compositional style. You can assign types. You don't need to use all of its bells and whistles if you don't want to. This allows you to use Python in a way that streamlines it for porting to a strongly typed, high performance language such as Rust, should the need or desire to do so ever arise.

The Python community is truly global, hosting local events in hundreds of countries. So many talented, helpful people have been dedicated to the language and community over a very long period of time. Look at its ecosystem on GitHub to get an idea of how that manifests. Questions about how to solve a problem are often a single search away from being answered on Stack Overflow, Google groups and countless channels on Freenode IRC. Python conferences are a great place to learn and connect.

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.

The comment "Meanwhile, the Unix shell had different problems -- it offered a suite of utilities for common tasks, but ran so slowly it couldn't handle complex logic."

This doesn't make sense and also why the F is the " Dutch national research centre for math and computer science. " using c and nor Fortran

Interesting article, I would love to read one regarding Java and Kotlin, or if even someone here would share some knowledge with me, I would be grateful.

Is Java dying, what is its future? Where is Kotlin heading, currently it is the hottest language for Android development, can it also compete with Python in some branches?

Java moved to a six month release cycle and it has breathed new life into the ecosystem as a whole. Its one of the most robust and important languages out there.

Java will likely never truly die because of legacy applications. It's also still firmly set in the market and that is not looking likely to change in the future. Its also the king of microservices with Spring Boot.

Kotlin could well take over the mobile space. Many of the touted benefits of Kotlin are slowly being added to Java itself.

Java itself may decline as a language, but I'm near certain that the JVM will be with humanity forever. Someone will be programming in a JVM language somewhere. Whether it's some future language or Java 532.

I recently gave a Python book to a co-worker that wanted to experiment with deep learning. Co-worker: Wow - this book is like 900 pages long! Me: Don't worry, it's mostly whitespace. And that is one of my favorite features of Python - easy to trace and code!

"I was very disappointed in how the people who disagreed technically went to social media and started ranting that the decision process was broken, or that I was making a grave mistake. I felt attacked behind my back,"

May I ask who did he mentioned about ?

I don't know the answer to that question, but this post from February 10, 2006 captures some of Guido's frustration with the way certain contributors would insist on changing Python in ways in which they might be able to win an argument about syntactic disambiguousity and technical implementability, but at the expense of that ineffable sense of essential Pythonicity.

https://www.artima.com/weblogs/viewpost.jsp?thread=147358

All Things Pythonic

Language Design Is Not Just Solving Puzzles

by Guido van van Rossum, February 10, 2006.

Summary

An incident on python-dev today made me appreciate (again) that there's more to language design than puzzle-solving. A ramble on the nature of Pythonicity, culminating in a comparison of language design to user interface design.

Some people seem to think that language design is just like solving a puzzle. Given a set of requirements they systematically search the solution space for a match, and when they find one, they claim to have the perfect language feature, as if they've solved a Sudoku puzzle. For example, today someone claimed to have solved the problem of the multi-statement lambda.

But such solutions often lack "Pythonicity" -- that elusive trait of a good Python feature. It's impossible to express Pythonicity as a hard constraint. Even the Zen of Python doesn't translate into a simple test of Pythonicity.

In the example above, it's easy to find the Achilles heel of the proposed solution: the double colon, while indeed syntactically unambiguous (one of the "puzzle constraints"), is completely arbitrary and doesn't resemble anything else in Python. A double colon occurs in one other place, but there it's part of the slice syntax, where a[::] is simply a degenerate case of the extended slice notation a[start:stop:step] with start, stop and step all omitted. But that's not analogous at all to the proposal's lambda <args>::<suite>. There's also no analogy to the use of :: in other languages -- in C++ (and Perl) it's a scoping operator.

And still that's not why I rejected this proposal. If the double colon is unpythonic, perhaps a solution could be found that uses a single colon and is still backwards compatible (the other big constraint looming big for Pythonic Puzzle solvers). I actually have one in mind: if there's text after the colon, it's a backwards-compatible expression lambda; if there's a newline, it's a multi-line lambda; the rest of the proposal can remain unchanged. Presto, QED, voila, etcetera.

But I'm rejecting that too, because in the end (and this is where I admit to unintentionally misleading the submitter) I find any solution unacceptable that embeds an indentation-based block in the middle of an expression. Since I find alternative syntax for statement grouping (e.g. braces or begin/end keywords) equally unacceptable, this pretty much makes a multi-line lambda an unsolvable puzzle.

And I like it that way! In a sense, the reason I went to considerable length describing the problems of embedding an indented block in an expression (thereby accidentally laying the bait) was that I wanted to convey the sense that the problem was unsolvable. I should have known my geek audience better and expected someone to solve it. :-)

The unspoken, right brain constraint here is that the complexity introduced by a solution to a design problem must be somehow proportional to the problem's importance. In my mind, the inability of lambda to contain a print statement or a while-loop etc. is only a minor flaw; after all instead of a lambda you can just use a named function nested in the current scope.

But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there's already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption.

Mathematicians don't mind these -- a proof is a proof is a proof, no matter whether it contains 2 or 2000 steps, or requires an infinite-dimensional space to prove something about integers. Sometimes, the software equivalent is acceptable as well, based on the theory that the end justifies the means. Some of Google's amazing accomplishments have this nature inside, even though we do our very best to make it appear simple.

And there's the rub: there's no way to make a Rube Goldberg language feature appear simple. Features of a programming language, whether syntactic or semantic, are all part of the language's user interface. And a user interface can handle only so much complexity or it becomes unusable. This is also the reason why Python will never have continuations, and even why I'm uninterested in optimizing tail recursion. But that's for another installment.

This is wrong in terms of the web space. With the modernization of PHP and the emergence of Laravel, and continued evolution of Drupal and Wordpress, I don't think PHP has ever been this dominant in the web stack. Django is an also-ran.

You can't deny Python is versatile language with a moderate learning curve and packages that will do almost anything.

These things have made me more productive programmer and allowed me to get stuff done in a reasonable amount of time.

I love Python but.... I would not go to the lengths that this article proposes. The dev world recreates itself every year with dozens of new high level languages and task specific support libraries. Every developer has their favorite language (Everyone is comfortable with their personal preference) That being said, I enjoy Python and it provides a quick, easy script to accomplish task in my space but I would not go as far as the article in saying that it is the end all be all for everyone. Use what you like, and understand that all languages have strength and weaknesses for task.

Is there a reason people don't choose Perl much anymore? It's a fine scripting language and supports the UNIX C API almost full stock.

^ Another Siracusaism, who's still - by his own admission - a Perlhead.

It doesn't scale to multiple developers, even more poorly than Python.

I find Python to be a great alternative to writing bash scripts. I did that with this semi-popular Android tool (https://github.com/ashishb/adb-enhanced). Python is close enough to be a language but straight-forward enough to be a shell script.

For the Python haters here. No, Python is not as good as GoLang or Kotlin for maintenance but IMHO, it is better Javascript/Typescript/C++ for writing non-performance critical code.

What I find baffling is that almost every program I'm interested in as a creative power user has a Python API for scripting, from type and graphic design to 3D modeling, rendering and music making.

I'm a bit into web design/frontend as well, and was thinking about either learning JS and Node more deeply, or add some other "backend language" like PHP or Ruby, and learn their frameworks like Laravel or Rails.

Should I pick Python, Django or Flask instead to cross the gap to my creative hobbies?

The data synergy of Node + Web is hard to beat, and JS is very elegant for writing asynchronous code. Also, I've found the web (canvas, svg, webgl with Three.js) to be an amazingly hackable creative platform. Just my two cents.

Flask is pretty easy to get started with, Django is a batteries included monster.

I have been a Python guy for 10 years now switching from another profession - I was a mechanical engineer. I tried to learn other languages like Java ,C and was partially successful too. But I don't remember creating anything useful in those languages.

Everything was so verbose that I got drowned in the syntax rather than the logic behind the program. For me, Python signifies ease of development and fast iterations and as such is suited for any young developer.

A joy to write and read. But a pain to debug and maintain. Coded a big project in Python once. When the project was still small everything was perfect. When the project grew it became unsustainable. Of course I was an already experienced C# dev, just getting started with Python but the problem is there. A whole lot of errors spilling to runtime is a big pain. But that's a problem with every dynamic language at variable levels.

Tools, tests, and logging are the cure to those troubles. I've not experienced substantial problems with projects large or small.

If a project is known to be huge up front and/or some developers will be inexperienced choosing a language with additional guardrails would be prudent.

I cant comment on general software engineering but in the data science domain coming to Python from SAS / SPSS feels like being given free superpowers

I've not written that many heavy applications in Python (Java mostly). I do like the dynamic nature of it. I find myself leaning more towars dynamic these days, appreciating Javascript today as well. I like the v.env side of Python. Many languages have this plumbing to get a project started and Python is the most comfortable of them all. Python is smart. Python is easy to teach also.

If you ask me the world only needs two programming languages, Scheme and OCaml and it would be better if OCaml had s-expressions as syntax.

There are more things in the computer programming universe than are dreamed of in your philosophy.

(With apologies to William Shakespeare...)

It's easy to get going on it, it's productive for writing scripts and experiments. It's dreadful for programming in the large, but only in comparison to languages designed to take account of the lessons learned about large code bases and team working. Most programmers have never encountered these and have very little idea of what they are missing.

Can totally agree that python is eating the world, while in the same time being too opinionated on certain things and lacking in certain points. I would rather see lua more adoption - its the language designed right - minimal and logical, easy to comprehend quickly for anyone who got any exposure to other C-like languages. Easy integrations as a bonus.

Python’s killer feature - and perhaps reason for its popularity- seems to be it’s nice-looking syntax, which is only the most superficial of qualities. Below that surface, the semantics and its standard libraries are all very irregular, and always leave a bad taste in my mouth. I now avoid touching it if i can.

https://outline.com/4zf4Dd

I have used all code from c+, java, php, javascript, ruby and more and found python is the easiest and simplest to use (you do not have to setup 5 classes to declare 1 variable) the only thing i hate about python is there is no built in parser to handle formatting.

Which is a simple but big design flaw for me.

Anybody else sad that this is not Ruby?

Funny that I seen a few articles titled somewhat like this in reference to javascipt.

Javascript might be eating the world of web development, but there are a whole lot of other scenarios outside of web programming that Python is more likely to be used in, IMHO.

Saying this again, is this a cover effect ? I'm strongly thinking that python reign just peaked, and that either python will change drastically into a more solid static core or people will go Julia..

Never had the chance to use python but what I hear most about Python is that it's easy to develop/saves developer time. Is it still true when maintaining a project vs developing from scratch?

Wow. uBlock registers at least 50 unique blocks, and my laptop still churns trying to load all the extraneous ad content ZDNet tries to jam down the pipe. ZDN stopped being journalism long ago

Best thing I have ever read on Python's history. Really fine work.

It's such a great language, and so incredibly slow :-/

Probably a kind of premature optimization on my part, but this is why I chose Golang over Python as my primary language. Maybe one day Python will have its own compiler without having to drop into writing C, who knows? For know I think the features of Go are just more attractive than those of Python.

I am just happy to see that debates on whether some programming language is awesome or the worst are still popular on HN.

Are there any good cloud solutions for developing in Python?

I’ve been using Pythonista on the iPad but it doesn’t support numpy.

I use pythonanywhere. Seems to work well enough and isn’t expensive. Main problem I have with it is I cannot use Altair-viz in a Jupyter notebook because their notebook server is out of date.

There's Python Anywhere: https://www.pythonanywhere.com/

It does now: http://omz-software.com/pythonista/ (just below the blue bar).

Some good news for you: Pythonista absolutely supports numpy, I followed advice on the web a few months ago to install it, and I just tried it to make sure it still works.

Anvil?

It’s really terrible that python should be growing. It’s a bad language and a bad ecosystem ...

The knowledge exists that we shouldn’t be encouraging systems to be built with the patterns/tools commonly advocated in the python world — at what point do we acknowledge that the forces promoting this kind of ecosystem are essentially propaganda-like mind viruses ... so much future suffering that will not be prevented ...

Well, I could be put in the ‘Python hater’ category: I do love Python for short programs using TensorFlow, the SpaCy NLP library, PyTorch, etc. I really hate using Python for large applications. Everyone gets to choose their own favorite languages, and for me that would be Common Lisp, Haskell, Java, or Scala for working on large projects. Each to their own though.

It's not flexible as PHP does, but I guess it's faster than PHP.

When it comes to raw performance, PHP7 is much faster than Python.

PHP is more flexible when it comes to building web applications. But in some areas Python just have better libraries (computer vision, matrices, high-level mathematical functions). I remember reading that PHP is going to add FFI and I believe FFI will have a big impact in PHP world.

Actually no, given that PHP uses a JIT nowadays, and PyPy is still barely used on the Python world.

I really hoped Julia would become a major player in scientific computing and data science, but it looks like ever less probable. I like Python, but for science I like Julia more.

Is it fair to say that Python is the new BASIC?

>"In the past, it had always been clear that if there were a decision to be made about a change in the language or an improved feature, a whole bunch of core developers would discuss the pros and cons of the thing. Either a clear consensus would appear or, if it was not so clear, I would mull it over in my head and decide one way or another. With PEP572, even though it was clearly controversial, I chose 'Yes, I want to do this', and people didn't agree to disagree.

This is a characteristically practical, effective Dutch attitude, known as the "Polder Model". The United States currently suffers from the opposite problem of extreme partisanship and gridlock.

https://en.wikipedia.org/wiki/Polder_model

The polder model (Dutch: poldermodel) is consensus decision-making, based on the acclaimed Dutch version of consensus-based economic and social policy making in the 1980s and 1990s.

The polder model has been described as "a pragmatic recognition of pluriformity" and "cooperation despite differences". It is thought that the Dutch politician Ina Brouwer was the first to use the term poldermodel, in her 1990 article "Het socialisme als poldermodel?" (Socialism as polder model?), although it is uncertain whether she coined the term or simply seems to have been the first to write it down.

[...] Other uses

The term polder model and especially the verb polderen (to polder) has been used pejoratively by some politicians to describe the slow decision-making process where all parties have to be heard. The model flourished under the "Purple" governments of Dutch prime minister Wim Kok, a coalition including the traditional rivals the Labour Party (a social-democratic party, whose colour is red) and the People's Party for Freedom and Democracy (right-wing liberals, whose colour is blue). In the declining economic climate of the early 21st century the model came under fierce attack particularly from right-wing politicians and Pim Fortuyn in his book entitled De puinhopen van acht jaar Paars ("The wreckage of eight years Purple").

Historical background

[...] A third explanation refers to a unique aspect of the Netherlands, that it consists in large part of polders, land reclaimed from the sea, which requires constant pumping and maintenance of the dykes. So ever since the Middle Ages, when the process of land reclamation began, different societies living in the same polder have been forced to cooperate because without unanimous agreement on shared responsibility for maintenance of the dykes and pumping stations, the polders would have flooded and everyone would have suffered. Crucially, even when different cities in the same polder were at war, they still had to cooperate in this respect. This is thought to have taught the Dutch to set aside differences for a greater purpose.

What stood out to me: online bullying (dressed-up sometimes as concern/outrage) is what led to Guido stepping down.

Python is great, but it will never be perfect. But the outrage stuff, the entitlement stuff, essentially anything that happens on Twitter... Python seems like a victim of it's own success. Once it got popular, it couldn't scale the checks that might have stopped this runaway train of shit-tweets and bickering on the mailing list.

Personally I don't like a lot of the things that have happened in 3 (asyncio, type whispering, fstrings). I can't help but wonder if, again, this is due to becoming too popular too fast. I say that because aesthetically these features seem to go against the Zen of python.

May you never have users, but if you do, may they not have Twitter accounts!

What’s wrong with fstrings? I use JavaScript at my day job and leaning python for Raspberry PI projects. Fstrings looks like it’s better than .format or + concatenating + a bunch is strings. Especially large strings.

I dunno, R is also exploding in popularity but it seems to be able to manage itself really well. To the point of successfully creating an environment that attracts women and other underrepresented groups towards it.

Dynamic typing does not scale.

Python is a prototyping language, but not a serious software engineering languagebfor large and fast projects.

Switch to JS was like obtaining new home, don't want to write Python code anymore. Also "Eating the World" isn't correct anymore, 'cause Python popularity decreasing last ~5 years according to Github stats.

I wonder what the consequences of this are given Python's apparently very poor energy consumption profile: https://thenewstack.io/which-programming-languages-use-the-l...

It appears to consume over 17x more power than JavaScript, 40x more power than Java or 75x more than C/Rust. The only language which performed worse than it in terms of pure power consumption was Perl.

While I'm sure these results aren't exactly indicative of day-to-day usage as they're based off of benchmarks which are not exactly representative of day to day use cases it nevertheless raises the question of whether Python is an appropriate choice of language where the application itself is likely to see a high level of total use. I suspect the answer is "more work needs to be done" on the subject to truly assess the impact and a big part of the answer is "depends on how you're using it". It'd be good to see some standardised tests of web frameworks. For instance, load testing a standardised server side version of the TodoMVC project to determine what happens for each framework there, along with what happens when you stick a cache in front of them and so on.

It'd also be interesting to attempt to estimate how much power consumption and hence CO2 generation each given programming language is responsible for given their marketshare and typical usage profiles - although I suspect in practice this would be quite difficult given the diverse usage profiles of modern programming languages. And obviously the fact that machine learning libraries, for instance, will naturally be quite energy intensive - it's probably the case that Python actually does quite well there because most of its popular libraries for that are just wrapping C or similar rather than being pure Python code.

Given the success of V8 and PHP7 in terms of boosting the performance and presumably energy efficiency profile of their respective languages it'd be nice to see the mainline CPython interpreter undertaking a similar kind of transformation. Obviously we have things like PyPy but it seems to me the Python community needs to be united around a solution to this which forks simply are not going to be able to drive.

Find the hot parts of your app with a profiler, then augment them with Cython to boost efficiency 10-100x.

I feel like the world has gone insane when it comes to Python. Or have I gone insane?

Python is an incredible waste of time. No types, IDEs that suck (a side effect of not having types), very partial validation with linting tools that are an afterthought to the language, indentation is a mess (good luck moving files between different editors and environments or through clipboards), slow, agonizing deployment (pyenv? Come on).

I’ve been doing C# these past two years and it is laughably effective in comparison, almost like cheating. Standard libraries covering almost anything, tooling that couldn’t get any better, runs everywhere, lighting fast builds.

Most importantly, in C#, due to the incredible tooling and language design, if it’s built successfully then there’s a very high chance it’ll do what I want it to right out of the bat. In C/C++, much less so. In Python it’s almost guaranteed not to do anything but crash unless I’ve ran everything through in depth coverage testing and I’d still take the C# build checking every time.

My Python is pretty good, and I’ve known it for more than 15 years now. I’m not taking this position out of ignorance.

For the love of god, go learn a proper language. It can be C#, which I think is as perfect platform/language as anything, or Rust or Go or even Java.

I see young devs on their vim or Sublime editors developing Python and I want to shout to them, that’s not how it’s done. You’re missing out on decades of industry evolution and know how in things like the Visual Stdio and .NET or even Java and JetBrains/Eclipse. You’re using stones to start fires where you could just use an oven.

I still use Python, but it’s always for very short and specific programs. It’s just a bad tool for more than that. If you are unable to resist the temptation of using Python for that short program, just make sure it never ever has a chance to grow.

Regrettably the ML world lives on Python, fine; let them have it.

There is hope still.

I hope that Julia eventually makes such a hit that performance gets taken more seriously as part of Python devs (yeah there is PyPy, but gets seldom used in the field).

I am like you though, my introduction to Python was version 1.6, and due to my experience with its performance, I never used it for anything beyond shell scripting on steroids.

As proven by Smalltalk, Dylan, Common Lisp and JavaScript, dynamism doesn't need to be slow.

Pycharm is pretty excellent in terms of IDEs. It's quite literally IntelliJ for python.

And that's a sad thing to hear. Before my death by thousand downvotes, I'd like to tell you why do I feel that way.

Back in the day when I was way more inexperienced than I'm now, I was a die-hard Python fanboy. To me, it seemed like a best option available due to it being way more concise and readable than JS/PHP, not to mention that it was way more powerful and dense. I didn't really bother with type safety at the time and I wasn't exposed to any real criticism of it at the time, as it happens often when you're just too new, and I was more than fine with it.

Time mercilessly marched forward since then. I worked with different codebases, changing tech stacks and languages a bit, learning new stuff and so on. With some experience, lots of self-education and a vast amount of different workflows to compare with, I've realized one important thing. While Python may be better than some languages that are considered trash by industry consensus, it's also a trashcan language to ones with sound and flexible type systems, not to mention that, across dynamically typed contenders, it's nowhere near as powerful as literally any solid Lisp.

That said, I feel bad for the industry that "dives into Python" more and more over the last years. While it may seem like a pretty easy and cool-ish language to write in, you will inevitably have large problems at scale, it just doesn't have what it takes to be easily scalable, and most importantly, it's just tedious to refactor when it's big, even though the language itself is mind-numbingly easy and even your grandma can jump right in.

In a conclusion I'd like to say that you'll be better off without using Python as your project's main driver. Yes, it's simple to write it and the developers supply is abundant. It's easy to start. It'll just be a major pain to scale it and support it later on.

Edit: Made a pun.

> sound and flexible type systems

Python has a more powerful type system than any mainstream language except for C++ (templates). No other mainstream language has support for explicit marking of variance of arguments, nor does any other language support literal (dependent) types, except for typescript.

Two things I don't like about Python:

1: No seperator sign like ";", so you cannot express everything you want in one line. Oneliners are often so useful that I don't want to live without them.

2: By default, it caches the bytecode on disk. This is slow and spills those files into the filesystem. I prefer PHP in this regard, which caches the bytecode in memory.

Python has semicolons.

I am currently writing Python based software for a client on serverless architecture. Honestly, I really feel like myself and a lot of people I know use Python only because it has some useful libraries like Pandas compared to other languages. In addition, the effect of 2.xx and 3.xx fiasco can still be felt during development.

These days, I really wish I could write my stuff in Elixir, but too bad its data science eco-system isn't as strong as python's. In the very least, even Ruby as a fallback is much much better to write code with since its philosophy is drastically different from Python's - "Optimize for programmer happiness (Ruby) vs Fuck the programmer and optimze for computers (Python)".[1]

[1] https://rubyonrails.org/doctrine/

This a complete misrepresentation of the Python philosophy and a cheap troll.

Recently was trying to convert Python to C#... there are few things that are as absolutely incomprehensible as a Python programmer being clever with numpy. I gave up on the conversion. Perhaps this is a point for Python’s flexibility, but I’d say it’s just a waste.

Here’s the code. Try to convert this to any C style language.

            mins = X.min(axis=0)
            maxs = X.max(axis=0)
            idxs = np.random.choice(range(self.dim), self.dim-self.exlevel-1, replace=False)  # Pick the indices for which the normal vector elements should be set to zero acccording to the extension level.
            self.n = np.random.normal(0,1,self.dim)                             # A random normal vector picked form a uniform n-sphere. Note that in order to pick uniformly from n-sphere, we need to pick a random normal for each component of this vector.
            self.n[idxs] = 0
            self.p = np.random.uniform(mins,maxs)                               # Picking a random intercept point for the hyperplane splitting data.
            w = (X-self.p).dot(self.n) < 0                                      # Criteria that determines if a data point should go to the left or right child node.
            return Node(X, self.n, self.p, e,\
            left=self.make_tree(X[w],e+1,l),\
            right=self.make_tree(X[~w],e+1,l),\
            node_type = 'inNode' )

Here is the C# version of that snippet, assuming the existence of such libraries.

    var mins = X.Min(axis: 0);
    var maxs = X.Max(axis: 0);
    var idxs = np.Random.Choice(Enunmeration.Range(this.dim), this.dim-this.exlevel-1, replace: false);  // Pick the indices for which the normal vector elements should be set to zero acccording to the extension level.
    this.n = np.Random.Normal(0,1, this.dim);                             // A random normal vector picked form a uniform n-sphere. Note that in order to pick uniformly from n-sphere, we need to pick a random normal for each component of this vector.
    this.n[idxs] = 0;
    this.p = np.Random.Uniform(mins,maxs);                               // Picking a random intercept point for the hyperplane splitting data.
    var w = (X-this.p).Dot(this.n) < 0;                                      // Criteria that determines if a data point should go to the left or right child node.
    return new Node(X, this.n, this.p, e,
                left: this.MakeTree(X[w],e+1,l),
                right: this.MakeTree(X[~w],e+1,l),
                node_type: "inNode")

There is nothing about Python flexibility there other than a possible missing library implementation.

Try converting typical Matlab code to a C-style language and you'll run into similar problems. That's just what you get when your base language isn't all that fast but you have a fast numerics library that allows you to do clever things with arrays and matrices.

Your challenge isn't possible because the code snippet isn't complete. It doesn't include the definition of 'make_tree', 'Node', or the broader context.

That being said, I have no doubt that C++ with Boost would look quite similar to that. The boost libraries have very powerful numeric constructs and can easily handle matrices, uniform random distributions, dot products, and trees.

Reply on news.ycombinator.com