If you've ever wondered about what that yellow light bulb means, it's simply an indication that there are possible intention actions at your disposal. Intentions in PyCharm are context-specific actions that you can invoke with Alt + Enter (Show Intention Actions). One very useful example of intentions at work is when using language injection in strings.

And with that, we can insert the many different languages that PyCharm supports:

The best part is that you get syntax highlighting and snippet completion within the string as well:

But, injections are not limited to languages alone, for example, you can have things such as file paths:

You can have a look at all the intentions at your disposal here:

All the intentions are context-specific; sometimes, they're tuned specifically for languages and others are often more general purpose. For example, in Python, you have the intention to convert from a single-quoted string into a double-quoted string, however, language injections work across different languages. You can get a good idea of what these intentions do just by looking at its individual page:

It gives you everything that you wanted to know about intentions, but notice what it is powered by. In this case, this is one of PyCharm's core functionalities, but some intentions are powered by plugins, so if one does not work, you can figure out what is causing the problem.

Code completion is probably the reason why most of us use PyCharm. The PyCharm team spends a lot of their time improving and refining completion options not only in PyCharm but also in other IDEs. One of the easiest ways to improve code completion is to gather runtime data.

Collecting runtime types allows PyCharm to provide better code completion. This runtime data is collected every time one debugs a program, not when one simply runs it. If by any chance, PyCharm shows you the wrong types, then clearing the caches is the best way to solve the problem.

Docstrings are parsed and used by PyCharm to give you better code completion as well as better quick documentation information. Here is an example, using Intentions.

Say we wanted to make a Person class so that we can declare the class and add a few parameters to its __init__ function:

We can also add parameter info through docstrings or annotations (in Python 3) and since docstrings work for both Python 2 and 3, we're going to stick with them.

This causes PyCharm to generate a lot of documentation for me (for free!):

Let me take a step back to say that this docstring is in a particular format, that is, it's in rst or reStructuredText. This means that PyCharm can parse the string and get information regarding the parameters to the init function and class it is initializing. Note that you have the choice between Epytext and reStructuredText. I suggest using reStructuredText because that is what PyCharm uses to generate documentation skeletons for a variety of stdlib classes. Here is where all of these options are set:

Now that we've put in some information regarding our Person object, let's see what the Quick Documentation (Ctrl + Q) brings up:

This is great, but we can get even more information out of docstrings. So now using another intention option, we can generate the parameter types for each of the arguments for Person:

And with this, we can say that the name will be of type str:

With this, you get even more information from Quick Documentation:

Please note that you need to be careful when adding docstrings because they require special formatting. So, in this case, we have the following:

        """
        :type name: str
        :param name: The name of the human

        :type age: int
        :param age: How old the human is


        :type gender: str 
        :param gender: Male or Female

        :type country_of_origin: str 
        :param country_of_origin: Somewhere on the planet, hopefully

See how we have the type of the parameter first, then its description, and finally a blank line between parameters. This is best practice, so even without PyCharm someone can quickly read about and understand the different parameters. This is how you need to arrange the information in your docstring in order for PyCharm to give you useful quick documentation. Docstrings can also be used by PyCharm to help you write more accurate code:

PyCharm correctly points out that you've put in the wrong parameters, and this kind of static analysis can be very helpful. Also, note that you can choose to tell PyCharm to ignore the problem (by pressing the right arrow after we've selected Inspect 'Type checker' options):

This will add a new command above the line, telling PyCharm to ignore the type checking for this statement:

Docstrings can provide a lot of code completion options for functions, however, they often fall short when it comes to providing code completion options for metaclasses. This is to be expected since docstrings provide static analysis.

No, it's not that PyCharm has something to hide; it's just that it has a lot of skeletons generated for different modules, and you can take a look at them too:

Python skeletons provide a lot of the code completion that you see in PyCharm, and all are hosted on an open source GitHub repository at https://github.com/JetBrains/python-skeletons.

And when I said skeletons, I meant skeletons! These are not implementations; they are merely something that PyCharm can statically analyze. Let's look at the decimal.py file:

There's no implementation here, just the bare information that PyCharm needs to give you the code completion options you need. The skeletons are still a work in progress but are getting better every day.