HN user

Spiritus

3,606 karma
Posts93
Comments301
View on HN
www.djangoproject.com 4y ago

Django 4.0

Spiritus
473pts219
www.psycopg.org 4y ago

Building a Django driver for Psycopg 3

Spiritus
171pts24
lwn.net 5y ago

Making CPython Faster

Spiritus
5pts2
endoflife.date 5y ago

Endoflife.date

Spiritus
3pts0
daniel.haxx.se 5y ago

I am an 80 column purist

Spiritus
73pts78
fasterthanli.me 5y ago

Veronica Mars and NTLM password hashes

Spiritus
2pts0
python-patterns.guide 6y ago

The Composition over Inheritance Principle

Spiritus
1pts0
breadcrumbscollector.tech 6y ago

Stop Naming Your Python Modules “Utils”

Spiritus
2pts0
www.hashicorp.com 6y ago

HashiCorp Nomad 0.11 Beta

Spiritus
2pts0
www.db-fiddle.com 6y ago

DB Fiddle – SQL Database Playground

Spiritus
2pts0
www.raspberrypi.org 6y ago

Thermal Testing Raspberry Pi 4

Spiritus
11pts3
hyper.is 7y ago

Hyper 3 Released

Spiritus
4pts1
github.com 8y ago

Vibora: Fast, asynchronous and sexy Python web framework

Spiritus
19pts3
lucumr.pocoo.org 9y ago

Diversity in Technology and Open Source

Spiritus
41pts78
github.com 9y ago

Show HN: CLI tool to inspect mp4 files in a tree-like view

Spiritus
3pts0
medium.com 9y ago

Code boilerplate: Is it always bad? A case study between Python and Go

Spiritus
17pts2
github.com 9y ago

Skim: Fuzzy Finder in Rust

Spiritus
2pts0
groups.google.com 9y ago

Proposal to delete the r/golang subreddit

Spiritus
37pts17
mypy-lang.blogspot.com 9y ago

MyPy 0.4.6 Released

Spiritus
1pts0
www.youtube.com 9y ago

RevDB, a reverse debugger for Python

Spiritus
2pts0
mail.python.org 9y ago

PEP-526: Syntax for Variable and Attribute Annotations

Spiritus
4pts1
hynek.me 9y ago

Better Python Object Serialization

Spiritus
1pts0
rhodesmill.org 10y ago

The Clean Architecture in Python (2014)

Spiritus
4pts1
unwiredcouch.com 10y ago

Make and Go for fun and profit

Spiritus
1pts0
gggritso.com 10y ago

Human Git Aliases

Spiritus
7pts1
github.com 10y ago

Benchmarks of Go serialization methods

Spiritus
2pts0
news.ycombinator.com 10y ago

Ask HN: Is startup equity just snake oil?

Spiritus
21pts24
www.dragonflybsd.org 10y ago

DragonFly BSD 4.4 released

Spiritus
12pts0
pkgsrc.se 10y ago

NetBSD's pkglint tool reimplemented in Go

Spiritus
1pts0
github.com 10y ago

Fast HTTP package for Go

Spiritus
7pts6
MCP is dead? 2 months ago

CLIs have to be distributed. Also have to be kept up to date. An MCP doesn't t have to concern itself with backwards compatibility and can be changed willy nilly since it's essentially always up to date.

It's also easier to manage for non-tech people. Try telling the people over at HR or finance to install a CLI.

It might be worth excluding certain directories from Spotlight to prevent it from indexing node_modules etc which tend to be massive but mostly useless from a Spotlight search perspective.

I suspect you are fighting the tide of common practice in the Python community.

I hope not!

Sorting module- and from-imports separately also makes it much easier for many people to visually scan a block of imports.

For me it's the opposite. My brain skips over the irrelevant parts (i.e. import/from). Not moving the import also produces better git diffs

For me µsort is a non-starter since it doesn't ignore the import/from part when sorting lexicographically. So when an import changes from `import foo` to `from foo import bar` (and vice versa), the import is moved. Sorting should start at the package name, nothing else.

It's likely because of this (custom Postgres client, request pipelining and not doing sync/commit after each query):

[Multiple Queries] This is the first test where Just(js) has quite a big lead. This is likely due to the fact it is using a custom postgres client written in Javascript and taking full advantage of pipelining of requests. It also avoids sending a Sync/Commit on every query. As far as I am aware this is within the rules but will be happy to make changes to sync on every query if it is not.

https://just.billywhizz.io/blog/on-javascript-performance-01...

Homebrew 3.0 5 years ago

Then `HOMEBREW_NO_AUTO_UPDATE` is probably for you.

If set, do not automatically update before running brew install, brew upgrade or brew tap.

[...] from time to time I need to write a script or use a popular python library like pygments and I used to hate having to do anything with python because of how difficult it seemed to install anything

Not sure I understand why you're having so much trouble. It's literally two commands:

    $ python3 -m venv venv  # Create virtualenv
    $ ./venv/bin/pip install pygments
However! One unfortunate thing with this is that `python3 -m venv` doesn't include the 'wheel' package in the virtualenv out-of-the-box. So it's often a good idea to install/upgrade pip, setuptools and wheel after creating the virtualenv:
    $ ./venv/bin/pip install -U pip setuptools wheel

Yes, I was genuinely asking. I'm very familiar with how the Python ecosystem works (I've been using it professionally for the past 8 years or so), and I disagree with your assessment. At least not when comparing to other dynamic languages.

Those libraries are installed by Pip... somewhere on your system.

They go into your virtualenv.

And then Python has to find it somehow at runtime.

If you use a virtualenv, this works 99.9% of the time.

That relies on environment variables being set correctly

What environment variables? Just use `./venv/bin/python` directly without environment variables.

a huge mess even before you consider things like virtualenv

There's nothing to consider, always use a virtualenv. It's the same for thing for Node, except it implicitly handles it for you.

and the fact that non-Linux systems usually have multiple copies of Python installed (and Python 2 and 3!).

How is that a problem? Just pick the interpreter you want to use when creating the virtualenv:

    virtualenv -p /usr/bin/python2 venv
    virtualenv -p python3 venv
    virtualenv -p python3.7 venv
> Consider the alternative: Go compiles programs to a single statically linked executable with no dependencies. You literally just copy one file to your target machine and run it. It basically can't fail. That's part of the reason Go is so popular for server stuff.

I agree that Go got it mostly right and it just works, except for that fact that it didn't even have a package manager for like 10 years so pinning dependencies was impossible unless you forked repositories.

Even JavaScript - for all the hate node_modules gets for being enormous, at least it works reliably!

In what way is Python + virtualenv + requirements.txt less reliable?