This document gives coding conventions for the Python code comprising the standard library in the main Python distribution. Please see the companion informational PEP describing style guidelines for the C code in the C implementation of Python 1.
This document and PEP 257 (Docstring Conventions) were adapted from Guido’s original Python Style Guide essay, with some additions from Barry’s style guide 2.
This style guide evolves over time as additional conventions are identified and past conventions are rendered obsolete by changes in the language itself.
Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific guides take precedence for that project.
One of Guido’s key insights is that code is read much more often than it is written. The guidelines provided here are intended to improve the readability of code and make it consistent across the wide spectrum of Python code. As PEP 20 says, “Readability counts”.
A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.
But most importantly: know when to be inconsistent – sometimes the style guide just doesn’t apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don’t hesitate to ask!
In particular: do not break backwards compatibility just to comply with this PEP!
Some other good reasons to ignore a particular guideline:
Use 4 spaces per indentation level.
Continuation lines should align wrapped elements either vertically using Python’s implicit line joining inside parentheses, brackets and braces, or using a hanging indent 3. When using a hanging indent the following considerations should be applied; there should be no arguments on the first line and further indentation should be used to clearly distinguish itself as a continuation line.
Yes:
# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
var_three, var_four)
# More indentation included to distinguish this from the rest.
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
# Hanging indents should add a level.
foo = long_function_name(
var_one, var_two,
var_three, var_four)
No:
# Arguments on first line forbidden when not using vertical alignment.
foo = long_function_name(var_one, var_two,
var_three, var_four)
# Further indentation required as indentation is not distinguishable.
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
The 4-space rule is optional for continuation lines.
Optional:
# Hanging indents *may* be indented to other than 4 spaces.
foo = long_function_name(
var_one, var_two,
var_three, var_four)
When the conditional part of an if
-statement is long enough to require that it be written across
multiple lines, it’s worth noting that the combination of a two character keyword (i.e. if
), plus a
single space, plus an opening parenthesis creates a natural 4-space indent for the subsequent lines of the
multiline conditional. This can produce a visual conflict with the indented suite of code nested inside the
if
-statement, which would also naturally be indented to 4 spaces. This PEP takes no explicit
position on how (or whether) to further visually distinguish such conditional lines from the nested suite inside
the if
-statement. Acceptable options in this situation include, but are not limited to:
# No extra indentation.
if (this_is_one_thing and
that_is_another_thing):
do_something()
# Add a comment, which will provide some distinction in editors
# supporting syntax highlighting.
if (this_is_one_thing and
that_is_another_thing):
# Since both conditions are true, we can frobnicate.
do_something()
# Add some extra indentation on the conditional continuation line.
if (this_is_one_thing
and that_is_another_thing):
do_something()
The closing brace/bracket/parenthesis on multi-line constructs may either line up under the first non-whitespace character of the last line of list, as in:
my_list = [
1, 2, 3,
4, 5, 6,
]
result = some_function_that_takes_arguments(
'a', 'b', 'c',
'd', 'e', 'f',
)
or it may be lined up under the first character of the line that starts the multi-line construct, as in:
my_list = [
1, 2, 3,
4, 5, 6,
]
result = some_function_that_takes_arguments(
'a', 'b', 'c',
'd', 'e', 'f',
)
Spaces are the preferred indentation method.
Tabs should be used solely to remain consistent with code that is already indented with tabs.
Python 3 disallows mixing the use of tabs and spaces for indentation.
Python 2 code indented with a mixture of tabs and spaces should be converted to using spaces exclusively.
When invoking the Python 2 command line interpreter with the -t
option, it issues warnings about
code that illegally mixes tabs and spaces. When using -tt
these warnings become errors. These
options are highly recommended!
Limit all lines to a maximum of 79 characters.
For flowing long blocks of text with fewer structural restrictions (docstrings or comments), the line length should be limited to 72 characters.
Limiting the required editor window width makes it possible to have several files open side-by-side, and works well when using code review tools that present the two versions in adjacent columns.
The default wrapping in most tools disrupts the visual structure of the code, making it more difficult to understand. The limits are chosen to avoid wrapping in editors with the window width set to 80, even if the tool places a marker glyph in the final column when wrapping lines. Some web based tools may not offer dynamic line wrapping at all.
Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the nominal line length from 80 to 100 characters (effectively increasing the maximum length to 99 characters), provided that comments and docstrings are still wrapped at 72 characters.
The Python standard library is conservative and requires limiting lines to 79 characters (and docstrings/comments to 72).
The preferred way of wrapping long lines is by using Python’s implied line continuation inside parentheses, brackets and braces. Long lines can be broken over multiple lines by wrapping expressions in parentheses. These should be used in preference to using a backslash for line continuation.
Backslashes may still be appropriate at times. For example, long, multiple with
-statements cannot
use implicit continuation, so backslashes are acceptable:
with open('/path/to/some/file/you/want/to/read') as file_1, \
open('/path/to/some/file/being/written', 'w') as file_2:
file_2.write(file_1.read())
(See the previous discussion on multiline if-statements_ for further thoughts on the indentation of such
multiline with
-statements.)
Another such case is with assert
statements.
Make sure to indent the continued line appropriately. The preferred place to break around a binary operator is after the operator, not before it. Some examples:
class Rectangle(Blob):
def __init__(self, width, height,
color='black', emphasis=None, highlight=0):
if (width == 0 and height == 0 and
color == 'red' and emphasis == 'strong' or
highlight > 100):
raise ValueError("sorry, you lose")
if width == 0 and height == 0 and (color == 'red' or
emphasis is None):
raise ValueError("I don't think so -- values are %s, %s" %
(width, height))
Blob.__init__(self, width, height,
color, emphasis, highlight)
Surround top-level function and class definitions with two blank lines.
Method definitions inside a class are surrounded by a single blank line.
Extra blank lines may be used (sparingly) to separate groups of related functions. Blank lines may be omitted between a bunch of related one-liners (e.g. a set of dummy implementations).
Use blank lines in functions, sparingly, to indicate logical sections.
Python accepts the control-L (i.e. ^L) form feed character as whitespace; Many tools treat these characters as page separators, so you may use them to separate pages of related sections of your file. Note, some editors and web-based code viewers may not recognize control-L as a form feed and will show another glyph in its place.
Code in the core Python distribution should always use UTF-8 (or ASCII in Python 2).
Files using ASCII (in Python 2) or UTF-8 (in Python 3) should not have an encoding declaration.
In the standard library, non-default encodings should be used only for test purposes or when a comment or
docstring needs to mention an author name that contains non-ASCII characters; otherwise, using \\x
,
\\u
, \\U
, or \\N
escapes is the preferred way to include non-ASCII data
in
string literals.
For Python 3.0 and beyond, the following policy is prescribed for the standard library (see PEP 3131): All identifiers in the Python standard library MUST use ASCII-only identifiers, and SHOULD use English words wherever feasible (in many cases, abbreviations and technical terms are used which aren’t English). In addition, string literals and comments must also be in ASCII. The only exceptions are (a) test cases testing the non-ASCII features, and (b) names of authors. Authors whose names are not based on the latin alphabet MUST provide a latin transliteration of their names.
Open source projects with a global audience are encouraged to adopt a similar policy.
Imports should usually be on separate lines, e.g.:
Yes:
import os
import sys
No:
import sys, os
It’s okay to say this though:
from subprocess import Popen, PIPE
Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.
Imports should be grouped in the following order:
You should put a blank line between each group of imports.
Put any relevant __all__
specification after the imports.
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 (such as when a
directory inside a package ends up on sys.path
):
import mypkg.sibling
from mypkg import sibling
from mypkg.sibling import example
However, explicit relative imports are an acceptable alternative to absolute imports, especially when dealing with complex package layouts where using absolute imports would be unnecessarily verbose:
from . import sibling
from .sibling import example
Standard library code should avoid complex package layouts and always use absolute imports.
Implicit relative imports should never be used and have been removed in Python 3.
When importing a class from a class-containing module, it’s usually okay to spell this:
from myclass import MyClass
from foo.bar.yourclass import YourClass
If this spelling causes local name clashes, then spell them :
import myclass
import foo.bar.yourclass
and use “myclass.MyClass” and “foo.bar.yourclass.YourClass”.
Wildcard imports (from <module> import *
) should be avoided, as they make it unclear
which names are present in the namespace, confusing both readers and many automated tools. There is one
defensible use case for a wildcard import, which is to republish an internal interface as part of a
public API (for example, overwriting a pure Python implementation of an interface with the definitions
from an optional accelerator module and exactly which definitions will be overwritten isn’t known in
advance).
When republishing names this way, the guidelines below regarding public and internal interfaces still apply.
In Python, single-quoted strings and double-quoted strings are the same. This PEP does not make a recommendation for this. Pick a rule and stick to it. When a string contains single or double quote characters, however, use the other one to avoid backslashes in the string. It improves readability.
For triple-quoted strings, always use double quote characters to be consistent with the docstring convention in PEP 257.
Avoid extraneous whitespace in the following situations:
Immediately inside parentheses, brackets or braces. :
Yes:
spam(ham[1], {eggs: 2})
No:
spam( ham[ 1 ], { eggs: 2 } )
Immediately before a comma, semicolon, or colon:
Yes:
if x == 4: print x, y; x, y = y, x
No:
if x == 4 : print x , y ; x , y = y , x
However, in a slice the colon acts like a binary operator, and should have equal amounts on either side (treating it as the operator with the lowest priority). In an extended slice, both colons must have the same amount of spacing applied. Exception: when a slice parameter is omitted, the space is omitted.
Yes:
ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
ham[lower:upper], ham[lower:upper:], ham[lower::step]
ham[lower+offset : upper+offset]
ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)]
ham[lower + offset : upper + offset]
No:
ham[lower + offset:upper + offset]
ham[1: 9], ham[1 :9], ham[1:9 :3]
ham[lower : : upper]
ham[ : upper]
Immediately before the open parenthesis that starts the argument list of a function call:
Yes:
spam(1)
No:
spam (1)
Immediately before the open parenthesis that starts an indexing or slicing:
Yes:
dct['key'] = lst[index]
No:
dct ['key'] = lst [index]
More than one space around an assignment (or other) operator to align it with another.
Yes:
x = 1
y = 2
long_variable = 3
No:
x = 1
y = 2
long_variable = 3
=
),
augmented assignment (+=
, -=
etc.), comparisons (==
,
<
, >
, !=
, <>
, <=
,
>=
, in
, not in
, is
, is not
), Booleans
(and
, or
, not
).If operators with different priorities are used, consider adding whitespace around the operators with the lowest priority(ies). Use your own judgment; however, never use more than one space, and always have the same amount of whitespace on both sides of a binary operator.
Yes:
i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
No:
i=i+1
submitted +=1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)
Don’t use spaces around the =
sign when used to indicate a keyword argument or a default
parameter value.
Yes:
def complex(real, imag=0.0):
return magic(r=real, i=imag)
No:
def complex(real, imag = 0.0):
return magic(r = real, i = imag)
Function annotations should use the normal rules for colons and always have spaces around the
->
arrow if present. (See Function Annotations_ below for more about function
annotations.)
Yes:
def munge(input: AnyStr): ...
def munge() -> AnyStr: ...
No:
def munge(input:AnyStr): ...
def munge()->PosInt: ...
When combining an argument annotation with a default value, use spaces around the =
sign
(but only for those arguments that have both an annotation and a default).
Yes:
def munge(sep: AnyStr = None): ...
def munge(input: AnyStr, sep: AnyStr = None, limit=1000): ...
No:
def munge(input: AnyStr=None): ...
def munge(input: AnyStr, limit = 1000): ...
Compound statements (multiple statements on the same line) are generally discouraged.
Yes:
if foo == 'blah':
do_blah_thing()
do_one()
do_two()
do_three()
Rather not:
if foo == 'blah': do_blah_thing()
do_one(); do_two(); do_three()
While sometimes it’s okay to put an if/for/while with a small body on the same line, never do this for multi-clause statements. Also avoid folding such long lines!
Rather not:
if foo == 'blah': do_blah_thing()
for x in lst: total += x
while t < 10: t = delay()
Definitely not:
if foo == 'blah': do_blah_thing()
else: do_non_blah_thing()
try: something()
finally: cleanup()
do_one(); do_two(); do_three(long, argument,
list, like, this)
if foo == 'blah': one(); two(); three()
Comments that contradict the code are worse than no comments. Always make a priority of keeping the comments up-to-date when the code changes!
Comments should be complete sentences. If a comment is a phrase or sentence, its first word should be capitalized, unless it is an identifier that begins with a lower case letter (never alter the case of identifiers!).
If a comment is short, the period at the end can be omitted. Block comments generally consist of one or more paragraphs built out of complete sentences, and each sentence should end in a period.
You should use two spaces after a sentence-ending period.
When writing English, follow Strunk and White.
Python coders from non-English speaking countries: please write your comments in English, unless you are 120% sure that the code will never be read by people who don’t speak your language.
Block comments generally apply to some (or all) code that follows them, and are indented to the same level as
that code. Each line of a block comment starts with a #
and a single space (unless it is indented
text inside the comment).
Paragraphs inside a block comment are separated by a line containing a single #
.
Use inline comments sparingly.
An inline comment is a comment on the same line as a statement. Inline comments should be separated by at least two spaces from the statement. They should start with a # and a single space.
Inline comments are unnecessary and in fact distracting if they state the obvious. Don’t do this:
x = x + 1 # Increment x
But sometimes, this is useful:
x = x + 1 # Compensate for border
Conventions for writing good documentation strings (a.k.a. “docstrings”) are immortalized in PEP 257.
def
line.PEP 257 describes good docstring conventions. Note that most importantly, the
"""
that ends a multiline docstring should be on a line by itself, e.g.:
"""Return a foobang
Optional plotz says to frobnicate the bizbaz first.
"""
"""
on the same line.If you have to have Subversion, CVS, or RCS crud in your source file, do it as follows. :
__version__ = "$Revision$"
# $Source$
These lines should be included after the module’s docstring, before any other code, separated by a blank line above and below.
The naming conventions of Python’s library are a bit of a mess, so we’ll never get this completely consistent – nevertheless, here are the currently recommended naming standards. New modules and packages (including third party frameworks) should be written to these standards, but where an existing library has a different style, internal consistency is preferred.
Names that are visible to the user as public parts of the API should follow conventions that reflect usage rather than implementation.
There are a lot of different naming styles. It helps to be able to recognize what naming style is being used, independently from what they are used for.
The following naming styles are commonly distinguished:
b
(single lowercase letter)B
(single uppercase letter)lowercase
lower_case_with_underscores
UPPERCASE
UPPER_CASE_WITH_UNDERSCORES
CapitalizedWords
(or CapWords, or CamelCase – so named because of the bumpy look of its
letters 4). This is also sometimes known
as StudlyCaps.
mixedCase
(differs from CapitalizedWords by initial lowercase character!)Capitalized_Words_With_Underscores
(ugly!)There’s also the style of using a short unique prefix to group related names together. This is not used much in
Python, but it is mentioned for completeness. For example, the os.stat()
function returns a tuple
whose items traditionally have names like st_mode
, st_size
, st_mtime
and
so on. (This is done to emphasize the correspondence with the fields of the POSIX system call struct, which
helps programmers familiar with that.)
The X11 library uses a leading X for all its public functions. In Python, this style is generally deemed unnecessary because attribute and method names are prefixed with an object, and function names are prefixed with a module name.
In addition, the following special forms using leading or trailing underscores are recognized (these can generally be combined with any case convention):
_single_leading_underscore
: weak “internal use” indicator. E.g. from M import *
does not import objects whose name starts with an underscore.single_trailing_underscore_
: used by convention to avoid conflicts with Python keyword, e.g.
:
Tkinter.Toplevel(master, class_='ClassName')
__double_leading_underscore
: when naming a class attribute, invokes name mangling (inside class
FooBar, __boo
becomes _FooBar__boo
; see below).__double_leading_and_trailing_underscore__
: “magic” objects or attributes that live in
user-controlled namespaces. E.g. __init__
, __import__
or __file__
.
Never invent such names; only use them as documented.Never use the characters ‘l’ (lowercase letter el), ‘O’ (uppercase letter oh), or ‘I’ (uppercase letter eye) as single character variable names.
In some fonts, these characters are indistinguishable from the numerals one and zero. When tempted to use ‘l’, use ‘L’ instead.
Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.
When an extension module written in C or C++ has an accompanying Python module that provides a higher level (e.g.
more object oriented) interface, the C/C++ module has a leading underscore (e.g. _socket
).
Class names should normally use the CapWords convention.
The naming convention for functions may be used instead in cases where the interface is documented and used primarily as a callable.
Note that there is a separate convention for builtin names: most builtin names are single words (or two words run together), with the CapWords convention used only for exception names and builtin constants.
Because exceptions should be classes, the class naming convention applies here. However, you should use the suffix “Error” on your exception names (if the exception actually is an error).
(Let’s hope that these variables are meant for use inside one module only.) The conventions are about the same as those for functions.
Modules that are designed for use via from M import *
should use the __all__
mechanism
to prevent exporting globals, or use the older convention of prefixing such globals with an underscore (which
you might want to do to indicate these globals are “module non-public”).
Function names should be lowercase, with words separated by underscores as necessary to improve readability.
mixedCase is allowed only in contexts where that’s already the prevailing style (e.g. threading.py), to retain backwards compatibility.
Always use self
for the first argument to instance methods.
Always use cls
for the first argument to class methods.
If a function argument’s name clashes with a reserved keyword, it is generally better to append a single trailing
underscore rather than use an abbreviation or spelling corruption. Thus class_
is better than
clss
. (Perhaps better is to avoid such clashes by using a synonym.)
Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability.
Use one leading underscore only for non-public methods and instance variables.
To avoid name clashes with subclasses, use two leading underscores to invoke Python’s name mangling rules.
Python mangles these names with the class name: if class Foo has an attribute named __a
, it cannot
be accessed by Foo.__a
. (An insistent user could still gain access by calling
Foo._Foo__a
.) Generally, double leading underscores should be used only to avoid name conflicts
with attributes in classes designed to be subclassed.
Note: there is some controversy about the use of __names (see below).
Constants are usually defined on a module level and written in all capital letters with underscores separating
words. Examples include MAX_OVERFLOW
and TOTAL
.
Always decide whether a class’s methods and instance variables (collectively: “attributes”) should be public or non-public. If in doubt, choose non-public; it’s easier to make it public later than to make a public attribute non-public.
Public attributes are those that you expect unrelated clients of your class to use, with your commitment to avoid backward incompatible changes. Non-public attributes are those that are not intended to be used by third parties; you make no guarantees that non-public attributes won’t change or even be removed.
We don’t use the term “private” here, since no attribute is really private in Python (without a generally unnecessary amount of work).
Another category of attributes are those that are part of the “subclass API” (often called “protected” in other languages). Some classes are designed to be inherited from, either to extend or modify aspects of the class’s behavior. When designing such a class, take care to make explicit decisions about which attributes are public, which are part of the subclass API, and which are truly only to be used by your base class.
With this in mind, here are the Pythonic guidelines:
If your public attribute name collides with a reserved keyword, append a single trailing underscore to your attribute name. This is preferable to an abbreviation or corrupted spelling. (However, notwithstanding this rule, ‘cls’ is the preferred spelling for any variable or argument which is known to be a class, especially the first argument to a class method.)
Note 1: See the argument name recommendation above for class methods.
For simple public data attributes, it is best to expose just the attribute name, without complicated accessor/mutator methods. Keep in mind that Python provides an easy path to future enhancement, should you find that a simple data attribute needs to grow functional behavior. In that case, use properties to hide functional implementation behind simple data attribute access syntax.
Note 1: Properties only work on new-style classes.
Note 2: Try to keep the functional behavior side-effect free, although side-effects such as caching are generally fine.
Note 3: Avoid using properties for computationally expensive operations; the attribute notation makes the caller believe that access is (relatively) cheap.
If your class is intended to be subclassed, and you have attributes that you do not want subclasses to use, consider naming them with double leading underscores and no trailing underscores. This invokes Python’s name mangling algorithm, where the name of the class is mangled into the attribute name. This helps avoid attribute name collisions should subclasses inadvertently contain attributes with the same name.
Note 1: Note that only the simple class name is used in the mangled name, so if a subclass chooses both the same class name and attribute name, you can still get name collisions.
Note 2: Name mangling can make certain uses, such as debugging and __getattr__()
, less
convenient. However the name mangling algorithm is well documented and easy to perform manually.
Note 3: Not everyone likes name mangling. Try to balance the need to avoid accidental name clashes with potential use by advanced callers.
Any backwards compatibility guarantees apply only to public interfaces. Accordingly, it is important that users be able to clearly distinguish between public and internal interfaces.
Documented interfaces are considered public, unless the documentation explicitly declares them to be provisional or internal interfaces exempt from the usual backwards compatibility guarantees. All undocumented interfaces should be assumed to be internal.
To better support introspection, modules should explicitly declare the names in their public API using the
__all__
attribute. Setting __all__
to an empty list indicates that the module has no
public API.
Even with __all__
set appropriately, internal interfaces (packages, modules, classes, functions,
attributes or other names) should still be prefixed with a single leading underscore.
An interface is also considered internal if any containing namespace (package, module or class) is considered internal.
Imported names should always be considered an implementation detail. Other modules must not rely on indirect
access to such imported names unless they are an explicitly documented part of the containing module’s API, such
as os.path
or a package’s __init__
module that exposes functionality from submodules.
Code should be written in a way that does not disadvantage other implementations of Python (PyPy, Jython, IronPython, Cython, Psyco, and such).
For example, do not rely on CPython’s efficient implementation of in-place string concatenation for
statements in the form a += b
or a = a + b
. This optimization is fragile even
in CPython (it only works for some types) and isn’t present at all in implementations that don’t use
refcounting. In performance sensitive parts of the library, the ''.join()
form should be
used instead. This will ensure that concatenation occurs in linear time across various implementations.
Comparisons to singletons like None should always be done with is
or is not
,
never the equality operators.
Also, beware of writing if x
when you really mean if x is not None
– e.g. when
testing whether a variable or argument that defaults to None was set to some other value. The other
value might have a type (such as a container) that could be false in a boolean context!
Use is not
operator rather than not ... is
. While both expressions are
functionally identical, the former is more readable and preferred.
Yes:
if foo is not None:
No:
if not foo is None:
When implementing ordering operations with rich comparisons, it is best to implement all six operations
(__eq__
, __ne__
, __lt__
, __le__
,
__gt__
, __ge__
) rather than relying on other code to only exercise a
particular comparison.
To minimize the effort involved, the functools.total_ordering()
decorator provides a tool to
generate missing comparison methods.
PEP 207 indicates that reflexivity rules are assumed by Python. Thus, the interpreter may swap
y > x
with x < y
, y >= x
with x <= y
,
and may swap the arguments of x == y
and x != y
. The sort()
and
min()
operations are guaranteed to use the <
operator and the
max()
function uses the >
operator. However, it is best to implement all
six operations so that confusion doesn’t arise in other contexts.
Always use a def statement instead of an assignment statement that binds a lambda expression directly to an identifier.
Yes:
def f(x): return 2*x
No:
f = lambda x: 2*x
The first form means that the name of the resulting function object is specifically ‘f’ instead of the generic ‘<lambda>’. This is more useful for tracebacks and string representations in general. The use of the assignment statement eliminates the sole benefit a lambda expression can offer over an explicit def statement (i.e. that it can be embedded inside a larger expression)
Derive exceptions from Exception
rather than BaseException
. Direct inheritance
from BaseException
is reserved for exceptions where catching them is almost always the
wrong thing to do.
Design exception hierarchies based on the distinctions that code catching the exceptions is likely to need, rather than the locations where the exceptions are raised. Aim to answer the question “What went wrong?” programmatically, rather than only stating that “A problem occurred” (see PEP 3151 for an example of this lesson being learned for the builtin exception hierarchy)
Class naming conventions apply here, although you should add the suffix “Error” to your exception classes if the exception is an error. Non-error exceptions that are used for non-local flow control or other forms of signaling need no special suffix.
Use exception chaining appropriately. In Python 3, “raise X from Y” should be used to indicate explicit replacement without losing the original traceback.
When deliberately replacing an inner exception (using “raise X” in Python 2 or “raise X from None” in Python 3.3+), ensure that relevant details are transferred to the new exception (such as preserving the attribute name when converting KeyError to AttributeError, or embedding the text of the original exception in the new exception message).
When raising an exception in Python 2, use raise ValueError('message')
instead of the older
form raise ValueError, 'message'
.
The latter form is not legal Python 3 syntax.
The paren-using form also means that when the exception arguments are long or include string formatting, you don’t need to use line continuation characters thanks to the containing parentheses.
When catching exceptions, mention specific exceptions whenever possible instead of using a bare
except:
clause.
For example, use:
try:
import platform_specific_module
except ImportError:
platform_specific_module = None
A bare except:
clause will catch SystemExit and KeyboardInterrupt exceptions, making it
harder to interrupt a program with Control-C, and can disguise other problems. If you want to catch all
exceptions that signal program errors, use except Exception:
(bare except is equivalent to
except BaseException:
).
A good rule of thumb is to limit use of bare ‘except’ clauses to two cases:
raise
. try...finally
can be a better way to handle this case.When binding caught exceptions to a name, prefer the explicit name binding syntax added in Python 2.6:
try:
process_data()
except Exception as exc:
raise DataProcessingFailedError(str(exc))
This is the only syntax supported in Python 3, and avoids the ambiguity problems associated with the older comma-based syntax.
errno
values.Additionally, for all try/except clauses, limit the try
clause to the absolute minimum
amount of code necessary. Again, this avoids masking bugs.
Yes:
try:
value = collection[key]
except KeyError:
return key_not_found(key)
else:
return handle_value(value)
No:
try:
# Too broad!
return handle_value(collection[key])
except KeyError:
# Will also catch KeyError raised by handle_value()
return key_not_found(key)
with
statement to ensure it is
cleaned up promptly and reliably after use. A try/finally statement is also acceptable.Context managers should be invoked through separate functions or methods whenever they do something other than acquire and release resources. For example:
Yes:
with conn.begin_transaction():
do_stuff_in_transaction(conn)
No:
with conn:
do_stuff_in_transaction(conn)
The latter example doesn’t provide any information to indicate that the __enter__ and __exit__ methods are doing something other than closing the connection after a transaction. Being explicit is important in this case.
Be consistent in return statements. Either all return statements in a function should return an
expression, or none of them should. If any return statement returns an expression, any return statements
where no value is returned should explicitly state this as return None
, and an explicit
return statement should be present at the end of the function (if reachable).
Yes:
def foo(x):
if x >= 0:
return math.sqrt(x)
else:
return None
def bar(x):
if x < 0:
return None
return math.sqrt(x)
No:
def foo(x):
if x >= 0:
return math.sqrt(x)
def bar(x):
if x < 0:
return
return math.sqrt(x)
Use string methods instead of the string module.
String methods are always much faster and share the same API with unicode strings. Override this rule if backward compatibility with Pythons older than 2.0 is required.
Use ''.startswith()
and ''.endswith()
instead of string slicing to check for
prefixes or suffixes.
startswith() and endswith() are cleaner and less error prone. For example:
Yes:
if foo.startswith('bar'):
No:
if foo[:3] == 'bar':
Object type comparisons should always use isinstance() instead of comparing types directly.  In Python 2, str and unicode have a common base class, basestring, so you can do:
if isinstance(obj, basestring):
Note that in Python 3, unicode
and basestring
no longer exist (there is only
str
) and a bytes object is no longer a kind of string (it is a sequence of integers
instead)
For sequences, (strings, lists, tuples), use the fact that empty sequences are false. :
Yes:
if not seq:
if seq:
No:
if len(seq)
if not len(seq)
Don’t compare boolean values to True or False using ==
. :
Yes:
if greeting:
No:
if greeting == True:
Worse:
if greeting is True:
With the acceptance of PEP 484, the style rules for function annotations are changing.
For code that wants to make a different use of function annotations it is recommended to put a comment of the form:
# type: ignore
near the top of the file; this tells type checker to ignore all annotations. (More fine-grained ways of disabling complaints from type checkers can be found in PEP 484.)
For code that needs to be backwards compatible, function annotations can be added in the form of comments. Basically, this Python 3 annotation:
def embezzle(self, account: str, funds: int = 1000000, **fake_receipts: str) -> None:
"""Embezzle funds from account using fake receipts."""
<code goes here>
is equivalent to the following:
def embezzle(self, account, funds=1000000, **fake_receipts):
# type: (str, int, **str) -> None
"""Embezzle funds from account using fake receipts."""
<code goes here>
The mypy type checker 6 currently supports this syntax, and other type checkers are encouraged to adopt it.
This document has been placed in the public domain.
PEP 7, Style Guide for C Code, van Rossum↩
Barry’s GNU Mailman style guide http://barry.warsaw.us/software/STYLEGUIDE.txt↩
Hanging indentation is a type-setting style where all the lines in a paragraph are indented except the first line. In the context of Python, the term is used to describe a style where the opening parenthesis of a parenthesized statement is the last non-whitespace character of the line, with subsequent lines being indented until the closing parenthesis.↩
Typeshed repo https://github.com/python/typeshed↩
mypy type checker http://mypy-lang.org https://github.com/JukkaL/mypy↩


