-
Notifications
You must be signed in to change notification settings - Fork 766
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intellisense not working for Panel package with Pylance Language Server #2572
Comments
Thanks for contacting us. We love hearing from library maintainers, and we appreciate the work you do for the Python community! The If you want a symbol such as
from .layout import Accordion as Accordion
__all__ = ["Accordion", "Card", ...] It looks like very little of the
That means Longer term, I encourage you to add more type information to the library, follow the guidance set forth in the documentation linked above, and add back the "py.typed" marker. |
Hi @erictraut Thanks. It makes sense and helps. For context Panel and the HoloViz ecosystem is built on top of Param. Param provides parameters for your Python classes and plays a role similar to traitlets in Jupyter. Its been around since 2003. An example is import param
class SomeClass(param.Parameterized):
text = param.String(default="hello world", doc="A string attribute")
author = param.String(default="Marc", doc="Name of author", constant=True) It also works similarly to dataclasses, attrs and pydantic. So all the type information is implicitly there. But static type checkers just don't understand it. But ipython and jupyter understands it really, really well on the other hand and should continue to do so. The challenge for us to understand which route to take. There seems to be many
The problem is that finding out which route to take is not something I/ we have the skills to do. Any advice here would be appriciated. |
Regarding I've started a PR to add |
Should I run |
If you want to participate in static type checking, you'll need to add static type annotations in one form or another — either inline or in the form of type stubs. I don't have any experience with
Mypy supports custom plugins, but these plugins are specific to mypy and don't work with any other static type checkers or languages servers within the Python community. We have no plans to add support for plugins in pyright. They are expensive to maintain, difficult for users to discover and install, and represent a security risk. We encourage library authors to stick to the typing standards. The Python static type standards continue to evolve to support more use cases. For example, we are in the process of ratifying PEP 681 to support attrs, pydantic and other libraries that use dataclass-like semantics. I wonder if that would would be applicable for
The purpose of Since you don't currently use
You need to run it on the installed package. |
Pep 681 is the "unofficial standard I mentioned". I have looked at it a bit. But the learning curve is steep for me. My impression was that Pep 681 was really not very general, but specific for dataclasses, attrs and pydantic. It's thought out in that context to fit those "models". Not really "models" in general?? But I might be wrong. The consequence would be that other models would become "legacy" python if they not already are :-) I've tried to convey that message to the Param maintainers. The same would probably be True for traits and traitlets. |
Regarding |
The way to really understand PEP 681 and whether it would work with Param or an updated version of Param is probably to try to implement PEP 681 for Param starting here |
Hello! I guess I'm the most official spokesperson for Param. Thanks for engaging with us! I'm not sure what about the Param docs is indicating "minimal maintenance" to you (surely that's a question to ask of the git repo or release history instead?), but maybe it's true in the sense that Param is a very mature library that rarely needs changing. So there are occasional fixes and additions, and usually not much more is needed; it's fully suitable for production usage and has been for many years now. We do have a 2.0 release coming up, with some breaking changes that clean up the API, but those would be the first intentionally breaking changes in many years. As for "modern Python", yes, eventually other mechanisms were added to the language and in other libraries that address some of the needs Param has been addressing since 2003. But there's still nothing else that provides the full set of functionality that Param provides, and unfortunately these partial alternatives used different syntax and sometimes different mechanisms. So now we have a situation where IDEs and other tooling has been built around static type hints that are almost entirely irrelevant in a Param-based approach, because such hints can only provide a tiny bit of what a Parameter supports. It would be great for the editors to show the user what Param itself already knows, but doing so by adding adding redundant type hints all over user code would destroy a lot of the simplicity that Param provides. But hey, I'm an old Emacs user, so maybe it's just that I wouldn't get any benefit from that, which is why Marc is the one raising this issue rather than me. :-) In any case, if there is a way that we can publish what Param knows in a form that static analyzers can consume, then I'm all for it! |
@MarcSkovMadsen, it seems that between this issue and #2574 your questions have been answered. If I'm wrong, let us know.
Sorry about that. We'll be providing documentation on docs.python.org in the next few months which hopefully will make it more approachable.
Attrs and pydantic compatibility was important because they are very popular libraries. However,
PEP 681 is on track to be approved in Python 3.11. Please try it. If you run into problems or have questions about, please contact me. |
Environment data
Pylance language server 2022.1.3 (pyright 98868f26)
Windows 10 Enterprise
Python 3.9.4 (PSF distribution)
VS Code 1.57.1
Panel==0.13.0
Expected behavior (with Jedi)
The above is with
Actual behavior (with Pylance)
As you can see only the sub-modules of the package are available. Not the other objects imported in the
__init__.py
files. For example theAccordion
does not show up when expandingpn.
.pn
__init__.py
file: https://github.com/holoviz/panel/blob/master/panel/__init__.pypn.widgets
__init__.py
file: https://github.com/holoviz/panel/blob/master/panel/widgets/__init__.pyThe above is with
Reproduce
python -m venv .venv
source .venv/Scripts/activate
script.py
filescript.py
file.Additional Context
I'm a contributor to Panel and would like to find the root cause and fix it, if the cause is on the Panel side. I've opened an issue with Panel here holoviz/panel#3400.
Any hints at how to identify the cause would be greatly appreciated. Thanks.
Logs
The text was updated successfully, but these errors were encountered: