amethyst

> Python, JS, C, Bash aren't even particularly great at the problems they solve

I would argue the "problem" that Python really solves is the amount of engineering effort required to read and write code for common software use cases. Ie, it's purpose is to help developers write better code faster and easier than other languages, while execution speed has usually had a lower priority. In that framing, it's great at solving the problem of development time and old code being hard to maintain, and that's why so many engineers like myself love it.

We've been to Muir Woods multiple times and it's easily 400ft from most of the parking spots just to get to the main entrance.

With modern wide angle lenses, it doesn't even need to be pointed directly at you to get you completely in the frame.

> What I am skeptical about is that this will continue to be solved for the next few years: there's always that chance that Google will outright kill it, or Apple/Samsung/whoever will become exclusive to a single car manufacturer, or the manufacturers will somehow bungle this up with a subscription model of some sort.

Or the manufacturers decide they don't like users bypassing their revenue models:

https://arstechnica.com/cars/2023/03/gm-confirms-its-droppin...

FWIW, I absolutely love Carplay and paid extra to have compatible head units installed in any of my previous cars that didn't have built in support. It's been fantastic, but I don't trust manufacturers to do what's in my own best interest.

See also the recent Mozilla privacy findings for cars.

Github has automation to detect and mitigate repos with AWS/GCC API keys. They probably don't (yet?) have equivalents for OpenAI or other similar services that aren't as popular.

PEP 612 made this much better FWIW.

https://peps.python.org/pep-0612/

That will only incentivize posting low quality worthless things in order to improve position and reach in comments. Might as well just charge them $8/mo for the privilege of making other people see their comments.

Edit: I think I misunderstood what you were suggesting (just a chronological timeline?).

TBH I had to read that part two times before realizing that it was describing an an unrolled loop.

Good catch, looks like a mixup somewhere in the writing/editing/publishing pipeline. The correct examples are given in the user guide [1], and I'll see if we can get the post updated accordingly. Thank you!

Edit: the post has been fixed now.

1: https://fixit.readthedocs.io/en/latest/guide.html#custom-rul...

At the moment, it's somewhere around pylint and flake8, depending on the number of lint rules running, but that's with no caching or performance optimization beyond per-file multiprocessing. I have plans for simple caching that should generally make Fixit faster than Flake8 with a warm cache, assuming that custom lint rules are reasonably performant. Fixit already has mechanisms for tracking time spent per rule, and we plan to make it easier to see which rules are the slowest in each run.

That said, I doubt it will ever achieve performance parity with Ruff, given that it's running Python code by design. But we also believe that offering targeted lint rules with auto-fixes more than makes up for time spent running linters by reducing the number of iterations spent during development, shortening code review, etc.

Eg, if there are common mistakes in a codebase that cause frequent rejections or extra iterations in code review, custom lint rules with auto-fixes can help catch — and fix — those mistakes before developers waste hours or days waiting for avoidable rejections.

They are two linters with very different goals. Where Ruff prioritizes speed over all other concerns, and chooses Rust as the method of achieving that goal with a set of generic lint rules, Fixit is focused on making it easy for Python developers to write custom lint rules.

The use of LibCST (which has a parser written in Rust) makes it easy to build lint rules in Python. Fixit allows engineers to write local lint rules in their project repo with a minimum of boilerplate, and then immediately enable them, without needing to write custom plugins or packages, and without needing to rebuild or deploy a new version of Fixit. This lowers the barriers to writing rules, and provides a quick development and feedback cycle when testing them.

Hierarchical configuration allows Fixit to fit well into larger monorepos, with each team/project able to easily control what lint rules run on their code base. Open source projects homed in those monorepos also have tools to ensure that results are the same when running on internal vs external CI systems.

The user guide has a short section on writing custom rules [1], and the API reference also covers the attributes of a LintRule [2]. I plan to document this in more detail at some point in the future.

1: https://fixit.readthedocs.io/en/latest/guide.html#custom-rul...

2: https://fixit.readthedocs.io/en/latest/api.html#lint-rules

It's a pattern that I have used multiple times in the past, and greatly appreciate for modular components like this, but in this specific case, this was the pattern used by the original authors of Fixit 1, and I was very happy to maintain and improve upon that during the redesign.

Hi, I'm Amethyst, the project lead and primary engineer for Fixit 2. Happy to answer any questions here if anyone wants to know more!

> How precise, responsive is reverse thrust

Not at all. Thrust reversers, depending on engine model, can take a few seconds or more to engage, and the engines themselves can take even longer to spool up thrust from idle or to spool down when no longer needed.

3.7 was released in 2018 and is already EOL. Those folks should probably start considering an upgrade...

Another key requirement would have been computer-aided flight control systems. The only reason the B-2 can remain stable during maneuvers is thanks to its fly-by-wire system that translates the pilot's directions into control surface adjustments that achieve the desired results, and continually adjust those controls faster than the human pilot can react.

time lost maybe nullified by increased focus and lack of fatigue due to the caffeine?

Keep in mind that many/most of these tools also need to work in diff review and CI tools, not just in an editor. That said, we primarily support developers using VS Code (with internal LSP/plugins/integrations) or our internal version of Jupyter notebooks. We also have a non-negligible number of folks that prefer alternative IDEs or editors like pycharm, vim, or emacs. We try to build our tools such that they are accessible by CLI or APIs, so that they can fit into any of these systems as needed.

The Cinder team's longterm goal is to upstream as much as we can, and make the rest available as pip-installable extensions that anyone could theoretically install and use on CPython. The fewer internal changes and patches we need to maintain, the faster we can adopt upstream Python releases and all of the associated performance and tooling wins.

It's mostly foundational work around developer tooling and infrastructure that isn't already covered by other dedicated teams (eg, there is a dedicated Cinder team). My latest work has focused around formatting and linting, and includes open source work on µsort, our import sorter [1], and fixit, our custom linter [2] that makes it easy for teams to build and deploy their own custom lint rules with autofixes.

Some of my team mates work on driving internal adoption of Cinder, rolling out new versions of Python everywhere, improvements to our build and packaging systems, supporting other Python tooling teams, etc. There's a lot of cross-functional project work, and our primary goal is to improve the Python developer experience, both internally and externally wherever we can.

1: https://usort.rtfd.io

2: https://fixit.rtfd.io

I'm not familiar enough with Django to say for sure, but I assume at this point it's almost entirely custom ORM and libraries on top of async django routing/response.

It's a heavily modified internal fork of Django. Source: I work on our Python Language Foundation team.

IG verification still requires validating your government ID matching your account name/bio, no? Twitter is just "do you have a working credit card #"?

Sadly, the name "down" was reserved for a trivial CLI tool to ping sites to "see if they are down".

https://pypi.org/project/down/

If they said "pump", you know the gas stations would immediately find a way to put tanks above the level of the cars so that they could operate on gravity instead.

> I have not received a National Security Letter.

source: https://durbin.ee/ as of Wed, May 24 at 1:45 PM PDT

Thank you!

> Dataclasses is notable because it's the only example (I'm aware of) of type hints effecting runtime behavior as part of the stdlib.

FWIW, `typing.NamedTuple` did this in Python 3.5, three years before dataclasses was introduced in 3.7.

    class Foo(typing.NamedTuple):
        a: int
        b: str

    f = Foo(a=1, b="hello")
    print(f.b)  # "hello"

Unrelated: the nostalagia of iliana's favicon is incredible. So much time spent on old modems watching that animation spin while waiting for pages to slowly load in...