20 Python Libraries You Arent Using (But Should)
by Caleb Hattingh
Copyright 2016 OReilly Media Inc. All rights reserved.
Printed in the United States of America.
Published by OReilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.
OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://safaribooksonline.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com .
- Editor: Dawn Schanafelt
- Production Editor: Colleen Lobner
- Copyeditor: Christina Edwards
- Interior Designer: David Futato
- Cover Designer: Randy Comer
- Illustrator: Rebecca Demarest
- August 2016: First Edition
Revision History for the First Edition
- 2016-08-08: First Release
The OReilly logo is a registered trademark of OReilly Media, Inc. 20 Python Libraries You Arent Using (But Should), the cover image, and related trade dress are trademarks of OReilly Media, Inc.
While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
978-1-491-96792-8
[LSI]
Chapter 1. Expanding Your Python Knowledge: Lesser-Known Libraries
The Python ecosystem is vast and far-reaching in both scope and depth.Starting out in this crazy, open-source forest is daunting, andeven with years of experience, it still requires continual effort tokeep up-to-date with the best libraries and techniques.
In this report we take a look at some of the lesser-known Pythonlibraries and tools. Python itself alreadyincludes a huge number of high-quality libraries; collectively theseare called the standard library. The standard library receives alot of attention, but there are still some libraries within it that shouldbe better known. We will start out by discussing several, extremely useful tools in thestandard library that you may not know about.
Were also going to discuss several exciting, lesser-known librariesfrom the third-party ecosystem. Many high-quality third-partylibraries are already well-known, including Numpy and Scipy, Django,Flask, and Requests; you can easily learn more about these librariesby searching for information online. Rather than focusing on thosestandouts, this report is instead going to focus on severalinteresting libraries that are growing in popularity.
Lets start by taking a look at the standard library.
The Standard Library
The libraries that tend to get all the attention are the onesheavily used for operating-system interaction, likesys
,os
,shutil
, and to aslightly lesser extent,glob
. This isunderstandable because most Python applications deal with inputprocessing; however, the Python standard library is very rich andincludes a bunch of additional functionality that manyPython programmers take too long to discover. In this chapter wewill mention a few libraries that every Python programmer shouldknow very well.
collections
First up we have the collections
module. If youve been working withPython for any length of time, it is very likely that you have madeuse of the this module; however, the batteries contained withinare so important that well go over them anyway, just in case.
collections.OrderedDict
collections.OrderedDict
gives you a dict
that will preserve theorder in which items are added to it; note that this is not the same asa sorted order.
The need for an ordereddict
comes up surprisingly often. A commonexample is processing lines in a file where the lines (or somethingwithin them) maps to other data. A mapping is the right solution, and youoften need to produce results in the same order inwhich the input data appeared. Here is a simple example of how theordering changes with a normal dict
:
>>
>
dict
(
zip
(
ascii_lowercase
,
range
(
4
)
)
)
{
'
a
'
:
0
,
'
b
'
:
1
,
'
c
'
:
2
,
'
d
'
:
3
}
>>
>
dict
(
zip
(
ascii_lowercase
,
range
(
5
)
)
)
{
'
a
'
:
0
,
'
b
'
:
1
,
'
c
'
:
2
,
'
d
'
:
3
,
'
e
'
:
4
}
>>
>
dict
(
zip
(
ascii_lowercase
,
range
(
6
)
)
)
{
'
a
'
:
0
,
'
b
'
:
1
,
'
c
'
:
2
,
'
d
'
:
3
,
'
f
'
:
5
,
'
e
'
:
4
}
>>
>
dict
(
zip
(
ascii_lowercase
,
range
(
7
)
)
)
{
'
a
'
:
0
,
'
b
'
:
1
,
'
c
'
:
2
,
'
d
'
:
3
,
'
g
'
:
6
,
'
f
'
:
5
,
'
e
'
:
4
}
See how the key "f
" now appears before the "e
" key in the sequence ofkeys? They no longer appear in the order of insertion, due to how the