ehmatthes.bsky.social
Programmer, writer, teacher... I also like the outdoors. :)
I write a weekly Python newsletter, at www.mostlypython.com. I'm also the author of Python Crash Course, from No Starch Press.
126 posts
1,266 followers
175 following
Regular Contributor
Active Commenter
comment in response to
post
I would love to hear more about the serious side of this. It feels like a y2k-fixing gig that never ends.
comment in response to
post
Does the behavior change if you tell it it's been really useful and you want it to stop asking you that?
comment in response to
post
I've met some fantastic people over the years sprinting on this project. If you're interested, please say hi at the conference! Even if you're working on something else, I'd love to meet you. :)
comment in response to
post
I'd be happy to join you for that conversation if you want. It's been a really interesting project to work on so far.
comment in response to
post
If you've been interested in contributing, there should be enough information there to jump in.
I'm going to focus on django-simple-deploy for a while, but I'll continue to pay attention to py-bugger as well. I'll be at PyCon sprints, and I'm happy to support contributions to either project. :)
comment in response to
post
I'm guessing it's a sigmoid curve, and we're most of the way up it already.
comment in response to
post
I say that because it seems the source of their ability to problem solve is the same as the source of their ability to hallucinate. So I don't really see a path where you can keep the generalized analytical abilities, while losing the tendency to overcomplicate and break things.
comment in response to
post
With fully AI-generated code, it works until it doesn't. And when it doesn't, someone has to go in and fix it, or bail on the project.
I have a hard time seeing this generation of AIs being refined enough to sort that mess to an arbitrary level of complexity.
comment in response to
post
With every previous new abstraction layer, there were still people who fully understood the lower layers. It was possible, if you wanted, to become an expert in any of those layers yourself.
comment in response to
post
I have a bit more work to do before going back to other projects. It's been so interesting and satisfying to work on this!
github.com/ehmatthes/py-bugger
comment in response to
post
I'm pretty sure there are many real-world bugs that will be hard to generate. But I'm also seeing that it should be possible to generate a range of specific bugs that are worth practicing against.
comment in response to
post
This has been really satisfying to work on, because I'm learning so much about syntax trees. It's really interesting figuring out how to deterministically break arbitrary codebases.
comment in response to
post
I'm happy to respond here, in issues or discussions, or over email.
For the record, here's the repo:
github.com/ehmatthes/py...
comment in response to
post
It introduces a very limited set of bugs at this point. But the structure is now in place to quickly expand its functionality.
I need to go back to django-simple-deploy for a bit, but if you're interested in the direction of py-bugger, please reach out.
comment in response to
post
You can also target a specific file:
comment in response to
post
Independent learners can start with a clean status, run py-bugger, and then try any number of approaches to debugging. If they get totally lost, they can run `git diff` to see what the bug was.
I think this kind of approach offers support to both teacher/student and independent learning situations.
comment in response to
post
An instructor could take a project, run py-bugger, and then share a copy of the project with students, without any git history.
The instructor can run `git diff` to see the actual bug. Students will have to find the bug.
comment in response to
post
Currently, it tells you that a bug was introduced that results in a specific kind of exception (the one you requested). It does not show the actual code change.
One of the next features: it will check for a clean status before modifying code, and suggest making a commit before introducing a bug.
comment in response to
post
If there's a clear way to run the project, it's also possible to verify the correct kind of exception was induced.
comment in response to
post
Yeah, it's a pretty interesting problem to solve! Some of it depends on how the underlying project is implemented.
One thought I've had: it might be possible to inspect the project, find out if it has tests, and run the tests. Then you could verify whether or not you've broken the project.
comment in response to
post
Unfortunately I can't use py-bugger for the package name, because it's too similar to something else on PyPI. (bugger maybe?)
I think I'll keep the command as `py-bugger`, and have a package name like py-bugger-lib or python-bugger.
comment in response to
post
Here you go!
github.com/ehmatthes/py...