[caymanjim]

Python is a pretty terrible language to work with. Tooling sucks. Dependency conflicts are common. There's no test framework/runner worth a damn. Web frameworks are inferior to those in most other languages.

If you're doing data science things, it's hard to beat pandas/numpy. I get that those are popular in that community because the barrier to entry with Python is low. People who are just looking for a tool to solve immediate problems would do well to reach for Python.

The problems start when you try to write more complex things. Then you run into the weaknesses in tooling, testing, and performance. People would do well to skip Python and go right to another solution.

I say this having spent half of the last decade working on Python projects. If not for data science and academia keeping it alive, it'd be disappearing along with Perl.

[oliwarner]

> Web frameworks are inferior to those in most other languages.

That's quite a statement. Go on, for most of the other languages, show me a web framework that's better than Django.

Python absolutely has deployment challenges, but the performance is Good Enough™ and the speed of modelling and maintaining and accessing databases in Django's ORM is so much better than anything else I've found. Its Admin interface too is superb for same-day turnarounds on little CRUD projects. Nothing comes close.

And I've written quite complex systems around Django. Ones that are multi-headed websites, APIs to physical hardware IO, ANPR, card readers, ID printers. Python hasn't let us down.

[innocentoldguy]

> That's quite a statement. Go on, for most of the other languages, show me a web framework that's better than Django.

I think that’s subjective, so take this with a grain of salt. I do have a different opinion though. Also, my point isn’t to argue, but to encourage consideration.

I’ve used Django and Python quite extensively in the past and I would say that, for me, Phoenix/Elixir and Ruby on Rails are both better web frameworks than Django.

The reason I feel this way is that Phoenix/Elixir, for example, has much better dependency management and tooling than Python/Django (e.g., Mix is vastly superior to Pip, in my opinion).

Also, when I was using Django in the past, even the core team suggested using a different directory layout than is generated by default. This meant that every Django application I worked on had a completely different project layout. Both Phoenix and Rails are more opinionated regarding their project layouts. Some may consider this bad, but the benefit is I can go to any Phoenix or Rails project and instantly be productive because I know where all my controllers, models, views, templates, and contexts are going to be. I also like that Phoenix is much faster, more scalable, and makes better use of hardware resources than either Python or Ruby.

I think Python and Django are excellent, but I’d place them at #3 in my top-three list of web frameworks. That’s just my opinion though.

[oliwarner]

That's fine. I disagree, but that's fine too.

What I took issue with was the suggestion that "most other languages" have a better web framework. I'd wager most other languages don't even have a web framework. And even amongst those that do, there's some real dirt out there, and much worse examples of packaging, tooling, etc. Two Python frameworks, Django and FastAPI would be in my as-objective-as-possible top 10.

It was a silly thing to say.

[innocentoldguy]

I see. I can agree with you assessment. I also agree that Django is a great framework. It's one of my top-three favorites.

[shpongled]

I am a self admitted python- and ORM-hater and I agree. Django is pretty fantastic, and I have successfully used it to spin up several complete CRUD projects in a day or two

[bb88]

If you use a DB, the DB will be the slowest aspect of a web framework, or any other kind of IO.

90% of the performance gains I've achieved are by optimizing/reducing large DB queries, or adding an index to the DB.

[_fizz_buzz_]

These are the kind of comments that really made me feel insecure when I started out to program. Every programming environment/language has its advantages and drawbacks and python is obviously not a terrible language. People build amazing stuff with python.

[kortex]

> Python is a pretty terrible language to work with.

That's just like, your opinion, man.

> Tooling sucks.

Not in my experience. Lot of tools could be better, but I would not say there is a lack of un-sucky tooling at this point. Poetry and pytest in particular are largely excellent to work with.

> Dependency conflicts are common.

This has been a problem historically but it's leagues better today, especially with lockfiles.

> There's no test framework/runner worth a damn.

Um, what? Unittest (stdlib), Pytest, tox, nose, hypothesis, schemathesis, and a few other lesser known ones.

> Web frameworks are inferior to those in most other languages.

FastAPI is pretty amazing. Flask is well regarded as a good intro framework. Django I'm not a fan of personally, but many love it.

> If not for data science and academia keeping it alive, it'd be disappearing along with Perl.

And machine learning. And web dev. And sysadmin scripting.

[wiz21c]

For the little data sciences like statistics and mildly complex ML, R is really good. At least for data exploration. The REPL/emacs combo I use is much better than python/jupyter. By better I mean it's far more productive to test ideas, compute statistics, charts, etc. Unfortunately R programs I write are not as structured as python programs. I wouldn't like to maintain that kind of code for a long time, nor would I build big applications in R.

[digisign]

Sounds like inexperience or confusion, to be honest. None of those are problems particular to Python. Meanwhile you did not mention any of Python's significant issues, such as performance or deploying end-user apps. But it is best-in-class for what it was originally designed for.

[ptx]

> There's no test framework/runner worth a damn.

The built-in unittest module is essentially a clone of JUnit, so it can't be much worse, and most of the remaining limitations are fixed by pytest which people seem pretty happy with. What test frameworks are you comparing them to?

[llanowarelves]

You're right.

The thing I want is a good monorepo solution for Python. There's at least 3 for JavaScript.

As much hate as JS gets, its package managers are also much better than Pip.

In order to manage complexity of Python as you do your big projects, you really need to do "enterprisey" patterns like DI. Even though it's rare for Python programmers to write like that.

Re: test runner: pytest is pretty good

[jvolkman]

What are you looking for in a monorepo solution?

[0x008]

probably managing requirements.txt of sub-projects and virtual environment management?

[jvolkman]

This is possible with existing general monorepo tools. We use Bazel for Python and other languages. With Python, we have a single requirements.txt at the root of the monorepo, but each target (a Python package, a module, an app, or some combination thereof) depends only on the packages it needs and the transitive packages of its dependencies.

Then if you need to do something like build a distributable archive for your app (say, to deploy it to lambda), you can use Bazel's dependency graph to get only the packages that the app transitively depends on.

[0x008]

What about the opposite case? I have several python packages with one requirements.txt each. But for development I want to have a single “root” virtual env?

[jvolkman]

In that case it seems like you could just have one all_requirements.txt that includes the individual files like:

  -r package_a/requirements.txt
  -r package_b/requirements.txt

etc.

[claytonjy]

Of things you mention I feel the testing part the most. I started python recently enough that I've only ever used pytest, but something about it just feels too...magical? I'm holding out hope for a new test framework that I'd feel more at home with, but I'm not aware of any such projects; do they exist?

[ptx]

You could give the built-in unittest module [1] a try. It's less magical (although also less flexible) and many of its old limitations that people used to cite as advantages of pytest (e.g. built-in test discovery) have since been fixed.

[1] https://docs.python.org/3/library/unittest.html

[gosukiwi]

I'm relatively new to Python, coming from Ruby and JS, and the built-in unittest module is just fine. I haven't had any issues with it, besides the documentation for setting it up following the conventions is really hard to find. But once it works, I like how simple it is. If you know OOP you'll feel right at home. You can simply create your own test case classes if you want to re-use stuff. No magical bloated configuration.

[d0mine]

If "too magical" is the only complaint that is mentioned, then pytest is not too bad :)

[Gordonjcp]

> People would do well to skip Python and go right to another solution.

Okay, so what solution? What do you recommend? I'm guessing if you're qualified to make statements like your first paragraph, you can bring your wealth of skill and experience to the table and show us what we should be using.

[systemvoltage]

> Dependency conflicts are common.

Is it really?