Hacker News Reader

Comment by Waterluvian | Hacker News Reader

Is toml even supported in the standard library? This seems just bizarre. Python's really overtaking node for massive churn. I feel like an old guy when peers say, "don't use virtual environment use pipenv." then someone says no no don't even use that, use poetry. Etc.

I think about 50% of why I enjoy, in my soul, about Rust when I'm hacking away and personal goofs is that the dependency and project management system is all first class and pretty decent and I sure hope they don't go changing it much.

View on HN

Here's their justification for using it. It makes sense to me.

https://www.python.org/dev/peps/pep-0518/#overview-of-file-f...

It makes sense to use toml. It makes zero sense not to bring pytoml in the stdlib before doing so. The way this was handled is a little absurd.

The PEP has provisional status. Maybe before it lands it will be brought in.

> The pytoml TOML parser is ~300 lines of pure Python code, so being outside the standard library didn't count heavily against it.

From the link. Makes sense I think.

It was on purpose because TOML has not reached 1.0 yet and breaking people using a module in the stdlib for parsing TOML because TOML itself changed would be an absolute mess. Plus not a single packaging project said it was an issue to either depend on or vendor a TOML parser.

Once TOML hits 1.0 I plan to work on getting a TOML parser into Python's stdlib.

(disclaimer: I am one of the co-authors of PEP 518 that apparently handled things in way that was "a little absurd" .)

But really goes against 'batteries included' not having TOML support in standard library.

Rust management system is first class because the language has been designed from scratch 10 years ago.

Python has been around since 1991. It came out before installing dependencies from internet was a thing. It had support for Windows XP, Atari, Solaris. You gotta be able to pip install stuff that are written in C (numpy) or in Fortran (scipy). It had been implemented in the JVM, .net, and Python itself using pypy.

All those years, what we knew about or needed from packaging system changed, and the tooling followed. We had easy_install, then setuptools, then distutils, then distutils2, the pip + setuptools again. We had virtualenv, then venv.

You cannot break from the past easily, especially on such a popular language, with half of it's user not even being devs.

While you're not wrong that it's much easier to build systems with the advent of foresight, Rust also supported Windows XP, Solaris, stuff in C or Fortran. That's not the issue.

It's really purely the "designed from scratch 10 years ago" (though, only six years for Cargo).

Python also doesn't support yaml in the standard library, interestingly.

Yaml is a big mess.

I do really like strict-yaml, however (last time I checked) it is just a hack to simplify the large PyYaml compiled package.

Thanks for the vote of confidence.

fwiw version 2.0 of strictyaml will feature its own specification and parser.

Great to hear. I've been manually deactivating almost all of the features of PyYaml for almost a decade now. Over and over. So quite happy someone is taking up the cause.

Reply on news.ycombinator.com