| 2011-03-23 21:51:33 |
Emilien Klein |
bug |
|
|
added bug |
| 2011-03-27 19:27:03 |
Emilien Klein |
colombiacasa: status |
New |
In Progress |
|
| 2011-03-27 19:27:03 |
Emilien Klein |
colombiacasa: assignee |
|
Emilien Klein (emilien-klein) |
|
| 2011-03-27 19:27:15 |
Emilien Klein |
description |
ColombiaCasa.com's code should respect the Style Guide for Python Code: http://www.python.org/dev/peps/pep-0008/
This can be done in various stages. A non-exhaustive list of points to respect:
- Maximum Line Length (Limit all lines to a maximum of 79 characters.)
- Blank Lines
- Imports should usually be on separate lines
- Don't use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value.
- Good documentation strings (a.k.a. "docstrings")
- Naming Conventions, particularly Function Names and Method Names and Instance Variables
- Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators.
- When catching exceptions, mention specific exceptions whenever possible instead of using a bare 'except:' clause.
- Use ''.startswith() and ''.endswith() instead of string slicing to check for prefixes or suffixes.
- Don't compare boolean values to True or False using == |
ColombiaCasa.com's code should respect the Style Guide for Python Code: http://www.python.org/dev/peps/pep-0008/
This can be done in various stages. A non-exhaustive list of points to respect:
- Maximum Line Length (Limit all lines to a maximum of 79 characters.)
- Imports should usually be on separate lines
- Don't use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value.
- Good documentation strings (a.k.a. "docstrings")
- Naming Conventions, particularly Function Names and Method Names and Instance Variables
- Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators.
- When catching exceptions, mention specific exceptions whenever possible instead of using a bare 'except:' clause.
- Use ''.startswith() and ''.endswith() instead of string slicing to check for prefixes or suffixes.
- Don't compare boolean values to True or False using ==
Already done:
- Blank Lines |
|
| 2011-03-27 20:08:28 |
Emilien Klein |
description |
ColombiaCasa.com's code should respect the Style Guide for Python Code: http://www.python.org/dev/peps/pep-0008/
This can be done in various stages. A non-exhaustive list of points to respect:
- Maximum Line Length (Limit all lines to a maximum of 79 characters.)
- Imports should usually be on separate lines
- Don't use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value.
- Good documentation strings (a.k.a. "docstrings")
- Naming Conventions, particularly Function Names and Method Names and Instance Variables
- Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators.
- When catching exceptions, mention specific exceptions whenever possible instead of using a bare 'except:' clause.
- Use ''.startswith() and ''.endswith() instead of string slicing to check for prefixes or suffixes.
- Don't compare boolean values to True or False using ==
Already done:
- Blank Lines |
ColombiaCasa.com's code should respect the Style Guide for Python Code: http://www.python.org/dev/peps/pep-0008/
This can be done in various stages. A non-exhaustive list of points to respect:
- Maximum Line Length (Limit all lines to a maximum of 79 characters.)
- Don't use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value.
- Good documentation strings (a.k.a. "docstrings")
- Naming Conventions, particularly Function Names and Method Names and Instance Variables
- Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators.
- When catching exceptions, mention specific exceptions whenever possible instead of using a bare 'except:' clause.
- Use ''.startswith() and ''.endswith() instead of string slicing to check for prefixes or suffixes.
- Don't compare boolean values to True or False using ==
Already done:
- Blank Lines
- Imports should usually be on separate lines |
|
| 2011-03-29 20:32:32 |
Emilien Klein |
description |
ColombiaCasa.com's code should respect the Style Guide for Python Code: http://www.python.org/dev/peps/pep-0008/
This can be done in various stages. A non-exhaustive list of points to respect:
- Maximum Line Length (Limit all lines to a maximum of 79 characters.)
- Don't use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value.
- Good documentation strings (a.k.a. "docstrings")
- Naming Conventions, particularly Function Names and Method Names and Instance Variables
- Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators.
- When catching exceptions, mention specific exceptions whenever possible instead of using a bare 'except:' clause.
- Use ''.startswith() and ''.endswith() instead of string slicing to check for prefixes or suffixes.
- Don't compare boolean values to True or False using ==
Already done:
- Blank Lines
- Imports should usually be on separate lines |
ColombiaCasa.com's code should respect the Style Guide for Python Code: http://www.python.org/dev/peps/pep-0008/
This can be done in various stages. A non-exhaustive list of points to respect:
- Maximum Line Length (Limit all lines to a maximum of 79 characters.)
- Don't use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value.
- Good documentation strings (a.k.a. "docstrings")
- Naming Conventions, particularly Function Names and Method Names and Instance Variables
- Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators.
- When catching exceptions, mention specific exceptions whenever possible instead of using a bare 'except:' clause.
- Don't compare boolean values to True or False using ==
Already done:
- Blank Lines
- Imports should usually be on separate lines
- Use ''.startswith() and ''.endswith() instead of string slicing to check for prefixes or suffixes. |
|
| 2011-03-29 20:40:22 |
Emilien Klein |
description |
ColombiaCasa.com's code should respect the Style Guide for Python Code: http://www.python.org/dev/peps/pep-0008/
This can be done in various stages. A non-exhaustive list of points to respect:
- Maximum Line Length (Limit all lines to a maximum of 79 characters.)
- Don't use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value.
- Good documentation strings (a.k.a. "docstrings")
- Naming Conventions, particularly Function Names and Method Names and Instance Variables
- Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators.
- When catching exceptions, mention specific exceptions whenever possible instead of using a bare 'except:' clause.
- Don't compare boolean values to True or False using ==
Already done:
- Blank Lines
- Imports should usually be on separate lines
- Use ''.startswith() and ''.endswith() instead of string slicing to check for prefixes or suffixes. |
ColombiaCasa.com's code should respect the Style Guide for Python Code: http://www.python.org/dev/peps/pep-0008/
This can be done in various stages. A non-exhaustive list of points to respect:
- Maximum Line Length (Limit all lines to a maximum of 79 characters.)
- Don't use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value.
- Good documentation strings (a.k.a. "docstrings")
- Naming Conventions, particularly Function Names and Method Names and Instance Variables
- When catching exceptions, mention specific exceptions whenever possible instead of using a bare 'except:' clause.
- Don't compare boolean values to True or False using ==
Already done:
- Blank Lines
- Imports should usually be on separate lines
- Use ''.startswith() and ''.endswith() instead of string slicing to check for prefixes or suffixes.
- Comparisons to singletons like None should always be done with 'is' or 'is not', never the equality operators. |
|
