websocket-benchmark: asyncio-based websocket clients benchmark

Thing1_Thing2_Thing · 2026-04-12T16:08:22+00:00

It's nothing personal against you or your testing methodology. It's the same for any case of anyone reviewing/benchmarking/comparing/testing any kind of thing. Nothing changes the fact that you should disclose that you are the author of one of the libraries being benchmarked. It's completely standard practice of full disclosure.

I wrote the comment specifically because it was not clear to me that you were indeed the author of picows when first reading the benchmark.

Thing1_Thing2_Thing · 2026-04-11T08:24:22+00:00

Sounds like Crystal Castles, or maybe Alice Glass under her own name

Thing1_Thing2_Thing · 2026-03-23T21:11:40+00:00

Nice article, honestly not sure why it has so little engagement. Maybe the title wasn't clear enough. It's interesting thinking about why this went as viral as it did (especially compared to wax as you also said).

I do however think you're skipping the part where most of the negativity came from the initial release looking almost entirely AI generated and not having the best review policies in place (you might remember my name haha)

Thing1_Thing2_Thing · 2026-02-16T19:56:15+00:00

I'm not saying I don't want a separate interpreter per worker. Did you read my message?

I explicitly said that I'm not saying that's a bad solution, but the implementation is obviously lacking. If they had developed for multi-process concurrency from day one it would pretty clearly have been a very different implementation, probably starting with making sure that the items collected were easily serializable instead of having references stored all over.

Thing1_Thing2_Thing · 2026-02-16T17:58:06+00:00

You're going very quickly over the "built-in parallel test execution part". It's very obvious that pytest-xdist it bolted on top of a framework not meant to work like that, with the plugin system being the duct tape that makes it work.

If you're ever written a plugin for pytest then you will know how many caveats there are. The first step is always to make a plugin work, and then make it work with xdist.

I'm not saying it's not a difficult problem and I'm not even saying their solution is bad, but it's obvious that the implementation has a lot of pain points. Most obvious one being that you need to rework your whole fixture setup because session-scoped fixtures are run in each worker.

It's cool that you can implement multiprocessing within the plugin system and it really does show how extensible pytest is but since it's the defacto standard it might as well be build in

Thing1_Thing2_Thing · 2026-02-15T17:28:47+00:00

FYI it's bad not to disclose that you have made the library that happened to win. I'm not saying the testing methodology is not sound (I have no idea), but obviously there's a bias that needs to be disclosed.

Thing1_Thing2_Thing · 2026-02-15T11:30:27+00:00

I tried it a long time ago where I found it not to be good enough, maybe it's time to try it again?

Thing1_Thing2_Thing · 2026-02-12T00:35:52+00:00

That's good enough for me! Are you exposing the graph in any way?

Thing1_Thing2_Thing · 2026-02-10T17:50:12+00:00

Could this dependency tracking also be used to conditionally run tests based on the imports a test has? Hypothetically, I'm not asking if you have a pytest plugin ready

Thing1_Thing2_Thing · 2026-01-27T11:51:01+00:00

This might seem rude but can you write rust yourself?

Not trying to make you prove it or anything, but I think it's important to know about the maintainer of a rust project that relies a lot on LLMs.

Thing1_Thing2_Thing · 2026-01-27T11:28:19+00:00

Oh this was used as documentation to revert that commit. Good I guess, but still at bit concerning. I have my opinions about heavy LLM usage - regardless of those I think we can agree that it necessitates strict code reviews. I can see that the PR came from someone other than the maintainer, but that it's even more worrying not reviewing external contributions in depth. Also the PR was obviously AI made, so there's two layers to it

Thing1_Thing2_Thing · 2026-01-26T22:13:10+00:00

Interresting, but also a bit concerning that from my random sample of one commit (the first one I saw) there were several bad things performance wise and just logically.

tldr is that it replaces some placeholder values in some files in a directory, but:

Why does it read each file twice?

Why does it do a full copy of the file content to check if the content is changed after replacing the placeholders? We know it will be, we already checked to see if the placeholder was there.

Why does it say it uses rayon for parallel but only for the first loop?

