semvec/pypi-packages huggingface dataset:
bold-smart-lock 0.3.9
Python library to communicate with Bold Smart Lock (https://boldsmartlock.com)
License: MIT
Keywords: bold,smart lock,home automation

# Bold Smart Lock Python Package
This package implements the Bold Smart Lock API to authenticate and unlock a Bold smart lock. Usage of this API requires a Bold Connect.

## Installation
To install dependencies during development run ```pip install .``` from the project directory.
Optionally use the included VSCode Dev Container to get a preconfigured envirionment.

## Usage

```python
import asyncio
import aiohttp
from bold_smart_lock.auth import AbstractAuth

from bold_smart_lock.bold_smart_lock import BoldSmartLock

class TestAuth(AbstractAuth):
    async def async_get_access_token(self) -> str:
        return "00000000-0000-0000-0000-000000000000"  # Obtain an access token with oAuth2 and specify it here

async def main():
  async with aiohttp.ClientSession() as session:
    auth = TestAuth(session)
    bold = BoldSmartLock(auth)

    # Get the devices and device permissions
    get_device_permissions_response = await bold.get_device_permissions()
    print(get_device_permissions_response)

    # Activate the smart lock by device id
    remote_activation_response = await bold.remote_activation(12345)
    print(remote_activation_response)

    # Deactivate the smart lock by device id
    remote_deactivation_response = await bold.remote_deactivation(12345)
    print(remote_deactivation_response)

asyncio.run(main())
```
pysos 1.3.0
Simple Object Storage - Persistent dicts and lists for python.
License: MIT
Keywords: persistent persistence dict list file

pySOS: Simple Objects Storage
=============================

> persistant dictionaries and lists for python

This is ideal for lists or dictionaries which either need persistence,
are too big to fit in memory or both.

There are existing alternatives like `shelve`, which are very good too.
There main difference with `pysos` is that:

- only the index is kept in memory, not the values (so you can hold more data than what would fit in memory)
- it provides both persistent dicts *and* lists
- objects must be json "dumpable" (no cyclic references, etc.)
- it's fast (much faster than `shelve` on windows, but slightly slower than native `dbms` on linux)
- it's unbuffered by design: when the function returns, you are sure it has been written on disk
- it's safe: even if the machine crashes in the middle of a big write, data will not be corrupted
- it is platform independent, unlike `shelve` which relies on an underlying `dbm` implementation, which may vary from system to system
- the data is stored in a plain text format

Usage
-----

`pip install pysos`

Dictionaries:
```
import pysos
db = pysos.Dict('somefile')
db['hello'] = 'persistence!'
```

Lists:
```
import pysos
db = pysos.List('somefile')
db.append('it is now saved in the file')
```


Performance
-----------

Just to give a ballpark figure, there is a mini benchmark included in `test_benchmark.py`.
Here are the results on my laptop:

    Writes: 28521 / second
    Reads: 188502 / second

The test is just writing 100k small key/values, and reading them all too.
It's just meant to give a rough idea.

It writes every time you set a value, but only the key/value pair.
So the cost of adding an item stays constant.
On the other hand, lots of updates / deletes / re-inserts would lead to data fragmentation in the file.
This might deteriorate performance in the long run.


F.A.Q.
------

### Is it thread safe?

No. It's not thread safe.
In practice, synchronization mechanisms are typically desired on a higher level anyway.

### Why not make it async writes?

In the original version, there was a switch to choose between sync and async mode.
However, it turned out to have only a relatively small impact on overall performance.
Less than 25% on the hardware/OS/data I tested if I remember right.
Since the benefits seem rather low, I removed the flag and the associated code altogether, 
in order to ensure safety by default.
IMHO, it's preferable to loose a few microseconds rather than data upon a crash.


### Why not use memory mapped files?

I experimented with that too. In my experience, with the hardware/OS/data I tested,
it turned out to ...*suck*. Using memory mapped files lead to inconsistent and unpredictible performance,
often much slower than direct file access.