Browsing projects by Tag(s)

Select a tag to browse associated projects and drill deeper into the tag cloud.

Showing page 1 of 1

Eventlet is a networking library written in Python. It achieves high scalability by using non-blocking io while at the same time retaining high programmer usability by using coroutines to make the non-blocking io operations appear blocking at the source code level.

4.75
   
  0 reviews  |  11 users  |  17,383 lines of code  |  14 current contributors  |  Analyzed 4 months ago
 
 

The uWSGI project aims at developing a full stack for building (and hosting) clustered/distributed network applications. Mainly targeted at the web and its standards, it has been successfully used in a lot of different contexts. Thanks to its pluggable architecture it can be extended without ... [More] limits to support more platforms and languages. Currently, you can write plugins in C, C++ and Objective-C. The “WSGI” part in the name is a tribute to the namesake Python standard, as it has been the first developed plugin for the project. Versatility, performance, low-resource usage and reliability are the strengths of the project (and the only rules followed). [Less]

5.0
 
  0 reviews  |  10 users  |  56,252 lines of code  |  54 current contributors  |  Analyzed 8 months ago
 
 

Loggerhead is a web viewer for projects in bazaar. It can be used to navigate a branch history, annotate files, view patches, perform searches, etc. It's originally based on bazaar-webserve, which is itself based on hgweb for Mercurial.

4.75
   
  0 reviews  |  7 users  |  46,136 lines of code  |  4 current contributors  |  Analyzed 8 days ago
 
 

Coroutines in python using enhanced generators from python 2.5

5.0
 
  0 reviews  |  5 users  |  4,494 lines of code  |  0 current contributors  |  Analyzed 8 days ago
 
 

Python WSGI HTTP server on libev.

4.0
   
  0 reviews  |  1 user  |  3,360 lines of code  |  0 current contributors  |  Analyzed 4 days ago
 
 

httpy is middleware to smooth over WSGI's most glaring warts. It barely hides start_response/return under a Response object. WSGI is a low-level web programming standard for Python.

0
 
  0 reviews  |  0 users  |  313 lines of code  |  0 current contributors  |  Analyzed 2 days ago
 
 

This project collects various one-off modules.

0
 
  0 reviews  |  0 users  |  937 lines of code  |  0 current contributors  |  Analyzed about 8 hours ago
 
 

IntroductionKineta is a non-SQL-based relational database which is designed to stay out of your way and make your life easier. For much more information on what Kineta is all about, see the WhyKineta wiki page. To start using Kineta, see GettingStarted. Reference Documentation is now also ... [More] available. Feature OverviewWritten in Python, distributed as a normal Python package. "Do what I want" semantics: To create a table, insert data. To add a column, update data. To remove a column, update all its values to 'None'. Put any data type in any column. Querying a non-existant column returns None. Querying a non-existant table returns 0 rows. No more schema migration problems! Automatically creates indexes based on past queries, drops indexes when they are no longer in use. Indexes can also be manually created/frozen. Robust relational query engine with joins/aggregate functions. Optimized to return large result sets from queries. Queries are specified as Python dictionaries/lists or JSON; easily manipulate queries as data structures. No reserved words, disallowed characters, or quoting issues. Any unicode string can be a table or column name. Can be embedded in Python apps or hosted in any WSGI-compliant web server. Communicate via open standards: JSON over HTTP. Simple, clean, secure: User-friendly API. No embedded programming languages; keep your data in your database and your code in one place. StatusCurrently Kineta is not ready for general use. The code is coming together well and is very usable, but a couple major things still need to be implemented. Thanks for your interest and check back here for updates. [Less]

0
 
  0 reviews  |  0 users  |  5,096 lines of code  |  0 current contributors  |  Analyzed 3 days ago
 
 

