Hi 👋 , this site is mostly python3 and then some other tech tossed in
most of this information is easily found on the internet, but the code and opinions are completely my own.
much of the code is dated, the git log will not provide any real insight into many of the files that exist.
- proof of concept,
- demo purposes
- quick reference.
examples of:
-
django projects
- superPOC is new and should contain modern things.
-
flask
-
google app engine projects (very old)
-
scripts - often very old
-
pypi - old mixed with new
-
editor configs and opinions - all modern, or will be added soon (again modern)
- vscode
- sublime text 3
- pycharm
- vim
-
also some markdown references.
this repo is a new work in progress, what you see listed above may not exist yet.
after you read this, google PEP8 and put under your pillow.
of course, it would not be much of a python tips page without mentioning the "Zen of Python", which really embodies the philosophy of this language.
python -c "import this"
results in (as your skills improve, this makes more and more sense)
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
As you develop your skills, you will find yourself finding the above to become more true as time goes by.
Ralph Waldo Emerson wrote:
Foolish consistency is the hobgoblin of little minds -
my interpretation of it is simply:
If you start working on a project and it does something consistently but without real cause, stop doing it! especially if that consistency is expensive. however, don't just make that decision if you are on a team. there could be valid reasons for why that consistency exists; in that case, try to learn from the folks why it is that way and ask the questin to the team "how could we do this better?" in short, don't let the details bog you down from making real progress.