Innovative Public Furniture Designed for Academic Institutes
- Written by Dima Stouhi
- about 9 hours
Architecture and design studio Hello Wood have created a line of "smart" outdoor furniture for educational institutes and public communal spaces. The two furniture pieces, Fluid Cube and City Snake, re-introduce modular public structures in a contemporary and sustainable way.
Commissioned by MVM Hungarian Electricity Private Limited Company (MVM), the solid-wood furniture pieces include smart functions powered by renewable energy. András Huszár, co-founder of Hello Wood explained that "the cool lines of the Fluid Cube and the City Snake were cut from sawn blocks of wood using CNC technology, which allowed us to minimize the waste".
The Fluid Cube is a fixed cubic structure with a solar-celled and tempered glass roof. The semi-transparency of the roof allows sunlight in but protects people sitting from the rain. The City Snake, on the other hand, is an elongated unit that allows for more adaptability in its ways of usage.
The expansion joints of both elements also play a role in shaping the character of each piece of furniture. These elements house "strips of light", powered by solar energy which ornament the furniture pieces. Integrated USB sockets, WiFi hotspots, and lighting are all powered by the shock-resistant solar panels developed by Hungarian brand Platio. The sleek pieces of solid wood furniture have already been installed at four Hungarian educational institutions, where they also serve as a community spaces.
Client: MVM Hungarian Electricity Private Limited Company (MVM)
Designed & built by Hello Wood
Chief designers: András Huszár, Péter Pozsár, Dávid Ráday
Project designer: Csaba Bányai, Gellért Ollé
Architects: Dániel Kiss, László Mangliár


