Please be kind


This is what I came up with. I understand there are correct codes all over the internet. The problem is in every discussion someone out of frustration posts the correct code and it cannot be unseen. I at least end up learning less and less and regurgitate other folks achievements. I’m posting this to find not what the correct answer is but where my thinking is faulty. Thanks for the input

def anti_vowel(text):
  vwls = ["aeiouAEIOU"]
  sent = [text]
  #print sent
  for letter in range(len(sent)):  
    #print sent[letter],
    for l in range(len(vwls)):
      if vwls[l] == sent[letter]:
        del sent[letter]
    return sent

print anti_vowel("I love you!")


Start by making sure that your overall idea amounts to the right solution (do it on paper or in your head or something)

Then add prints to your code and compare what’s printed to what you just did manually. Rethink the parts responsible for the part(s) that went wrong


Back at it again are we. I suspect I gave a near identical answer last time. But that’s how one starts, right. And one might run into trouble while doing it, but that’s just the next thing to investigate/ask about

You’re not meant to be stuck so do ask plenty if you need to - beats making it take days.
You’re meant to look at and reason about it yourself. But ask as much as you need to do that.


Haha! Yeah, I’ve actually been plodding away at it. Am putting in serious daily effort now. I don’t have a good grasp of how long to struggle with a problem before I yell help. I know the possibility of getting out of my misery and faster progression through the course is always tempting but also understand the students mind is stunted by it. I’m been sweating this out for 3 days now employing various approaches. Thanks again for the input - when I build the next Quora/FB/or Whatsapp I’ll credit your assistance, lol!


Try to figure out what’s stopping you, what you’re unable to reason about, and ask about it

Your communication skills are obviously fine, I’m taking that as an indication of that you shouldn’t have any issues with any of these things, just gotta fix what goes wrong

Looking at your code it isn’t all that far off. So… you’re getting the operations wrong - question is why you wrote anything at all if you don’t know how to do an operation right? So where are you certain, and where are you not, and how can you find out, or what can’t you find out? You’re doing some guessing and that just doesn’t work out at all, because you’re going to guess wrong

Anything you write should be with pretty firm ideas about what it does and why it’s needed. And that’s pretty hard with a new language, but mostly has to do with carefully learning the basics and building on them, so that they can be combined later


Can I ask you a question? (You ever notice when people seek permission to ask you a question they are getting ready to pry beyond their access? lol) Anyway, when you were here - I mean at my level of coding what helped you the most? I mean past the fundamentals -shoulder to the wheel, nose to the grindstone stuff. I’m not lazy but somedays I wonder if there’s a better way and I’m just not using it. Like ploughing with oxen when on the other side of the world there are people capturing continents with steam engines. I’m even willing to accept that my progress might be slower for the same reason I learned to read much earlier than other kids. Programming aptitude if you wanna put a name on it. I want to -as fast as possible (perhaps this is my problem?) bridge the distance between my conception of the obvious and its translation into computer-readable code.


And the answer is always just ask

That’s really difficult to accurately answer, to even have an accurate recollection of. I’d like to think I was good at checking my assumptions, I knew what the things I used did. I horribly misused them and produced very long code for what it did, but I knew what they did, there was a plan for how they should fit together and I was able to go in anywhere and check that it really was doing what I thought. So I’m sticking by what I just said, really :P

There is a problem there with python. I’d be surprised if you knew how for-loops do what they do. It’s a good argument for sticking with while-loops and explicitly increasing a counter.

But it’s still an excellent first language in that it’s easy to make things happen, you kind of just write it the way you think it without silly amounts of boilerplate

…Practice? Seeing the effects of what you write


Have you done anything more with your function?

Again, adding prints to find out what ends up happening is a good way to start.
If you print out all the is-it-a-vowel comparisons you’ll be able to tell wether it’s behaving correctly so far, and if so have a look at the deletions, or otherwise the comparison itself or looping of letters

