6 ms·

> most fractured development ecosystems of any moderately used language Can you elaborate? What's done wrong with Python and right with other "moderately used

by est 2y ago

> most fractured development ecosystems of any moderately used language Can you elaborate? What's done wrong with Python and right with other "moderately used language" ? For start, C/C++ doesn't even have an official ecosystem. For Java or Golang, it looks better only because the "ecosystem" does not always include native extensions like cgo or JNI. Once you add them the complexity were no better than Python's

rwmj 2y ago
Python .pth files are horrific. Here's an actual .pth file I was dealing with the other day (from Google Cloud Storage) which completely prevents you from overriding the module using PYTHONPATH: import sys, types, os;has_mfs = sys.version_info > (3, 5);p = os.path.join(sys._getframe(1).f_locals['sitedir'], *('google',));importlib = has_mfs and __import__('importlib.util');has_mfs and __import__('importlib.machinery');m = has_mfs and sys.modules.setdefault('google', importlib.util.module_from_spec(importlib.machinery.PathFinder.find_spec('google', [os.path.dirname(p)])));m = m or sys.modules.setdefault('google', types.ModuleType('google'));mp = (m or []) and m.__dict__.setdefault('__path__',[]);(p not in mp) and mp.append(p)
- talideon 2y ago
  If .pth files are the worst thing you can find to complain about, Python's doing pretty well. That horrific .pth file in question is better placed as the feet of its creators than the mechanism itself.
  - rwmj 2y ago
    The fact they considered allowing executable code in path lookups shows a certain attitude.
    - oefrha 2y ago
      It shows that the language is highly dynamic and you can patch anything? The .pth mechanism allows the party controlling the Python installation (site) to run some init code before any user code, basically an rc mechanism. Nothing more, nothing radical. Maybe you’re unhappy with the dynamism, in which case your complaint is misplaced.
      - rwmj 2y ago
        In this case it prevents someone using PYTHONPATH to alter or override the order that modules are loaded. Hard to justify that.
        talideon 2y ago
        Again, the blame for that is at the feet of those who wrote the .pth file, not the mechanism itself.
    - talideon 2y ago
      I searched all my machines and could only find simple ones, all related to some legacy crud for setuptools, one of which was a way to get eggs (which nobody should be using these days) to work. They're barely a thing these days and mostly a relic from before the end of the Great Setuptools Stagnation and the site package all but discourages their use.
    - talideon 2y ago
      You'll also be happy to learn that there's an issue open to deprecate them: https://github.com/python/cpython/issues/78125 https://github.com/python/cpython/issues/78125 It's been open since 2018 though. You might find it worth a read.
      - rwmj 2y ago
        Yup, subscribed to that one already!
- est 2y ago
  I agree those particular .pth files were horrific. But python package made by Google were noturously bad. Its awefulness dates back to the GAE days.
crabbone 2y ago
You have Anaconda packaging world vs PyPI. You have pyproject.toml for project management, which is not supported by Anaconda or the flagship documentation generation tool: Sphynx. You have half a dozen of package installers, none of them work to the full extent / all have different problems. You have plenty of ways to install Python, all of them suck. You have plenty of ways to do some common tasks, s.a. GUI, Web, automation: and all of them suck in different ways, w/o a hint of unifying link. Similarly, you have an, allegedly, common relational database interface, but most commonly used SQL bindings don't use it. And the list goes on.
- est 2y ago
  > You have Anaconda packaging world vs PyPI As I said, it's only because .so extensions were hard. If every package were pure Python, I would simply copy paste them in my source code `lib` path. Don't laugh at me, this is called "vendoring" or "static linking" by other languages, and the "requests" famously included a version of urllib3 for quite a while
  - crabbone 2y ago
    Oh, but there's plenty more to Python packaging... unfortunately. You can put a ton of random stuff that's not Python modules into wheels: scripts, data, headers. Anaconda doesn't support most of that.
- Demiurge 2y ago
  > You have Anaconda packaging world vs PyPI There is no fracture or "versus" here. You can pip install on top of Anaconda. Anaconda provides a more stringent solver and OS level packages that some pip level modules often depend on, it just solves the integration problem, but I use both, including requirements.txt in my Anaconda env.yml all the time. > You have pyproject.toml for project management, which is not supported by Anaconda or the flagship documentation generation tool: Sphynx. Again, Anaconda is not "standard" python thing, it is a replacement for build OS level packages, such as GDAL, which is a just a subset of Python modules. Anaconda does not need to support standard python tooling, because those python tools exist outside of Anaconda. To simplify, for every Anaconda package, you can likely find it in PyPI, but for every PyPI, you will not find it in for conda. Anaconda is not a competitor for PyPI, it does not need to replicate every PyPI feature. > You have plenty of ways to install Python, all of them suck. What does this actually mean? You install Python with all the major OS installation methods, and absolutely none of them suck, any more than installing anything on this OS does. The standard ways are Python Setup.exe, apt-get install, and brew install. Yes, you can additional options such as conda distros, yet what exactly sucks about them? Nothing. > You have plenty of ways to do some common tasks, s.a. GUI, Web, automation: and all of them suck in different ways, w/o a hint of unifying link. I think I'm starting to get it. Everything sucks if you've been around long enough. Django is vastly prevalent web framework. wx widgets is standard, and there are bindings for most GUI toolkits. There are many toolkits, is it Pythons fault they all got invented by different organizations? Is it an interpreted language responsiblity to provide a cross platform GUI toolkit for you? > Similarly, you have an, allegedly, common relational database interface, but most commonly used SQL bindings don't use it. What are you even talking about? Who in the world cares about this? People use database specific libraries, in every single language, because every database has its own set of features. > And the list goes on. Your list reeks of someone flinging critiques without even knowing what they’re talking about—just a lot of hot air fueled by emotional baggage, likely from some long-dead language you once cherished before it was mercifully abandoned.