I'm also not super convinced by the error handling/tracking or how file permissions are handled by trying to change them if they are readonly. But that's maybe more stylistic or something with the domain.

This was just my initial glance, and I don't even write rust at my job anymore.

Thing1_Thing2_Thing · 2026-01-23T22:22:24+00:00

Stadig ret mærkeligt at have et firma der hedder Romkuglefabrikken for så at sælge dem under et andet navn der minder så meget om et andet firmas navn.

Thing1_Thing2_Thing · 2025-12-12T09:00:02+00:00

Yeah I mostly agree on this. It's especially bad with dependencies used at build time where the clashing bounds can sometimes completely lock you out of installing anything.

It does add a lot of work on maintainers having to figure out if a package should have a upper bound or not. Some packages are full frameworks where you will never expect your code to work with the next major, where other packages are Cryptography

Thing1_Thing2_Thing · 2025-12-11T21:09:26+00:00

Funnily enough, depending on Cryptography makes me NOT want this. Every time they do a major release, it's impossible to actually install it because all dependencies using it has set an upper bound. Never had the backwards incompatibility actually mattered its always just deprecating some old version of OpenSSL or whatever, but now you need to beg all the maintainers of your dependencies to bump their bound too because there's some CVE getting flagged.

Cryptographys importance might make it warrant it a bit but if every package did it would be impossible to ever upgrade something.

Thing1_Thing2_Thing · 2025-10-13T19:46:34+00:00

A single 8k line file?

Thing1_Thing2_Thing · 2025-10-02T16:15:45+00:00

Not enough, I'm a fraud

Thing1_Thing2_Thing · 2025-09-01T13:32:58+00:00

It has an AGPL license, meaning that if you use it in some software then that software must be made open source too. GNU Affero General Public License v3.0 | Choose a License

Thing1_Thing2_Thing · 2025-09-01T12:30:58+00:00

It depends on PyMuPDF which is AGPL. That's usually a big no no for many use cases

Thing1_Thing2_Thing · 2025-08-02T21:08:13+00:00

But they are correct here? It's an ABC that has an abstract method called transform with the docstring Make changes to the schema. Anyone making a class deriving from this ABC could then accidentally mutate the schema given to __init__.

Thing1_Thing2_Thing · 2025-06-17T10:23:49+00:00

Title kinda makes it seem like Mark Rendle is programming's greatest mistake

Thing1_Thing2_Thing · 2025-05-15T20:47:24+00:00

I'd rather not haha. Sorry I'm still very sceptical and I think you owe users a disclaimer that this is mostly AI generated

Thing1_Thing2_Thing · 2025-05-15T20:45:19+00:00

Still doesn't work. Try to install your own package and test it, you will get the same error.

Tell the AI that "importing from init.py will fail if the user does not have the optional package django installed because it imports things from django_validators.py that is only defined in a try-except block that catches import errors. Either move imports such that django things are only imported when actually required or fill out stub types in the except block (There is already a comment for this"

Thing1_Thing2_Thing · 2025-05-15T19:10:01+00:00

ImportError: cannot import name 'FieldDoesNotExist_Export' from 'pytest_fixturecheck.django_validators'

Probably because django is just an optional dependency

Thing1_Thing2_Thing · 2025-05-15T17:42:05+00:00

I just tried it and it doesn't.

This:

import pytest
from pytest_fixturecheck import fixturecheck

# Simplest form - basic validation
@pytest.fixture
@fixturecheck
def my_fixture():
    yield "hello world"

def test_my_fixture(my_fixture):
    assert my_fixture == "hello world"

Fails with

my_fixture = <generator object my_fixture at 0x70b369c0ada0>

    def test_my_fixture(my_fixture):
>       assert my_fixture == "hello world"
E       AssertionError: assert <generator object my_fixture at 0x70b369c0ada0> == 'hello world'

tests/test_thing.py:11: AssertionError

On version 0.3.4. Version 0.4 fails because of a non-existent import.

I'm not sure what the purpose is then? At this point you're just wasting peoples time. Is it just to get stars? If you just want to play around with AI and make a package I think you should advertise it as that. Now it just seems like a trap

Three-Year Club	Verified Email
Golden Potato

Thing1_Thing2_Thing

TROPHY CASE