Simple Python2.7 Programming Beginner experience Summary

If you have never used Python, I highly 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 the Python world is a large number of third-party packages. Similarly, managing these packages is also very easy. As a rule, the packages required for the project are listed in the Requirements.txt file. Each package occupies a single row and usually contains a version number. Here's an example of this blog using pelican:

pelican==3.3markdownpelican-extended-sitemap==1.0.0

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

First, we need to install PIP. Most python installers already have built-in Easy_install (Python's default package management tool), so we use easy_install pip to install PIP. This should be the last time you've used Easy_install. If you do not have Easy_install installed, it seems to be available in the Linux system from the Python-setuptools package.

If you're using a Python version above or equal to 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 your different projects use different versions of the package. Virtualenv Wrapper provides some good scripts that can make things easier.

sudo pip install Virtualenvwrapper

When Virtualenvwrapper is installed, it will list the virtualenv as a dependent package, so it will be installed automatically.

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

IPython

Ipython is a substitute for the standard Python interactive programming environment that supports auto-completion, quick access to documents, and many other features that the standard interactive programming environment should have.

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

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

Test

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

Here is an example of the ridiculous use of nose for the creation of a person to test. All functions beginning with test_ in a file beginning with Test_ will be called:

Def test_equality ():  assert True = = False

As expected, our test did not pass when we ran the nose.

(test) Jhaddad@jons-mac-pro ~virtual_env/src$ nosetests                                                                   f==================================================== ==================fail:test_nose_example.test_ Equality----------------------------------------------------------------------Traceback (most recent): 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 = = Falseassertionerror----------------------------------------------------------------------

There are also some convenient ways to invoke Nose.tools in the

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

If you want to use a more junit-like approach, it's also possible:

From nose.tools import assert_truefrom unittest Import TestCase class Exampletest (TestCase):   def setup: # Setup & TearDown is 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 ): 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 excellent mock library is included 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 of time. This example is obviously artificially fabricated. We use a mock to return the sample data instead of actually making the call.

Import mock from mock import patchfrom time Import sleep class Sweetness (object):  def slow_remote_call (self):    SLE EP (Ten)    return "Some_data" # Lets pretend we get this back from our remote API call Def test_long_call ():  s = Sweet Ness ()  result = S.slow_remote_call ()  assert result = = "Some_data"

Of course, our testing takes 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 remote calls are useful, or do we want to test what we 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 mock import patchfrom time Import sleep class Sweetness (object):  def slow_remote_call (self):    SLE EP (Ten)    return "Some_data" # Lets pretend we get this back from our remote API call Def test_long_call ():  s = Sweet Ness () with  Patch.object (S, "Slow_remote_call", return_value= "Some_data"):    result = S.slow_remote_call ()  assert result = = "Some_data"

OK, let's try it 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 a ridiculous simplification. Personally, I just ignore calls from remote systems, not my database calls.

Nose-progressive is a good module that can improve the output of nose so that errors are displayed when they occur, rather than being left to the end. If your test takes some time, then this is a good thing.
Pip install nose-progressive and add--with-progressive to your nosetests
Debugging

IPDB is an excellent tool, I have used it to detect a lot of strange bugs. Pip Install ipdb installs the tool and then import ipdb in your code; Ipdb.set_trace (), then you will get a good interactive hint when your program runs. It executes one line of the program at a time and checks for variables.

Python has a good tracking module built in to help me figure out what's going on. Here's a Python program that doesn't work:

A = 1b = 2a = 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: 
 
  
   
  tracing.py (1): a = 1tracing.py (2): b = 2tracing.py (3): a = b---modulenam E:trace, FuncName: _unsettracetrace.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 graph of the time and number of function calls.

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

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

From gevent import Monkeymonkey.patch_all () From time import sleep, time def fetch_url (URL):  print "fetching%s"% URL  sleep  print ' done fetching%s '% URL from gevent.pool import pool urls = ["http://test.com", "http://bacon.co M "," http://eggs.com "] p = Pool (Ten) Start = Time () p.map (Fetch_url, URLs) print time ()-Start

It is important to note that the patch at the top of the code for 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. Using gevent:

(test) Jhaddad@jons-mac-pro ~virtual_env/src$ python g.py                                                                  fetching http://test.comFetching/HTTP Bacon.comfetching Http://eggs.comDone fetching Http://test.comDone fetching http://bacon.comDone fetching/HTTP eggs.com10.001791954

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

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

