Modified items

All recently modified items, latest first.

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.

zope-zc.buildout-2.1.0-1.lbn13.noarch: Buildout is a project designed to solve 2 problems: 1. Application-centric assembly and deployment Assembly runs the gamut from stitching together libraries to create a running program, to production deployment configuration of applications, and associated systems and tools (e.g. run-control scripts, cron jobs, logs, service registration, etc.). Buildout might be confused with build tools like make or ant, but it is a little higher level and might invoke systems like make or ant to get it's work done. Buildout might be confused with systems like puppet or chef, but it is more application focused. Systems like puppet or chef might use buildout to get their work done. Buildout is also somewhat Python-centric, even though it can be used to assemble and deploy non-python applications. It has some special features for assembling Python programs. It's scripted with Python, unlike, say puppet or chef, which are scripted with Ruby. 2. Repeatable assembly of programs from Python software distributions Buildout puts great effort toward making program assembly a highly repeatable process, whether in a very open-ended development mode, where dependency versions aren't locked down, or in a deployment environment where dependency versions are fully specified. You should be able to check buildout into a VCS and later check it out. Two checkouts built at the same time in the same environment should always give the same result, regardless of their history. Among other things, after a buildout, all dependencies should be at the most recent version consistent with any version specifications expressed in the buildout. Buildout supports applications consisting of multiple programs, with different programs in an application free to use different versions of Python distributions. This is in contrast with a Python installation (real or virtual), where, for any given distribution, there can only be one installed. To learn more about buildout, including how to use it, see http://buildout.org/.

zope-zc.blist-1.0b2-2.lbn13.noarch: The sequence in this package has a list-like API, but stores its values in individual buckets. This means that, for small changes in large sequences, the sequence could be a big win. For instance, an ordered BTree-based container might want to store order in a sequence, so that moves only cause a bucket or two--around 50 strings or less--to be rewritten in the database, rather than the entire contents (which might be thousands of strings, for instance). If the sequence is most often completely rearranged, the complexity of the code in this package is not desirable. It only makes sense if changes most frequently are fairly small. One downside is that reading and writing is more work than with a normal list. If this were to actually gain traction, perhaps writing some or all of it in C would be helpful. However, it still seems pretty snappy. Another downside is the corollary of the bucket advantage listed initially: with more persistent objects, iterating over it will fill a lot of ZODB's object cache (which is based on the number of objects cached, rather than the size). Consider specifying a big object cache if you are using these to store a lot of data and are frequently iterating or changing. These sequences return slices as iterators, and add some helpful iteration methods. It adds a copy method that provides a cheap copy of the blist that shares all buckets and indexes until a write happens, at which point it copies and mutates the affected indexes and buckets. We'll take a glance at how these differences work, and then describe the implementation's basic mechanism, and close with a brief discussion of performance characteristics in the abstract.

zope-zc.async-1.5.4-4.lbn13.noarch: The zc.async package provides an easy-to-use Python tool that schedules work persistently and reliably across multiple processes and machines. For instance... * Web apps: maybe your web application lets users request the creation of a large PDF, or some other expensive task. * Postponed work: maybe you have a job that needs to be done at a certain time, not right now. * Parallel processing: maybe you have a long-running problem that can be made to complete faster by splitting it up into discrete parts, each performed in parallel, across multiple machines. * Serial processing: maybe you want to decompose and serialize a job. High-level features include the following: * easy to use; * flexible configuration, changeable dynamically in production; * reliable; * supports high availability; * good debugging tools; * well-tested; and * friendly to testing. While developed as part of the Zope project, zc.async can be used stand-alone. How does it work? The system uses the Zope Object Database (ZODB), a transactional, pickle-based Python object database, for communication and coordination among participating processes. zc.async participants can each run in their own process, or share a process (run in threads) with other code. The Twisted framework supplies some code (failures and reactor implementations, primarily) and some concepts to the package.

zope-zc-1.1-1.lbn13.noarch: Zope Corp base module hierarchy

zope-zLOG-2.11.1-2.lbn13.noarch: A general logging facility

zope-zExceptions-2.13.0-2.lbn13.noarch: zExceptions contains common exceptions used in Zope2.

zope-z3c.zcmlhook-1.0b1-2.lbn13.noarch: z3c.zcmlhook

zope-z3c.widgets.flashupload-1.0c1-4.lbn13.noarch

« Previous 20 items Next 20 items » 1 ... 2279 2280 2281 2282 2283 2284 2285 ... 2359


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

Sections

Modified items