-
python2-zope.copy-4.2-1.lbn19.noarch
zope.copy :target:
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
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.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
python2-zope.deprecation-4.4.0-10.lbn25.noarch
When we started working on Zope 3.1, we noticed that the hardest part of the
development process was to ensure backward-compatibility and correctly mark
deprecated modules, classes, functions, methods and properties. This package
provides a simple function called 'deprecated(names, reason)' to deprecate
the previously mentioned Python objects.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
python2-zope.event-4.4-1.lbn25.noarch
The ``zope.event`` package provides a simple event system. It provides:
- An event publishing system
- A very simple event-dispatching system on which more sophisticated
event dispatching systems can be built. For example, a type-based
event dispatching system that builds on ``zope.event`` can be found in
``zope.component``
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
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.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
python2-zope.i18nmessageid-4.3.1-1.lbn25.x86_64
To translate any text, we must be able to discover the source domain
of the text. A source domain is an identifier that identifies a
project that produces program source strings. Source strings occur as
literals in python programs, text in templates, and some text in XML
data. The project implies a source language and an application context.
We can think of a source domain as a collection of messages and
associated translation strings.
We often need to create unicode strings that will be displayed by
separate views. The view cannot translate the string without knowing
its source domain. A string or unicode literal carries no domain
information, therefore we use messages. Messages are unicode strings
which carry a translation source domain and possibly a default
translation. They are created by a message factory. The message factory
is created by calling MessageFactory with the source domain.
This package provides facilities for delaring such messages within
program source text; translation of the messages is the responsiblitiy of
the 'zope.i18n' package.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
python2-zope.interface-4.6.0-10.lbn25.x86_64
This package provides an implementation of "object interfaces" for Python. Interfaces
are a mechanism for labeling objects as conforming to a given API or contract. So, this
package can be considered as implementation of the Design By Contract methodology
support in Python.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
python2-zope.proxy-4.3.1-10.lbn25.x86_64
Proxies are special objects which serve as mostly-transparent
wrappers around another object, intervening in the apparent behavior of
the wrapped object only when necessary to apply the policy (e.g., access
checking, location brokering, etc.) for which the proxy is responsible.
Editorial note:
Unfortunately, we don't have separate documentation for zope.proxy
at this time. This is a shame because they are generically useful.
We are publishing this release without documentation mainly because
it is a dependency of other releases.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
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.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
python2-zope.testing-4.7-1.lbn25.noarch
This package provides a number of testing frameworks.
cleanup
Provides a mixin class for cleaning up after tests that make global changes.
formparser
An HTML parser that extracts form information.
Python 2 only
This is intended to support functional tests that need to extract information from HTML forms returned by the publisher.
See formparser.txt.
loggingsupport
Support for testing logging code
If you want to test that your code generates proper log output, you can create and install a handler that collects output.
loghandler
Logging handler for tests that check logging output.
module
Lets a doctest pretend to be a Python module.
See module.txt.
renormalizing
Regular expression pattern normalizing output checker. Useful for doctests.
server
Provides a simple HTTP server compatible with the zope.app.testing functional testing API. Lets you interactively play with the system under test. Helpful in debugging functional doctest failures.
Python 2 only
setupstack
A simple framework for automating doctest set-up and tear-down. See setupstack.txt.
wait
A small utility for dealing with timing non-determinism See wait.txt.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
