<commit_before>#!/usr/bin/env python3
# -*- coding: utf-8 -*-

'''@package _cookbook
Python Cookbook

  - unittest
  - doctest
  - Number Division
  - Loop Techniques
  - Unpack Iterable
  - Output Format
  - Function Arguments
  - OOP
  - Context Manager
  - file I/O
  - Find & Sort Algorithms
  - Text Pattern
  - Network
  - Thread
  - Django (Web framework)
  

## Command Line Options

    `-t`  Issue a warning when a source file mixes tabs and spaces for
          indentation in a way that makes it depend on the worth of a tab
          expressed in spaces.
        
    `-tt` Issue a error when a source file mixes tabs and spaces for
          indentation in a way that makes it depend on the worth of a tab
          expressed in spaces.
        
    `-O`  Turn on basic optimizations. This changes the file name extension for
          compiled (bytecode) files from <em>.pyc</em> to <em>.pyo</em>, and set
          the <code>__debug__</code> to <code>False</code>.
       
    `-OO` Discard docstrings in addition to the <em>-O</em> optimizations.
    

## Python Coding Style

- Use 4-space indentation, and avoid tabs. ( `-t` option )

- Limit lines to a maximum of *79* characters, and docstrings/comments to *72*.

- Separate top-level function and class definitions with two blank lines, and
  method definitions inside a class are separated by a single blank line.

- Code should always use **UTF-8**.

- When possible, put comments on a line of their own.

- Always make a priority of keeping the comments up-to-date when the code
  changes!

- Using docstrings.

- Use spaces around operators and after commas, but not directly inside
  bracketing constructs. eg. `a = f(a, b)`

- Name your classes and functions consistently; the convention is to use
  `CamelCase` for classes and `lower_case_with_underscores` for functions and
  methods.

- Avoid using underscores to begin variable, function or class names.

> Generally, a variable name `_xxx` is considered "private" and should not be
> used outside that module or class. It's good practice to use `_xxx` to
> denote when a variable is private. Since variables named `__xxx__` often
> mean special things to Python, you should avoid using naming normal
> variables this way.

- Avoid recalculation of the same value.

- Avoid numeric indexing.

- Avoid numeric constants.

> You should name the constants, since it's much easier to read the code and
> therefore easier to get right and to modify later.

- Don't use fancy encodings if your code is meant to be used in international
  environments. Plain **ASCII** works best in any case.

- Absolute imports are recommended, as they are usually more readable and tend
  to be better behaved (or at least give better error messages) if the import
  system is incorrectly configured.

- Imports should usually be on separate lines.

- Module ordering for import statements.

> It is recommended that all module imports happen at the top of Python
> modules. Futhermore, imports should follow this ordering:
>
>      - Standard Library Modules
>      - Third-Party Modules
>      - Application-Specific Modules
>
> Seperate these groups with an empty line between the imports of these three
> types of modules.

- Restrict wildcard imports ( `from module import *` ).

> In practice, using `from module import *` is considered poor style because
> it "pollutes" the current namespace and has the potential of overriding
> names in the current namespace; however, it is extremely convenient if a
> module has many variables that are often accessed, or if the module has a
> very long name.

- Keep user interaction outside of functions.

> The functions should be kept "clean", meaning they shoule silently be used
> purely to take parameters and provide return values. More importantly, it is
> good practice to seperate functions into two categories: those that do
> things (i.e., interactive with users or set variables) and those that
> calculate things (usually returning results).

- Easier to ask for forgiveness than permission (EAFP).

> This common Python coding style assumes the existence of valid keys or
> attributes and catches exceptions if the assumption proves false. This clean
> and fast style is characterized by the presence of many `try` and `except`
> statements. The technique contrasts with the **LBYL** style common to many
> other languages such as C.
>
>     LBYL = (L)ook (B)efore (Y)ou (L)eap:
>
> This coding style explicitly tests for pre-conditions before making calls or
> lookups. This style contrasts with the EAFP approach and is characterized by
> the presence of many if statements.
>
> In a multi-threaded environment, the **LBYL** approach can risk introducing
> a race condition between “the looking” and “the leaping”. For example, the
> code, if key in mapping: return mapping[key] can fail if another thread
> removes key from mapping after the test, but before the lookup. This issue
> can be solved with locks or by using the **EAFP** approach.

- Use local variables to subtitute for module attributes.

> Names like `os.linesep` require the interpreter to do two lookups: 1) lookup
> `os` to find that it is a module, and 2) loopup the `linesep` attribute of
> that module. Because modules are also global variables, we pay another
> penalty. If you use an attribute like this oftern in a function, it's
> recommended that you alias it to a single local variable. Lookups are much
> faster -- local variables are always searched first before globals, and no
> attribute needs to be lookuped either. This is one of the tricks in making
> your program faster: replace often-used (and name-lengthy) module attributes
> with local references, your code runs fasters and has less clutter with a
> shorter name.


## Virtual Running Environment

```bash
# Create
sudo apt-get install python-virtualenv
virtualenv env-dir
cd env-dir

# Active
source bin/activate
```


## PEP

  - [PEP 8 - Style Guide for Python Code](http://legacy.python.org/dev/peps/pep-0008/)
  - [PEP 257 - Docstring Conventions](http://legacy.python.org/dev/peps/pep-0257/)
  - [PEP 0343 - The with Statement](http://www.python.org/dev/peps/pep-0343/)

## Reference

  - [Python 2 Documentation](https://docs.python.org/2/)
  - [Python 3 Documentation](https://docs.python.org/3/)
  - [Django](https://www.djangoproject.com/)
  
      
Copyright (c) 2014 <NAME> <<EMAIL>>
All Rights Reserved.<commit_msg>Add link of Think Python into Python cookbook<commit_after>#!/usr/bin/env python3
# -*- coding: utf-8 -*-

'''@package _cookbook
Python Cookbook

  - unittest
  - doctest
  - Number Division
  - Loop Techniques
  - Unpack Iterable
  - Output Format
  - Function Arguments
  - OOP
  - Context Manager
  - file I/O
  - Find & Sort Algorithms
  - Text Pattern
  - Network
  - Thread
  - Django (Web framework)
  