by est 2y ago

rwmj 2y ago

Python .pth files are horrific. Here's an actual .pth file I was dealing with the other day (from Google Cloud Storage) which completely prevents you from overriding the module using PYTHONPATH: import sys, types, os;has_mfs = sys.version_info > (3, 5);p = os.path.join(sys._getframe(1).f_locals['sitedir'], *('google',));importlib = has_mfs and __import__('importlib.util');has_mfs and __import__('importlib.machinery');m = has_mfs and sys.modules.setdefault('google', importlib.util.module_from_spec(importlib.machinery.PathFinder.find_spec('google', [os.path.dirname(p)])));m = m or sys.modules.setdefault('google', types.ModuleType('google'));mp = (m or []) and m.__dict__.setdefault('__path__',[]);(p not in mp) and mp.append(p)

talideon 2y ago
If .pth files are the worst thing you can find to complain about, Python's doing pretty well. That horrific .pth file in question is better placed as the feet of its creators than the mechanism itself.
- rwmj 2y ago
  The fact they considered allowing executable code in path lookups shows a certain attitude.
  - oefrha 2y ago
    It shows that the language is highly dynamic and you can patch anything? The .pth mechanism allows the party controlling the Python installation (site) to run some init code before any user code, basically an rc mechanism. Nothing more, nothing radical. Maybe you’re unhappy with the dynamism, in which case your complaint is misplaced.
    - rwmj 2y ago
      In this case it prevents someone using PYTHONPATH to alter or override the order that modules are loaded. Hard to justify that.
      - talideon 2y ago
        Again, the blame for that is at the feet of those who wrote the .pth file, not the mechanism itself.
  - talideon 2y ago
    I searched all my machines and could only find simple ones, all related to some legacy crud for setuptools, one of which was a way to get eggs (which nobody should be using these days) to work. They're barely a thing these days and mostly a relic from before the end of the Great Setuptools Stagnation and the site package all but discourages their use.
  - talideon 2y ago
    You'll also be happy to learn that there's an issue open to deprecate them: https://github.com/python/cpython/issues/78125 https://github.com/python/cpython/issues/78125 It's been open since 2018 though. You might find it worth a read.
    - rwmj 2y ago
      Yup, subscribed to that one already!
est 2y ago
I agree those particular .pth files were horrific. But python package made by Google were noturously bad. Its awefulness dates back to the GAE days.

crabbone 2y ago

You have Anaconda packaging world vs PyPI. You have pyproject.toml for project management, which is not supported by Anaconda or the flagship documentation generation tool: Sphynx. You have half a dozen of package installers, none of them work to the full extent / all have different problems. You have plenty of ways to install Python, all of them suck. You have plenty of ways to do some common tasks, s.a. GUI, Web, automation: and all of them suck in different ways, w/o a hint of unifying link. Similarly, you have an, allegedly, common relational database interface, but most commonly used SQL bindings don't use it. And the list goes on.

est 2y ago
> You have Anaconda packaging world vs PyPI As I said, it's only because .so extensions were hard. If every package were pure Python, I would simply copy paste them in my source code `lib` path. Don't laugh at me, this is called "vendoring" or "static linking" by other languages, and the "requests" famously included a version of urllib3 for quite a while
- crabbone 2y ago
  Oh, but there's plenty more to Python packaging... unfortunately. You can put a ton of random stuff that's not Python modules into wheels: scripts, data, headers. Anaconda doesn't support most of that.
Demiurge 2y ago
> You have Anaconda packaging world vs PyPI There is no fracture or "versus" here. You can pip install on top of Anaconda. Anaconda provides a more stringent solver and OS level packages that some pip level modules often depend on, it just solves the integration problem, but I use both, including requirements.txt in my Anaconda env.yml all the time. > You have pyproject.toml for project management, which is not supported by Anaconda or the flagship documentation generation tool: Sphynx. Again, Anaconda is not "standard" python thing, it is a replacement for build OS level packages, such as GDAL, which is a just a subset of Python modules. Anaconda does not need to support standard python tooling, because those python tools exist outside of Anaconda. To simplify, for every Anaconda package, you can likely find it in PyPI, but for every PyPI, you will not find it in for conda. Anaconda is not a competitor for PyPI, it does not need to replicate every PyPI feature. > You have plenty of ways to install Python, all of them suck. What does this actually mean? You install Python with all the major OS installation methods, and absolutely none of them suck, any more than installing anything on this OS does. The standard ways are Python Setup.exe, apt-get install, and brew install. Yes, you can additional options such as conda distros, yet what exactly sucks about them? Nothing. > You have plenty of ways to do some common tasks, s.a. GUI, Web, automation: and all of them suck in different ways, w/o a hint of unifying link. I think I'm starting to get it. Everything sucks if you've been around long enough. Django is vastly prevalent web framework. wx widgets is standard, and there are bindings for most GUI toolkits. There are many toolkits, is it Pythons fault they all got invented by different organizations? Is it an interpreted language responsiblity to provide a cross platform GUI toolkit for you? > Similarly, you have an, allegedly, common relational database interface, but most commonly used SQL bindings don't use it. What are you even talking about? Who in the world cares about this? People use database specific libraries, in every single language, because every database has its own set of features. > And the list goes on. Your list reeks of someone flinging critiques without even knowing what they’re talking about—just a lot of hot air fueled by emotional baggage, likely from some long-dead language you once cherished before it was mercifully abandoned.