A question on PygLatin


#1

I was wondering if the following lines:

new_word = word + first + pyg
new_word = new_word[1:len(new_word)]

can be expressed as:

new_word = (word + first + pyg)[1:len(new_word)]

Basically it is the same, isn't it?
But the second options shows me a truncated string without the pyg.
Can someone explain to me whats the difference?


#2

nobody can reply?...


#3

This is kind of a "press the run button and find out" thing though


#4

I would love to help, but unfourtunately im not very familar with python(especially with the whitespaces) so i will just invite some people who will surely help you.


#5

Which I did, and as I said previously in the OP, it showed truncated.
I just want to deepen my understanding of why this is happening, and how the interpreter was interpreting it, since it seems to me that syntactically it seems to be equivalent.

The first option, making two assignations separately works, the second one I tried to make it more efficient and it failed. Both apparently (to me) are the same, but the interpreter evidently thinks it is not.
So I would like to know the why instead of letting it pass as an oddity.


#6

So the question is not whether they are equivalent, you already found that out.

Assignment goes like this, right:

<var-name> = <expression>

So first the expression is evaluated, and then the variable is made to refer to the resulting value.
What's the length of new_word when that's being evaluated?

With slicing you can leave some arguments out as well, so you don't need to specify the end if you mean "until the end" some examples:

[:] # copy
[1:] # all but the first
[:-1] # all but the last
[::-1] # backwards

#7

@ionatan I learned the len(variable) from the codecademy course, that is the way they teach it... (Later on I learned that I can leave it [1:] in the udacity course, seems to be way more thorough than codecademy)
Thanks for the tips!

Your answer made me think about the assignation of new_word in the second option, I was trying to go back and check my code but it seems that codecademy doesn't save it... :frowning:
But I guess that the problem was that in the second option that because the new_word wasn't assigned as the concatenated string, the length was off so that was why it appeared truncated.

Now I wonder if:

new_word = (word + first + pyg)[1:]

would have worked as:

new_word = word + first + pyg
new_word = new_word[1:len(new_word)]


#8

Yes,

a = len(a) # a is undefined

But the track doesn't contradict that


#9

Thanks!, I just found the code and you were right.
Btw, I found also the lesson that "instructs" me to add [1:len(new_word)]
I wonder what was the didactic value of asking me to do that...?


#10

But the length is already set correctly there.

Yes, it's pointless to specify the length. The author either wasn't aware or wanted to make a point of that you can specify the end.

The way I see it:
Codecademy isn't always going to give you the best suggestions.
It's extremely brief, it's just an introduction to languages.
Use it to get spoon fed with syntax and get some idea of how to get around.

And then you can move on to other stuff. There are lots of sites, I'll mention the one that's on the top of my mind for the moment which is www.codewars.com where you solve user-generated problems and then get to see how others do it which is great for picking up tricks. Just keep in mind that the crowd might not always vote up the best solution, and shortest isn't always best.


#11

Thanks @ionatan!
I have a question, what's the best practice?
Being extremely verbose, assigning variables everywhere, or cramming everything to be efficient.
For instance, instead of:

original = raw_input()
first = original[0]
pyg = "ay"
new_word = original + first + pyg
print new_word

to simply put:

original = raw_input()
print original + original[0] + "ay"

Is there any performance difference in the programs? Or is it just about prioritizing readability of the source code?


#12

There's no easy answer to that, lots of things to take into account. If it somewhat resembles natural language, then you're doing good, but that's still not all there is to it.

Aim to split up your code into functions so that any given piece of code only has a few things to keep track of.

It's very clear what the second one does. Knowing what the first one does, I have bit of a "ugh, don't wanna read through it" kind of reaction. It's diluted.

Comments can help a lot. You can try to write comments that describe what is supposed to happen, and then fill in the code. Don't describe the implementation, describe what's being done.

# get the word to translate from stdin

# print <all but the first letter> + <the first letter> + 'ay'

As a bonus, these are really good for comparing your code to your intentions, helps in debugging. helps in maintaining code too, that the intentions are stated. Both the intentions and their implementations can be checked to see if they add up.


#13

Thanks a lot @ionatan you helped me a lot!
I think I am getting the hang of it, I'll check the codewars as soon as I finish the udacity and codecademy's courses.
Codecademy was amazing to get my feet wet.