Search results

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

z3c.zcmlhook

zope-z3c.zcmlhook-1.0b1-2.lbn25.noarch

z3c.zcmlhook

zope-z3c.zcmlhook-1.0b1-2.lbn25.noarch

z3c.zcmlhook

zope-zc-1.1-1.lbn13.noarch

Zope Corp base module hierarchy

zope-zc-2.0.0-3.lbn25.noarch

Zope Corp base module hierarchy

zope-zc-2.0.0a1-2.lbn19.noarch

Zope Corp base module hierarchy

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.async-1.5.4-5.lbn19.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.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.blist-1.0b2-2.lbn19.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.