Modified items

All recently modified items, latest first.

python3-pymdown-extensions-10.2-1.lbn36.noarch: PyMdown Extensions Extensions for Python Markdown. Documentation Extension documentation is found here: https:/facelessuser.github.io/pymdown-extensions/. License License is MIT except for a few exceptions. See LICENSE for more info.

python3-lazy-loader-0.4-4.lbn36.noarch: lazy-loader makes it easy to load subpackages and functions on demand. Motivation: • Allow subpackages to be made visible to users without incurring import costs. • Allow external libraries to be imported only when used, improving import times.

python3-proteus-7.6.1-1.lbn36.noarch: A client library to access Tryton's internal objects like Models and Wizards.

python3-pillow-heif-0.10.0-1.lbn36.x86_64: pillow-heif Python bindings to libheif for working with HEIF images and plugin for Pillow. Features: Decoding of 8, 10, 12 bit HEIC files. Encoding of 8, 10, 12 bit HEIC files. EXIF, XMP, IPTC read & write support. Support of multiple images in one file and a PrimaryImage attribute. Adding & removing thumbnails. Reading of Depth Images. (beta) Reading of Auxiliary Images by johncf Adding HEIF support to Pillow in one line of code as a plugin. Note: Here is a light version pi-heif of this project without encoding capabilities. Example of use as a Pillow plugin from PIL import Image from pillow_heif import register_heif_opener register_heif_opener() im = Image.open("image.heic") # do whatever need with a Pillow image im = im.rotate(13) im.save(f"rotated_image.heic", quality=90) 16 bit PNG to 10 bit HEIF using OpenCV import cv2 import pillow_heif cv_img = cv2.imread("16bit_with_alpha.png", cv2.IMREAD_UNC

python3-laces-0.1.2-1.lbn36.noarch: Laces 👟 Django components that know how to render themselves. Laces components provide a simple way to combine data (in the form of Python objects) with the Django templates that are meant to render that data. The components can then be simply rendered in any other template using the {% component %} template tag. That parent template does not need to know anything about the component's template or data. No need to receive, filter, restructure or pass any data to the component's template. Just let the component render itself. Template and data are tied together (sorry, not sorry 😅) in the component, and they can be passed around together. This becomes especially useful when components are nested — it allows us to avoid building the same nested structure twice (once in the data and again in the templates). Working with objects that know how to render themselves as HTML elements is a common pattern found in complex Django applications, such as the Wagtail admin interface. The Wagtail

python3-gdal-3.8.1-1.lbn36.x86_64: The GDAL Python 3 modules provide support to handle multiple GIS file formats.

python3-draftjs-exporter-5.1.0-1.lbn36.noarch: draftjs-exporter

python3-django-treebeard-4.7.1-1.lbn36.noarch: django-treebeard django-treebeard is a library that implements efficient tree implementations for the Django Web Framework 2.2 and later. It is written by Gustavo Picón and licensed under the Apache License 2.0. Status Features django-treebeard is: Flexible: Includes 3 different tree implementations with the same API: Adjacency List Materialized Path Nested Sets Fast: Optimized non-naive tree operations Easy: Uses Django Model Inheritance with abstract classes to define your own models. Clean: Testable and well tested code base. Code/branch test coverage is above 96%. You can find the documentation in http:/django-treebeard.readthedocs.io/en/latest/ Supported versions django-treebeard officially supports Django 3.2, 4.1, 4.2, 5.0 Python 3.8 - 3.12 PostgreSQL, MySQL, MSSQL, SQLite database back-ends.

python3-django-tasks-0.8.1-1.lbn36.noarch: Django Tasks An implementation and backport of background workers and tasks in Django, as defined in DEP 0014. Warning: This package is under active development, and breaking changes may be released at any time. Be sure to pin to specific versions if you're using this package in a production environment. Installation python -m pip install django-tasks The first step is to add django_tasks to your INSTALLED_APPS. INSTALLED_APPS = [ "django_tasks", ] Secondly, you'll need to configure a backend. This connects the tasks to whatever is going to execute them. If omitted, the following configuration is used: TASKS = { "default": { "BACKEND": "django_tasks.backends.immediate.ImmediateBackend" } } A few backends are included by default: django_tasks.backends.dummy.DummyBackend: Don't execute the tasks, just store them. This is especially useful for testing. django_tasks.backends.immediate.ImmediateBackend: Execute the task immediately in the current threa