Preplanning Checklist
Dealing with the loss of a loved one can be overwhelming to your surviving family and friends, but pre-planning your funeral service can help them better deal with the stress of losing someone.
Choose the Type of Service You Want
Pre-planning your funeral service can not only ease the burden on your loved ones, but it helps ensure your final wishes are honored. While some families struggle with making those final decisions after losing someone, your family won’t have to worry with making those hard choices.
- Choose what funeral home and director you would like to use to handle your service.
- Decide what type of service you want (traditional, cremation, donation, etc…).
- If you choose a traditional service with burial, decide where you want to be buried.
- Meet with the funeral director and look at your options for caskets and urns.
- If you decide you want to be buried, choose clothing options.
- Look at options for a location to hold your service (funeral home, religious facility, sentimental building, graveside).
- What type of flowers do you want? Do you want flowers, or would you rather donations be given to a particular charity or a charity of one’s choice? Who will be a part of your service? You should decide on pallbearers and even ask them personally.
- You should also decide who you would like to officiate or participate in your service.
- Choose which songs you would like played at your service.
- Write an obituary or make notes about information you would like to be included in your obituary.
Choose Who You Want to be in Charge
Your family and friends want to take part in the process of fulfilling your final wishes, they only need instructions on what they need to do.
- Make sure someone, preferably your executor, has a copy of the will.
- Give a family member or chosen friend a list of important account information that will need to be contacted and handled following your death. Also make sure someone knows your final wishes for your desired service.
- Designate someone to be your power of attorney.
- Have someone prepared to cancel basic utility services and subscriptions.
Choose To Pay In Advance
Making decisions about your funeral service in advance can benefit you and your survivors financially. If possible, pay for all expenses in advance, freeing your family from that financial burden. When possible, pre pay for:
- Cemetery services, burial plot
- All funeral arrangements including casket, urn, flowers, transportation and specialized services


