Modified items

All recently modified items, latest first.

zope-zc.zkzopeserver-1.3.2-1.lbn13.noarch: zc.zkzopeserver provides a wrapper for the zope.server WSGI runner that registers with ZooKeeper. By registering with ZooKeeper, you can let the operating system assign ports and have clients find your server by looking in ZooKeeper.

zope-zc.zkzeo-0.3.2-1.lbn13.noarch: Managing addresses, and especially ports is a drag. ZooKeeper can be used as a service registry. Servers can register themselves and clients can find services there. The zc.zkzeo package provides support for registering ZEO servers and a ZEO client storage that gets addresses from ZooKeeper.

zope-zc.zk-1.2.0-1.lbn13.noarch: The zc.zk package provides some high-level interfaces to the low-level zookeeper extension. It's not complete, in that it doesn't try, at this time, to be a complete high-level interface. Rather, it provides facilities we need to use ZooKeeper to connect services: ZODB database clients and servers HTTP-based clients and services Load balancers and HTTP application servers The current (initial) use cases are: Register a server providing a service. Get the addresses of servers providing a service. Get and set service configuration data. Model system architecture as a tree.

zope-zc.z3monitor-0.8.0-1.lbn13.noarch: The Zope 3 monitor server is a server that runs in a Zope 3 process and that provides a command-line interface to request various bits of information. It is based on zc.monitor, which is itself based on zc.ngi, so we can use the zc.ngi testing infrastructure to demonstrate it. This package provides several Zope 3 and ZODB monitoring and introspection tools that work within the zc.monitor server. These are demonstrated below. Please see the zc.monitor documentation for details on how the server works. This package also supports starting a monitor using ZConfig, and provides a default configure.zcml for registering plugins. The ZConfig setup is not demonstrated in this documentation, but the usage is simple.

zope-zc.twist-1.3.1-2.lbn13.x86_64: Twist: Talking to the ZODB in Twisted Reactor Calls The twist package contains a few functions and classes, but primarily a helper for having a deferred call on a callable persistent object, or on a method on a persistent object. This lets you have a Twisted reactor call or a Twisted deferred callback affect the ZODB. Everything can be done within the main thread, so it can be full-bore Twisted usage, without threads. There are a few important "gotchas": see the Gotchas section below for details. The main API is Partial. You can pass it a callable persistent object, a method of a persistent object, or a normal non-persistent callable, and any arguments or keyword arguments of the same sort. DO NOT use non-persistent data structures (such as lists) of persistent objects with a database connection as arguments. This is your responsibility. If nothing is persistent, the partial will not bother to get a connection, and will behave normally.

zope-zc.thread-0.1.0-1.lbn13.noarch: The thread-creation API provided by the Python threading module is annoying. :) This package provides a very simple thread-creation API that: Makes threads daemonic and allows daemonicity to be passed to the constructor. For example: zc.thread.Thread(mythreadfunc) Starts a daemonic thread named 'mythreadfunc' running mythreadfunc. Allows threads to be defined via decorators, as in: import zc.thread @zc.thread.Thread def mythread(): ... In the example above, a daemonic thread named mythread is created and started. The thread is also assigned to the variable mythread. You can control whether threads are daemonic and wether they are started by default: import zc.thread @zc.thread.Thread(daemon=False, start=False) def mythread(): ... After a thread finishes, you can get the return value of the target function from the thread's value attribute, or, if the function raises an exception, you can get the exception object from the thread's exception attribute. (This feature was inspired by the same feature in gevent greenlets.) There's also a Process constructor/decorator that works like Thread, but with multi-processing processes, and without the value and exception attributes.

zope-zc.testbrowser-1.0.0a5-3.lbn13.noarch: Programmable web browser for functional black-box testing of web applications

zope-zc.sourcefactory-0.7.0-2.lbn13.noarch: An easy way to create custom Zope 3 sources.

zope-zc.resumelb-0.7.1-1.lbn13.noarch: This package provides a load balancer for WSGI applications that sorts requests into request classes and assigns requests of a given class to the same workers. The load balancer can benefit you if you have an application that: has too much load (or is too slow) to be handled by a single process, has a working set that is too large to fit in the caches used by your process, and there is a way to classify requests so that there is little overlap in the working sets of the various classes.

zope-zc.resourcelibrary-1.3.4-2.lbn13.noarch: Post-rendering Resource Inclusion