## Command Line Options

    `-t`  Issue a warning when a source file mixes tabs and spaces for
          indentation in a way that makes it depend on the worth of a tab
          expressed in spaces.
        
    `-tt` Issue a error when a source file mixes tabs and spaces for
          indentation in a way that makes it depend on the worth of a tab
          expressed in spaces.
        
    `-O`  Turn on basic optimizations. This changes the file name extension for
          compiled (bytecode) files from <em>.pyc</em> to <em>.pyo</em>, and set
          the <code>__debug__</code> to <code>False</code>.
       
    `-OO` Discard docstrings in addition to the <em>-O</em> optimizations.
    

## Python Coding Style

- Use 4-space indentation, and avoid tabs. ( `-t` option )

- Limit lines to a maximum of *79* characters, and docstrings/comments to *72*.

- Separate top-level function and class definitions with two blank lines, and
  method definitions inside a class are separated by a single blank line.

- Code should always use **UTF-8**.

- When possible, put comments on a line of their own.

- Always make a priority of keeping the comments up-to-date when the code
  changes!

- Using docstrings.

- Use spaces around operators and after commas, but not directly inside
  bracketing constructs. eg. `a = f(a, b)`

- Name your classes and functions consistently; the convention is to use
  `CamelCase` for classes and `lower_case_with_underscores` for functions and
  methods.

- Avoid using underscores to begin variable, function or class names.

> Generally, a variable name `_xxx` is considered "private" and should not be
> used outside that module or class. It's good practice to use `_xxx` to
> denote when a variable is private. Since variables named `__xxx__` often
> mean special things to Python, you should avoid using naming normal
> variables this way.

- Avoid recalculation of the same value.

- Avoid numeric indexing.

- Avoid numeric constants.

> You should name the constants, since it's much easier to read the code and
> therefore easier to get right and to modify later.