IntroductionTesting a WSGI application normally involves starting a server at a local host and port, then pointing your test code to that address. Instead, this library lets you intercept calls to any specific host/port combination and redirect them into a WSGI application importable by your test ... [More] program. Thus, you can avoid spawning multiple processes or threads to test your Web app. How Does It Work?wsgi_intercept works by replacing httplib.HTTPConnection with a subclass, wsgi_intercept.WSGI_HTTPConnection. This class then redirects specific server/port combinations into a WSGI application by emulating a socket. If no intercept is registered for the host and port requested, those requests are passed on to the standard handler. The functions add_wsgi_intercept(host, port, app_create_fn, script_name='') and remove_wsgi_intercept(host,port) specify which URLs should be redirect into what applications. Note especially that app_create_fn is a function object returning a WSGI application; script_name becomes SCRIPT_NAME in the WSGI app's environment, if set. Installeasy_install wsgi_intercept(The easy_install command is bundled with the setuptools module) To use a development version of wsgi_intercept, run: easy_install http://wsgi-intercept.googlecode.com/svn/trunkPackages InterceptedUnfortunately each of the Web testing frameworks uses its own specific mechanism for making HTTP call-outs, so individual implementations are needed. Below are the packages supported and how to create an intercept. urllib2urllib2 is a standard Python module, and urllib2.urlopen is a pretty normal way to open URLs. The following code will install the WSGI intercept stuff as a default urllib2 handler: >>> from wsgi_intercept.urllib2_intercept import install_opener >>> install_opener() #doctest: +ELLIPSIS >>> import wsgi_intercept >>> from wsgi_intercept.test_wsgi_app import create_fn >>> wsgi_intercept.add_wsgi_intercept('some_host', 80, create_fn) >>> import urllib2 >>> urllib2.urlopen('http://some_host:80/').read() 'WSGI intercept successful!\n'The only tricky bit in there is that different handler classes need to be constructed for Python 2.3 and Python 2.4, because the httplib interface changed between those versions. httplib2httplib2 is a 3rd party extension of the built-in httplib. To intercept requests, it is similar to urllib2: >>> from wsgi_intercept.httplib2_intercept import install >>> install() >>> import wsgi_intercept >>> from wsgi_intercept.test_wsgi_app import create_fn >>> wsgi_intercept.add_wsgi_intercept('some_host', 80, create_fn) >>> import httplib2 >>> resp, content = httplib2.Http().request('http://some_host:80/', 'GET') >>> content 'WSGI intercept successful!\n'(Contributed by David "Whit" Morris.) webtestwebtest is an extension to unittest that has some nice functions for testing Web sites. To install the WSGI intercept handler, do >>> import wsgi_intercept.webtest_intercept >>> class WSGI_Test(wsgi_intercept.webtest_intercept.WebCase): ... HTTP_CONN = wsgi_intercept.WSGI_HTTPConnection ... HOST='localhost' ... PORT=80 ... ... def setUp(self): ... wsgi_intercept.add_wsgi_intercept(self.HOST, self.PORT, create_fn) ... >>>webunitwebunit is another unittest-like framework that contains nice functions for Web testing. (funkload uses webunit, too.) webunit needed to be patched to support different scheme handlers. The patched package is in webunit/wsgi_webunit/, and the only file that was changed was webunittest.py; the original is in webunittest-orig.py. To install the WSGI intercept handler, do >>> from httplib import HTTP >>> import wsgi_intercept.webunit_intercept >>> class WSGI_HTTP(HTTP): ... _connection_class = wsgi_intercept.WSGI_HTTPConnection ... >>> class WSGI_WebTestCase(wsgi_intercept.webunit_intercept.WebTestCase): ... scheme_handlers = dict(http=WSGI_HTTP) ... ... def setUp(self): ... wsgi_intercept.add_wsgi_intercept('127.0.0.1', 80, create_fn) ... >>>mechanizemechanize is John J. Lee's port of Perl's WWW::Mechanize to Python. It mimics a browser. (It's also what's behind twill.) mechanize is just as easy as mechanoid: >>> import wsgi_intercept.mechanize_intercept >>> from wsgi_intercept.test_wsgi_app import create_fn >>> wsgi_intercept.add_wsgi_intercept('some_host', 80, create_fn) >>> b = wsgi_intercept.mechanize_intercept.Browser() >>> response = b.open('http://some_host:80') >>> response.read() 'WSGI intercept successful!\n'mechanoidmechanoid is a fork of mechanize. >>> import wsgi_intercept.mechanoid_intercept >>> from wsgi_intercept.test_wsgi_app import create_fn >>> wsgi_intercept.add_wsgi_intercept('some_host', 80, create_fn) >>> b = wsgi_intercept.mechanoid_intercept.Browser() >>> response = b.open('http://some_host:80') >>> response.read() 'WSGI intercept successful!\n'zope.testbrowserzope.testbrowser is a prettified interface to mechanize that is used primarily for testing Zope applications. zope.testbrowser is also pretty easy >>> import wsgi_intercept.zope_testbrowser >>> from wsgi_intercept.test_wsgi_app import create_fn >>> wsgi_intercept.add_wsgi_intercept('some_host', 80, create_fn) >>> b = wsgi_intercept.zope_testbrowser.WSGI_Browser('http://some_host:80/') >>> b.contents 'WSGI intercept successful!\n'HistoryPursuant to Ian Bicking's "best Web testing framework" post, Titus Brown put together an in-process HTTP-to-WSGI interception mechanism for his own Web testing system, twill. Because the mechanism is pretty generic -- it works at the httplib level -- Titus decided to try adding it into all of the other Python Web testing frameworks. This is the result. Mocking your HTTP ServerMarc Hedlund has gone one further, and written a full-blown mock HTTP server for wsgi_intercept. Combined with wsgi_intercept itself, this lets you entirely replace client calls to a server with a mock setup that hits neither the network nor server code. You can see his work in the file mock_http.py. Run mock_http.py to see a test. Project HomeIf you aren't already there, this project lives on Google Code. Please submit all bugs, patches, failing tests, et cetera using the Issue Tracker [Less]

0
 
  0 reviews  |  0 users  |  2,351 lines of code  |  0 current contributors  |  Analyzed 9 days ago
 
 

IntroductionAspen is a Python webserver. Aspen is framework-agnostic and relies heavily on WSGI. Aspen is fast enough. Roadmap 0.3 -- First public release (November, 2006) 0.4 -- Pure WSGI (December, 2006) 0.5 -- Auto-restart; directory handlers (December, 2006) 0.6 -- Daemonization ... [More] (December, 2006) 0.7 -- User Interface (cli, conf file, environment) (January, 2007) 0.7.1 -- bug fixes (March, 2007) 0.8 -- simplates, aspen.mod_wsgi, aspen.monitord (December, 2007) 0.9 -- ??? Help us out! [Less]

0
 
  0 reviews  |  0 users  |  27,797 lines of code  |  0 current contributors  |  Analyzed 8 days ago
 
 
 
 

Creative Commons License Copyright © 2013 Black Duck Software, Inc. and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a Creative Commons Attribution 3.0 Unported License . Ohloh ® and the Ohloh logo are trademarks of Black Duck Software, Inc. in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.