Ok thanks for explaining. I will proceed by trying it with typeshed. Best Regards, -- Ilya Kamenshchikov
On Tue, Apr 23, 2019 at 9:44 PM Ivan Levkivskyi <levkivs...@gmail.com> wrote: > Mypy doesn't use source code of stlib for analysis and instead uses stub > files from typeshed. IIUC PyCharm can also do that (i.e. use the typeshed > stubs). > The whole idea of typeshed is to avoid changing stlib solely for the sake > of static analysis. Please open an issue on typeshed an/or PyCharm tracker. > > -- > Ivan > > > > On Tue, 23 Apr 2019 at 20:38, Ilya Kamenshchikov <ikamenshchi...@gmail.com> > wrote: > >> How would we answer the same question if it was not a part of stdlib? >> I am not sure it is fair to expect of Pycharm to parse / execute the >> __getattr__ on modules, as more elaborate implementation could even contain >> different types per some condition at the runtime or anything at all. >> The code: >> >> TYPE_CHECKING = False >> if TYPE_CHECKING: >> from .process import ProcessPoolExecutor >> from .thread import ThreadPoolExecutor >> >> works for type checking in PyCharm and is fast. >> >> This is how stdlib can be an example to how side libraries can be >> implemented. If we can agree that this is the only clear, performant and >> sufficient code - then perhaps modifying mypy is a reasonable price to pay. >> >> Perhaps this particular case can be just patched locally by PyCharm >> /JetBrains, but what is a general solution to this class of problems? >> >> Best Regards, >> -- >> Ilya Kamenshchikov >> >> >> On Tue, Apr 23, 2019 at 7:05 PM Guido van Rossum <gu...@python.org> >> wrote: >> >>> In any case I think this should be filed (by the OP) as an issue against >>> JetBrains' PyCharm issue tracker. Who knows they may be able to >>> special-case this in a jiffy. I don't think we should add any clever hacks >>> to the stdlib for this. >>> >>> On Tue, Apr 23, 2019 at 9:59 AM Nathaniel Smith <n...@pobox.com> wrote: >>> >>>> On Tue, Apr 23, 2019, 05:09 Andrew Svetlov <andrew.svet...@gmail.com> >>>> wrote: >>>> >>>>> I agree that `from typing import TYPE_CHECKING` is not desirable from >>>>> the import time reduction perspective. >>>>> >>>>> From my understanding code completion *can* be based on type hinting >>>>> to avoid actual code execution. >>>>> That's why I've mentioned that typeshed already has the correct type >>>>> information. >>>>> >>>>> if TYPE_CHECKING: >>>>> import ... >>>>> >>>>> requires mypy modification. >>>>> >>>>> if False: >>>>> import ... >>>>> >>>>> Works right now for stdlib (mypy ignores stdlib code but uses typeshed >>>>> anyway) but looks a little cryptic. >>>>> Requires a comprehensive comment at least. >>>>> >>>> >>>> Last time I looked at this, I'm pretty sure `if False` broke at least >>>> one popular static analysis tool (ie it was clever enough to ignore >>>> everything inside `if False`) – I think either pylint or jedi? >>>> >>>> I'd suggest checking any clever hacks against at least: mypy, >>>> pylint/astroid, jedi, pyflakes, and pycharm. They all have their own static >>>> analysis engines, and each one has its own idiosyncratic quirks. >>>> >>>> We've struggled with this a *lot* in trio, and eventually ended up >>>> giving up on all forms of dynamic export cleverness; we've even banned the >>>> use of __all__ entirely. Static analysis has gotten good enough that users >>>> won't accept it not working, but it hasn't gotten good enough to handle >>>> anything but the simplest static exports in a reliable way: >>>> https://github.com/python-trio/trio/pull/316 >>>> https://github.com/python-trio/trio/issues/542 >>>> >>>> The stdlib has more leeway because when tools don't work on the stdlib >>>> then they tend to eventually add workarounds. I'm just saying, think twice >>>> before diving into clever hacks to workaround static analysis limits, and >>>> if you're going to do it then be careful to be thorough. You're basically >>>> relying on undocumented bugs, and it gets really messy really quickly. >>>> >>>> -n >>>> _______________________________________________ >>>> Python-Dev mailing list >>>> Python-Dev@python.org >>>> https://mail.python.org/mailman/listinfo/python-dev >>>> Unsubscribe: >>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>>> >>> >>> >>> -- >>> --Guido van Rossum (python.org/~guido) >>> *Pronouns: he/him/his **(why is my pronoun here?)* >>> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> >>> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com >> >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