- Don't use fancy encodings if your code is meant to be used in international
  environments. Plain **ASCII** works best in any case.

- Absolute imports are recommended, as they are usually more readable and tend
  to be better behaved (or at least give better error messages) if the import
  system is incorrectly configured.

- Imports should usually be on separate lines.

- Module ordering for import statements.

> It is recommended that all module imports happen at the top of Python
> modules. Futhermore, imports should follow this ordering:
>
>      - Standard Library Modules
>      - Third-Party Modules
>      - Application-Specific Modules
>
> Seperate these groups with an empty line between the imports of these three
> types of modules.

- Restrict wildcard imports ( `from module import *` ).

> In practice, using `from module import *` is considered poor style because
> it "pollutes" the current namespace and has the potential of overriding
> names in the current namespace; however, it is extremely convenient if a
> module has many variables that are often accessed, or if the module has a
> very long name.

- Keep user interaction outside of functions.

> The functions should be kept "clean", meaning they shoule silently be used
> purely to take parameters and provide return values. More importantly, it is
> good practice to seperate functions into two categories: those that do
> things (i.e., interactive with users or set variables) and those that
> calculate things (usually returning results).

- Easier to ask for forgiveness than permission (EAFP).

> This common Python coding style assumes the existence of valid keys or
> attributes and catches exceptions if the assumption proves false. This clean
> and fast style is characterized by the presence of many `try` and `except`
> statements. The technique contrasts with the **LBYL** style common to many
> other languages such as C.
>
>     LBYL = (L)ook (B)efore (Y)ou (L)eap:
>
> This coding style explicitly tests for pre-conditions before making calls or
> lookups. This style contrasts with the EAFP approach and is characterized by
> the presence of many if statements.
>
> In a multi-threaded environment, the **LBYL** approach can risk introducing
> a race condition between “the looking” and “the leaping”. For example, the
> code, if key in mapping: return mapping[key] can fail if another thread
> removes key from mapping after the test, but before the lookup. This issue
> can be solved with locks or by using the **EAFP** approach.

- Use local variables to subtitute for module attributes.

> Names like `os.linesep` require the interpreter to do two lookups: 1) lookup
> `os` to find that it is a module, and 2) loopup the `linesep` attribute of
> that module. Because modules are also global variables, we pay another
> penalty. If you use an attribute like this oftern in a function, it's
> recommended that you alias it to a single local variable. Lookups are much
> faster -- local variables are always searched first before globals, and no
> attribute needs to be lookuped either. This is one of the tricks in making
> your program faster: replace often-used (and name-lengthy) module attributes
> with local references, your code runs fasters and has less clutter with a
> shorter name.


## Virtual Running Environment

```bash
# Create
sudo apt-get install python-virtualenv
virtualenv env-dir
cd env-dir

# Active
source bin/activate
```


## PEP

  - [PEP 8 - Style Guide for Python Code](http://legacy.python.org/dev/peps/pep-0008/)
  - [PEP 257 - Docstring Conventions](http://legacy.python.org/dev/peps/pep-0257/)
  - [PEP 0343 - The with Statement](http://www.python.org/dev/peps/pep-0343/)

## Reference

  - [Think Python](http://www.greenteapress.com/thinkpython/html/index.html)
  - [Python 2 Documentation](https://docs.python.org/2/)
  - [Python 3 Documentation](https://docs.python.org/3/)
  - [Django](https://www.djangoproject.com/)
  
      
Copyright (c) 2014 <NAME> <<EMAIL>>
All Rights Reserved.
{'fraction_non_alphanumeric': 0.07430197677101762, 'fraction_numerical': 0.0058457041766018, 'mean_word_length': 3.5083217753120666, 'pattern_counts': {'":': 0, '<': 29, '<?xml version=': 0, '>': 135, 'https://': 6, 'lorem ipsum': 0, 'www.': 5, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2842177', 'n_tokens_mistral': 3636, 'n_tokens_neox': 3458, 'n_words': 1774}