Modified items

All recently modified items, latest first.

python2-importlib-metadata-2.0.0-1.lbn25.noarch: importlib_metadata is a library which provides an API for accessing an installed package’s metadata, such as its entry points or its top-level name. This functionality intends to replace most uses of pkg_resources entry point API and metadata API. Along with importlib.resources in Python 3.7 and newer (backported as importlib_resources for older versions of Python), this can eliminate the need to use the older and less efficient pkg_resources package.

python2-formencode-1.3.1-2.lbn25.py37.noarch: FormEncode validates and converts nested structures. It allows for a. declarative form of defining the validation, and decoupled processes. for filling and generating forms. This package contains the python2 version of the module.

python2-devel-2.7.17-1.lbn25.x86_64: This package contains libraries and header files used to build applications with and native libraries for Python 2

python2-apptools-4.4.0-8.lbn25.py37.noarch: The AppTools project includes a set of packages that Enthought has found useful in creating a number of applications. They implement functionality that is commonly needed by many applications * enthought.appscripting: Framework for scripting applications. * enthought.help: Provides a plugin for displaying documents and examples and running demos in Envisage Workbench applications. * enthought.io: Provides an abstraction for files and folders in a file system. * enthought.naming: Manages naming contexts, supporting non-string data types and scoped preferences * enthought.permissions: Supports limiting access to parts of an application unless the user is appropriately authorised (not full-blown security). and many more.

python2-appdirs-1.4.3-7.lbn25.py37.noarch: A small Python 2 module for determining appropriate " + " platform-specific directories, e.g. a "user data dir".

python2-SOAPpy-0.12.22-1.lbn25.py37.noarch: SOAPpy provides tools for building SOAP clients and servers. For more information see SOAPpy Simple to use SOAP library for Python .. contents::Disclaimer Please use suds < rather than SOAPpy. SOAPpy is old and clamsy.Credits Companies |makinacom|_ * Planet Makina Corpus <>_ * Contact us <mailto:python@makinacorpus.org>_.. |makinaco.. _makinacom: Cayce Ullman <c_ullman@yahoo.com> Brian ...

python2-RestrictedPython-5.1-1.lbn25.noarch: RestrictedPython provides a restricted execution environment for Python, e.g. for running untrusted code.

python2-BTrees-4.7.2-1.lbn25.x86_64: This package contains a set of persistent object containers built around a modified BTree data structure. The trees are optimized for use inside ZODB's "optimistic concurrency" paradigm, and include explicit resolution of conflicts detected by that mechanism.

python2-AuthEncoding-4.1-1.lbn25.noarch: AuthEncoding is a framework for handling LDAP style password hashes.It is used in Zope2 but does not depend on any other Zope package.Changelog 4.0.0 (20150930) Supporting Python 3.3 up to 3.5 and PyPy2. Added SHA256DigestScheme. 3.0.0 (20150928) Extracted from AccessControl 3.0.11

python2-zope.untrustedpython-4.0.0-1.lbn25.noarch: Untrusted python library

python2-zope.testrunner-5.1-1.lbn25.noarch: zope.testrunner uses buildout. To start, run python bootstrap.py. It will create a number of directories and the bin/buildout script. Next, run bin/buildout. It will create a test script for you. Now, run bin/test to run the zope.testrunner test suite.

python2-zope.testbrowser-5.3.1-1.lbn25.noarch: zope.testbrowser README zope.testbrowser provides an easy-to-use programmable web browser with special focus on testing. It is used in Zope, but it's not Zope

python2-zope.security-4.3.1-1.lbn25.x86_64: The Security framework provides a generic mechanism to implement security policies on Python objects. This introduction provides a tutorial of the framework explaining concepts, design, and going through sample usage from the perspective of a Python programmer using the framework outside of Zope.

python2-zope.location-4.2-1.lbn25.noarch: In Zope3, location are special objects that has a structural location.

