williamzeng0

That makes sense! Appreciate the sentiment.

Appreciate the comment!

Sorry about that everyone! I didn't expect the formatting to look like this. Thanks for summarizing it here.

I'm actually building something for JetBrains, it's called https://sweep.dev. We're trying to bring next-edit prediction (like in Cursor) to JetBrains IDEs.

https://sweep.dev/ is better than Copilot/Windsurf in PyCharm (disclaimer I am one of the founders)

IDEs are here to stay, I built an AI plugin for IntelliJ for that reason (https://sweep.dev/)

Yes but I think they have worse things to worry about, namely Cursor.

Also if you're interested our plugin is https://sweep.dev!

You can try Sweep here! https://plugins.jetbrains.com/plugin/26860-sweep-ai

do you mean jetbrains ai team?

I think the two big things are privacy mode on by default and zero data retention by default.

No code or prompts are stored unless you opt-in. We also have on-prem deployment options but it's much more expensive.

Shameless plug but our co is building a AI plugin for JetBrains that has next edit autocomplete + a strong coding agent (sweep dev)

VSCode is way worse for large codebases and also much worse for Ruby, Golang, etc.

Transparently I'm a founder building a plugin that's like "Cursor for JetBrains IDEs", if you're an windsurf user you might like us: https://plugins.jetbrains.com/plugin/26860-sweep-ai

not yet - but it's fairly straightforward to implement the UI once you get the AI down. i've been working on an MVP here: https://docs.sweep.dev/autocomplete#next-edit-prediction-in-...

I think they're getting there but missing big features like a high quality "Apply" workflow and next-edit predictions.

I'm working with two of my friends to fill the missing pieces as a JetBrains plugin: https://docs.sweep.dev/

Ah - we do support PhpStorm. Docs will be updated.

We only support Sonnet 3.5/3.7 (we still go back and forth on which one we like), and we also support on-prem deployments!

Fixing this! This was a prompting bug re: claude sonnet.

This is great! I see it also supports an 'ignore' parameter.

That sounds great, I'm going to see how Sweep does on this issue: https://github.com/sweepai/sweep/issues/3333

I appreciate the sentiment! Makes a ton of sense.

Thank you for checking! That works, we could just override the key logic to check the source code (I'm guessing it's easily accessible)

This is great, thanks for the suggestion! We've just updated our docs and code with this change: https://github.com/sweepai/sweep/pull/3332

The version input makes sense, I could also see some developers disliking that ux because of it's verbosity. But to deliberately invalidate you have to make a manual effort in either case.

Thread safety is a big issue with ours, we'll run into issues when two different processes attempt to write to the same location, or we'll get a bad read. This is a better solution for large scale workloads.

Ours is more meant for single-process scripts like an LLM workflow.

file.mtime. (file last modified) is an awesome way to key the cache.

+1, we considered traversing the function's dependencies to key the cache on (not just the initial function source code), but decided to leave this in a as a constraint. Otherwise we also blowing up the cache when we didn't want it to happen.

Making the __dict__ opt-in makes it a lot more user-friendly at the expense of a little verbosity. That makes sense.

These tips make sense, we often use named args in our function calls (not using them has caused so many bugs), but we don't really enforce the order. Copilot doesn't always get it right either.

By moving inspect.getsource out of the wrapper, do you mean initializing it when the module is imported? I'm curious how that improves performance.

100%, invalidation needs to be fast or you're not really saving time. I'm curious about calling a global function, what's the use case for that?

It does feel like diskcache is for performance gains in production rather than dev time gains. It seems like it would be bothersome to quickly invalidate the cache in case of a bad write.

Diskcache works well, we just wanted a dependency free version that we had more control over (easier cache key deletion). I think you'd have to write a custom hashing function for diskcache to use the function source code as a key.

I'm also unsure if Diskcache supports ignoring certain fields in the function call.