Live data from Hacker News

Python Is Eating the World

zdnet.com

121–130 of 993 posts

Re: Python Is Eating the World

#121

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.

This is about as sensible to me as saying it is a good idea because most trains are longer than they are wide. Who cares about those things, we use computers that nearly all have 4:3 or 16:~10 displays (or wider), and many of use use more than one of them.

Re: Python Is Eating the World

#122
post #54

Earlier 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.

> Pip freeze does not resolve transitive dependencies

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 another

This 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

#123
post #103
post #55

Earlier 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?

See https://thenewstack.io/which-programming-languages-use-the-l...

Re: Python Is Eating the World

#124

In 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…

The 2 to 3 transition was already too difficult.

It now has optional typing.

Re: Python Is Eating the World

#125
post #33

Python 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.

Python is uniquely ill-suited for dependency management compared to many other languages. For some reason dependencies are installed into the interpreter itself (I know what I just said is very imprecise/inaccurate but I think it gets the point across).

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

#126

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…

> it's 2019

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

#127
post #61

Earlier 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

Maybe I'm misremembering, but, isn't the point of pip install --user to get things onto your import path when running the base Python interpreter, just like sudo pip install would (except scoped to your user)? If so, wouldn't installing an incompatible newer version of some library (or worse, a broken version) break system commands that import that library, when that same user is running those commands?

Re: Python Is Eating the World

#128
"I was very disappointed in how the people who disagreed technically went to social media and started ranting that the decision process was broken, or that I was making a grave mistake. I felt attacked behind my back,"

May I ask who did he mentioned about ?

Re: Python Is Eating the World

#129
post #4

If 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.

The default should actually be a shared cache that is symlinked to local projects, like pnpm does.

Re: Python Is Eating the World

#130
post #55

Earlier quoted context omitted.

One thing people overlook with interpreted languages is the environmental impact in terms of extra electricity used.

You're gonna flip when you hear about the environmental impact of a developer.

just imagine using python of cryptocurrency mining.
Post reply on HN