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…
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.
Python Is Eating the World
121–130 of 993 posts
Re: Python Is Eating the World
#122Earlier quoted context omitted.
Yes, those are caught when using pip freeze.
> Yes, those are caught when using pip freeze. No they are not. Pip freeze does not resolve transitive dependencies, nor does pip know what to do if your transitive dependencies conflict with each another.
I don't think this is correct:
$ python3 -m venv /tmp/v
$ /tmp/v/bin/pip install flask
[...]
Collecting MarkupSafe>=0.23 (from Jinja2>=2.10.1->flask)
[...]
$ /tmp/v/bin/pip freeze | grep MarkupSafe
MarkupSafe==1.1.1
> nor does pip know what to do if your transitive dependencies conflict with each anotherThis is true, but because Python exposes all libraries in a single namespace at runtime, there isn't actually anything reasonable to do if they genuinely conflict. You can't have both, say, MarkupSafe 1.1.1 and MarkupSafe 1.1.0 in PYTHONPATH and expect them to be both accessible. There's no way in an import statement to say which one you want.
However, it's notable that pip runs into trouble in cases where transitive dependencies don't genuinely conflict, too. See https://github.com/pypa/pip/issues/988 - this is a bug / acknowledged deficiency, and there is work in progress towards fixing it.
Re: Python Is Eating the World
#123Earlier quoted context omitted.
One thing people overlook with interpreted languages is the environmental impact in terms of extra electricity used.
What is that impact, quantitatively?
Re: Python Is Eating the World
#124In 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 softwar…
It now has optional typing.
Re: Python Is Eating the World
#125Python 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…
Is there a model dependency management system for some other language that addresses all these issues? Dependency hell is everywhere.
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.
Re: Python Is Eating the World
#126Reading 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…
use an auto-linter - black is what most seem to be using
and stop using flake8/pylint directly, try prospector with sensible --sensitivity
Re: Python Is Eating the World
#127Earlier quoted context omitted.
pip install --user and sudo pip install won't break your venv. But they will break your system Python and any OS commands that depend upon system Python, perhaps including pip and virtualenv themselves, which is incredibly confusing. I've helped both friends and coworkers un-break it, and the symptoms aren't generally obvious. I wrote the patch to pip in Debian to prevent sudo pip install from removing files from Deb…
> But they will break your system Python and any OS commands that depend upon system Python Sudo pip install might on some distros (and I consider this to be a bug on the distro level, not a Python issue) but I've never heard of --user breaking anything
Re: Python Is Eating the World
#128May I ask who did he mentioned about ?
Re: Python Is Eating the World
#129If 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…
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.