ANN: Gracie v0.2 -- a local-account OpenID provider
Howdy all, I'm pleased to announce the creation of the Gracie project. What is Gracie? === Gracie is an OpenID server (a "provider" in OpenID terminology) that serves OpenID identities for the local system PAM accounts. It authenticates users with a username/password challenge. The OpenID protocol is documented at http://openid.net/>. Gracie is intended for use within trusted environments that have an existing authentication system available via PAM (e.g. most GNU/Linux environments), that would like to provide OpenIDs for all local users instead of maintaining disparate web-based accounts for local services. What can Gracie do now? === Gracie 0.2 is still alpha-development software, not intended for use in production environments. That said, this version does satisfy some basic requirements. Currently Gracie can serve OpenID 1.1 authentication for local PAM users. It will authenticate the user with a web form, using the PAM system where the Gracie server is running. It assumes that any consumer request for identity is authorised to be given the user's identity. What improvements are needed? = The current state of Gracie is functional but still needs much improvement. Please check the TODO.txt file in the source package for a list of improvements that need to be made. As of this announcement, Gracie version 0.2 is available. The project's home page is http://trac.whitetree.org/gracie/>. -- \ "When I turned two I was really anxious, because I'd doubled my | `\ age in a year. I thought, if this keeps up, by the time I'm six | _o__) I'll be ninety." -- Steven Wright | Ben Finney <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
ANN: python-ldap-2.3.0
Find a new release of python-ldap: http://python-ldap.sourceforge.net/ python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). Released 2.3.0 2007-03-27 Changes since 2.2.1: * OpenLDAP 2.3+ required now to build. * Added support for Cancel operation ext. op. if supported in OpenLDAP API of the libs used for the build. Modules/ * Removed deprecated code for setting options by name * Added l_ldap_cancel() * Some modifications related to PEP 353 for Python 2.5 on 64-bit platforms (see SF#1467529, thanks to Matej) * Added new function l_ldap_str2dn(), removed functions l_ldap_explode_dn() and l_ldap_explode_rdn() (see SF#1657848, thanks to David) Lib/ * Added method ldapobject.LDAPObject.cancel() * ldap.schema.subentry.urlfetch() now can do non-anonymous simple bind if the LDAP URL provided contains extensions 'bindname' and 'X-BINDPW'. (see SF#1589206) * ldap.filter.escape_filter_chars() has new a key-word argument escape_mode now which defines which chars to be escaped (see SF#1193271). * Various important fixes to ldapobject.ReconnectLDAPObject * Moved all DN-related functions to sub-module ldap.dn, import them in ldap.functions for backward compability * ldap.dn.explode_dn() and ldap.dn.explode_rdn() use the new wrapper function ldap.dn.str2dn() (related to SF#1657848) * changetype issue partially fixed (see SF#1683746) -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
PyPy 1.0: JIT compilers for free and more
== PyPy 1.0: JIT compilers for free and more == Welcome to the PyPy 1.0 release - a milestone integrating the results of four years of research, engineering, management and sprinting efforts, concluding the 28 months phase of EU co-funding! Although still not mature enough for general use, PyPy 1.0 materializes for the first time the full extent of our original vision: - A flexible Python interpreter, written in "RPython": - Mostly unaware of threading, memory and lower-level target platform aspects. - Showcasing advanced interpreter features and prototypes. - Passing core CPython regression tests, translatable to C, LLVM and .NET. - An advanced framework to translate such interpreters and programs: - That performs whole type-inference on RPython programs. - Can weave in threading, memory and target platform aspects. - Has low level (C, LLVM) and high level (CLI, Java, JavaScript) backends. - A **Just-In-Time Compiler generator** able to **automatically** enhance the low level versions of our Python interpreter, leading to run-time machine code that runs algorithmic examples at speeds typical of JITs! Previous releases, particularly the 0.99.0 release from February, already highlighted features of our Python implementation and the abilities of our translation approach but the **new JIT generator** clearly marks a major research result and gives weight to our vision that one can generate efficient interpreter implementations, starting from a description in a high level language. We have prepared several entry points to help you get started: * The main entry point for JIT documentation and status: http://codespeak.net/pypy/dist/pypy/doc/jit.html * The main documentation and getting-started PyPy entry point: http://codespeak.net/pypy/dist/pypy/doc/index.html * Our online "play1" demos showcasing various Python interpreters, features (and a new way to program AJAX applications): http://play1.codespeak.net/ * Our detailed and in-depth Reports about various aspects of the project: http://codespeak.net/pypy/dist/pypy/doc/index-report.html In the next few months we are going to discuss the goals and form of the next stage of development - now more than ever depending on your feedback and contributions - and we hope you appreciate PyPy 1.0 as an interesting basis for greater things to come, as much as we do ourselves! have fun, the PyPy release team, Samuele Pedroni, Armin Rigo, Holger Krekel, Michael Hudson, Carl Friedrich Bolz, Antonio Cuni, Anders Chrigstroem, Guido Wesdorp Maciej Fijalkowski, Alexandre Fayolle and many others: http://codespeak.net/pypy/dist/pypy/doc/contributor.html What is PyPy? Technically, PyPy is both a Python interpreter implementation and an advanced compiler, or more precisely a framework for implementing dynamic languages and generating virtual machines for them. The framework allows for alternative frontends and for alternative backends, currently C, LLVM and .NET. For our main target "C", we can can "mix in" different garbage collectors and threading models, including micro-threads aka "Stackless". The inherent complexity that arises from this ambitious approach is mostly kept away from the Python interpreter implementation, our main frontend. PyPy is now also a Just-In-Time compiler generator. The translation framework contains the now-integrated JIT generation technology. This depends only on a few hints added to the interpreter source and should be able to cope with the changes to the interpreter and be generally applicable to other interpreters written using the framework. Socially, PyPy is a collaborative effort of many individuals working together in a distributed and sprint-driven way since 2003. PyPy would not have gotten as far as it has without the coding, feedback and general support from numerous people. Formally, many of the current developers were involved in executing an EU contract with the goal of exploring and researching new approaches to language and compiler development and software engineering. This contract's duration is about to end this month (March 2007) and we are working and preparing the according final review which is scheduled for May 2007. For the future, we are in the process of setting up structures to help maintain conceptual integrity of the project and to discuss and deal with funding opportunities related to further PyPy sprinting and developments. See here for results of the discussion so far: http://codespeak.net/pipermail/pypy-dev/2007q1/003577.html 1.0.0 Feature highlights == Here is a summary list of key features included in PyPy 1.0: - The Just-In-Time compiler generator, now capable of generating the first JIT compiler versions of our Python interpreter: http://cod
python-cjson 1.0.3x2 released
This is an enhanced version of python-cjson, the fast JSON encoder/decoder.
Qiangning Hong submitted a patch to fix segfault with Python 2.5 on 64 bit
platforms. Version python-cjson 1.0.3x2 released to incorporate this patch.
It's numbered 1.0.3x, where x stands for eXtension.
The main improvement is the ability to extend the JSON encoder and decoder
with extensions functions to serialize/unserialize objects not in the
original JSON specification. This is achieved without sacrificing the speed
and stability of the original implementation. Please send bug reports to
[EMAIL PROTECTED] and do not contact the original author (Dan Pascu) about this
version.
Download and more information:
http://cx.hu/python-cjson/
Example to encode/decode python date objects as JavaScript Date:
import re
import cjson
import datetime
# Encoding Date objects:
def dateEncoder(d):
assert isinstance(d, datetime.date)
return 'new Date(Date.UTC(%d,%d,%d))'%(d.year, d.month, d.day)
json=cjson.encode([1,datetime.date(2007,1,2),2], extension=dateEncoder)
assert json=='[1, new Date(Date.UTC(2007,1,2)), 2]'
# Decoding Date objects:
re_date=re.compile('^new\sDate\(Date\.UTC\(.*?\)\)')
def dateDecoder(json,idx):
json=json[idx:]
m=re_date.match(json)
if not m: raise 'cannot parse JSON string as Date object: %s'%json[idx:]
args=cjson.decode('[%s]'%json[18:m.end()-2])
dt=datetime.date(*args)
return (dt,m.end()) # must return (object, character_count) tuple
data=cjson.decode('[1, new Date(Date.UTC(2007,1,2)), 2]',
extension=dateDecoder)
assert data==[1,datetime.date(2007,1,2),2]
--
http://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http://www.python.org/psf/donations.html
SyPy - Sydney Users Group Meeting, Thursday April 5, 2007
Hi everyone, For our April meeting, Google have kindly offered to host us. Thursday, April 5, 2007 6:15-8:30PM Google Australia Level 18, Tower 1 Darling Park 201 Sussex St Sydney We will have two presentations: 1. Alec Thomas will give us a debrief on his time at PyCon 2007 2. Andrew Bennets will talk about the Bazaar Distributed Version Control followed by some lively discussion and for those who want to, we will continue the gathering at a local watering hole after 8:30PM. The room can hold 40 people. To attend this meeting you must RSVP to Alan Green (alangreen at google dot com) Regards Mark About SyPy A group of Sydney based python users who meet on the first thursday of the month. Website: http://sypy.org Maillist: http://groups.google.com/group/sydneypython -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Elixir 0.3.0 released!
We are pleased to announce that version 0.3.0 of Elixir is now available. As always, feedback is very welcome, preferably on Elixir mailing list. Highlights for this release - - Added support for autoloading/reflecting databases with has_and_belongs_to_many relationships. See the docs for details. - Added support for the "version_id_col" option on entities. This option adds a column to the table which will be used to prevent concurrent modifications on any row of the entity's table (i.e. it will raise an error if it happens). - Added an "ondelete" argument to belongs_to relationships. - The tablename option can now be given a callable so that people can provide their own function to get the table name for an entity. - Made the provided metadata not threadlocal. This could break things for you in some rare case. Please see the (newly created) FAQ file for details about this. - Fixed bug preventing having entities without any statement. - Fixed typo which broke the use_alter argument on belongs_to relationships. The full list of changes can be seen at: http://elixir.ematia.de/svn/elixir/tags/0.3.0/CHANGES What is Elixir? - Elixir is a declarative layer on top of SQLAlchemy. It is a fairly thin wrapper, which provides the ability to define model objects following the Active Record design pattern, and using a DSL syntax similar to that of the Ruby on Rails ActiveRecord system. Elixir does not intend to replace SQLAlchemy's core features, but instead focuses on providing a simpler syntax for defining model objects when you do not need the full expressiveness of SQLAlchemy's manual mapper definitions. Mailing list http://groups.google.com/group/sqlelixir/about -- Gaëtan de Menten http://openhex.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Shed Skin Optimizing Python-to-C++ Compiler 0.0.21
Hi all,
Development of Shed Skin is continuing at a steady pace. I have just
released 0.0.21, which comes with the following changes:
-important type inference fix/cleanup
-support for 'bisect', 'collections.deque' and 'string.maketrans'
-improved 'copy' support
-support for 'try, else' construction
-some optimizations ('dict[..] += ..', "''.join(sorted(str))")
-several minor bug fixes
See the homepage for more information about Shed Skin, and a
collection of 27 'largish' programs (in total about 7,000 lines) that
compile with the latest release:
http://mark.dufour.googlepages.com
I am always looking for developers to join the project. So far I have
not received much help. An important area where Shed Skin is still
lacking is integration with CPython (building extension modules and
using non-compiled modules from compiled code). Other areas I could
really use help with are systematic testing, bug reporting, building a
better website/wiki, etc. Please let me know if you are interested,
and/or join the mailing list from the sourceforge site.
Thanks,
Mark Dufour.
--
"One of my most productive days was throwing away 1000 lines of code"
- Ken Thompson
--
http://mail.python.org/mailman/listinfo/python-announce-list
Support the Python Software Foundation:
http://www.python.org/psf/donations.html
