semvec/pypi-packages huggingface dataset:
dispatk 0.1
Multiple dispatcher on arguments values.
License: MIT
Keywords: multiple dispatch generic functions genericfunctions decorator

# dispatk

## Description

This function is inspired by singledispatch of Python 3.4+ (PEP 443),
but the dispatch happens on the key extracted fro the arguments values.

```
from dispatk import dispatk

@dispatk(lambda n: int(n))
def fib(n):
    return fib(n-1) + fib(n-2)
@fib.register(0)
def _(n):
    return 0
@fib.register(1, 2)
def _(n):
    return 1
@fib.register(41)
def _(n):
    return 165580141
```

*register* accepts one or more keys, so

```
@fib.register(1, 2)
def _(n):
    return 1
```

is equivalent to

```
@fib.register(1)
@fib.register(2)
def _(n):
    return 1
```
tabletest3 1.1.0
Unit testing module for table-like test, for Python 3.
License: MIT
Keywords: unittest test table testing

# TableTest3 [![Build Status](https://travis-ci.org/horia141/tabletest3.svg)](https://travis-ci.org/horia141/tabletest3) #

Unit testing module for table-like test, for Python 3.

For Python 2, check out [TableTest](https://github.com/horia141/tabletest).

Many unit tests, especially those for side-effect free functions, can be written like this:

```python
import unittest
class FooTest(unittest.TestCase):
  TEST_CASES = [ case_1, case_2, ... ]
  def test_all(self):
    for test_case in TEST_CASES:
      do something with test_case
```

If there are many test cases, they'll all appear as a single unit test in test runners. Furthermore,
the failure of one test will cause all others to fail. Finally, it might be hard to identify which
of the tests actually fail.

TableTest3 aims to solve this problem. Using it, we can rewrite the previous example as:

```python
import tabletest
class FooTest(tabletest3.TableTestCase):
  TEST_CASES = [ case_1, case_2, ... ]
  @tabletest3.tabletest(TEST_CASES)
  def test_all(self, test_case):
    do something with test_case
```

When the testrunner will run this class, it will now find one test for each test case. Each test
will basically invoke `tabletest` with a single test case.

The setup functions like this:
* You must define a `TEST_CASE` class variable which can be iterated as a sequence.
* You must define a single argumet test function which does the testing required for each
  test case.
* Each element of `TEST_CASE` generates a test function, called `test_all_{xx}`, for the previous
  example.
* Iteration order is not guaranteed and should not be depended on.
* All other `unittest.TestCase` behavior remains intact: `setUp` and `tearDown` methods, other test
  methods etc.
* More than one test can be annotated with tabletests per test case.
* However, the name must starst with `test_`, so it is picked up by the runner.

## Installation ##

Installation is straightforward, via `pip`:

```bash
pip install tabletest3
```

## Development ##

Working on this project is pretty much standard Python development. Perhaps the most novel aspect is the usage of the [Bazel][bazel] build system. At the moment, only a `py_library` and a `py_test` are defined as build rules. Nevertheless, tests are run through [Bazel][bazel] rather than through regular invocation. To run the tests use:

```bash
bazel test //:tabletest3_test
```

To push a new version of the package to PyPi use:

```bash
bazel run //:tabletest3_upload -- --user=[pypi user] --pass=[pypi password]
```

## References ##

See [Tabletests][tabletests] and [How Tabletest Works][how-tabletest-works] for a longer introduction as well as a deep dive into the library.

[tabletests]: https://horia141.github.com/jekyll/update/2015/08/31/tabletests.html
[how-tabletest-works]: https://horia141.github.com/jekyll/update/2015/09/08/how-tabletest-works.html
[bazel]: http://bazel.io
tabletest 1.1.0
Unit testing module for table-like test, for Python 2.
License: MIT
Keywords: unittest test table testing

# TableTest [![Build Status](https://travis-ci.org/horia141/tabletest.svg)](https://travis-ci.org/horia141/tabletest) #

Unit testing module for table-like test, for Python 2.

For Python 3, check out [TableTest3](https://github.com/horia141/tabletest3).

Many unit tests, especially those for side-effect free functions, can be written like this:

```python
import unittest
class FooTest(unittest.TestCase):
  TEST_CASES = [ case_1, case_2, ... ]
  def test_all(self):
    for test_case in TEST_CASES:
      do something with test_case
```

If there are many test cases, they'll all appear as a single unit test in test runners. Furthermore,
the failure of one test will cause all others to fail. Finally, it might be hard to identify which
of the tests actually fail.

TableTest aims to solve this problem. Using it, we can rewrite the previous example as:

```python
import tabletest
class FooTest(tabletest.TableTestCase):
  TEST_CASES = [ case_1, case_2, ... ]
  @tabletest.tabletest(TEST_CASES)
  def test_all(self, test_case):
    do something with test_case
```

When the testrunner will run this class, it will now find one test for each test case. Each test
will basically invoke `tabletest` with a single test case.

The setup functions like this:
* You must define a `TEST_CASE` class variable which can be iterated as a sequence.
* You must define a single argumet test function which does the testing required for each
  test case.
* Each element of `TEST_CASE` generates a test function, called `test_all_{xx}`, for the previous
  example.
* Iteration order is not guaranteed and should not be depended on.
* All other `unittest.TestCase` behavior remains intact: `setUp` and `tearDown` methods, other test
  methods etc.
* More than one test can be annotated with tabletests per test case.
* However, the name must starst with `test_`, so it is picked up by the runner.

## Installation ##

Installation is straightforward, via `pip`:

```bash
pip install tabletest
```

## Development ##

Working on this project is pretty much standard Python development. Perhaps the most novel aspect is the usage of the [Bazel][bazel] build system. At the moment, only a `py_library`, a`py_test` and a `pypi_package` are defined as build rules. Nevertheless, tests are run through [Bazel][bazel] rather than through regular invocation. To run the tests use:

```bash
bazel test //:tabletest_test
```

To push a new version of the package to PyPi use:

```bash
bazel run //:tabletest_upload -- --user=[pypi user] --pass=[pypi password]
```

## References ##

See [Tabletests][tabletests] and [How Tabletest Works][how-tabletest-works] for a longer introduction as well as a deep dive into the library.

[tabletests]: https://horia141.github.com/jekyll/update/2015/08/31/tabletests.html
[how-tabletest-works]: https://horia141.github.com/jekyll/update/2015/09/08/how-tabletest-works.html
[bazel]: http://bazel.io
hasItChanged 0.0.5
Monitor websites for changes
License: MIT
Keywords: email smtp sendgrid http

Has it changed?
===============

Grabs current version of each page in a list, and checks against
previous stored version.  Sends email and stores new version if
there is any change.  Currently uses sendgrid to send the email.
Configuration is done through environment variables.  Example
environments are in the examples directory.  These environments can
be instantiated using
`envdir <https://pypi.python.org/pypi/envdir>`_.