python2-zope.lifecycleevent-4.3-2.lbn25.noarch: ================= Life-cycle events ================= In Zope 3, events are used by components to inform each other about relevant new objects and object modifications. To keep all subscribers up to date it is indispensable that the life cycle of an object is accompanied by various events. >>> from zope.event import notify >>> from zope.lifecycleevent import ObjectCreatedEvent, ObjectModifiedEvent >>> class Sample(object) : ... "Test class" >>> obj = Sample() >>> notify(ObjectCreatedEvent(obj)) >>> obj.modified = True >>> notify(ObjectModifiedEvent(obj)) Zope 3's Dublin Core Metadata for instance, rely on the bare ObjectCreatedEvent and ObjectModifiedEvent to record creation and modification times. Other event consumers like catalogs and caches may need more information to update themselves in an efficient manner. The necessary information can be provided as optional modification descriptions of the ObjectModifiedEvent. Some examples: >>> from zope.interface import Interface, Attribute, implements >>> class IFile(Interface): ... data = Attribute("Data") ... >>> class File(object): ... implements(IFile) ... >>> file = File() >>> file.data = "123" >>> notify(ObjectModifiedEvent(obj, IFile)) This says that we modified something via IFile. Note that an interface is an acceptable description. In fact, we might allow pretty much anything as a description and it depends on your needs what kind of descriptions you use. In the following we use an IAttributes description to describe in more detail which parts of an object where modified : >>> file.data = "456" >>> from zope.dublincore.interfaces import IZopeDublinCore >>> from zope.interface import directlyProvides >>> from zope.annotation.interfaces import IAttributeAnnotatable >>> directlyProvides(file, IAttributeAnnotatable) >>> IZopeDublinCore(file).title = u"New title" >>> IZopeDublinCore(file).title = u"New description" >>> from zope.lifecycleevent import Attributes >>> event = ObjectModifiedEvent( ... obj, ... Attributes(IFile, 'data'), ... Attributes(IZopeDublinCore, 'title', 'description'), ... ) >>> notify(event) This says we modified the file data and the DC title and description.

python2-zope.hookable-4.2.0-10.lbn25.x86_64: Hookable object support. Support the efficient creation of hookable objects, which are callable objects that are meant to be replaced by other callables, at least optionally. The idea is you create a function that does some default thing and make it hookable. Later, someone can modify what it does by calling its sethook method and changing its implementation. All users of the function, including those that imported it, will see the change.

python2-zope.deferredimport-4.3-10.lbn25.noarch: Often, especially for package modules, you want to import names for convenience, but not actually perform the imports until necessary. The zope.deferredimport package provided facilities for defining names in modules that will be imported from somewhere else when used. You can also cause deprecation warnings to be issued when a variable is used.

python2-zope.copy-4.2-1.lbn25.noarch: This package provides a pluggable way to copy persistent objects. It was once extracted from the zc.copy package to contain much less dependencies. In fact, we only depend on zope.interface to provide pluggability. The package provides a clone function that does the object cloning and the copy wrapper that sets __parent__ and __name__ attributes of object's copy to None. This is useful, when working with Zope's located objects (see zope.location package). The copy function actually calls the clone function so we'll use the first one in the examples below. We'll also look a bit at their differences in the end of this document. The clone function (and thus the copy function that wraps it) uses pickling to copy the object and all its subobjects recursively. As each object and subobject is pickled, the function tries to adapt it to zope.copy.interfaces.ICopyHook. If a copy hook is found, the recursive copy is halted. The hook is called with two values: the main, top-level object that is being copied; and a callable that supports registering functions to be called after the copy is made. The copy hook should return the exact object or subobject that should be used at this point in the copy, or raise zope.copy.interfaces.ResumeCopy exception to resume copying the object or subobject recursively after all. Note that we use zope's component architecture provided by the zope.component package in this document, but the zope.copy package itself doesn't use or depend on it, so you can provide another adaptation mechanism as described in zope.interface's adapter documentation.

python2-zope.configuration-4.3.0-1.lbn25.noarch: The zope configuration system provides an extensible system for supporting various kinds of configurations. It is based on the idea of configuration directives. Users of the configuration system provide configuration directives in some language that express configuration choices. The intent is that the language be pluggable. An XML language is provided by default.

python2-zope.component-4.6.2-10.lbn25.noarch: Zope component architecture

« Previous 20 items Next 20 items » 1 ... 678 679 680 681 682 683 684 ... 2449


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

Sections

Modified items