Simple Python2.7 Programming Beginner's experience summary _python

If you've never used Python, I strongly recommend that you read the Python introduction because you need to know the basic syntax and type.
Package Management

One of the best places in Python world is a large number of third-party packages. Similarly, managing these packages is also very easy. By convention, the packages needed for the project are listed in the Requirements.txt file. Each package occupies one row and typically contains a version number. Here is an example of this blog using pelican:

pelican==3.3
markdown
pelican-extended-sitemap==1.0.0

One flaw with Python packages is that they are installed globally by default. We're going to use a tool that allows us to have a separate environment for each project, the tool called Virtualenv. We also have to install a more advanced package management tool, called Pip, that he can work with virtualenv.

First, we need to install the PIP. Most Python installers have built-in easy_install (Python's default package management tool), so we use the Easy_install pip to install the PIP. This should be the last time you use Easy_install. If you don't have Easy_install installed in Linux, it looks like you can get it from the Python-setuptools package.

If you're using a Python version above 3.3, then virtualenv is already part of the standard library, so there's no need to install it anymore.

Next, you want to install Virtualenv and virtualenvwrapper. VIRTUALENV enables you to create an independent environment for each project. This is especially useful when you have different projects that use different versions of the package. Virtualenv Wrapper provides some good scripts to make things easier.

sudo pip install Virtualenvwrapper

When Virtualenvwrapper is installed, it lists virtualenv as a dependent package, so it is automatically installed.

Open a new shell and enter mkvirtualenv test. If you open another shell, you are not in the virtualenv, you can start it by Workon test. If you have finished your work, you can use deactivate to deactivate it.

IPython

Ipython is a substitute for a standard Python interactive programming environment that supports automatic completion, fast document access, and many other features that the standard interactive programming environment should have.

When you are in a virtual environment, you can easily install using the PIP install Ipython, using Ipython on the command line to start

Another good feature is the "notebook", which requires additional components. After the installation is complete, you can use Ipython notebook, and there will be a good Web UI, you can create a notebook. This is very popular in the field of scientific computing.

Test

I recommend using nose or py.test. I use nose in most cases. They are basically similar. I'll explain some of nose's details.

Here's an example of a person who has been testing for the ridiculous use of nose to create. All functions that begin with test_ in a file that starts with Test_ are called:

Def test_equality ():
  assert True = = False

As expected, our tests did not pass when the nose was run.

(test) Jhaddad@jons-mac-pro ~virtual_env/src$ nosetests                                                                   
F
=============================================== =======================
FAIL:test_nose_example.test_equality
----------------------------------------- -----------------------------
Traceback (most recent call last):
 File "/users/jhaddad/.virtualenvs/test/lib /python2.7/site-packages/nose/case.py ", line 197, in Runtest
  self.test (*self.arg)
 File"/users/jhaddad/. virtualenvs/test/src/test_nose_example.py ", line 3, in test_equality
  assert True = = False
assertionerror
 
----------------------------------------------------------------------

Nose.tools also has some handy ways to call

From Nose.tools import assert_true
def test_equality ():
  assert_true (False)

If you want to use a more similar approach to JUnit, it's OK:

From Nose.tools import assert_true from
unittest import TestCase
 
class Exampletest (TestCase):
 
  def setUp ( Self): # SetUp & Teardown are both available
    Self.blah = False
 
  def test_blah (self):
    self.asserttrue ( Self.blah)

To start the test:

(test) Jhaddad@jons-mac-pro ~virtual_env/src$ nosetests                                                                   
F
=============================================== =======================
Fail:test_blah (test_nose_example. exampletest)
----------------------------------------------------------------------
traceback (most Recent call last):
 File "/users/jhaddad/.virtualenvs/test/src/test_nose_example.py", line one, in Test_blah
  Self.asserttrue (Self.blah)
Assertionerror:false is not true
 
--------------------------------------------- -------------------------
Ran 1 Test in 0.003s
 
FAILED (Failures=1)

The Great Mock Library is contained in Python 3, but if you are using Python 2, you can use PyPI to get it. This test will make a remote call, but this call will take 10s. This example is obviously artificially fabricated. We use a mock to return the sample data instead of actually making the call.

Import mock from
 
mocks import patch from time
import sleep
 
class Sweetness (object):
  def Slow_remote_call (self): Sleep
    (a) return
    "Some_data" # Lets pretend we ' "back to our remote API call
 
def Test_long_ca LL ():
  s = sweetness () result
  = S.slow_remote_call ()
  assert result = = "Some_data"

Of course, our tests take a long time.

(test) Jhaddad@jons-mac-pro ~virtual_env/src$ nosetests test_mock.py                                                            
 
Ran 1 Test in 10.001s
 
OK

It's too slow! So we're going to ask ourselves, what are we testing? Do we need to test whether a remote call is useful or do we want to test what to do when we get the data? Most of the cases are the latter. Let's get rid of this stupid remote call:

Import mock from
 
mocks import patch from time
import sleep
 
class Sweetness (object):
  def Slow_remote_call (self): Sleep
    (a) return
    "Some_data" # Lets pretend we ' "back to our remote API call
 
def Test_long_ca LL ():
  s = sweetness ()
  with Patch.object (S, "Slow_remote_call", return_value= "Some_data"): Result
    = S.slow_remote_call ()
  assert result = = "Some_data"

Well, let's try again:

(test) Jhaddad@jons-mac-pro ~virtual_env/src$ nosetests test_mock.py                                                            
.
----------------------------------------------------------------------
Ran 1 Test in 0.001s
 
OK

Much better. Remember, this example is an absurd simplification. Personally, I just ignore calls from the remote system, not my database calls.

Nose-progressive is a good module that can improve the output of nose, allowing errors to appear when they occur, rather than staying in the end. If your test takes a certain amount of time, then that's a good thing.
Pip install nose-progressive and add--with-progressive to your nosetests
Debugging

Ipdb is a great tool and I've used it to find out a lot of weird bugs. Pip Install ipdb Install the tool, and then import ipdb in your code; Ipdb.set_trace (), and then you'll get a good interactive tip when your program is running. It executes one line of the program at a time and checks for variables.

Python has a good tracking module built into it to help me figure out what's going on. Here's a little-used Python program:

A = 1
b = 2
a = b

Here is the tracking result for this program:

(test) Jhaddad@jons-mac-pro ~virtual_env/src$ python-m trace--trace tracing.py                                                    1? 
 ---modulename:tracing, funcname: <module>
tracing.py (1): a = 1
tracing.py (2): b = 2
tracing.py (3): A = b
 ---modulename:trace, funcname: _unsettrace
trace.py:     sys.settrace (None)

This is useful when you want to figure out the internal structure of other programs. If you've used strace before, they work in a very similar way.

On some occasions, I use Pycallgraph to track performance issues. It can create a chart of the times and times of function calls.

Finally, Objgraph is useful for finding memory leaks. Here's a good article about how to use it to find a memory leak.
gevent

Gevent is a good library that encapsulates greenlets, making Python a function of asynchronous invocation. Yes, it was great. My favorite feature is pool, which abstracts the asynchronous call section, gives us a simple way to use, an asynchronous map () function:

From gevent import Monkey
Monkey.patch_all ()
 
from time import sleep, time
 
def fetch_url (URL):
  print Fetching%s '% URL Sleep
  (ten)
  print ' done fetching%s '% URL from
 
gevent.pool import pool
 
urls = [' http://t Est.com "," http://bacon.com "," http://eggs.com "]
 
p = Pool (+)
 
start = time ()
P.map (Fetch_url, URLs)
print Time ()-Start

It is important to note that the patch on the top of the code for the Gevent monkey does not work correctly without it. If we let Python call Fetch_url 3 times in a row, we usually expect this process to take 30 seconds. Use gevent:

(test) Jhaddad@jons-mac-pro ~virtual_env/src$ python g.py                                                                  
fetching http://test.com fetching http://bacon.com
fetching http://eggs.com
Done fetching http://test.com do
fetching http://bacon.com done
fetching http://eggs.com
10.001791954

This is useful if you have a lot of database calls or get from remote URLs. I don't really like callback functions, so this abstraction works well for me.
Conclusions

Well, if you see this, you're probably already learning something new. These tools have had a big impact on me over the past year. It took a lot of time to find a dozen of them, so hopefully this article will reduce the effort that other people need to make good use of the language.