Library code should be a virtual document

[isidorn]

Hi VS Code dev here 👋

Have the following code

num1 = 1.5
num2 = 6.3
# Add two numbers
sum = float(num1) + float(num2)

Go to references on float -> notice a new editor appears with editable content.
This feels like a very bad experience since this is library code and should be read only.

As @jrieken suggest Python should be a virtual document provider, as a virtual document fits this use case much better.

fyi @luabud

[luabud]

@karthiknadig do you know if it makes sense to transfer this to Pylance, or would it need to be done in vscode-python?

[luabud]

hey @isidorn! During housekeeping I transferred this to the Pylance repo and then talked about this with the team. We were thinking whether it wouldn't make more sense for Pylance to return the content with a flag saying it should be read only or not (and then VS Code would handle that appropriately)?

For context, it's not uncommon for users to want to edit their stub files (.pyi) that are open when they use "Go to references" (folks in our team actually do this all the time). The main exceptions are usually builtins.pyi like in the float example, and probably anything under site-packages.

[isidorn]

@luabud thanks for discussing with the team.

You understand the needs of the python users much better than me, and if you decided that editing stub files makes sense then we should allow that. As for builtins.pyi and site-packages if you can mark them as readonly that would make sense to me. And currently the mechanism to mark something as readonly should be through your document provider. You probably already have a ContentProvider, and that provider returns TextModels, and each of those TextModels can decide if it is readonly or not. At least, that is how it works in core when I implemented it for debug, and I think the same should be exposed to extensions.

Code pointer https://github.com/microsoft/vscode/blob/isidorn/account-avatar/src/vscode-dts/vscode.d.ts#L1802

Though if this is deemed as not low-hanging fruit feel free to close it as out of scope.

[rchiodo]

We're not a TextDocumentContentProvider for python files. We just provide URIs that VS code opens using the default content provider. I don't think it would be worth the effort to start doing this as we've had no up votes on this issue.

I think in order for this to work we'd have to create a custom URI scheme for built in files. Then we'd be a content provider for just that scheme.

[luabud]

thanks all for the additional context! I'll close this as out of scope then 😊