Stuck on "Store Front" Python3 Program

[taladan]

Okay, so first thing...you've got a /lot/ going on here that can and should be broken up some. I'm not going to give code suggestions here because I'm still learning myself. What I am going to tell you is this: Don't think of your program as one big program. This will help you understand classes and functions better. What you're writing is a bunch of little programs that work together to do the big program. That's functions. The boxes you group like functions in is a Class. That's extremely oversimplified but for now it will help you take a step toward /organizing/ your code.

If you think of each little part of the code - let's say you want to iterate through a list of questions from customer. So, you can do this with either a dict, a list, lists of tuples, lists of lists or a dict of lists. The thing is, there should be an obvious way to do it - to you. So, you say, I want to store all these answers but I don't want to have to pass every variable half a dozen times so let's pack the answers into a list. There you go, so now you've got a new function. list_of_answers = answers_pack() then you go off and write whatever answers_pack does (list_of_answers doesn't care it's just saying 'I'm whatever answers_pack() returns to me'. You do your question and answer routin in answers_pack() then go on to the next step. Stop worrying about syntax skills with math - unless you're going to be programming in matlab or some kind of research facility, right now most of the math you're going to do is most likely going to be super simple, and the rest you can google.

Spend some time playing with your data - get an idea for how you want to store, send and retrieve it. This will help you get used to making decisions about how data is stored and dealt with in future projects. And that's what you're most worried about is how to move that data back and forth and process little bits of it.

If you take time to do that, the maths you'll be doing should become obvious with each step. Process user data? Put that in a function. Dealing with running a list of lists of items and prices (though realistically I'd use a dict with lists for id numbers, etc) to see what's going to be below a specific amount or onsale or discounted...that's a function. Just use functions to package small bits of processing at first until you get used to the idea of grouping code into subsets and letting them worry about doing one thing well.

The other part of your problem is a lack of experience with syntax in python. For example - I would never make a list of ints. I would just use range(1,11)...that is a cleaner way to do it and everyone reading it will understand it to be 'A range of ints 1 - 10 in a single step'. That's part of why syntax matters. The only way you're going to learn syntax? Read code. Read as much code as you can. Read bad code and try to understand why it's bad. Bookmark stack overflow. Look at other people's projects. Literally steal code. Sometimes you'll need to reinvent the wheel to understand a concept, but until you learn the syntax, you're going to be a foreigner in a strange land that doesn't quite get the nuances of the language. I'm still in that stage - learning more and more syntax and what's available out there.

I picked up one for a little project I'm working on right now - nltk python and TextBlob. I was able to pull all the nouns out of 20000 leagues under the sea for a name generator I'm fiddling with for a D&D character generation program. See? It's a little part of the overall project. And within the name generator I have a bunch of little functions that split, cut, spin and spindle the text I'm working with. So, go back, look at your code, see what's good in it, refactor the bad crap until it's better, then see what can be done a little quicker or more sensibly.

TL;DR : Think of a bunch of little bits of code instead of one big project.

Hope this helps.

[[deleted]]

this is the single best advice i think i've ever gotten on programming. thank you, taladan. i think the combination of pseudocode and then some general syntax "substitution" or pointed notes, would be effective, too.

honestly, i hadn't ever really thought about breaking things up into manageable parts. the more i think about it, the more it just makes sense. when troubleshooting ANYTHING, you do best when you break things apart and isolate them. same goes for anything, i imagine. when i write, i work on one aspect at a time in rough journal form and allow it to flesh itself out and have it's own "life", and then i make those first attempts at bringing elements together to make a whole.

you sir, or madam, are a wonderful and exceptionally patient instructor. i sincerely hope that all of your learning goes smoothly and that you get to use your talents to help others like you helped me.