If the symbol is imported from a py.typed library and the author of the library has taken the time to indicate which symbols are private and which are public, it seems to me that pylance should honor that information and omit completion suggestions that violate the interface contract of the library. It's different when dealing with a non-py.typed library or user code, but this issue is specifically about py.typed libraries.

If a user of a library wants to violate the public interface contract of a library they're consuming, that's their prerogative, but I don't think tooling should help them do so. IMO, tooling should steer developers away from this practice because it results in code that is not robust (since it can break when internal implementation details change in a library update). It also harms library maintainers in that it prevents them from making internal changes to the library without breaking their users.

If we could detect that a py.typed library is not being written, but rather just being used, then yes I agree. Users of py.typed libraries should not import private modules.

But if I'm writing a py.typed package, I still need to import private modules from my own package. Can we detect this scenario?

Pyright already has all the logic in place to properly report the use of private modules and symbols under the correct circumstances. It needs to do this to properly handle the reportPrivateUsage diagnostic check. The completion provider in pylance is not honoring this information currently.

Oh actually I think we can control the sort order, we just never special cased this situation.

I get similar behavior when, for example, using auto-import suggestions on the symbol CRSpectrometer which I want the ide to suggest the "public" api and use the alias inside of specio.spectrometers rather than the _device_implementations the reason being... for some purposes it's useful to organize some of the "CR" device implementations in the same module. They share a lot of configuration functions and symbols as they are made by the same manufacturer. But the nature of those devices is different "colorimeters" vs "spectrometers" and I'm trying to organize the devices in my library by those designations...

The code is organized the way I want, but the suggestions are pushing the users to access the device implementations directly leading to confusing code...

But then... aliases themselves are confusing. Maybe I need to go about this a different way.

Seems I got the correct behavior by changing "include aliases in user files"

This might look different for users who actually installed via pip rather than are maintainers / using editable dependencies.

forgive my import time not being in the top of the file hahah.... this is an example script 😅

I believe that would be a new feature request. We didn't do custom sorting for private entries, so they just sort alphabetically AFAIK.

Video example.

Thanks! I'll figure out how to open an issue and request it then.