Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Welcome to Python
Transcript of Welcome to Python
Who uses Python?
How everything started
You Like Python,
Guido van Rossum,
198x, ABC, OS Amoeba.
Over six years ago, in December 1989, I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. My office ... would be closed, but I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately: a descendant of ABC that would appeal to Unix/C hackers. I chose Python as a working title for the project, being in a slightly irreverent mood (and a big fan of Monty Python's Flying Circus).
What is Python?
...which is open source software
It is a programming language...
...with a C-based reference implementation...
- CPython, bytecode interpreter
- the future of the Python
Python Interpreter Code (in RPhyton)
Your own Interpreter Code (in RPhyton)
Your Own Interpreter + JIT
Python Interpreter + JIT
Key features of Python,
a SuperHighLevel language
There is nothing unnecessary in Python
Python uses dynamic types
Stating the type
Assigning the value
We call it Minimalism
Python Easter Egg
When you type "import this", you can see The Zen of Python
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.
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!
The Zen of Python
Supporting Programming Paradigms
everything are objects
The Path of Development
No Compatibility Between
The Magic of Whitespaces
The Path of Development