#
INFO 610 Fall 2019
Week 17.5, Nov 7, 2019
DRY, Homework
chrisfauerbach.github.io/info610_fall_2019/
--- # What's an API?
* Application Programming Interface * Act as a common interface between systems --- # DRY - Donate Repeat Yourself * Remember this? ```python # Adding GET @app.route('/country/
', methods=['GET']) def get_country(id): conn = psycopg2.connect(dbname="postgres", user="postgres", password="postgres", host="localhost", port=5432) cur = conn.cursor(cursor_factory=psycopg2.extras.RealDictCursor) cur.execute("SELECT * FROM country WHERE country_id = %s;", (id, )) res = cur.fetchone() cur.close() conn.close() return res # Adding DELETE @app.route('/country/
', methods=['DELETE']) def del_country(id): conn = psycopg2.connect(dbname="postgres", user="postgres", password="postgres", host="localhost", port=5432) cur = conn.cursor(cursor_factory=psycopg2.extras.RealDictCursor) cur.execute("DELETE FROM country WHERE country_id = %s;", (id, )) res = cur.fetchone() cur.close() conn.close() return res ``` --- # Don't repeat. ```python # Adding GET @app.route('/country/
', methods=['GET']) @data_connection def get_country(id, cur=cur): cur.execute("SELECT * FROM country WHERE country_id = %s;", (id, )) res = cur.fetchone() return res # Adding DELETE @app.route('/country/
', methods=['DELETE']) @data_connection def del_country(id): cur.execute("DELETE FROM country WHERE country_id = %s;", (id, )) res = cur.fetchone() return res ``` --- # Python Trick * Function Decorators / Wrappers ```python def data_connection(func): def wrapper_to_add(*args, **kwargs): cur = None conn = None try: conn = psycopg2.connect(dbname="postgres", user="postgres", password="postgres", host="localhost", port=5432) cur = conn.cursor(cursor_factory=psycopg2.extras.RealDictCursor) func(*args, cur=cur, **kwargs) except: print("Exception while processing. Will Attempt to Rollback") traceback.print_exc(file=sys.stdout) try: if cur: cur.rollback() except: print("Had an issue rolling back.") traceback.print_exc(file=sys.stdout) finally: if cur: cur.close() if conn: conn.close() return wrapper_to_add ``` --- # Homework Build a single python file application: "my_api.py" * https://flask.palletsprojects.com/en/1.1.x/ Requirements: * Choose two tables (e.g. inventory, product) * Create a GET function for the collection, supporting at least ONE option parameter for filtering. * e.g. inventory?in_stock_count=5 * e.g. product?manufacturer=Logitech * name = request.args.get("name", "World") # World==default * Create a GET function that gets details by ID * Create a POST and PUT function for each of those tables * Update the database * If insert, return the new ID ("insert into ... returning id" - learn!) ```python json_data = request.get_json() email = json_data['email'] ``` * insert into my_table (value) values ('some value') returning id; ?? * At least ONE GET API that queries multiple tables. * product_inventory_with_descriptions --- # Example ```bash curl "http://myserver:5000/inventory" curl "http://myserver:5000/inventory?in_stock_count=5" curl "http://myserver:5000/inventory/4" curl "http://myserver:5000/product?manufacturer=Logitech" curl "http://myserver:5000/product/3" curl "http://myserver:5000/product_inventory_with_descriptions" curl -XPOST "http://myserver:5000/inventory -d \ '{"product_id": 4,"in_stock_count":5, "first_available":"01/02/2019.12:00:00"} ``` # Put it all together 1) SQL Scripts to create the DB 2) Python API 3) Bash script to run curl --- # --- # --- # --- # --- # --- #


