I'm trying to create an application in Python 3.5 and i use spaces all the time for indentation, but the editor print out "inconsistent use of tabs and spaces in indentation" when it comes to
print("This car has "+str(self.odometer_reading)+" miles on it.")
How can i solve this problem? I'm a beginner in programming. I would be glad if i could get some overall tips on my code.
class Car():
def __init__(self,make,model,year):
#初始化描述汽车的属性
self.make=make
self.model=model
self.year=year
self.odometer_reading=0
def read_odometer(self):
#打印一条指出汽车里程的消息
print("This car has "+str(self.odometer_reading)+" miles on it.")
my_new_car.read_odometer()
It means that some of your code you've indented by pressing space and some of the code has been indented by pressing tab. You can tell which one is in use for a certain line by pressing backspace on the insert and if it deletes approx 4 characters worth of space it was an indent, otherwise it was a space. I would recommend that you either pick space or tab to indent your code then be consistent. To get your code working I would recommend you simplify remove all indentation then use either space or tab to indent.
Many editors support the display of the indentation mark and spaces.
Turn them on, you will see what the interpreter is talking about.
Its not possible to tell from your code displayed here. They have all be converted to spaces by syntax highlighter.
Related
I am using the IdeaVim-EasyMotion (https://github.com/AlexPl292/IdeaVim-EasyMotion) plugin for pycharm. When I use it, it selects texts instead of moving the cursor. Anybody knows how to make it work properly. Cheers!
e.g.,
It highlights the texts instead of moving the cursor
I had this same issue and it's super annoying, but I find that even though easymotion presents me with capital letters to select where to jump, lowercase letters work just fine.
So, while this sequence selects text:
\\foHU
this does not, but goes to the same place:
\\fohu
I've got this funny problem when trying to copy and paste the character٭ It doesn't let me get my cursor behind it and swapps the whole line of characters (see gif). Also the cursor has a funny double cursor, when I highlight ٭
I think I activated some strange mode here accidently with some keys. Anyone know whats going on?
This character٭ (Arabic 5-pointed star) is naturally designed for a right-to-left writing language, such as Arabic. The computer recognizes it and automatically switches the cursor to writing right-to-left.
I've been reading PEP 8 but I don't understand why Python3 bothers to single out mixing tabs and spaces with this error message.
TabError: inconsistent use of tabs and spaces in indentation
I understand the importance of consistency but an error message that halts execution seems extreme, especially since mixed tabs and spaces doesn't make any difference to the compiler and most good editors support tab/space conversions. On top of that, Python3 doesn't have a problem with you ignoring other PEP conventions (for example using three space indentations instead of four), you won't even get a warning message for it.
So what's the deal, why does Python3 all of sudden treat mixing spaces and tabs like the ultimate evil?
You can perfectly well mix tabs and spaces in a python file (though PEP8 says you shouldn't).
(Stackoverflow prints tab as 4 spaces, example tabs are correct in this gist; test them out yourself!)
Here's a perfectly valid python function:
def foo():
print("one tab") # all indentation is one tab.
if True:
print("two spaces")
else:
print("four spaces")
what you can't do is mix tabs and spaces in the same block:
def foo():
print("one tab")
print("eight spaces")
This gives a TabError.
Even if these lined up in your text editor.
This is because (roughly) they may line up differently in someone else's text editor and look like a different procedure. To give a silly example:
def foo():
while True:
"we should exit immediately"
return True # suppose this was tab indented
The last line may look like it lines up with the string, and hence returns immediately, but since it's tab indented perhaps it's lined up with the while (so the while loop never exits). ???
Here lies the ambiguity, and so the parser say no.
However, PEP8 says you should just always use 4 spaces, avoiding this ambiguity.
So oftentimes, while editing with Vim, I'll get into a variety of situations where whitespace gives me hassle. For example, say I have a comment like this:
#This program was featured on the Today show, it is an algorithm for promoting world peace in third-world countries
#given the name of that country and the name of a celebrity to endorse its cause
If I want to, for example, trim the lines so they go to X characters, I end up putting a newline somewhere in the middle of the top line to get this (after hitting the newline and auto-indenting):
#This program was featured on the Today show, it is an algorithm for promoting
world peace in third-world countries
#given the name of that country and the name of a celebrity to endorse its cause
I then add a # to the beginning of the line, and that's all well and good, but then I want that line to line up, too. To do so, I have to delete the newline, all the whitespace for the indent on the next line, and then the commenting # mark. It doesn't take an awfully long amount of time to do that, but this and similar situations all add up over a day's worth of coding.
Now the example above is pretty specific, but my question isn't. What's a good way in Vim to delete all whitespace INCLUDING NEWLINES up until the next non-whitespace character? If Vim already has movements that do that, that would be awesome, but if not, does anyone have a favorite Vim function they use to do the above that could be mapped to a key? At the very least, am I missing some Vim usage idiom that prevents me from even having to worry about this case?
EDIT: Formatting to width, while useful and applicable to the case above, isn't the focus of this question. I'm concerned more with whitespace removal that doesn't stop at the end of a line, but instead carries on to the first non-whitespace character of the next line.
You really just want to reformat that comment to fit the current 'textwidth'. If the comment is a paragraph (i.e., separated by a line of whitespace above and below), then you can just use gqip (gq is the reformat command, ip is the "inner-paragraph" text object) to reformat it. If it's not a standalone paragraph, you can visually select those lines and then use gq.
This likely also relies on having 'formatoptions' set correctly to make sure the comment characters are handled properly, but in many cases the ftplugin has already done that.
This is a while later, but I found that there is a command that does what I need to in 90% of circumstances:
J -- join line below to the current one
This command seems to work:
:.s/\W*$\n\W*//g
it uses a replace to remove whitespace up to end of line and the new line at the end.
In this example:
testting aad $
asdjkasdjsdaksddjk$
(to see meta characters in vim use the command :set list)
if you place the cursor on the first line and use the first command it will delete everything from aad to $ (not including aad but including $ and a newline.)
Also, note for what you are doing it is far more efficient to use an external program to format comments for you. In particular, par is a great small C program that edits text and wraps it to desired lengths.
If you have par in your path, to do what you are trying to do is as easy as selecting the block of comment with Shift+v and running the command
:!par 40pgr
where 40 is the desired width in columns.
If you are feeling hackish, write your own program in C/perl/C++/python that edits comments however you like, then put it in path and use the external filter command :! to process blocks of text through it.
Is it possible to have a carriage return without bringing about a linebreak ?
For instance I want to write the following sentences in 2 lines and not 4 (and I do not want to type spaces of course) :
On a ship at sea: a tempestuous noise of thunder and lightning heard.
Enter a Master and a Boatswain
Master : Boatswain!
Boatswain : Here, master: what cheer?
Thanks in advance for your help
Thierry
In a text file, the expected line-end character or character sequence is platform dependent. On Windows, the sequence "carriage return (CR, \r) + line feed (LF, \n)" is used, while Unix systems use newline only (LF \n). Macintoshes traditionally used \r only, but these days on OS X I see them dealing with just about any version. Text editors on any system are often able to support all three versions, and to convert between them.
For VIM, see this article for tips how to convert/set line end character sequences.
However, I'm not exactly sure what advantage the change would have for you: Whichever sequence or character you use, it is just the marker for the end of the line (so there should be one of these, at the end of the first line and you'd have a 2 line text file in any event). However, if your application expects a certain character, you can either change the application -- many programming languages support some form of "universal" newline -- or change the data.
Just in case this is what you're looking for:
:set wrap
:set linebreak
The first tells vim to wrap long lines, and the second tells it to only break lines at word breaks, instead of in the middle of words when it reaches the window size.