Get in there somewhere in the middle and have a look at the state of things. That’s how everyone really ever does it. And if you do this, you’ll have a hard time not finding the issue, or finding something you can’t reason about which is nearly as good, it’s a loose string to pull at (with something to learn at the end)


I scratched my original approach which was to turn the inputs into lists, why I approached it this way originally I can’t even think of now… My current approach is to work the problem as strings and implementing print outputs as standard procedure now


Right, the operations you need will dictate what data structure to use.
Whichever one you find suitable, there are three issues that are important to understand with the above code, one is about syntax and verifying what it did, another is about unnecessary information creating clutter, and the last about doing a really strange expensive difficult-to-reason-about operation


I can see where I screwed it up now. The comparison isn’t working out like it should but at least now I know where exactly the leak is!

def anti_vowel(text):
  vwls = "aeiouAEIOU"
  for letter in text: 
    print text[2]
    for l in vwls:
      print vwls[0]
    if letter == l:
        del letter
    return text
print anti_vowel("Parkour is fun")


That’s one thing off my list at least.
Indexes. Not interesting.


Just like that 3 hrs of my weekend slugging away at code. Am no complaining - I do love the ‘aha’ moments very much - that split second of euphoria right after you hit run and discover there’s no blood on the other side of the console

How are indexes off your list? I’d imagine with the advent of so called big data indexes and indexing should be ‘ready at hip level’ for the draw, no?
My current team (I play Scrum-Master at my day job btw) is all about distilling data. Its a big part of why I want to ‘learn up’ in this.


You were using range to produce indexes which you didn’t need. You just needed the letters, so one should loop over the string/list, not indexes just to get the letters
The position wasn’t interesting. Just getting the letters

Also, from the original code

['blahblah'] <- a list with one element. If you iterate over this you will do 1 iteration
compare to
list('blahblah') <- create a list from the elements in ‘blahblah’ -> ['b', 'l', 'a', 'h', 'b', 'l', 'a', 'h']

The last and third issue is what happens when you remove something from a list you’re currently iterating over - things will move, your loop would need to account for it, or do something else entirely. As for strings, you cannot modify them at all, they are immutable
So you CAN remove elements inside a list, but everything following has to move (expensive), and you have to adjust the loop for that (complicated), and it just isn’t what you would do manually (strange, and referring to what you’d do manually says much about how you could do it differently)

Also this:

calling that variable letter is entirely misleading - making it really hard to read/reason about code


If you think this is strange or hard to figure out, it’s not.

list is a type – it’s not a function. It’s callable, like a function, yes. Calling a type creates an instance (in the case of list, a list), and they’ll typically accept an argument to create it from (an iterable in the case of list), or empty if no arguments are given

list()      # []
str()       # ''
int()       # 0
type(0)     # int
type(0)()   # 0 (because type(0) is int, and then call it)
type([])()  # [] same thing

What exactly they accept as input and what they do with it varies because they neccessarily do different things (they represent different things, that’s the point. They are types. There may also be other functions or methods that do something to return an instance of a type (a value), like str.join)

And besides, actions like creating a list of characters from a string is exactly the kind of thing you figure out by googling and clicking the first stackoverflow result

And on deleting elements, just doesn’t make sense for this task - it’s not the action you meant, not really. So figuring out that this isn’t what you want isn’t difficult either, if you just consider what it does.


Straight shots - all to the head. Thank you!


The outcome works but the formatting is completely jumbled.
What am I missing?

def anti_vowel(text):
  #vwls = ("")
  for letter in text: 
    if letter not in list("aeiouAEIOU"):
      print letter,
print anti_vowel("Parkour is fun")


Where exactly should the result be printed there? I see two print statements.
And, how is that function supposed to communicate with the world outside of itself?


I tried ‘returning’ the individual cycles but that didn’t work i.e.

for ......

return text

It ends up printing the unprocessed text input which I can’t explain since the text is modified in the function.


That’ll exit. That’s kind of what return means.

But which should it be?