From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, "Alex Bennée" <alex.bennee@linaro.org>,
"John Snow" <jsnow@redhat.com>, "Kevin Wolf" <kwolf@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Mads Ynddal" <mads@ynddal.dk>
Subject: Re: [PATCH 0/6] tracetool: add mypy --strict checking [AI discussion ahead!]
Date: Wed, 8 Oct 2025 11:40:29 +0100 [thread overview]
Message-ID: <aOY_nawkW8K7XxDv@redhat.com> (raw)
In-Reply-To: <20251008063546.376603-1-pbonzini@redhat.com>
On Wed, Oct 08, 2025 at 08:35:39AM +0200, Paolo Bonzini wrote:
> Comparing the results from RightTyper and AI, both tools benefit from human
> help: the dead code removal which I mentioned, the small cleanups in patch 1,
> the final manual fixes for the remaining (mostly trivial) errors. But at
> least in this case, AI is a winner:
>
> - it left basically no unannotated code: fixing the above errors was enough
> to pass "mypy --strict", unlike RightTyper which needed a little more work
> due to its profiling-based nature and a few other limitations (see patch 5).
>
> - most importantly, trying various other tools that didn't work, as well as
> figuring out how to use RightTyper, took a couple hours more. Surprising
> as it was, I could not find any static type inferencing tool for Python;
> neither pytype nor pyre worked for me. This is also why I think this
> is not apples to oranges, but a fair comparison between AI-based and
> regular tooling.
FWIW, there was a third possible option here, a sort of hybrid...
prompt> find me tools that can add python type annotatinos to code
prompt> show me how to invoke tool <blah> on the QEMU codebase.
prompt> run the tool <blah> on the QEMU code, run mypy tests and
commit the result
that would probably have saved the hours learning how to use RightTyper
making it more competitive with the pure AI approach.
> After the diffstat, you can find a diff from this series to the version
> based on Claude Code. It's impossible to be 100% objective but,
> besides being functionally equivalent, I don't think either would be
> identifiable as written by an LLM, by a person, by a tool+human combo,
> or even by a good type inferencing tool (if it existed).
AFAICS the diff there is either whitespace changes, or a differing
style for importing a module vs importing a name from a module.
Whitespace we should be enforcing with 'black' formatting rules.
For import style, I'd say that's an irrelevant difference.
IOW, I'd call the two patches identical for any practical purposes.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2025-10-08 10:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 6:35 [PATCH 0/6] tracetool: add mypy --strict checking [AI discussion ahead!] Paolo Bonzini
2025-10-08 6:35 ` [PATCH 1/6] tracetool: rename variable with conflicting types Paolo Bonzini
2025-10-08 9:27 ` Daniel P. Berrangé
2025-10-08 18:06 ` Stefan Hajnoczi
2025-10-08 6:35 ` [PATCH 2/6] tracetool: apply isort and add check Paolo Bonzini
2025-10-08 9:29 ` Daniel P. Berrangé
2025-10-08 17:58 ` Stefan Hajnoczi
2025-10-09 7:52 ` Daniel P. Berrangé
2025-10-09 8:22 ` Paolo Bonzini
2025-10-09 8:58 ` Daniel P. Berrangé
2025-10-09 11:26 ` Paolo Bonzini
2025-10-09 12:05 ` Daniel P. Berrangé
2025-10-09 7:58 ` Paolo Bonzini
2025-10-08 6:35 ` [PATCH 3/6] tracetool: "import annotations" Paolo Bonzini
2025-10-08 9:31 ` Daniel P. Berrangé
2025-10-08 18:06 ` Stefan Hajnoczi
2025-10-08 6:35 ` [PATCH 4/6] tracetool: add type annotations Paolo Bonzini
2025-10-08 18:09 ` Stefan Hajnoczi
2025-10-08 6:35 ` [PATCH 5/6] tracetool: complete typing annotations Paolo Bonzini
2025-10-08 18:10 ` Stefan Hajnoczi
2025-10-08 6:35 ` [PATCH 6/6] tracetool: add typing checks to "make -C python check" Paolo Bonzini
2025-10-08 9:32 ` Daniel P. Berrangé
2025-10-08 18:12 ` Stefan Hajnoczi
2025-10-08 7:18 ` [PATCH 0/6] tracetool: add mypy --strict checking [AI discussion ahead!] Markus Armbruster
2025-10-08 10:34 ` Daniel P. Berrangé
2025-10-10 12:38 ` Markus Armbruster
2025-10-10 13:49 ` Paolo Bonzini
2025-10-10 17:41 ` Markus Armbruster
2025-10-08 10:40 ` Daniel P. Berrangé [this message]
2025-10-08 17:23 ` Stefan Hajnoczi
2025-10-08 17:41 ` Paolo Bonzini
2025-10-14 19:02 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aOY_nawkW8K7XxDv@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mads@ynddal.dk \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.