Graphic Designer, Developer, Photographer
About me
My name is Shubham Sharan, I am from New Dehli, India currently pursing a Bachelor's degree in Computer Science Honors, focusing in the Software Engineering Stream with a minor in Statistics. I aspire to be a data scientist and some of my current traits are listed as follows:
Simple Modular diagrams accompanied with flowcharts, UML diagrams and functional interfaces
Simple HTML based webpages, using CSS styling and functionality based using Javascript code.
Writing sleek efficient Java code and I tend to dabble a bit in Python as well.
I tend to use photoshop and create vectors of my sketches and the photographs I tend to take.
A good understanding of a variety of data collection techniques which is analyzed by a collection of statistical principles.
I tend to do travel photography, which incorporate elements like architecture, nature and much more.


In index.js you can see that
document.body.style.backgroundColor = ComponentWithDependencies.getColor();
is called twice. After 2 seconds we are binding custom BlueColorProvider and color is changed from red to blue.


Plugin Information |
|---|
View Validating String Parameter on the plugin site for more information. |
Older versions of this plugin may not be safe to use. Please review the following warnings before using an older version:
Usage
This plugin is used wherever build parameter selection is available, most commonly in the job configuration page by enabling parameterized builds (this parameter type will also be available as release parameters using the release plugin).
Configure the parameter by entering a name, regular expression to validate the entered value and optionally a default value, an error message shown when the user entered value fails the regular expression check and a parameter description.
When a build is requested, the user will be prompted with the parameters to enter. Users enter the parameter as normal, but will now be prompted with an error message if the entered value does not meet the regular expression.
Once the entered value meets the configured regular expression, the error message is no longer displayed.
Version History
Version 2.4 (TBD)
Version 2.3 (04-Feb-2015)
- Fixed links to regex pattern documentation
- Use codemirror for the description field
Version 2.2 (13-Sep-2011)
- JENKINS-10139 Fix for regex containing back slashes
Version 2.1 (27-Feb-2011)
- If an invalid value is passed to the build, the build will be aborted and an error message will display in console indicating the parameter and failing value
Version 2.0 (19-Feb-2011)
- Migrated code to jenkins and performed release
Version 1.4 (13-Oct-2010)
- JENKINS-7794 validation check doesn't work if Jenkins is hosted with a context root
Version 1.3 (22-May-2010)
- JENKINS-6158 Build will fail if invalid parameter is passed
- JENKINS-6160 Jenkins will record regex used to validate the build parameter as part of build configuration and display as tooltip on the parameter page.
Version 1.2 (29-Aug-2009)
- Used the javascript function encodeURIComponent to properly handle characters within the user entered values for regex and validation error message. (Issue 4334)
Version 1.1 (28-Aug-2009)
- Supported the release plugins as well as any other plugin that uses build parameters
Version 1.0 (24-Aug-2009)
- Initial Version
Attachments:
build-error.PNG (image/png)
build-success.PNG (image/png)
validerror.PNG (image/png)
validerror2.PNG (image/png)


