[sjellis]

> You says "X is bad", "Y is better" but you don't say how exactly X is bad, in what way Y is better.

I gave you a breakdown in my earlier comment, but I'm thinking that writing more isn't going to make this better:

* Your experience: Python does everything that you need, and quickly, because you are already very proficient in the language and the tools. * My experience: Shopping for a programming language, knows Python syntax but no attachment beyond that, has tried out a number of languages and has working knowledge of their tooling.

I'm not suggesting that Python is a bad language, just that I think that the tooling and developer experience for new users is not competitive with some other languages. If you are proficient in Python, and haven't tried other languages recently, you won't have experienced the jump: Python is slightly more hard work than Ruby or Node.js, but Rust, Go and .NET Core have a level of slickness and integration that older platforms just don't have.

> What is so bad about "a multi-file Python project that could act as a library as well as a CLI, and be packaged as a wheel for PyPI."

Again, see my previous comment for a list, including some bits that you are omitting. I found that document and read it, but it assumes that you have already created something with docs and tests (laid out in an appropriate directory structure). Since I didn't actually submit the package to PyPI, I didn't have to think about twine, but that's another paper cut. Which is my main point: if someone is not already sold on Python, every small quirk and special case becomes another obstacle, and the Python tooling has collected more than a few.

[d0mine]

It shouldn't be that hard to demonstrate "shocking" difference in experience.

Could you provide an explicit list of what do you mean by "a breakdown in my earlier comment"? (obviously, I wouldn't ask for more information in my comments if your previous comments were specific enough) e.g., in language X I can do Y using command Z but Python requires A,B,C instead (implying that Z is "shockingly" better than doing A,B,C).

As I understand, the issue is that you want the structure of a project in a language X to be generated for you by a single command (whatever the project) or that this command must be available by default.

I've googled "python create command-line project template":

  $ pip install -U cookiecutter
  $ cookiecutter https://github.com/audreyr/cookiecutter-pypackage.git

I don't remember using this tool but If you like a machine-generated configuration; it might be the start.

[sjellis]

> It shouldn't be that hard to demonstrate "shocking" difference in experience.

Please try installing Rust with the rustup tool, creating a "Hello world" skeleton CLI tool, and compiling a deployable executable for it. It will take you (not joking) perhaps 10 minutes or less if you have never done anything with Rust before. Then look at how you would add docs and tests. The Rust language is not simple, but the tools are really good. Try the same exercise with Go if you prefer.

If you are willing to give this a try and invest the 10 minutes, you'll understand why I didn't use the phrase "shocking" casually: listing off features doesn't really convey how huge the usability gap is.

> Could you provide an explicit list of what do you mean by "a breakdown in my earlier comment"?

It was this:

> "Python best practice: figure out the correct directory structure by reading docs and looking at GitHub repositories, learn how to write setup.py & setup.cfg & requirements.txt & MANIFEST.in files, setup py.test and tox (because Python 2 still lives), write your README in RST format (as used by nothing else ever), and for bonus points: write your own Makefile. Get depressed when you realize that target platforms either don't have Python or have the wrong version."