sorted by: recent | see :
popular
Content Tagged with Python + zope
icalendar 2.0.1 released
Restarting zope for plone development
Setuptools distribution_links Considered Harmful
site-packages is too implicit
rm -rf PasteDeploy-1.3.1-py2.4.egg rm -rf Routes-1.7.3-py2.4.egg rm -rf WebHelpers-0.3.2-py2.4.egg rm -rf Beaker-0.9.5-py2.4.egg rm -rf FormEncode-0.7.1-py2.4.egg rm -rf decorator-2.2.0-py2.4.egg rm -rf nose-0.10.3-py2.4.egg rm -rf Mako-0.1.8-py2.4.egg rm -rf WebOb-0.9.2-py2.4.egg rm -rf simplejson-1.7.1-py2.4.egg rm -rf Babel-0.9.2-py2.4.egg rm -rf Pylons-0.9.6.2-py2.4.egg rm -rf Genshi-0.5-py2.4-macosx-10.5-i386.egg rm -rf SQLAlchemy-0.5.0beta1-py2.4.egg rm -rf ToscaWidgets-0.9.2-py2.4.egg rm -rf TurboGears2.egg-link rm -rf Paver-0.8.1-py2.4.egg
import sys sys.path[0:0] = [ '/Users/kteague/buildouts/shared/eggs/PasteDeploy-1.3.1-py2.4.egg', '/Users/kteague/buildouts/shared/eggs/Routes-1.7.3-py2.4.egg', ]
/Users/kteague/buildouts/shared/eggs/Routes-1.7.3-py2.4.egg /Users/kteague/buildouts/shared/eggs/Routes-1.9-py2.4.egg
Neither of these are active on your Python path, but you can pop them onto your sys.path and import the version you require as desired. This approach means that your application declares what versions of which packages it wants to use
import sys sys.require('PasteDeploy','1.3.1')
This is similar to the approach that Ruby Gems takes. I'm not sure if it's better than the buildout approach, since this approach embeds your library dependency information in the source code instead of having that information available in an easily parsed buildout.cfg or setup.py file.
Ten Years of Python Web Programming
A misconception about the ZODB
class Source(Persistent): def __init__(self, ref): self.ref = ref
class Target(Persistent): def __init__(self, message): self.message = message
>>> c = Target("First message") >>> c.message 'First message' >>> a = Source(c) >>> b = Source(c) >>> c.message = "Second message" >>> a.ref.message 'Second message' >>> b.ref.message 'Second message'
from ZODB import FileStorage, DB from persistent import Persistent import transaction
class Source(Persistent): def __init__(self, ref): self.ref = ref
class Target(Persistent): def __init__(self, message): self.message = message
def getroot(): # open the database storage = FileStorage.FileStorage('/tmp/mystorage.fs') db = DB(storage) conn = db.open() dbroot = conn.root() return dbroot
def main(): dbroot = getroot()
if 'a' not in dbroot: print "Filling database" fill_database(dbroot) else: print "Reusing existing database" # reset to first message dbroot['c'].message = 'First message'
a = dbroot['a'] b = dbroot['b'] c = dbroot['c']
print "message through a:", a.ref.message print "message through b:", b.ref.message print "ref is the same:", a.ref is b.ref print "ref is indeed c:", a.ref is c print "changing message c to: Second message" c.message = 'Second message' print "message through a:", a.ref.message print "message through b:", b.ref.message
# commit any changes to the database transaction.commit()
def fill_database(dbroot): dbroot['c'] = c = Target('First message') dbroot['a'] = a = Source(c) dbroot['b'] = b = Source(c)
if __name__ == '__main__': main()
was created by Brandon Rhodes and Noah Gift for IBM developerworks.
My Experience Writing a Build System
Python 3 will make you a better programmer.
for i in len(d.keys()): key = d.keys()[i]
Zope.org
Zope3 on App Engine - Redux
Initial Request Zope Load Time -0.588495016098 Subsequent Request Zope Load Time -0.000102996826172
Zope3 on Google App Engine
functionally, it isn’t a typical zope environment in any sense, its a collection as an application using zope egg components. there isn’t any zodb, but thats not really an issue for most of the zope core components. potentially though existing components could be used with some sort of modification to use null/dummy implementations as was done for zope.deferredimport.
Google app engine maintains a hard limit on the number of files in an application. See
$ find . -type f | wc -l 4980
$ ls -al | wc-l 139