THREE COLORS: BLUE A film review by Chad Polenz Copyright 1997 Chad Polenz
*** 1994, R, 98 minutes [1 hour, 38 minutes] [drama] starring: Juliette Binoche (Julie), Benoit Regent (Olivier), Charlotte Very (Lucille), Phillippe Volter (Realtor), produced by Marin Karmitz, written by Krzystof Kieslowski, Krzystof Piesiewicz, directed by Krzystof Kieslowski.
If you ever wondered what it would be like to be invisible, "Blue" will give you the feeling you are. It is a film where all we do is follow a woman around, get to know her, and see what an interesting life she leads. We hardly ever get stories told like this, and although this can become rather strange at times, it is still original, realistic, and enjoyable.
We meet a woman named Julie (Binoche), who finds herself unable to cope with the death of her husband and daughter who died in a car accident she was also involved in. The accident itself opens up the story, but it is portrayed in somewhat of a strange manner. At first Julie tries to commit suicide, but can't bring herself to do it. Is she afraid of death or does she really want to live?
Slowly, things start to return to normal in her life. She doesn't want anything around her that will remind her of her family, so she sells her house and all of her possessions and moves from the country to the city.
Kieslowski's film tends to have a rather strange tone, both in the way the story is told, but also in the way it is presented, that is, not exactly in a straightforward manner. At times this can become confusing, but nevertheless it makes the story more intriguing and interesting.
Julie has some kind of an affair with her husband's friend Olivier (Regent), but she doesn't seem to enjoy it much. It's as if she can't feel anything anymore. This sense of emptiness can be felt throughout the film, as there is no real plot to it, just some strangely connected events in Julie's life; swimming, dining, talking with her neighbors, etc.
Some small things occur to build up her character, but it seems more like an excuse to follow show how seemingly normal people can live unusual lives. For example, her neighbor Lucille (Very), is a prostitute of sorts, whom she saves her from being evicted because she won't sign a petition to have her removed. She does this not so much to defend Lucille, but rather just to spite everyone and stay out of controversy.
Julie's husband was a famous French composer whose music would supposedly unite Europe, but when she gets a copy of his unfinished symphony she throws it away until she learns Olivier tried to finish it. This is an example of powerful symbolism: is it because of her own honor and/or selfishness she would threaten something that could bring peace between nations? Or is it love and respect for her husband, that only he could finish the piece?
Not much happens in "Blue" but it is still a good movie to watch just to observe how normal people really are.
visit Chad'z Movie page @ http://members.aol.com/ChadPolenz/index.html
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


On the other hand, we denounce
27 de dezembro de 2020
On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain.
These cases are perfectly simple and easy to distinguish. In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted.
The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains.On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee the pain and trouble that are bound to ensue; and equal blame belongs to those who fail in their duty through weakness of will, which is the same as saying through shrinking from toil and pain.
These cases are perfectly simple and easy to distinguish
In a free hour, when our power of choice is untrammelled and when nothing prevents our being able to do what we like best, every pleasure is to be welcomed and every pain avoided. But in certain circumstances and owing to the claims of duty or the obligations of business it will frequently occur that pleasures have to be repudiated and annoyances accepted.
At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio.  Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat.
  Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?


VAR_SAMP and VAR_POP Functions
The VAR_SAMP and VAR_POP functions return the sample and population variance of a set of numeric values (integer, decimal, or floating-point). The result of the VAR_SAMP function is equivalent to the squared sample standard deviation of the same set of values.
VAR_SAMP and VARIANCE are synonyms for the same function.
Syntax
VAR_SAMP | VARIANCE ( [ DISTINCT | ALL ] expression) VAR_POP ( [ DISTINCT | ALL ] expression)
The expression must have an integer, decimal, or floating-point data type. Regardless of the data type of the expression, the return type of this function is a double precision number.
Note
The results of these functions might vary across data warehouse clusters, depending on the configuration of the cluster in each case.
Usage Notes
When the sample variance (VARIANCE or VAR_SAMP) is calculated for an expression that consists of a single value, the result of the function is NULL not 0.
Examples
The following query returns the rounded sample and population variance of the NUMTICKETS column in the LISTING table.
select avg(numtickets), round(var_samp(numtickets)) varsamp, round(var_pop(numtickets)) varpop from listing; avg | varsamp | varpop -----+---------+-------- 10 | 54 | 54 (1 row)
The following query runs the same calculations but casts the results to decimal values.
select avg(numtickets), cast(var_samp(numtickets) as dec(10,4)) varsamp, cast(var_pop(numtickets) as dec(10,4)) varpop from listing; avg | varsamp | varpop -----+---------+--------- 10 | 53.6291 | 53.6288 (1 row)


Motorcyclist seriously injured after Wales' Euro qualifier match
Police said the 25-year-old biker was later arrested following the crash
by Ffion LewisA motorcyclist suffered serious injuries after a crash involving a car and a motorbike as Wales fans made their way back from last night's 2-0 win over Hungary.
The accident happened on Cornwall Road, near Cardiff City Stadium at around 10.15pm last night, Tuesday November 11.
The area was particularly busy at the time of the incident due to crowds leaving the ground.
Police and paramedics attended the scene and a 25-year-old male motorcyclist was taken to the University Hospital of Wales with serious injuries.
Officer said that the motorcyclist was subsequently arrested on suspicion of driving under the influence of alcohol, taking a motor vehicle without consent and driving without insurance.
An eyewitness at the scene said: "The driver was lying in the middle of the road with a number of people helping him.
"There was substantial debris on the road and the motorbike was lying on its side.
"Passers by, many who'd left the Wales game, were offering help and directing traffic including buses around the man.
"We saw two ambulance response vehicles and an ambulance arrive."
A spokeswoman for South Wales Police said: "Police are investigating a collision between a motorbike and car near the junction of Cornwall Street and North Clive Street, Grangetown, at around 10.15pm last night.
"The motorcyclist was arrested for driving a motor vehicle whilst under the influence of excess alcohol, taking a motor vehicle without consent and driving without insurance.
"The 25-year-old from Riverside was treated by paramedics at the scene and taken to the University Hospital of Wales, Cardiff, with serious injuries."
Anyone with information on the incident is asked to contact South Wales Police on 101.


| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Counter
Simple counter implementation
|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Counter
Simple counter implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Triple
Simple triple elements holder implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Triple
Simple triple elements holder implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Counter
Simple counter implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Optional
Simple Optional class, based loosely on Java 8's optional class
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| AtomicBoolean |
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Triple
Simple triple elements holder implementation
|
| Class and Description |
|---|
| Counter
Simple counter implementation
|
| Class and Description |
|---|
| Counter
Simple counter implementation
|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Counter
Simple counter implementation
|
| Class and Description |
|---|
| Atomic |
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Counter
Simple counter implementation
|
| Class and Description |
|---|
| Counter
Simple counter implementation
|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| CounterMap |
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| AtomicDouble |
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| AtomicBoolean |
| AtomicDouble |
| Counter
Simple counter implementation
|
| CounterMap |
| ImmutablePair
Simple pair implementation
|
| ImmutableQuad
Simple quad elements holder implementation
|
| ImmutableTriple
Simple triple elements holder implementation
|
| Optional
Simple Optional class, based loosely on Java 8's optional class
|
| Pair
Simple pair implementation
|
| Quad
Simple triple elements holder implementation
|
| Triple
Simple triple elements holder implementation
|
| Class and Description |
|---|
| AtomicBoolean |
| AtomicDouble |
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Triple
Simple triple elements holder implementation
|
| Class and Description |
|---|
| Counter
Simple counter implementation
|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| AtomicDouble |
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| AtomicBoolean |
| Triple
Simple triple elements holder implementation
|
| Class and Description |
|---|
| SynchronizedObject
This class is simple holder for provided variable which can be accessed & updated in thread-safe way
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| AtomicBoolean |
| Optional
Simple Optional class, based loosely on Java 8's optional class
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| AtomicBoolean |
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Atomic |
| AtomicBoolean |
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Atomic |
| AtomicBoolean |
| Class and Description |
|---|
| Optional
Simple Optional class, based loosely on Java 8's optional class
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
| Class and Description |
|---|
| Pair
Simple pair implementation
|
Copyright © 2020. All rights reserved.


<lcNeeds>
The <lcNeeds>
provides the needs
behind the outcomes described by the
<lcGoals>
.
Category: Learning and training: common content elements


A professionally managed organization engaged in the marketing & sales of multi-brand Air-conditioning, Refrigeration equipment, components, spare parts, and a comprehensive range of other HVACR products.
With an extesive product portfolio, we stay as a landmark and a preferred choice of customers spread across residential, commercial, industrial, automobile, and marine applications.
We are there for you. Whether you are having difficulty with your chilled water systems, your air conditioning is not working properly or you simply have a question about some aspect of your HVAC systems, Cool Tech has a 24/7 service network at your disposal.To ensure smooth operation and minimal downtime for all your installed equipment, Cool Tech has an extensive stock of spare parts for refrigeration and air conditioning used, available through an efficient parts service. All stocked items are quoted and dispatched immediately, and our depots hold large stocks of spares to ensure minimal delivery time and costs. Our spare parts service can provide components for any brand of HVAC&R equipment.
Cool Tech top priority is customer satisfaction. We achieve that first and foremost through our unbeatable service. We also ensure we provide as many options as possible to make that service convenient and stress-free.
We remain committed to provide environmentally responsible and technically superior products / components / spare parts from the industry's most leading brands, both from domestic and international segments.


| Number of clients | 100,000 |
| Total values reported / obfuscated | 700,000 |
| Unique values reported / obfuscated | 50 |
| k | Size of Bloom filter in bits | 16 |
| h | Hash functions in Bloom filter | 2 |
| m | Number of Cohorts | 64 |
| p | Probability p | 0.5 |
| q | Probability q | 0.75 |
| f | Probability f | 0.5 |


--- layout: post title: Led blinking program with ATmega128, AVR Studio 6 and ISIS Proteus date: 2013-04-30 14:21:12.000000000 +02:00 type: post parent_id: '0' published: true password: '' status: publish tags: - AtMega - Atmel AVR - C/C++ meta: _edit_last: '49460244' _wpas_skip_3508581: '1' author: login: mpho112 email<EMAIL_ADDRESS>display_name: Mpho first_name: '' last_name: '' ---
My 1st blog attempt
So I have been learning/refreshing Embedded C, my initial project was just a simple program. Blinking an Led
I have attached the source code, and schematic
Source Code:
#include <avr/io.h>
#include <util/delay.h>
void BlnkLED() // function declaration
{
DDRA = 0xFF; // set up pin direction
PORTA ^= 0x01 ; // toggle the pins
_delay_ms(500); //delay
}
int main (void)
{
while(1){
BlnkLED();
}
}


Perfect Blue (1999) Reviewed by Eugene Novikov http://www.ultimate-movie.com Member: Online Film Critics Society
** out of four
Dubbed in English from Japanese. Not Rated (Would be a strong R or an NC-17).
For those who do not know, "anime" is a Japanese form of animation. It has a very distinctive style and, with graphic violence and often nudity, it's strictly for adults. Perfect Blue is one of the few animes released on the big screen in the US and why they chose this one is beyond me. It's an intriguing but pretentious, confusing, often incoherent meditation on the nature of reality: a concept that has been explored so thoroughly in Hollywood the past couple years, did we really need to import a movie about it?
Perfect Blue tells the story of Mima, a lead singer for a pop group named "Cham" who decides to leave music for an acting career. Her first television role does not exactly fit in with her previous perky persona. In fact, her deeply troubled character resembles herself all too well; so much so that she begins to confuse her life with that of her television counterpart.
One day she finds a page on the internet entitled "Mima's Room". It has too much personal information: things other people wouldn't know unless they were watching her. At the same time, she begins getting anonymous letters -- one of them complete with a letter bomb -- and she grows frightened. Soon the stress of her job overwhelms her and she spaces out of reality. She is no longer able to separate the dream world from the real world and is haunted by visions of her pop-star alter ego and a mysterious man who seems intent on doing her harm.
After running it over in my head for hours, I am now pretty sure that I understand just what went on in Perfect Blue, but as I was watching I had no idea. This may have been the effect that director Satoshi Kon was going for, but either way it doesn't work; instead of enjoying the kinetic, visually charged production I was scratching my head. I have no problem with films that are, by their very nature, complex, but it's no fun when it gets to the point of being impossible to follow.
I understand that translating a film into English from another language is a daunting task, but when said film has pretentions of being a legitimate psychological thriller, its dialogue should not sound as if it was written by a third-grader. Here, the content does indeed suggest an adult suspenser but the dialogue seems to have come from The Iron Giant (especially botched is a scene where Mima is taught to use the internet: it comes like an extraordinarily bad commercial for an online service).
Well-made action sequences and a terrific, powerful soundtrack almost redeem this sloppy, incoherent movie. One of the reasons I love animation is that it makes it easy for filmmakers to stage long, complicated scenes that would be very difficult (i.e. expensive) to do when bound by the limits of the real world. Perfect Blue takes full advantage of this wonderful medium. The drawings themselves are fluid and realistic while the things they do with the drawings are amazing.
The film does look great, but my rating would have been at least a star higher had director Satoshi Kon paid a little less attention to the visuals and a more to narrative cohesion. I am a sucker for "what-is- reality" movies; even the otherwise lambasted The Thirteenth Floor eked out a 3-star rating from me. I definitely find the premise of Perfect Blue to be brimming with potential. Too bad the film disrupted my idea of reality with its mediocrity. ©1999 Eugene Novikov
Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Welcome to the Internet Camera
View Video - ActiveX Mode
View Video - Java Mode
System Administration


--- layout: post title: My Hero! tags: - ego status: publish type: post published: true meta: {} --- Blog
Australia's Geekiest ManSlashdot identified our very own Jonathan Oxer as Australia's Geekiest Man, a well deserved honour and it couldn't have happened to a nicer guy. Now we need to know who Australia's Geekiest Woman is. Possibly Kirrily, although she recently moved to San Francisco so I don't know if she still qualifies. Updated: In early March Jon made it onto Australian national TV


