Python 点滴

1. What is the difference between dict.items() and dict.iteritems()?

It's part of an evolution. Originally Python items() built a real list of tuples and returned that. That could potentially take a lot of extra memory. Then generators were introduced to the language in general, and that method was reimplemented as a iterator-generator method named iteritems(). The original being left for backwards compatibility. One of the changes of Python 3.x is that theitems() methods now also return iterators and a list is never fully built. In Python 3.x there is noiteritems() method any longer,asitems() is now the same asiteritems() in Python 2.x (WRONG!!!).

the Py3 behavior isn't the same as iteritems(). It actually makes a full sequence-protocol object that also reflects changes to the dict (and is backed by the dict itself, rather than a redundant list)- it's been backported to 2.7 as viewitems()

In Py2.x :

dict.items(), dict.keys() and dict.values() return acopy of the dictionary'slist of(k, v) pair, keys and values, which could takes a lot of memory if the copied list is very large.

dict.iteritems(), dict.iterkeys() and dict.itervalues() return aniterator over the dictionary’s(k, v) pair, keys and values

dict.viewitems(), dict.viewkeys() and dict.viewvalues() return theview objects, which can reflect the dictionary's changes (i.e. if youdel an item or add a(k,v) pair in the dictionary, the view object canautomatically change at the same time.)

While in Py3.x, things are more clean, since there are only

dict.items(), dict.keys() and dict.values() available, which return theview objects just asdict.viewitems() in Py2.x did.

But just as @lvc noted, view object isn't the same asiterator, so if you want to return aniterator in Py3.x, you could useiter(dictview) :

2. ImportError: No module named matplotlib.pyplot

You have 2 pythons installed on your machine, one is the standard python that comes with MacOSX and the second is the one you installed with ports (this is the one that has matplotlib installed in it's library, the one that comes with macosx does not).

/usr/bin/python

Is the standard mac python and since it doesn't have matplotlib you should always start your script with the one installed with ports.

Python import matplotlib.pyplot not working

3. Understanding imports and PYTHONPATH

4. The Quick Guide to Python Eggs

5. The Hitchhiker's Guide to Packaging

How To Package Your Python Code

6. A module's __name__

RuntimeError on windows trying python multiprocessing

Python multiprocessing.Pool: when to use apply, apply_async or map?

Pool.apply_async  is also like Python's built-in  apply , except that the call returns immediately instead of waiting for the result. An  ApplyResult  object is returned. You call its  get()  method to retrieve the result of the function call. The  get()  method blocks until the function is completed. Thus,  pool.apply(func, args, kwargs)  is equivalent to  pool.apply_async(func, args, kwargs).get() .

Notice also that you could call a number of different functions with Pool.apply_async (not all calls need to use the same function).

In contrast, Pool.map applies the same function to many arguments. However, unlike Pool.apply_async, the results are returned in an order corresponding to the order of the arguments.

pool.apply(f, args): f is only executed in ONE of the workers of the pool. So ONE of the processes in the pool will run f(args).

pool.map(f, iterable): This method chops the iterable into a number of chunks which it submits to the process pool as separate tasks. So you take advantage of all the processes in the pool.

Look inside  multiprocessing/pool.py  and you will see that  Pool.map(func,iterable)  is equivalent to  Pool.map_async(func,iterable).get() . So the relationship between  Pool.map  and  Pool.map_async  is similar to that of  Pool.apply  and  Pool.apply_async . The  async  commands return immediately, while the non- async  commands block. The  async  commands also have a callback.

7. NumPy-快速处理数据

Speeding up Python (NumPy, Cython, and Weave)

Weave (scipy.weave)

8. (Using Weave) Error: Unable to find vcvarsall.bat

Finding the correct version of VC++ to use

Newer versions of Python (at least 3.4.1) are compiled using newer versions of Visual Studio C++, as shown in this screenshot. It is important to use the correct version of Visual C++ so that the compiled library will work with your Python version.

• Yellow (top) is Python 3.4.1, it uses MSC v.1600 (Visual Studio C++ 2010)
• Red (bottom) is Python 2.7, it uses MSC v.1500 (Visual Studio C++ 2008) 

Note : Yes, the native 64-bit compilers are in  Program Files (x86) . Don't ask me why.
Additionally, if you are wondering what the difference between  vcvars64.bat  and  vcvarsx86_amd64.bat  or more importantly the difference between  amd64  and  x86_amd64 , the former are for the native 64-bit compiler tools and the latter are the 64-bit cross compilers that can run on a 32-bit Windows installation.

Cannot find vcvarsall.bat when running a Python script

The fix is to create a variable called VS90COMNTOOLS and have that point to your Visual Studio 2010 common tools folder, e.g.

SET VS90COMNTOOLS=C:\Program Files\Microsoft Visual Studio 10.0\Common7\Tools\

Or,

SET VS90COMNTOOLS=%VS100COMNTOOLS%

Building lxml for Python 2.7 on Windows

Typically, extension modules need to be compiled with the same compiler that was used to compile Python.

Python 2.6, 2.7, and 3.1 are all built with that release (i.e. 2008). Because of another long tradition, Python extension modules must be built with the same compiler version (more specifically, CRT version) as Python itself. So to build extension modules for any of these releases, you need to have a copy of VS 2008 or VS 2008 Express.

API Reference (2.7.8)

Typically, extension modules need to be compiled with the same compiler that was used to compile Python. For Python 2.3 and earlier, the compiler was Visual Studio 6. For Python 2.4 and 2.5, the compiler is Visual Studio .NET 2003. The AMD64 and Itanium binaries are created using the Platform SDK.

Unofficial Windows Binaries for Python Extension Packages

Many binaries depend on Numpy-MKL 1.8 and the Microsoft Visual C++ 2008 (x64, x86, and SP1 for CPython 2.6 to 3.2) or Visual C++ 2010 (x64, x86, for CPython 3.3 and 3.4) redistributable packages.

ffs