Sorry Folks. I commited to a wrong respository.
I was testing it against the latest version py3k and I thought i moved
it back to my original respository.
Apologize for the trouble and I shall remove it immediately.
--
Senthil
On Mon, Jan 3, 2011 at 5:47 PM, senthil.kumaran
On 1/3/2011 4:47 AM, senthil.kumaran wrote:
Author: senthil.kumaran
Date: Mon Jan 3 10:47:09 2011
New Revision: 87677
Log:
py3k implmentation of RSA algorithm,
Added:
python/branches/py3k/py3rsa.py (contents, props changed)
Did you really mean this to go in the py3k top-level
On Jan 2, 2011, at 10:18 PM, Guido van Rossum wrote:
On Sun, Jan 2, 2011 at 5:50 PM, Alex Gaynor alex.gay...@gmail.com wrote:
No, it's singularly impossible to prove that any global load will be any
given
value at compile time. Any optimization based on this premise is wrong.
True.
Hello all,
In the Tools/ directory (py3k) we have a tool/directory called
unicode. The description in Tools/README is:
unicode Tools used to generate unicode database files for
Python 2.0 (by Fredrik Lundh).
As described this is not at all useful for Python 3.2. I'm
On Mon, Jan 3, 2011 at 10:33 AM, Michael Foord mich...@voidspace.org.uk wrote:
..
If someone knows if this tool is still used/useful then please let us know
how the description should best be updated. If there are no replies I'll
remove it.
If you are talking about Tools/unicode/, this is
On 03/01/2011 15:39, Alexander Belopolsky wrote:
On Mon, Jan 3, 2011 at 10:33 AM, Michael Foordmich...@voidspace.org.uk wrote:
..
If someone knows if this tool is still used/useful then please let us know
how the description should best be updated. If there are no replies I'll
remove it.
If
On Sun, Jan 2, 2011 at 9:36 PM, Terry Reedy tjre...@udel.edu wrote:
On 1/2/2011 10:18 PM, Guido van Rossum wrote:
My proposed way out of this conundrum has been to change the language
semantics slightly so that global names which (a) coincide with a
builtin, and (b) have no explicit
On Mon, Jan 3, 2011 at 6:12 AM, Glyph Lefkowitz gl...@twistedmatrix.com wrote:
Wouldn't this optimization break things like mocking out 'open' for testing
via 'module.open = fakeopen'? I confess I haven't ever wanted to change
'len' but that one seems pretty useful.
I am explicitly
Michael Foord wrote:
On 03/01/2011 15:39, Alexander Belopolsky wrote:
On Mon, Jan 3, 2011 at 10:33 AM, Michael
Foordmich...@voidspace.org.uk wrote:
..
If someone knows if this tool is still used/useful then please let us
know
how the description should best be updated. If there are no
On 03/01/2011 16:19, M.-A. Lemburg wrote:
Michael Foord wrote:
On 03/01/2011 15:39, Alexander Belopolsky wrote:
On Mon, Jan 3, 2011 at 10:33 AM, Michael
Foordmich...@voidspace.org.uk wrote:
..
If someone knows if this tool is still used/useful then please let us
know
how the description
On Sun, 2011-01-02 at 19:18 -0800, Guido van Rossum wrote:
On Sun, Jan 2, 2011 at 5:50 PM, Alex Gaynor alex.gay...@gmail.com wrote:
No, it's singularly impossible to prove that any global load will be any
given
value at compile time. Any optimization based on this premise is wrong.
There are several reports of bugs caused by the fact that the behavior
of C functions asctime and ctime is undefined when they are asked to
format time for more than 4-digit years:
http://bugs.python.org/issue8013
http://bugs.python.org/issue6608 (closed)
http://bugs.python.org/issue10563
Given the rule garbage in - garbage out, I'd do the most useful
thing, which would be to produce a longer output string (and update
the docs). This would match the behavior of e.g. '%04d' % y when y
. If that means the platform libc asctime/ctime can't be used, too
bad.
--Guido
On Mon, Jan
Hi,
In the PEP , I read:
--
import os, sys
enc, esc = sys.getfilesystemencoding(), 'surrogateescape'
def wsgi_string(u):
# Convert an environment variable to a WSGI bytes-as-unicode
string
return u.encode(enc, esc).decode('iso-8859-1')
def run_with_cgi(application):
14 matches
Mail list logo
