semvec/pypi-packages huggingface dataset:
photo-to-excel 1.0.0
Covert your photos to Excel file
Requires Python: <3.12,>=3.9.6

# photo_to_excel
This code allows you to convert your photo to excel format. 

## The Photo-to-Excel converter works in the following way:
1. The photo you specify is first pixelated into 64x64 pixel format. (or any other size you specify)
2. Colours are extracted from each of the pixels.
3. Excel workbook is created, and the extracted colours are used to colour a grid of 64x64 cells in excel. 

<p align="center">
  <img src="tests/test_photos/output_example.png"  width="600">
</p>

## Instructions:
Create a `PhotoToExcel` object with the image path as the inpput. Then call the `rgb_to_excel` method to convert the photo to excel. The xlsx file will be saved in the same direcory and have the same name as the original image provided.

### Example: 
If you wanted to comemorate the Bush shoeing incident by converting the photo to excel, you would do the following:
```python
from photo_to_excel import PhotoToExcel

test_img_path = "tests/test_photos/bush_shoeing_incident.jpg"

test_img = PhotoToExcel(test_img_path, save_pixelated=True)
test_img.rgb_to_excel()
```

By selecting `save_pixelated=True`, you can save the pixelated image that is used in the process of creating the excel file.

And here is your finished result:

<p align="center">
  <img src="tests/test_photos/output_example2.png"  width="600">
</p>

Future releases will include adjustment for image dimention ratio, for now, you either have to calculate if yourself or use the default 64x64 pixel format and your photos will be a bit distorted. 

## Installation
You can install the package using pip:
```bash
pip install photo-to-excel
```

## Issues
If you encounter any issues, please let me know by creating an issue on this repository. Sugestions are welcome too.

## The purpose of the project:
You might ask 'why would I convert my photos to Excel?'. My response is: 'why not?'.
construct-additional-obelisks 0.3.1
The one Obelisk client to rule them all
Requires Python: >=3.9

# Construct Additional Obelisks

After years of copy-pasting and modifying Obelisk client implementations all over,
we've had enough of hearing "construct additional obelisks".
Thus, we have decided to build the one client to rule them all.

## Usage

Take your pick of asynchronous or sync,
import the relevant Producer or Consumer and go crazy.
There is explicitly minimal documentation on actual filter values,
read the [Obelisk docs](https://obelisk.docs.apiary.io/) for that.

Please never copy the repo into your own project,
rather use `pip install construct-addditional-obelisks`.

### Retry strategies

Construct Additional Obelisks provides first class support for retry behaviours.
These are defined in `strategies/retry.py`,
we provide `NoRetryStrategy`, `ImmediateRetryStrategy`, 
and `ExponentialBackoffRetryStrategy.`
These do exactly what it says on the tin,
when provided in the constructor of your producer, consumer or client,
they will cause the client to retry requests according to the strategy
whenever the response status is not in the 2XX range.

The default strategy is no retry,
we do recommend setting at least some form of retry
as the token validity behaviour sometimes encounters edge cases.

### Async and Sync support

The library has an async and blocking edition.
The async edition is contained in the module `asynchronous` 
due to `async` being a reserved keyword and invalid package name,
synchronous can be found in `sync`. 
The `sync` edition is simply a wrapper around `asynchronous`, 
maintaining an own event loop.

### HFS and Classic support

All constructors take an optional `kind` argument,
set this to the appropriate variety for you.

There is no special handling for HFS userId / patientId fields as those are never
directly touched by the library.
The only exception is that `Datapoint` has explicit support for userId
and allows extra fields to provide naive support for other field names.

## Building and Docs

`uv` is used to manage this project.
Tests can be run using `uv run pytest`, building and deployment are handled by `uv build` and `uv publish`.

Documentation uses the classic `sphinx` setup, with numpydoc for their lovely layouts and conventions.
Building is as follows:

``` sh
# uv run sphinx-build -M html docs/source/ docs/build/
```

## Credits

Base implementation originally by Pieter Moens <Pieter.Moens@ugent.be>,
modified by Kyana Bosschaerts <Kyana.Bosschaerts@ugent.be>
and finally consolidated by Stef Pletinck <Stef.Pletinck@ugent.be>.
django-managerie 0.6.1
Expose Django management commands in the admin
Requires Python: >=3.10

[![pypi](https://img.shields.io/pypi/v/django-managerie.svg)](https://pypi.python.org/pypi/django-managerie/)

# django-managerie

:lightbulb: Expose Django management commands as forms in the admin, like so:

![Screenshot](./screenshot.png)

## Requirements

- Django 4.2+ (this project tracks Django's end-of-life policy)
- Python 3.10+

## Installation

Install the package as you would any Python package, then add `django_managerie` to your `INSTALLED_APPS`.

### Automatic patching

This is the easiest way to get up and running.
You can have Managerie patch the admin site's dashboard view to include pseudo-models with the name "Commands"
for all apps where management commands are available, and while it's at it, it'll also include URLs of its own.

Hook up Managerie to your admin site (e.g. in `urls.py`, where you have `admin.autodiscover()`), like so:

```python
from django.contrib import admin
from django_managerie import Managerie
# ...
managerie = Managerie(admin_site=admin.site)
managerie.patch()
```

### No patching

This is likely safer (in the presence of slightly less tolerant 3rd party apps that mangle the admin, for instance),
but you can't enjoy the luxury of the Commands buttons in the admin dashboard.

```python
from django.contrib import admin
from django.conf.urls import include, url
from django_managerie import Managerie
# ...
managerie = Managerie(admin_site=admin.site)
# ...
urlpatterns = [
    # ...
    # ... url(r'^admin/', include(admin.site.urls)), ...
    url(r'^admin/', include(managerie.urls)),  # Add this!
]
```

## Usage

If you allowed Managerie to patch your admin, superusers can now see `Commands` "objects" in the admin dashboard.
If you didn't patch the admin, you can access a list of all commands through `/admin/managerie/`
(or wherever your admin is mounted).

If you click through to a command, you'll see the arguments of the command laid out as a form.
Fill the form, then hit "Execute Command", and you're done! :sparkles:

### Accessing the Django request from a managerie'd command

Managerie sets `_managerie_request` on the command instance to the current Django request.
You can use it to access the request, for instance, to get the current user.

### Accessing standard input

By default, Managerie will patch `sys.stdin` to be an empty stream.
If you need to read from standard input (e.g. long input),
set the `managerie_accepts_stdin` attribute on your command class to `True`.

This will cause Managerie to add a text-area to the form, which will be passed to the command as standard input.

Note that `sys.stdin.buffer` (binary mode) is not supported.

## TODO

- More `argparse` action support
- Multiple-argument support (`nargs`)