11 ms·

Python is a general -purpose programming language. No size fits all. You've ignored "in a simple case" and ignored the next paragraph that discussed "more comp

by d0mine 10y ago

Python is a general -purpose programming language. No size fits all. You've ignored "in a simple case" and ignored the next paragraph that discussed "more complex cases." If I have a task: publish Ubuntu PPA with a package that does X, or deploy a web app on a PaaS, or add a component that massages some data for a numerical simulation on a cluster or something else. I do not see what Go, Rust, .NET do here that Python can't. Obviously, there could be specific use-cases where some language/framework has advantages over other languages/frameworks and (as I said) there may be use-cases that can be improved that why they should be named explicitly -- that is why I've asked in the first place -- so far I don't see "shoking difference" in the general case (I don't doubt that you had experienced the shoking difference for your specific (unnamed) task).

sjellis 10y ago
My original comment was specifically about building a CLI tool, which I did as a learning exercise to practice writing a multi-file Python project that could act as a library as well as a CLI, and be packaged as a wheel for PyPI. Please bear in mind here that I did this because I wanted to learn and follow current best practices, with a project that I specifically picked because it would not require 3rd-party libraries or big frameworks to muddle things. I don't think that it was dissatisfying because Python is a general-purpose programming language, but because the process currently happens to involve an assortment of different tools, piecing together scattered information, and being willing to suffer a few paper cuts like Python versions and multiple old file formats. That was my experience building a simple Python 3 application, and it didn't leave me eager to do it again. We can discuss how Go-style tooling and packaging can also help with the cases that you mentioned, but I didn't really want to stray off into an extended analysis. My original points were just that the overall developer experience that new Python users currently get compares poorly to some other languages, and that is totally fixable. I hope that things do improve, and feel that Pipenv is a very welcome move in that direction.
- d0mine 10y ago
  You says "X is bad", "Y is better" but you don't say how exactly X is bad, in what way Y is better. 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." Put __init__.py in a directory and you've created a Python package where you could add as many modules including other packages as you like. Copy-paste setup.py ("pip init" like "npm init" would help here), update it with your info and to upload a wheel to PyPI, run: $ pip install twine $ python setup.py sdist bdist_wheel $ twine upload dist/* (you might need "twine register". "pip publish" would be nice). I didn't read it but as far as I understand all of this is on one page https://packaging.python.org/distributing/ https://packaging.python.org/distributing/
  - sjellis 10y ago
    > 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.

by d0mine 10y ago

sjellis 10y ago

My original comment was specifically about building a CLI tool, which I did as a learning exercise to practice writing a multi-file Python project that could act as a library as well as a CLI, and be packaged as a wheel for PyPI. Please bear in mind here that I did this because I wanted to learn and follow current best practices, with a project that I specifically picked because it would not require 3rd-party libraries or big frameworks to muddle things. I don't think that it was dissatisfying because Python is a general-purpose programming language, but because the process currently happens to involve an assortment of different tools, piecing together scattered information, and being willing to suffer a few paper cuts like Python versions and multiple old file formats. That was my experience building a simple Python 3 application, and it didn't leave me eager to do it again. We can discuss how Go-style tooling and packaging can also help with the cases that you mentioned, but I didn't really want to stray off into an extended analysis. My original points were just that the overall developer experience that new Python users currently get compares poorly to some other languages, and that is totally fixable. I hope that things do improve, and feel that Pipenv is a very welcome move in that direction.

d0mine 10y ago
You says "X is bad", "Y is better" but you don't say how exactly X is bad, in what way Y is better. 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." Put __init__.py in a directory and you've created a Python package where you could add as many modules including other packages as you like. Copy-paste setup.py ("pip init" like "npm init" would help here), update it with your info and to upload a wheel to PyPI, run: $ pip install twine $ python setup.py sdist bdist_wheel $ twine upload dist/* (you might need "twine register". "pip publish" would be nice). I didn't read it but as far as I understand all of this is on one page https://packaging.python.org/distributing/ https://packaging.python.org/distributing/
- sjellis 10y ago
  > 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.