(just another timm tool)
Easier Command-Line Options
Documentation for this code is available
[on-line](http://tttv1.net/GLOBALS.py).
Install via `wget -O options.py http://ttvi1.net/GLOBALS.py`. Then use as follows:
from opt import *
our = options(
"1 line header",
"Preamble text (multi-line).",
"End text (multi-line).",
group1 = [
"1 line group description",
,h("1 line help",keyword1 = num") # "--keyword1 X" expects any float
,h("1 line help",keyword2 = False") # "--keyword2" will set keyword=True
,h("1 line help",keyword3 = str) # "--keyword3 X" expects any string
,h("1 line help",keyword4 = [x,y,z..]") # "--keyword4 X" expects one of x,y,z...
where the type of "X" is set from "x"
],
group2 = [
...
])
After that, data on the above groups is stored in `our`; e.g. `our.group1.keyword1`.
The above call defines a variable `our` with fields (e.g.)
our.group1.keyword1
etc. Also, on the command line,
python codeThatUsesOptions.py--keyword1 X --keyword2 Y
will override the defaults shown below. Further,
python --help
will print help text, divided into the groups.
wget -O options.py http://tiny.cc/ttv1options
The standard way to process options in Python is the `argparse`
library which can be verbose, to say the least. So this code is
an expansion function that takes a simple declarative syntax of the
optopms, then expands it into the argparse commands.
There's two functions that handle this process:
- `our=options(about,header,footer, groups)` writes a dictionary of options to `our`,
while first checking if any command-line options overrides the defaults.
- `h(help,key=default)` is for one item. It exapnds into a whole
dictionary of options for argparse.
Here are some examples of this expansions. For example,
h("disable all tests", brave = False)
expands into
dict(help = "disable all test",
key = "--brave",
default = False,
action = "store_true")
and
h("split redos", splitRedo = 20)
exapnds into
dict(metavar = "S",
key = "--when",
type = str,
choices = ["mon","tues","wed"],
help = "day of week",
default = "mon"
)
and
h("day of week", when=["mon","tues","wed"])
expands into
dict(metavar = "S",
key = "--when",
type = str,
choices = ["mon","tues","wed"],
help = "day of week",
default = "mon"
)
In the above `"mon"` was used as the default since it was
the first item in the when list.
import sys,argparse
def h(help,d): key,val = next(iter(d.items())) default = val[0] if isinstance(val,list) else val # step0: remember defaults out = dict(default=default) add = lambda d : out.update(d) # convenience function for adding args # step1: Set type and meta var if val is not False: if isinstance(default,int ): add(metavar= "I", type= int) elif isinstance(default,float): add(metavar= "F", type= float) else : add(metavar= "S", type= str) # step2: add help and type-specific misc flags if val is False : add(help=help, action="store_true") elif isinstance(val,list): add(help=help, choices=val) else: add(help=help + ("; e.g. %s" % str(val))) # -------------- return key, out
def options(prog, before, after, d): class o: def __init__(i, d) : i.dict.update(d) def repr(i) : return i.dict.repr() def getitem(i, k) : return i.dict[k] def setitem(i,k,v) : i.dict[k] = v # ------------------------------- parser = argparse.ArgumentParser( prog = prog, description = before, epilog = after, formatter_class=argparse.RawTextHelpFormatter) inside,out = {}, o() for context in sorted(d.keys()): out[context] = o() description = d[context][0] group = parser.add_argument_group(context, description) for key,rest in d[context][1:]: group.add_argument("--" + key,**rest) assert key not in inside, 'keys cannot repeat' inside[key] = context parsed = vars(parser.parse_args()) for key,val in parsed.items(): out[inside[key]][key]= val return out
____
<img align=right
src="https://raw.githubusercontent.com/timm/timm.github.io/master/timm.png"
width=170>
Copyright © 2016 Tim Menzies<EMAIL_ADDRESS>This program is free software. It comes without any warranty, to
the extent permitted by applicable law. You can redistribute it
and/or modify it under the terms of the Do What The F*ck You Want
To Public License, Version 2, as published by Sam Hocevar. See
[http://www.wtfpl.net](http://www.wtfpl.net) for more details.
Share and enjoy.


Default is 0. If the amount of 'ahead' commits is less than or equal to this value, the fork is automatically removed from the list.
Add a GitHub Access Token
Useful Forks uses the GitHub API to retrieve repository metadata. You may see this dialog because you have hit the GitHub API rate limit.
To raise that limit (it increases it by almost 5000 calls per hour), you should provide a personal Access Token.
If you don't already have one, you can create one and paste its ID into the text-box below. The required scope is pre-configured by the "Create" button's link below.
Customize query settings
Settings will be saved on your local browser and will apply to your future queries.
Default is 0. If the amount of 'ahead' commits is less than or equal to this value, the fork is automatically removed from the list.
Default is 'Parent'. Which repository, relative to the evaluated fork, should be used to calculate the commit diff ('ahead' and 'behind').
Default is checked. Determines whether to display or not the "Export table as CSV" button when a scan ends.


Unlimited Games. How should Red play 32?
pips Red=145 White=123
(CorrectAnswer= 0/0, ErrorScore= 0)
With a deficit of 17 pips after the roll advancing the rear checkers would seem to be the wrong game plan. That 23-pt anchor will generate a lot of shots later on.
When I first looked at this problem it was from a match at 0-0 to 5. In that scenario Red should definitely play 6/3, 5/3, because 23/21, 10/7 loses too many gammons.
In a money game the Jacoby Rule protects against a lot of gammon losses because the cube has to have been turned for a gammon to count. That makes all the difference to evaluating this position. Now 6/3, 5/3 is still the best play but 23/21, 10/7, which seeks to make a more advanced anchor, has virtually the same equity so you can choose either play.
When I first looked at this problem it was from a match at 0-0 to 5. In that scenario Red should definitely play 6/3, 5/3, because 23/21, 10/7 loses too many gammons.
In a money game the Jacoby Rule protects against a lot of gammon losses because the cube has to have been turned for a gammon to count. That makes all the difference to evaluating this position. Now 6/3, 5/3 is still the best play but 23/21, 10/7, which seeks to make a more advanced anchor, has virtually the same equity so you can choose either play.
1. Cubeful 2-ply 6/3 5/3 Eq.: -0.413 0.365 0.078 0.003 - 0.635 0.090 0.002 2. Cubeful 2-ply 10/7 6/4 Eq.: -0.447 (-0.034) 0.353 0.069 0.002 - 0.647 0.084 0.003 3. Cubeful 2-ply 10/8 6/3 Eq.: -0.477 (-0.064) 0.345 0.065 0.002 - 0.655 0.084 0.002 4. Cubeful 2-ply 10/7 5/3 Eq.: -0.478 (-0.065) 0.346 0.065 0.002 - 0.654 0.087 0.003 5. Cubeful 2-ply 10/7 8/6 Eq.: -0.504 (-0.091) 0.340 0.063 0.002 - 0.660 0.082 0.002


class DoctrineExtensionListener implements ContainerAwareInterface
Methods
| setContainer(ContainerInterface $container = null) | ||
|
onKernelRequest(GetResponseEvent $event)
This handler will be used by Loggable doctrine extension to set the username |
Details
at line 22
public
setContainer(ContainerInterface $container = null)
at line 31
public
onKernelRequest(GetResponseEvent $event)
This handler will be used by Loggable doctrine extension to set the username


- Description
- allows adding and removing of hierarchy data nodes, replacing of
the value of hierarchy data node members, as well as obtaining the
value of hieryrchy data node members.
Adding and removing must only be supported if the access object
points to the "Children" data member of a node or to the root node.
It will insert a new node or or remove an existing one. If supported
on data nodes, adding must add new data members to the node, removing
must remove data members. However, the mandatory data members (Title,
TargetURL, Children) must never be removable.
Replacing and getting values must be supported be every data node.
|