semvec/pypi-packages huggingface dataset:
markstore 1.2.0
Markdown as plain-text data storage
Requires Python: >=3.7

# markstore
Markdown as plain-text data storage

## But Why?
Why use this when there are numerous alternatives for data storage and serialization?  
Check if your use-case meets the following criteria:

1) Primarily human readable (not necessarily, writable) plain-text, especially for non-programmers
2) Easy consumption by version control
3) Easy export, or a desire to prevent vendor lock-in to your application

### What this is
A simple, json-like interface to serialize basic objects to and from a markdown file.

### What this isn't
- A generic markdown processing/generator tool
- A configuration language

It is a non-goal of this library to be tolerant of human error.
The intended use case is **machine-to-machine serialization** and the occasional export
to a human.

## Example

### To File
```py
import markstore

# Serialize
myObject = {
    "myKey": "myData"
}

with open("out.md", mode='wb') as f:
    markstore.dump(myObject, f)

# Deserialize
with open("out.md", mode='rb') as f:
    myObject = markstore.load(f)

```

### To String
```py
import markstore

# Serialize
myObject = {
    "myKey": "myData"
}

myStr = markstore.dumps(myObject)

# Deserialize
myObject = markstore.loads(myStr)

```



## Markdown Object Specification

### Lists
```py
["one", "two", "three", ["four", "five"], "six"]
```
Translates to 

```md
- one
- two
- three
- - four
  - five
- six
```

### Dicts
```py
{
    "key1": "data1",
    "key2": "data2",
    "key3": { 
        "subkey1": "subdata1",
        "subkey2": "subdata2"
        }
}
```

Translates to 

```md
# key1
data1
# key2
data2
# key3
## subkey1
subdata1
## subkey2
subdata2
```

### Combinations
```py
{
    "Key1":
    "My Data",
    "Data": [{
        "Subkey1": "Subdata1"
    }, {
        "Subkey2": {
            "Subkey2.1": "Subdata2.1",
            "Subkey2.2": "Subdata2.2"
        }
    }],
    "Key2":
    "Other data"
}
```

```md
# Key1
My Data
# Data
- ## Subkey1
  Subdata1
- ## Subkey2
  ### Subkey2.1
  Subdata2.1
  ### Subkey2.2
  Subdata2.2
# Key2
Other data
```

**Inner dictionary keys are always prefixed by an increasing number of `#`, even if the key is within a list**
annex4risk-detector 1.4.10
risk classification chat assistant
Requires Python: >=3.8

# Risk Detector

Minimal skeleton of dynamic risk classification chat assistant.

## Installation

```bash
pip install -r requirements.txt
# or install the package
pip install .
```

## CLI usage

The project exposes a command line interface providing helpers to manage rules and run the interactive dialog.

```bash
annex4risk-detector --help
```

Typical workflow:

```bash
# create database tables
annex4risk-detector init_db --db-url sqlite:///risk.db

# load YAML rules into the database
annex4risk-detector sync_rules --db-url sqlite:///risk.db --dir path/to/rules

# start an interactive classification chat
annex4risk-detector chat --db-url sqlite:///risk.db
```

See `risk-detector --help` for all available commands.

## Demo script

For a quick demonstration with a temporary SQLite database and pre-filled
answers that exercise all risk levels, run:

```bash
python demo_script.py
```

The script loads sample rules from `test_rules/risk` and shows how the dialog
flows for scenarios ending in the `prohibited`, `high_risk`,
`not_high_risk` (including Art. 6(3) derogation), and `out_of_scope` categories.

## Serverless deployment

When deploying the Lambda handler, use a database reachable from the
serverless environment (for example, an Amazon RDS PostgreSQL instance).
Expose the connection string via the `DB_URL` environment variable –
`handler.py` reads this variable and passes it to `DialogOrchestrator`.

Before deployment initialise the database and load the rules:

```bash
annex4risk-detector init_db --db-url "$DB_URL"
annex4risk-detector sync_rules --db-url "$DB_URL" --dir path/to/rules
```

These commands create tables including `chat_answers` and `risk_outcomes`
which persist every answer and classification result.
python-getpaid 0.1.0
Umbrella package for the python-getpaid payment processing ecosystem.
Requires Python: >=3.12

# python-getpaid

Umbrella package for the **python-getpaid** payment processing ecosystem.

## Installation

Install the core library:

```bash
pip install python-getpaid
```

### Payment gateway backends

```bash
pip install python-getpaid[payu]
pip install python-getpaid[paynow]
pip install python-getpaid[przelewy24]
pip install python-getpaid[backends]       # all backends
```

### Framework adapters

```bash
pip install python-getpaid[django]
pip install python-getpaid[fastapi]
pip install python-getpaid[litestar]
pip install python-getpaid[frameworks]     # all framework adapters
```

### Everything

```bash
pip install python-getpaid[all]
```

## Extras reference

| Extra | Installs |
|---|---|
| `payu` | `python-getpaid-payu` |
| `paynow` | `python-getpaid-paynow` |
| `przelewy24` | `python-getpaid-przelewy24` |
| `django` | `django-getpaid` |
| `fastapi` | `fastapi-getpaid` |
| `litestar` | `litestar-getpaid` |
| `backends` | All payment gateway backends |
| `frameworks` | All framework adapters |
| `all` | Everything above |
query-agent-benchmarking 0.6
A Python library for benchmarking Weaviate's Query Agent!
Requires Python: >=3.10

# Query Agent Benchmarking

This repo contains a package for benchmarking the performance of Weaviate's Query Agent.

## News 📯

[9/25] 📊 Search Mode Benchmarking is live on the [Weaviate Blog](https://weaviate.io/blog/search-mode-benchmarking).

## How to Run 🧰

Populate Weaviate with benchmark data:
```
uv run python3 scripts/populate-db.py
```

Run eval:
```
uv run python3 scripts/run-search-benchmark.py
```

See `query_agent_benchmarking/benchmark-config.yml` to change the dataset populated in your Weaviate instance, as well as ablate `hybrid-search` or `query-agent-search-only`, as well as the number of samples and concurrency parameters.