Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am learning Python by using Pycharm from Jetbrains . I am unable to pass this Question :
Print out this text using one String "The name of this ice-cream is "Sweet'n'Tasty"
My solution is:
print('The name of this ice-cream is \"Sweet\'n\'Tasty\"')
It shows the right output but the program does not accept is as a solution.
Why the seemingly right answer is not accepted, and how to satisfy given requirement?
I found this page because I ran into the exact same issue, earlier today.
In short, it's the lesson's logic being picky on syntax, in a very unclear way. You're typing the right thing for what it's asking, and you're typing something that parses with no error-- but the lesson rejects it anyway.
The long, drawn out answer.
The task is:
A backslash is used to escape a quote so it can be used in strings such as 'It\'s me' and "She said \"Hello\"". The special symbol '\n' is used to add a line break to a string.
Print out this text using one string: The name of this ice-cream is "Sweeet'n'Tasty"
And they provide to you:
dont_worry = "Don't worry about apostrophes"
print(dont_worry)
print("The name of this ice-cream is \"Sweeet\"")
print('text')
where the text in the print('text') on the last line is meant to be replaced with your answer.
The lesson seems to want to teach you that you can escape both a single quote and a double quote with a backslash. Note the double quotes on the second print instance, and the single quote on the third print instance [where they want you to type your answer]
if you replace the text in print('text') with: The name of this ice-cream is \"Sweeet'n'Tasty\"
the task fails with:
File
"/PycharmProjects/PythonIntroduction/lesson3/task8/character_escaping.py",
line 4
print('The name of this ice-cream is \"Sweeet'n'Tasty\"')
^ SyntaxError: invalid syntax
so if you add slashes to the single quotes [apostrophes in this context]
print('The name of this ice-cream is \"Sweeet\'n\'Tasty\"')
even though the text does parse correctly in the console below:
Don't worry about apostrophes
The name of this ice-cream is "Sweeet"
The name of this ice-cream is "Sweeet'n'Tasty"
The task fails and you get an infuriating error that reads:
Use backslash () to escape quotes
Even though that's what you've done.
If you try to backspace the single quotes to replace with double quotes for print('text') you get:
It's not allowed to delete answer placeholders
Now - if you move cursor [or caret] next to a quote, you get a lightbulb hint that gives you an option to:
Convert single quoted string to double-quoted string
which is what they want you to do ... but through some logic error, it takes your typed answer of
print('The name of this ice-cream is \"Sweeet\'n\'Tasty\"')
and munges it up to:
print("The name of this ice-cream is \\")
and the boundaries for the answer box text get all fouled up and wrap up to the previous line-- it looks like a bug in the lesson software itself.
SO
what you must do from the start is use your cursor to get the lighbulb hint FIRST and "Convert single quoted string to double-quoted string"
so that print('text') becomes print("text")
^^^ note the change from single to double quotes ^^^
and THEN type your correct answer of
print("The name of this ice-cream is \"Sweeet'n'Tasty\"")
This took me MUCH longer than I would have liked it to, to figure it out. As a beginner in programming and brand-new to Python, this was a huge roadblock. If I were using this in an instructor-led course they might have said "Oh, this is a bug in the software, you can see we're getting the right answer, let's skip it and move on." but for self-study, I was convinced I wasn't right, and I was overlooking something basic. It was discouraging as slamming into a brick wall. Repeatedly.
I guess the teachable moment here is:
Sometimes the textbook is wrong and you have to understand & prove it to yourself why.
You can also try using as in python if you use a single quote outside then double quotes are allowed within the String.
`print('The name of this ice-cream is "Sweet\'n\'Tasty"')`
Also for more reference, you can have a look here
I hope that helps.
This question already has answers here:
Quickest way to change a pair of parenthesis to brackets in vim
(6 answers)
Closed 8 years ago.
I am looking for a VIM key combo for changing something like
blahblah["hello"]
to
blahblah("hello")
My best effort so far is
0f[yi[%c%()^["0P^[
but anything better would be much appreciated.
BTW, my combo works by doing:
find the first instance of [ (you get my point),
yank the insides (which of course means to register 0 by default, and it leaves the cursor on the first "),
move the cursor back onto the first instance of [ with %,
delete the whole [...] bit and go into insert mode,
write () and <Esc> out of insert mode,
paste the contents of register 0 in between the ().
I was hoping to have a muscle-memorable key combination that I could use for things like this where you want to 'keep the contents but change the surroundings'.
My proposal, if you reduce it to the minimum (and use ca[ rather than %c% -- credit to this SO for the a motion that I had not really known about) is not too bad because it is the sort of thing you can invent again once you know it is possible:
yi[ca[()<Esc>"0P
However, it occurred to me that a search-and-replace is going to be just the right kind of solution when you need to do a few of these in a file. Here is my best effort:
select the area in visual mode (I tend to use VISUAL LINE mode as a default),
then :s/\[\(.\{-}\)\]/(\1)/g<Enter> and you're done.
That itself looks a bit mad, but it is just a simple example of so-called backreferencing so I was quite happy to have had to get that clear in my mind too.
Vi experts, I have two questions concerning the column editing!
First, I already know how to go to the visual mode and do a column edit. But the point is that after shift+I and type, you can only see the first row changing before esc. My question is this, is it possible to make the editing operation visible in all rows? Or is this still an impossible task with the current vim?
My second question is, I want to insert a column with increasing numbers (0...9) or some user defined increasing items such as (monday...sunday) blahblah, what is the best way to achieve this, can I define a few customized functions and then call them?
"Still an impossible task" exposes a wrong assumption: Vim never wanted to be a WYSIWYG editor; just updating the current row requires less screen updates (which can be significant over slow connections; the whole modal editing of vi was partly born out of that necessity).
There are some attempts at "multiple cursors" plugins; with those, you might achieve this, though.
second question
(Note that it is bad style to ask about two unrelated things in a single question.)
Yes, you can do almost anything in "a few customized functions" (but you'd have to clarify your exact use case to get meaningful answers).
Some of that can be done via the speeddating plugin:
{Visual}<C-A> Increment by [count] the component under the cursor on each line of the linewise visual selection. If a component is absent on a line, it is filled in as being [count] higher than on the line above it. This can be used to create sequences. For example, place a "0" on a line followed by 4 blank lines, visually select all 5 lines, and press <C-A> to get a sequence of 1 through 5. You can use letters in visual mode too: make the first entry Z if you want a list starting with A.
Does anybody have her vim setup in a way that uses hard tabs as indentation characters, but does use spaces for alignment? The problem I have is that when starting a continuation line like in
if (condition1 && (anotherlongcondition || /* <-- Here I insert a newline */
|-------|------- whatever /* some additional alignment added automatically */
, then cin (which is a must for me) adds some alignment just the way I prefer positionally, but this alignment is created using as much hard tabs as possible and filling the rest with spaces (as I tried to visualize).
So, in short, cin doesn't really seem to distinguish between indentation and alignment. I'd really like that all the added alignment in the example above is spaces. This way the alignment would be preserved correctly when switching ts temporarily.
To make it clear again, I'd like to be able to write the following code, never pressing <TAB> or <SPACE> in front of the first non-blank character in any line (and not doing any manual shifting or whatever):
void foo(int bar)
{
|-------somestatement;
|-------if (somecondition && (someothercondition ||
|------- whatevercomesnext))
|-------|-------dosomething;
}
I have already tried out ctab.vim, but it focuses on editing an aligned line with soft tabs, which seems silly to me because manual alignment is a task which affords 1-step refinement and not tab-width-step refinement. I did not change the way cin uses mixed tabs and spaces for alignment.
I have not managed to find any built-in way to accomplish that. Perhaps still, there is one? Anyway, I doubt that there's a plugin that does that. Although I admittedly don't vim-script myself and may not have enough experience, I must say that most plugins I tried out only messed up my editor configuration...
In addition to your :set cino=(1, you may also be interested in the 'preserveindent' and 'copyindent' options if you've not encountered them already. They don't completely solve your problem, but they do go some way towards helping.
Okay, sorry for the question. I've finally found some good material for it.
http://vim.1045645.n5.nabble.com/Indent-with-tabs-align-with-spaces-td1183279.html
To sum up, currently vim is not flexible enough for this to be done comfortably.
My workaround currently is using :set cinoptions=(1 which adds only one alignment unit when starting a continuation line. This way, I can be sure that the added alignment is a space (as long as I did not :set ts=1, at least) and add the nice amount of spaces manually. This is still ok in terms of speed and seems to be the least distracting behaviour to me!
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why did we bother with line numbers at all?
I'm curious about why early versions of the BASIC programming language had line numbering like in:
42 PRINT "Hello world!"
The text editors back then had no line numbering?
EDIT: Yes, I know they are used for GOTOs, but why? I mean having labels was too computationally expensive?
Many microcomputers had a BASIC interpreter in ROM that would start upon bootup. The problem was that there was no text editor or file system to speak of. You had an interactive prompt to do everything through. If you wanted to insert a line of code, you just typed it, starting with the line number. It would insert it into the correct spot in you code. e.g:
>10 print "hello"
>30 goto 10
>20 print "world"
>list
10 PRINT "hello"
20 PRINT "world"
30 GOTO 10
>
(In that example > is the BASIC prompt)
If you wanted to erase a line, you would type something like ERASE 20.
Some really fancy systems gave you a line editor (i.e. EDIT 10)
And if you didn't plan your line numbers and ran out (how do I insert a line between 10 and 11?) some systems gave you a RENUM command which would renumber your code (and adjust GOTOs and GOSUBs appropriately).
Fun Times!
The original BASIC line numbering was actually an integral part of the language, and used for control flow.
The GOTO and GOSUB commands would take the line, and use it for control flow. This was common then (even though it's discouraged now).
They were used as labels for GOTO and GOSUB
Like this:
10 PRINT "HELLO WORLD"
20 GOTO 10
There were no named labels in some early BASIC versions
They were also required if you wanted to insert a line between 2 existing lines of code, because in the early days, you had no full text editors. Everything had to be typed in the "interactive" interpreter.
So if you typed:
15 PRINT "AND THE UNIVERSE"
The program would become:
10 PRINT "HELLO WORLD"
15 PRINT "AND THE UNIVERSE"
20 GOTO 10
When you ran out of line numbers, you could run a "renumbering" tool to renumber all lines in your program, but in the very early days of the Commodore 64 and other home computers, we didn't even have that, so you'd have to renumber manually. That's why you had to leave gaps of 10 or more in the line numbers, so you could easily add lines in between.
If you want to try out the Commodore 64 interpreter, check out this C64 emulator written in Flash: http://codeazur.com.br/stuff/fc64_final/ (no install required)
In BASIC, the line numbers indicated sequence.
Also, many older editors weren't for files, but simply lines ("line editors", e.g. ed, the standard editor). By numbering them this way, you knew which line you were working on.
A simple google reveals what wikipedia has to say about it:
Line numbers were a required element of syntax in some older programming languages such as GW-BASIC.[2] The primary reason for this is that most operating systems at the time lacked interactive text editors; since the programmer's interface was usually limited to a line editor, line numbers provided a mechanism by which specific lines in the source code could be referenced for editing, and by which the programmer could insert a new line at a specific point. Line numbers also provided a convenient means of distinguishing between code to be entered into the program and commands to be executed immediately when entered by the user (which do not have line numbers).
Back in the day all languages had sequence numbers, everything was on punched cards.
There was one line per card.
Decks of cards made up your program.
When you dropped the cards, you'd put them in a card sorter that used those sequence numbers.
And of course, they were referenced by control flow constructs.
On the C64, there wasn't even a real editor (built-in at least). To edit a part of the program, you'd do something like LIST 100-200, and then you'd only be able to edit those lines that were currently displayed on the screen (no scrolling upwards!)
They were labels for statements, so that you could GOTO the line number. The number of the statements did not necessarily have to match the physical line numbers in the file.
The line numbers were used in control flow. There were no named subroutines. You had to use GOSUB 60, for instance, to call the subroutine starting at line 60.
On your update, not all languages had labels, but all languages had line numbers at one time. At one time, everything was punch cards. BASIC was one of the very first interactive languages, where you could actually type something and have a response immediately. Line numbers were still the current technology.
Labels are an extra expense. You have to keep track of the correlation between the symbolic label and the code or data to which it refers. But if every line has a line number (and if all transfer of control flow statements always refer to the beginning of a line), then you don't need a separate symbol table.
Also keep in mind that original BASIC interpreters didn't need a symbol table for variables: There were 26 variables named A-Z. Some were sophisticated and had An-Zn. Some got very fancy and added a distinction between string, integer and floating point by adding "$" or "%" after the variable. But no symbol table was required.
IIRC, line numbers were mostly used as labels for GOTO and GOSUB statements, since in some (most?) flavors of BASIC there was no way to label a section of code.
They were also used by the editor - ie you said:
edit 100
to edit line 100.
As others have pointed out, these line numbers were used as part of subroutines.
Of course, there's a reason that this isn't done anymore. Imagine if you say GOTO 20 on line 10, and then later realize you need to write 10 more lines of code after line 10. All of a sudden, you're smashing up against 20 so you either need to shift your subroutine farther away (higher numbers) and change your GOTO value, or you need to write another subroutine that jumps farther in the code.
In other words, it became a nightmare of true spaghetti code and is not fun to maintain.
It was entered in on the command-line in many instances (or was, on my old Commodore 64) so there might not always have been a text editor, or if there was, it was quite basic.
In addition, you would need to do GOTOs and the like, as well as inserting lines in between others.
ie:
10 PRINT "HELLO"
20 GOTO 10
15 PRINT " WORLD"
where it would go in the logical 10 15 20
Some editors only had an "overwrite" mode and no "insert" mode. This made editing of existing code extremely painful. By adding that line-number feature, you could however patch existing code from anywhere within the file:
100 PRINT "Broken Code"
200 PRINT "Foobar"
...
101 patch the broken code
102 patch more broken code
Because line numbers didn't have to be ordered within the file.
Line numbers were a PART of the language, in some VERY early ones, even the OS was just these simple lines. ALL you had was one line at a time to manipulate. Try writing an accounting system using 1-4k program files and segmenting it by size to get stuff done. To edit you used the line numbers to tell what you were editing. So, if you entered like:
10 PRINT "howdy"
20 GOTO 10
10 PRINT "WOOPS"
15 PRINT "MORE WOOPS"
20
RUN
YOU WOULD GET:
WOOPS
MORE WHOOPS
The blank 20 would effectivly delete that line.