base32hex support in python?
Hi, One of the modules that I am currently working on requires base32hex encoding as defined by RFC 4648, section 7. I checked base64 module which has base32encode/decode functionality but not with extended hex alphabet. Is there a module, currently available, that provides this? As far as I see, it looks fairly simple to add support for base32hex. It differs from the base32 encoding only in the alphabet used. I am willing to provide a patch. Just to note, map01 argument won't be applicable to base32hexdecode as this encoding uses both 0 (zero) and O (oh) in its alphabet. Looking at the section 13 of RFC 4648, I think, adding base32hex support would make it conform to RFC 4648. - Vishal DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -- http://mail.python.org/mailman/listinfo/python-list
Re: Re: Help: Group based synchronize decorator
Thanks. - vishal -Original Message- Sent: Friday, June 19, 2009 3:15 PM To: python-list@python.org Subject: Python-list Digest, Vol 69, Issue 214 Message: 6 Date: Fri, 19 Jun 2009 10:53:27 +0200 From: Piet van Oostrum p...@cs.uu.nl To: python-list@python.org Subject: Re: Help: Group based synchronize decorator Message-ID: m2zlc4r4e0@cs.uu.nl Content-Type: text/plain; charset=us-ascii Vishal Shetye (VS) wrote: VS I want to synchronize calls using rw locks per 'group' and my implementation is similar to VS http://code.activestate.com/recipes/465057/ VS except that I have my own Lock implementation. VS All my synchronized functions take 'whatGroup' as param. My lock considers 'group' while deciding on granting locks through acquire. VS What I could come up with is: VS - decorator knows(assumes) first param to decorated functions is always 'whatGroup' VS - decorator passes this 'whatGroup' argument to my lock which is used in acquire logic. VS Is it ok to make such assumptions in decorator? As long as you make sure that all decorated functions indeed adhere to that assumption there is nothing wrong with it. -- Piet van Oostrum p...@cs.uu.nl URL: http://pietvanoostrum.com [PGP 8DAE142BE17999C4] Private email: p...@vanoostrum.org DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -- http://mail.python.org/mailman/listinfo/python-list
Help: Group based synchronize decorator
I want to synchronize calls using rw locks per 'group' and my implementation is similar to http://code.activestate.com/recipes/465057/ except that I have my own Lock implementation. All my synchronized functions take 'whatGroup' as param. My lock considers 'group' while deciding on granting locks through acquire. What I could come up with is: - decorator knows(assumes) first param to decorated functions is always 'whatGroup' - decorator passes this 'whatGroup' argument to my lock which is used in acquire logic. Is it ok to make such assumptions in decorator? Any suggestions/alternatives? thanks vishal DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -- http://mail.python.org/mailman/listinfo/python-list
