ambivalence

oh no, AI too powerful too quick. let me quit to work on tools to make AI better at debugging code.

excellent logic, m'lord.

What the other person is trying to explain to you is that your Yubikey solution fails the following scenario: you leave your laptop at school.

With TouchID, nobody can unlock it. With a Yubikey in the USB-C port, anyone could unlock it.

That's why macOS Yubikey login integration requires you to type in a PIN on the lock screen. At which point it's no different from typing in a password.

Not equivalent to TouchID at all.

A big chunk of the performance gain comes from the fact that with tail calls the CPU doesn't have to reset the registers (configured through the `preserve_none` calling convention).

Simon Willison is a great guy, but he's not a Python core developer and his ad hoc benchmark is not what the CPython core team members are using. For the latter, see https://github.com/faster-cpython/benchmarking-public

Wouldn't kill them to mention that all the heavy lifting is done by Pyodide.

> I'd maybe quibble with "running natively on WebAssembly with speed in the same order of magnitude as Rust" given I expect that statement would be just as true if you replaced Rust on WebAssembly with the equivalent JavaScript.

This is incorrect. It's widely publicized that WebAssembly is often faster than JavaScript.

Work on what you want, so don't let me deter you. But in my personal case, what pushed me from fish to xonsh was that I could never quite internalize the way it wanted to do functions, if statements (and tests inside them) and loops.

Once you were reading code, it made sense for the most part. But when I had to write a new multiline command or a script, I had to look things up in documentation constantly. For my brain "similar but different" was torture, not an advantage.

With Xonsh you get real Python and this solves all my problems. As soon as you learn what $VAR, $(CMD), and @EXPR do, you're good to go!

Not impressed with tako. Replaces the BSD license with GPL for mostly removing functionality and reverts.

It looks unmaintained. Last release 5 years ago, documentation is sporadic.

Reminds me of some of the angry forks of Black that get like 100 downloads a year.

Markdown is plaintext so you decide what it means. I personally write *italic* and **bold**, so I can use _underline_. Most Markdown to HTML converters would make the last example into italic, but you can customize many of them.

Commonmark doesn't even mention "bold", "italic", and "underline". It just says "emphasis" and "strong emphasis". You can style it however you want.

I wholeheartedly agree with this post. I also keep my notes in Markdown, I also have plenty of Python scripting around them, including automatic publishing of my website.

I use FSNotes today on macOS and iOS. Both apps are open source, both use well-structured .textbundle directories that separate Markdown content from JSON metadata and binary attachments. Synchronization happens through Git. It's a very powerful combination.

Ironically, I wrote a blog post some 8 years ago about this very subject. That blog post is now offline.

Not sure how much "trust" I actually need there. It's mostly convenience for me where it's easy to kill results from websites you never want to see again. This process allows for getting terrific results real quick after you start using it. Also not having ads is great, because you know the result ordering isn't affected by that, and your ad blocker won't be breaking your experience every now and then.

On top of that it's pretty fast and the price is right.

Xonsh is a fantastic shell. I literally think they are most hindered by the name at this point, since it's one of those clever names that are pronounced in a peculiar way and one that doesn't convey too well that it's really Python + sh in a beautifully consistent design.

It's very easy to switch if you're willing to spend 30 minutes to go through this talk about its design by the author: https://www.youtube.com/watch?v=uaje5I22kgE

After this short intro you will know how Python and shell interact within xonsh and you'll avoid surprises.

I wish it started faster, but it's a really small price to pay for having Python 3.13 open literally at all times.

You know that people change their minds and now Guido is working as part of a team at Microsoft that is literally called "Faster CPython"?

> Even the most perfectly-written Python code will still be dog-slow and require an enormous budget to actually run at scale.

Nah, asyncio on uvloop is plenty fast.

It is on Mastodon as well, actually: https://mastodon.social/@ambv/110665808046065754

If you want real irony here, it's this: powering an app called Threads with Python that's got a global interpreter lock which makes threading hard.

Get it? Threads, threading...? OK, I'll see myself out.

In short: static analysis, unit tests, staging environments, effective log aggregation.

The first one is a big productivity booster as it shows you bugs before you commit them.

Here's a post about this, not exactly new but still describing the general principles very well: https://instagram-engineering.com/static-analysis-at-scale-a...

A fair point about what? Threads is out for less than a day, I have 8 followers there so far. I originally posted this information on Mastodon, actually: https://mastodon.social/@ambv/110665808046065754

However, I have a much larger following on Twitter, so it was the tweet that got picked up by someone here on HN.

We'll see how this looks like in twelve months.

The fork is where the tweaks live.

There are three related terms: mocking, faking, and stubbing. They mean subtly different things, which the article points out. The author prefers the last one, and uses the middle one for complex cases, avoiding mocks altogether. But that doesn't mean he leaves third-party networking libraries run wild in unit tests. In fact, the very example he builds in the article shows how to avoid that without having to create a mock. Maybe you need to read it again?

As long as you can easily review code side-by-side with line numbers intact, you're good. The default was chosen for lower resolution 13" laptop monitors to be able to display the Phabricator diff page (think: Github PR review page) without having to wrap any lines.

Yes, and yes. Edit: and yes.

This is now improved. Black is compiled with mypyc, should be roughly 2X faster than before.

This was decided very early in the project, the discussion can be read here: https://github.com/psf/black/issues/51

Thanks for the link. I just moved the website to Netlify from Fastmail. Hopefully the DNS on your side will update soon.

At 4.2 million downloads per month, it's not exactly a prototype toy either.

There are quite a few inaccuracies here.

Guido is now working on Python performance at Microsoft and is not the BDFL anymore. Instead, there is a five-person Steering Council overseeing Python.

The best C/C++ interaction options include Cython, cffi, and pybind11. None of those are mentioned. I don't know anybody still recommending SWIG.

No mention for FastAPI or asyncio is a big omission in the Web backend use case. Relatedly, the article still recommends Requests when the community is largely moving to httpx which supports both blocking and async networking.

For packaging, the author mentions and links to Conan (a C++ package manager) which sounds like he misheard Conda.

He's also saying that the easiest way to get Python on Windows is chocolatey. Well, if you type "python" into a command prompt on a fresh install of Windows, it will take you to the Windows Store where you can install the latest Python release with one click. For many users this gotta be easier than figuring out chocolatey.

There is no discussion on "Python, the language" and its state in 2021. I was looking forward to a discussion on that.

I don't mean to pile on but the definitive title sounded like we'd get something pretty authoritative. This ain't that.