zope-zc.relation-1.0-2.lbn13.noarch: Index intransitive and transitive n-ary relationships.

zope-zc.recipe.testrunner-1.4.0-2.lbn13.noarch: ZC Buildout recipe for creating test runners

zope-zc.recipe.egg-1.3.2-2.lbn13.noarch: Buildout Egg-Installation Recipe The egg-installation recipe installs eggs into a buildout eggs directory. It also generates scripts in a buildout bin directory with egg paths baked into them.

zope-zc.queue-1.1-2.lbn13.noarch: Persistent queues are simply queues that are optimized for persistency via the ZODB. They assume that the ZODB is using MVCC to avoid read conflicts. They attempt to resolve write conflicts so that transactions that add and remove objects simultaneously are merged, unless the transactions are trying to remove the same value from the queue. An important characteristic of these queues is that they do not expect to hold more than one reference to any given equivalent item at a time. For instance, some of the conflict resolution features will not perform desirably if it is reasonable for your application to hold two copies of the string "hello" within the same queue at once [1]. The module provides two flavors: a simple persistent queue that keeps all contained objects in one persistent object (Queue), and a persistent queue that divides up its contents into multiple composite elements (CompositeQueue). They should be equivalent in terms of API and so are mostly examined in the abstract in this document: we'll generate instances with a representative Queue factory, that could be either class. They only differ in an aspect of their write conflict resolution behavior.

zope-zc.parse_addr-1.0.0-1.lbn13.noarch: Parse network addresses of the form: HOST:PORT >>> import zc.parse_addr >>> zc.parse_addr.parse_addr('1.2.3.4:56') ('1.2.3.4', 56) It would be great if this little utility function was part of the socket module.

zope-zc.ngi-2.0.1-1.lbn13.noarch: The Network Gateway Interface provides: * the ability to test application networking code without use of sockets, threads or subprocesses * clean separation of application code and low-level networking code * a fairly simple inheritence free set of networking APIs * an event-based framework that makes it easy to handle many simultaneous connections while still supporting an imperative programming style.

zope-zc.monitor-0.3.1-1.lbn13.noarch: The monitor server is a server that provides a command-line interface to request various bits of information. The server is zc.ngi based, so we can use the zc.ngi testing infrastructure to demonstrate it.

zope-zc.mappingobject-1.0.0-1.lbn13.noarch: zc.mappingobject provides a wrapper for a mapping objects that provides both attribute and item access. >>> import zc.mappingobject >>> mapping = dict(a=1) >>> ob = zc.mappingobject.mappingobject(mapping) >>> ob.a 1 >>> ob.a = 2 >>> ob.a 2 >>> mapping {'a': 2} >>> list(ob) ['a'] >>> len(ob) 1 >>> ob['a'] = 3 >>> ob.a 3 >>> mapping {'a': 3} >>> del ob.a >>> mapping {} >>> ob.a Traceback (most recent call last): ... AttributeError: a >>> ob.b = 1 >>> mapping {'b': 1} >>> del ob['b'] >>> mapping

zope-zc.lockfile-1.0.2-1.lbn13.noarch: The zc.lockfile package provides a basic portable implementation of interprocess locks using lock files. The purpose if not specifically to lock files, but to simply provide locks with an implementation based on file-locking primitives. Of course, these locks could be used to mediate access to other files. For example, the ZODB file storage implementation uses file locks to mediate access to file-storage database files. The database files and lock file files are separate files.

zope-zc.dict-1.3b1-2.lbn13.noarch: BTree-based persistent dict-like objects (regular dict and ordered) that can be used as base classes. This is a bit of a heavyweight solution, as every zc.dict.Dict (and zc.dict.OrderedDict) is at least 3 persistent objects. Keep this in mind if you intend to create lots and lots of these. To build, run ``python bootstrap/bootstrap.py`` and then ``bin/buildout`` from this directory. A clean, non-system Python is strongly recommended. An efficient, persistent and subclassable dict PersistentDict is very inefficient if it contains more than a couple of values, and BTrees are not recommended to inherit from. This class is a simple wrapper over a BTree. It retains the efficiency of BTrees and is safe to use as a base class. Also, it implements the full Python dict interface.

« Previous 20 items Next 20 items » 1 ... 2348 2349 2350 2351 2352 2353 2354 ... 2429


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

Sections

Modified items