This is the second post in the PyCharm tips series. Because the last article got some approval from everyone, so today I recommend some useful tips to you, you can choose what you need.

First of all, there is no guarantee that it is helpful to all people, so please spare your heart. If you think it is useful, please give a “like” to prove that some people are watching this series. Then I will have more motivation to continue to update, don’t you agree?

If you haven’t seen the first post, you can check it out here:

06. Debug like a god

If we are in a crawler project, we will use regular expressions to match what we want to crawl. Regex is something that many people can do in one step, and it usually takes a lot of debugging to match as expected. After we changed the re, we ran it, and we need to crawl the request to the website again to find that there is no match. Then we changed the version, and we also need to launch the request again. The result is still found that there is no match.

(This example may not be appropriate, since there are many ways to do this without resending the request, but it just shows a very clumsy and inefficient debugging process, just take a look.)

And we in these dozens of debugging, to the same site to initiate a request is meaningless repeated work. If Pycharm, like IPython Shell and Jupyter Notebook, can remember all the variables after running, then we can adjust our code by executing command expressions after breaking points without having to re-run the project or script. Do our re debugging.

The answer, of course, is yes.

Let’s say I’m debugging a few simple lines of code. A break point is made at line 3. Then click the Show Python Prompt button in the illustrated location.

This is the Python Shell interface, and the Shell environment is open to the application environment we are currently running. Variables are accessible to each other, and you can easily debug.

We have made a break point above to illustrate this effect. It doesn’t have to be a point of interruption. If you do not break the point, you can still view and manipulate all variables in this interface after the script is executed.

We are now ready for our debugging needs, but manually clicking Show Python Prompt every time we run the script is a bit cumbersome. Huh? There’s actually a place where you can turn it on by default. This switch is still relatively secret, ordinary people really can’t find it.

You need to click on the icon where you want to Edit Configurations.

And then check it here.

By default, every time you run the script, it stores the values of all variables for you and opens the console command line for you.

In addition to the above method, there is another way to execute command expressions during debugging, and this is probably more familiar, but also mentioned here, as a summary. But in terms of function, it is not as easy to use as the above method. Because of this approach, you must be required to run the project in Debug mode and break points.

To use it, after you have made the breakpoint, right-click on the icon and use Evaluate Expression

The Evaluate Expression window pops up, where you can run command expressions and manipulate variables directly.

07. Specify parameters to execute the script

You run your project on Pycharm, how does it normally work? What I do is, right click and hit Run, or use the Shift + F10 shortcut.

Sometimes, when running/debugging scripts, we need to specify some parameters, which can be specified directly on the command line.

Suppose on the command line, the command to run the script looks like this

python main.py init --local
Copy the code

Those who have just used Pycharm may not know that Pycharm can also be used to specify parameters. Click on the location below

Go to the Settings panel and fill in Script Parameters.

Also at the bottom of the image, you can see that it’s much easier to switch the interpreter here than if you were to come over here

08. Filter test files during search

Next, introduce a, I look at the framework source code when a small tip, may only apply to a small number of people.

The framework I usually look at is OpenStack. I don’t know what other frameworks are like, but there are a lot of (really a lot of) unit test files in OpenStack. This has caused me a lot of trouble using Find in Path, as you can see from the search results below. When you search for a function, the test file has many more results than the normal file.

These test file search results, for us to see the source code not only does not have any help, more importantly also interferes with the line of sight. So I researched, starting from the File name, just fill in the File mask! Test * filters out these test files. Search results were suddenly much clearer.

09. Turn off that annoying light bulb tip

I didn’t want to write this, but a friend of Zhihu has this demand, so I researched it.

So what is this light bulb tip? What does it do?

When we have grammatical errors in the code, or the code is not written in accordance with pep8 code specifications, the mouse selects the code with problems, and a small light bulb will automatically pop up. The light bulb is colored. If it is red, it is usually a grammar problem, and if it is not handled, the code will be affected. If it is a yellow light bulb, it is just a reminder that the code is not standard, etc., and does not affect the operation of the program.

The bulb, though, is well-intentioned, but I think it’s a bit redundant (probably because I’m not personally in the habit of using it), with a red wavy line indicating grammatical errors. You might say that the light bulb doesn’t just serve as a cue, it automatically corrects the code, which I personally feel is not as efficient or as accurate as manual correction.

Because sometimes, as this friend on Zhihu said, it will block our code and often be late, this is indeed a worry.

I have researched and found that Pycharm (2018 version) has a “on” button. Uncheck the “Show Intention bulb” in the picture below to turn off this function.

10. Close the wavy lines that are an eyesore

I’m going to give you a little code example to think about why name and my_name don’t have wavy lines, but myname and wangbm do.

Pycharm itself checks for variable names in real time, and if the variable name is not an existing English word, a wavy line appears. Python recommends using underscores to separate multiple words in a variable. (Other languages may prefer to use camel names, But Python uses underscores), so my_name is canonical in Pycharm’s view, and myName is treated as a word. Myname is not canonical because it does not have it in the vocabulary.

Everyone’s variable naming habits are different, and if you’re using a lot of myName style variable naming in your project, like the one below (which is cloudinit code), it’s uncomfortable and gives the illusion that the code is buggy.

So how do you turn off this non-syntactic wavy line? It’s very simple. The switch is in the bottom right corner of your face like a button

Then select Syntax level. The same piece of code looks like this, much cleaner.

These are the five PyCharm tips of the week. Have you learned them?

And finally, can I get a thumbs up? * ^_^ *