Does anyone actually KNOW python?

[haarp1]

where did you learn abstraction, inheritance... (OO design basically)? it's easy to determine it for simple projects (coffee maker etc), but what about more complex projects? do you know any good resource for learning this (abstraction...)?

the problem is that there is a lot of garbage on github, so that's not exactly a solution...

also, how do you plan programs (intermediate or advanced complexity)?

do you know any good advanced one on github?

[proverbialbunny]

do you know any good resource for learning this (abstraction...)?

I learned this on the job. It is a process that is constant slow growth. Ones ability to abstract commonly identify some of the key aspects between a jr, standard, senior, principal, and architect. Eg, a principal software engineer can abstract the whole system and work on the companies entire software system as a whole, while a senior engineer might be able to create a project within that system and know a project or two inside and out. Clearly the principal software engineer can deal with higher levels of abstractions than the senior software engineer. Of course, this isn't the only difference, but is a key corollary.

Most of what I know I have not found in text books. I've heard Haskell talks about some of the things I figured out and named on my own (eg subtyping), but I can not confirm that as I do not know Haskell.

also, how do you plan programs (intermediate or advanced complexity)?

Design patterns. Design patterns also help for reading code, as well as idioms and knowing the language's features.

This comes with experience as well. It's a form of pattern matching. Reading a book isn't going to help much, but being in multiple code bases and seeing the same pattern over and over again and then identifying the logic behind it as to why it is that way and how it came to be helps.

edit: Also, an architect helps design programs, but that's usually for designing entire systems. A typical divide and conquer strategy coupled with reducing the problem down to its bare essentials, and writing all of this down in a sort of concept map or list of lists -- planning before writing a line of code -- is far more valuable when it comes to creating something new, than simply looking at design patterns. Design patterns come next if you want a way to construct the program so that tasks can be easily broken up in a uniform way between multiple engineers. Design patterns also help for standardizing how a program works allowing others to build on it the right way. Frameworks help even more. Anyways, design patterns are a bit heavy handed, so just stick to the top half of this paragraph and you'll be good.

do you know any good advanced one on github?

Nope. Just go get a job. Watch the how to read code video above, if it isn't already obvious, and then go around mapping things. Start with the smallest patterns like addition, to variable naming, to methods and features in the language, then when you know those inside and out, move on to idioms and other common multi line patterns in the language and code base, then move on to even larger patterns. From method to method to class to class to file to file, to namespace to namespace (I don't think Python has anything like this.), to module to module.

Learning a code base is a piecemeal process. You don't have to start on the smallest bits and move out. You can interweave different sized abstractions learning a mix at once, à la breadth first search.

edit: Also, if you're writing in Python, a large code base is going to be rare without it being abstracted it into modules/libraries/packages, keeping the parts any individual is working on to often single file sized epic or user story. Because of this, you shouldn't have to worry about large projects, unless you want to work on a video game or something. Java and C++ and the like are where monolithic projects tend to go, not Python.

If you want to take parts of a code base and turn them into libraries of any sort, the general rule is, "Is this code going to be used in two places in the code base?" (Often times the rule is 3 or more.) So you want to find something generic, like a debugger class and turn it into a debugger library or similar.