python3-django-stubs-ext-5.2.2-1.lbn36.noarch: Extensions and monkey-patching for django-stubs This package contains extensions and monkey-patching functions for the django-stubs package. Certain features of django-stubs (i.e. generic django classes that don't define the __class_getitem__ method) require runtime monkey-patching, which can't be done with type stubs. These extensions were split into a separate package so library consumers don't need mypy as a runtime dependency (#526). Installation pip install django-stubs-ext Usage In your Django application, use the following code: import django_stubs_ext django_stubs_ext.monkeypatch() This only needs to be called once, so the call to monkeypatch should be placed in your top-level settings. Real-life example can be found here. Version compatibility Since django-stubs supports multiple Django versions, this package takes care to only monkey-patch the features needed by your django version, and decides which features to patch at runtime. This is completely safe, as (currently) w

python3-django-permissionedforms-0.1-1.lbn36.noarch: django-permissionedforms django-permissionedforms is an extension to Django's forms framework, allowing you to define forms where certain fields are shown or omitted according to the user's permissions. Installation Run: pip install django-permissionedforms Usage To add permission rules to a basic Django form, subclass permissionedforms.PermissionedForm in place of django.forms.Form and add an inner Meta class: from permissionedforms import PermissionedForm class PersonForm(PermissionedForm): first_name = forms.CharField() last_name = forms.CharField() class Meta: field_permissions = { 'last_name': 'myapp.change_last_name' } field_permissions is a dict, mapping field names to permission codenames. For each field listed, that field will only be included in the final form if the user has the specified permission, as defined by the user.has_perm() method. See Django's documentation on custom permissions and programmatically creating permissions f

python3-django-modelcluster-6.4-1.lbn36.noarch: If you had a data model like this: class Band(models.Model): name = models.CharField(max_length=255) class BandMember(models.Model): band = models.ForeignKey('Band', related_name='members', on_delete=models.CASCADE) name = models.CharField(max_length=255) wouldn’t it be nice if you could construct bundles of objects like this, independently of the database: beatles = Band(name='The Beatles') beatles.members = [ BandMember(name='John Lennon'), BandMember(name='Paul McCartney'), ] Unfortunately, you can’t. Objects need to exist in the database for foreign key relations to work: IntegrityError: null value in column "band_id" violates not-null constraint But what if you could? There are all sorts of scenarios where you might want to work with a ‘cluster’ of related objects, without necessarily holding them in the database: maybe you want to render a preview of the data the user has just submitted, prior to saving. Maybe you need to construct a tree of things, serialize

python3-factory-boy-3.2.1-2.fc36.noarch: factory_boy is a fixtures replacement based on thoughtbot's factory_girl <http://github.com/thoughtbot/factory_girl>. Its features include: - Straightforward syntax - Support for multiple build strategies (saved/unsaved instances, attribute dicts, stubbed objects) - Powerful helpers for common cases (sequences, sub-factories, reverse dependencies, circular factories, ...) - Multiple factories per class support, including inheritance - Support for various ORMs (currently Django, Mogo, SQLAlchemy)

python3-plone-base-1.1.3-1.lbn36.noarch: plone.base This package is the base package of the CMS Plone <>_. It contains only interface contracts and basic features and utilities. It was created to be able to maintain a clean dependency graph (PLIP 3395 < details this package contains:interfaces (package) All zope.interface based contracts for the Plone core packages. In Plone 5 and below this was at...

python3-argon2-cffi-bindings-21.2.0-9.lbn36.x86_64: This package provides low-level CFFI bindings to the Argon2 password hashing algorithm. If you want to hash passwords in an application, this package is not for you. Have a look at argon2-cffi with its high-level abstractions! These bindings have been extracted from argon2-cffi and it remains its main consumer. However, they may be used by other packages that want to use the Argon2 library without dealing with C-related complexities.

python3-argon2-cffi-23.1.0-4.lbn36.noarch: CFFI-based Argon2 Bindings for Python.

python3-orderedmultidict-1.0.1-1.lbn36.noarch: A multivalue dictionary is a dictionary that can store multiple values for the same key. An ordered multivalue dictionary is a multivalue dictionary that retains the order of insertions and deletions.omdict retains method parity with dict.Information and documentation at

python3-ordereddict-1.1-1.lbn36.noarch: Drop-in substitute for Py2.7's new collections.OrderedDict. The recipe has big- oh performance that matches regular dictionaries (amortized O(1) insertion/deletion/lookup and O(n) iteration/repr/copy/equality_testing). Originally based on http://code.activestate.com/recipes/576693/

python3-ordered-set-4.1.0-14.lbn36.noarch: An OrderedSet is a custom MutableSet that remembers its order, so that every entry has an index that can be looked up. Python 3 version.

python3-factory-trytond-1.0.0-1.lbn36.noarch: Factory-trytond Factory-trytond is a factory_boy extension developed to work with Tryton ERP. We can create our own ERP's model factories to do some testing or to populate our databases with some sample data. How does it work? Steps to use Factory-trytond: Inherit the base factory class. Define the meta model the factory will construct. Define the default declarations of the factory. Note that the meta model can be a trytond pool model name. Here's a factory example with Tryton's model User: import factory import factory_trytond class UserFactory(factory_trytond.TrytonFactory): class Meta: model = 'res.user' name = factory.Faker('name') login = factory.Faker('user_name') user = UserFactory.build() user.save() # it is a standard Tryton object as would be returned by Tryton's object pool

« Previous 20 items Next 20 items » 1 ... 117 118 119 120 121 122 123 ... 2448


	Copyright © 2000-2025 Corporation of Balclutha Inc. All rights reserved.

Sections

Modified items