The Ultimate Python Programming Tutorial
course's star rating by considering a number of different factors
such as the number of ratings, the age of ratings, and the
likelihood of fraudulent ratings.
Find online courses made by experts from around the world.
Take your courses with you and learn anywhere, anytime.
Learn and practice real-world skills and achieve your goals.
In this online Python course from O'Reilly Media, you will learn how to program with the popular development language. This tutorial is designed for the beginner, and you do not need to have any experience at all with programming or development in order to learn how to program with Python using this video tutorial.
Some of the topics that this course covers throughout the ultimate Python for beginners training include installing Python, data types and creating variables, input and output, decision making and repetition, iterators, list comprehension and functions. He also covers variable scope, modules - creating and using pre-built ones, object oriented programming, inheritance, exception handling and using data structures.
By the completion of this python for beginners video based training course on Python programming, you will be comfortable with Python and how to apply it to developing applications. Throughout the course you will apply what you learn in real-world examples, reinforcing what Mike is teaching you. Working files are included to allow you to use the same source material that the author does in this training course
Take this course now online Python course and master your skill!
Not for you? No problem.
30 day money back guarantee.
Learn on the go.
Desktop, iOS and Android.
Certificate of completion.
|Section 1: Introduction|
Working Files - Download These FirstPreview
What This Course CoversPreview
|Section 2: Installing Python|
Installing Python In WindowsPreview
Installing Python On A MacPreview
|Section 3: Writing Your First Program - Hello, World!|
Entering And Running A Program In WindowsPreview
Entering And Running A Program On A Mac
|Section 4: Python Basic Data Types And Variables|
Expressions, Statements, Variables
Working With Numbers
Working With Strings
Working With Booleans
Working With Lists
Working With Dictionaries
Working With Tuples
|Section 5: Python Input/Output|
Using The Print Function - Part 1
Using The Print Function - Part 2
Getting Input From The User
|Section 6: Making Decisions - if Statements|
The Relational Operators
The Logical Operators
Simple if Statement
|Section 7: while Loops|
Introduction To while Loops
Count-Controlled while Loops
Event-Controlled while Loops
Working With Files - Part 1
Working With Files - Part 2
|Section 8: for Loops|
Introduction To for Loops - Part 1
Introduction To for Loops - Part 2
for Loops With Lists
for Loops With Tuples
for Loops With Dictionaries
for Loops With Files
|Section 9: Iterators|
Using iter And next
Iterators And Dictionaries
|Section 10: List Comprehensions|
Introduction To List Comprehensions
Using List Comprehensions With Files
|Section 11: Functions|
Introduction To Functions - Why
Functions With Multiple Arguments
|Section 12: More On Functions|
Recursive Functions - Part 1
Recursive Functions - Part 2
|Section 13: Scope|
Exercise 1 - Part 1
Exercise 1 - Part 2
|Section 14: Modules|
Using Built-In Modules
User-Defined Modules - Part 1
User-Defined Modules - Part 2
|Section 15: Object-Oriented Programming - Part 1|
Abstract Data Types
Designing A Class, Fields And Constructors
Designing A Class, Methods
Data Structure For Fields
|Section 16: Object-Oriented Programming - Part 2|
Creating A Derived Class - Part 1
Creating A Derived Class - Part 2
Infinite Skills is a Canadian based company who offer a huge and ever growing range of high quality eLearning solutions that teach using studio quality narrated videos backed-up with practical hands-on examples and comprehensive working files. All courses are created by trained educators and experts in video based education.
The emphasis is on teaching real life skills that are essential for progressing in today's commercial environment.
Good libraries are like novels -- hard to write in any language. Every language has a different
definition of good. Java can't be transliterated to Pythonwell because every language has its
"Pythonic" code is in harmony with standard libraries and conventions of Python and takes advantage of the features baked into Python. You might not think you create APIs -- you do, if only for your future self. Anywhere you present functionality to other code, even in the same codebase. Your function names, classes, command line flags, HTTP endpoints, and error messages are all part of your API.
To build a library that's easy to use, you have to put yourself in the shoes of a developer who heard about your library this morning and has a problem to solve this afternoon. Don't make them put aside all they know already. Use familiar vocabulary in your API. Reuse conventions from the rest of Python. Try to avoid surprising them with anything.
Craft is any process that attempts to create a functional artifact without separating design from manufacture. -- Wroblewski source
As you build your library, you will likely see rough spots that need improvement. That's normal -- try to smooth them out as they become visible instead of promising to clean it up later. Think about how your decisions will affect the finished product. Is naming this method requests.requests_get going to make it easy to remember? No, it looks confusing since you're already in a namespace. For more about simplicity and readability, take a minute to review The Zen of Python (PEP 20).
Names make code readable, it's how users most often will be thinking about your library.
Avoid names like "skycopter" -- what even is that? Names need to be easy to reason about. If
the name that best describes your object or function is exceptionally long, consider that it
may have too many responsibilities and will be too complicated for users to understand
easily. This is doubly true if it contains the name of one or more design patterns .
Use familiar words if you can. Requests has methods that match HTTP method names, which users of requests likely know already.
The average human can hold five to nine chunks of stuff in their head at once; don't fill up all
those slots with just your function call. If you have that many knobs on your widget, fear not.
You can make sane defaults, use a configuration file, or add a wrapper class so developers
don't need every parameter for every call.
Say you have a function that looks up a user on your service by their username: that requires API credentials, an API endpoint, and a user to query for.
So which would you prefer to call -- get_user or Session.user? I'd prefer not to provide the arguments every time, and a class is one way to do that. Another alternative is to use functools from the standard library. A "partial" is a function that remembers some provided arguments and calls the underlying implementation.
The code above saves the first arguments to get_user and gives back a new function that only needs to be passed the username similarly to the Session class. The difference is that functools lets us skip the boilerplate code to create the object.
Python has loads of standard method names associated with defined protocols. Most of them are made to integrate your objects with builtins -- think len and str. To let your object use those builtins you simply need to implement __len__ and __str__. If you find yourself writing a method like .length() ask yourself if thats what users would expect. The answer is likely "No!"
When you make an object, also define a nice __repr__ function for it -- you'll thank yourself later. By default, when you print an object, Python tells you about its location in memory.
Two lines of code are all it takes to make printing an object useful.
This may not seem like much of a change, but for users new to your library or those that are using it interactively this is a huge improvement. It makes it easy to see what an object is without knowing all the fields it provides.
When you present a user with a list, you must consider their needs. Are you presenting the filename of every file on their filesystem as a list; loading every item into memory at once? If you can calculate the values incrementally, it's helpful to do so. It means you can start processing values without waiting for the full list to be loaded into memory. Consider looping over a bunch of numbers.
In Python 2, that code would create a list of all 1000 digits and returned it to be iterated over.
It works, but using all that memory doesn't help the caller. The caller only needs to know the
next value. In Python 3, range would generate the next number only when asked. Generators
are iterable, but don't produce all their values up front.
Here, we make our own generator to count up from zero.
What makes a generator different from a normal function is the yield keyword. The function stops what it's doing at the yield and hands control back to whatever called it. This lets the caller (our for loop) process each result before calculating the next value. For our generator, counting to 5 million would have the same memory footprint as counting to four.
It's easy to add setup steps for your classes in the __init__ method, but failures might leave you with some resources that need to be cleaned up. Lockfiles, open sockets, and other things need to be cleaned up whether your object finished creating or not.
It's easy to forget to release all your resources. Python provides context managers to make the process of acquiring and releasing shared resources easier. A context manager is a simple way to ensure that initialization and teardown are easy to do correctly. To use a context manager, you open a block using the with statement and teardown is automatically done when exiting the block.
The calling code can be much simpler thanks to with. You can also see that the contextmanager is actually a decorator atop a generator function. See how nicely these compose? Context managers are useful for safely writing to files, getting transaction locks, database connections, and more.
Developers are people too. When I buy a power tool, I don't read the warnings. After a trip to Ikea, I don't read the instructions unless I have to. Your program is a tool, and its job is to help users. Your users want to install a library and get back to work, and a great user interface is critical to letting them do just that.
Where is your documentation? I hear you, documentation isn't code, but it is the
Application-Human Interface for your project. Without documentation you leave developers
adrift on StackOverflow -- or worse, send them wading through your source code never to be
For an example of nice documentation, take a gander at the tox or sphinx docs. Both prominently feature a low-jargon description of the project. Here's the Sphinx summary:
Sphinx is a tool that makes it easy to create intelligent and beautiful documentation
And on tox's page:
tox aims to automate and standardize testing in Python
A curious developer might then say "neat, how does this tool do that?" Both pages answer
immediately with code samples and feature highlights. In just a minute or two I can decide
whether these are the right tools for my job.
Further down the page, there are paragraphs of additional detail and links to: extra examples, documentation, user stories, and feature lists.
For a deeper dive into documentation, check out Django contributor Jacob Kaplan-Moss' series on Writing Great Documentation. It ought to be required reading for Computer Science students. William Zinsser's book On Writing Well is an excellent guide for any nonfiction, but does not focus on technical documentation.
Computers break. Assumptions can be wrong. The International Space Station has six computers running all the time, checking each others' work. In space, every calculation must be correct every time. When things break in (or outside of) your library, which of these should you show?
Your error messages need to be as helpful as possible. They are born to say "______ went wrong, and here's how you make it stop _____". You may not be able to depend on being able to surface logs directly, but you can always be sure to throw readable exceptions. It's a good idea to create your own exception classes, check out this example from SQLAlchemy (full code).
Having a top-level class for all SQLAlchemy's exception classes makes it easy to see if a
problem comes from SQLAlchemy with an issubclass test. For users, this makes it easy to
track down the source of a problem.
Specific exceptions like DisconnectionError help by explaining everything SQLAlchemy tried before raising the exception.
Next time you sit down to write a library, don't start by writing code. Get out of the author
mindset for a moment and think about how you'd expect it to work. Consider which features
you'd need, and which are "nice-to-have". Look at libraries that solve similar problems and
see what idioms they use, or what they do that doesn't seem quite right.
Take the time to solve the problem you set out to in the best way you know how. Your users and fellow developers will thank you.