Re: [Python-Dev] [Python-checkins] r87677 - python/branches/py3k/py3rsa.py
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 python-check...@python.org 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) Added: python/branches/py3k/py3rsa.py == --- (empty file) +++ python/branches/py3k/py3rsa.py Mon Jan 3 10:47:09 2011 @@ -0,0 +1,181 @@ +# Copyright (c) 2010 Russell Dias +# Licensed under the MIT licence. +# http://www.inversezen.com +# +# This is an implementation of the RSA public key +# encryption written in Python by Russell Dias + +__author__ = 'Russell Dias // inversezen.com' +# Py3k port done by Senthil (sent...@uthcode.com) +__date__ = '05/12/2010' +__version__ = '0.0.1' + +import random +from math import log + +def gcd(u, v): + The Greatest Common Divisor, returns + the largest positive integer that divides + u with v without a remainder. + + while v: + u, v = u, u % v + return u + +def eec(u, v): + The Extended Eculidean Algorithm + For u and v this algorithm finds (u1, u2, u3) + such that uu1 + vu2 = u3 = gcd(u, v) + + We also use auxiliary vectors (v1, v2, v3) and + (tmp1, tmp2, tmp3) + + (u1, u2, u3) = (1, 0, u) + (v1, v2, v3) = (0, 1, v) + while (v3 != 0): + quotient = u3 // v3 + tmp1 = u1 - quotient * v1 + tmp2 = u2 - quotient * v2 + tmp3 = u3 - quotient * v3 + (u1, u2, u3) = (v1, v2, v3) + (v1, v2, v3) = (tmp1, tmp2, tmp3) + return u3, u1, u2 + +def stringEncode(string): + Brandon Sterne's algorithm to convert + string to long + + message = 0 + messageCount = len(string) - 1 + + for letter in string: + message += (256**messageCount) * ord(letter) + messageCount -= 1 + return message + +def stringDecode(number): + Convert long back to string + + + letters = [] + text = '' + integer = int(log(number, 256)) + + while(integer = 0): + letter = number // (256**integer) + letters.append(chr(letter)) + number -= letter * (256**integer) + integer -= 1 + for char in letters: + text += char + + return text + +def split_to_odd(n): + Return values 2 ^ k, such that 2^k*q = n; + or an odd integer to test for primiality + Let n be an odd prime. Then n-1 is even, + where k is a positive integer. + + k = 0 + while (n 0) and (n % 2 == 0): + k += 1 + n = 1 + return (k, n) + +def prime(a, q, k, n): + if pow(a, q, n) == 1: + return True + elif (n - 1) in [pow(a, q*(2**j), n) for j in range(k)]: + return True + else: + return False + +def miller_rabin(n, trials): + + There is still a small chance that n will return a + false positive. To reduce risk, it is recommended to use + more trials. + + # 2^k * q = n - 1; q is an odd int + (k, q) = split_to_odd(n - 1) + + for trial in range(trials): + a = random.randint(2, n-1) + if not prime(a, q, k, n): + return False + return True + +def get_prime(k): + Generate prime of size k bits, with 50 tests + to ensure accuracy. + + prime = 0 + while (prime == 0): + prime = random.randrange(pow(2,k//2-1) + 1, pow(2, k//2), 2) + if not miller_rabin(prime, 50): + prime = 0 + return prime + +def modular_inverse(a, m): + To calculate the decryption exponent such that + (d * e) mod phi(N) = 1 OR g == 1 in our implementation. + Where m is Phi(n) (PHI = (p-1) * (q-1) ) + + s % m or d (decryption exponent) is the multiplicative inverse of + the encryption exponent e. + + g, s, t = eec(a, m) + if g == 1: + return s % m + else: + return None + +def key_gen(bits): + The public encryption exponent e, + can be an artibrary prime number. + + Obviously, the higher the number, + the more secure the key pairs are. + + e = 17 + p = get_prime(bits) + q = get_prime(bits) + d = modular_inverse(e, (p-1)*(q-1)) + return p*q,d,e + +def write_to_file(e, d, n): + Write our public and private keys to file + + public = open(publicKey, w) + public.write(str(e)) + public.write(\n) + public.write(str(n)) + public.close() + + private = open(privateKey, w) + private.write(str(d)) + private.write(\n) +
Re: [Python-Dev] [Python-checkins] r87677 - python/branches/py3k/py3rsa.py
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 directory? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible optimization for LOAD_FAST ?
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. 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 assignment to them in the current module, would be fair game for such optimizations, with the understanding that the presence of e.g. len = len anywhere in the module (even in dead code!) would be sufficient to disable the optimization. But barring someone interested in implementing something based on this rule, the proposal has languished for many years. 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. If CPython wants such optimizations, it should do what PyPy and its ilk do, which is to notice the assignment, but recompile code in that module to disable the fast path at runtime, preserving the existing semantics. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tools/unicode
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 removing the for Python 2.0 from the description, but I would rather remove the tool altogether. 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. All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools/unicode
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 definitely a very useful tool used to generate unicodedata and encoding modules from raw unicode.org files. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools/unicode
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 you are talking about Tools/unicode/, this is definitely a very useful tool used to generate unicodedata and encoding modules from raw unicode.org files. The description currently reads Tools used to generate unicode database files. I'll update it to read: tool used to generate unicodedata and encoding modules from raw unicode.org files All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible optimization for LOAD_FAST ?
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 assignment to them in the current
module, would be fair game for such optimizations, with the
understanding that the presence of e.g. len = len anywhere in the
module (even in dead code!) would be sufficient to disable the
optimization.
I believe this amounts to saying
1) Python code executes in three scopes (rather than two): global builtin,
modular (misleadingly call global), and local. This much is a possible
viewpoint today.
In fact it is the specification today.
2) A name that is not an assignment target anywhere -- and that matches a
builtin name -- is treated as a builtin. This is the new part, and it
amounts to a rule for entire modules that is much like the current rule for
separating local and global names within a function. The difference from the
global/local rule would be that unassigned non-builtin names would be left
to runtime resolution in globals.
It would seem that this new rule would simplify the lookup of module
('global') names since if xxx in not in globals, there is no need to look in
builtins. This is assuming that following 'len=len' with 'del len' cannot
'unmodularize' the name.
Actually I would leave the lookup mechanism for names that don't get
special treatment the same -- the only difference would be for
builtins in contexts where the compiler can generate better code
(typically involving a new opcode) based on all the conditions being
met.
For the rule to work 'retroactively' within a module as it does within
functions would require a similar preliminary pass.
We actually already do such a pass.
So it could not work interactively.
That's fine. We could also disable it automatically in when eval() or
exec() is the source of the code.
Should batch mode main modules work the same as when
imported?
Yes.
Interactive mode could work as it does at present or with slight
modification, which would be that builtin names within functions, if not yet
overridden, also get resolved when the function is compiled.
Interactive mode would just work as it does today.
I would also make a rule saying that 'open' is not treated this way.
It is the only one where I can think of legitimate reasons for
changing the semantics dynamically in a way that is not detectable by
the compiler, assuming it only sees the source code for one module at
a time.
Some things that could be optimized this way: len(x), isinstance(x,
(int, float)), range(10), issubclass(x, str), bool(x), int(x),
hash(x), etc... in general, the less the function does the better a
target for this optimization it is.
One more thing: to avoid heisenbugs, I propose that, for any
particular builtin, if this optimization is used anywhere in a module,
it is should be used everywhere in that module (except in scopes where
the name has a different meaning). This means that we can tell users
about it and they can observe it without too much of a worry that a
slight change to their program might disable it. (I've seen this with
optimizations in gcc, and it makes performance work tricky.)
Still, it's all academic until someone implements some of the
optimizations. (There rest of the work is all in the docs and in the
users' minds.)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible optimization for LOAD_FAST ?
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 excluding open from this optimization, for that very reason. If CPython wants such optimizations, it should do what PyPy and its ilk do, which is to notice the assignment, but recompile code in that module to disable the fast path at runtime, preserving the existing semantics. In general I am against duplicating bytecode -- it can blow up too much. (It is an entirely appropriate technique for JIT compilers -- but my point here is that bytecode is different.) Recompiling a module is not a trivial change -- for example, either code objects would have to become mutable, or we'd have to track down all the code objects and replace them. Neither sounds attractive to me. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools/unicode
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 replies I'll remove it. If you are talking about Tools/unicode/, this is definitely a very useful tool used to generate unicodedata and encoding modules from raw unicode.org files. The description currently reads Tools used to generate unicode database files. I'll update it to read: tool used to generate unicodedata and encoding modules from raw unicode.org files Make that Tools for generating unicodedata and codecs from unicode.org and other mapping files. The scripts in that dir are not just one tool, but several tools needed to maintain the Unicode database in Python as well as generate new codecs from mapping files. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 03 2011) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tools/unicode
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 should best be updated. If there are no replies I'll remove it. If you are talking about Tools/unicode/, this is definitely a very useful tool used to generate unicodedata and encoding modules from raw unicode.org files. The description currently reads Tools used to generate unicode database files. I'll update it to read: tool used to generate unicodedata and encoding modules from raw unicode.org files Make that Tools for generating unicodedata and codecs from unicode.org and other mapping files. The scripts in that dir are not just one tool, but several tools needed to maintain the Unicode database in Python as well as generate new codecs from mapping files. Thanks Marc-Andre. I'll add you and Martin as maintainers in the README description as well. All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible optimization for LOAD_FAST ?
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. True. 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 assignment to them in the current module, would be fair game for such optimizations, with the understanding that the presence of e.g. len = len anywhere in the module (even in dead code!) would be sufficient to disable the optimization. But barring someone interested in implementing something based on this rule, the proposal has languished for many years. Is there a PEP for this? FWIW, this is reminiscent of Fortran's rules for intrinsics (its name for builtins), which have a similar optimization behavior (except there the potential overrides that the compiler doesn't need to take into account are load-time definitions). I've been attempting another way in: http://bugs.python.org/issue10399 using a new JUMP_IF_SPECIALIZABLE opcode. This compares what a value is against a compile-time prediction, branching to an optimized implementation if the guess was correct. I use this to implement function-call inlining within the generated bytecode. Caveat-of-doom: That code's very much a work-in-progress at this stage, though: sometimes it doesn't segfault :) and the way that I track the predicted values is taking some other liberties with semantics (see that URL and the dmalcolm-ast-optimization-branch in SVN). (There's probably at least 2 PEPs in the above idea, though have yet to write my first PEP) Hope this is helpful Dave ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Checking input range in time.asctime and time.ctime
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 (superseded by #8013)
I have a patch ready at issue 8013 that adds a check for large values
and causes time.asctime and time.ctime raise ValueError instead of
producing system-dependent results or in some cases crashing or
corrupting the python process.
There is little dispute that python should not crash on invalid input,
but I would like to ask for a second opinion on whether it would be
better to produce some distinct 24-character string, say 'Mon Jan 1
00:00:00 *999', instead of raising an exception.
Note that on some Windows systems, the current behavior is to produce
'%c999' % (year // 1000 + ord('0')) for at least some large values of
year. Linux asctime produces strings that are longer than 26
characters, but I don't think we should support this behavior because
POSIX defines asctime() result as a 26 character string and Python
manual defines time.asctime() result as a 24 character string.
Producing longer timestamps is likely to break as many applications as
accepting large years will fix. OSX asctime returns a NULL pointer for
large years.
My position is that raising an error is the right solution. This is
consistent with year range supported by datetime.
Another small issue that I would like to raise here is issue6608 patch
resulting in time.asctime() accepting 0 as a valid entry at any
position of the timetuple. This is consistent with the behavior of
time.strftime(), but was overlooked when issue6608 was reviewed. I
find the case for accepting say 0 month or 0 day in time.asctime()
weaker than that for time.strftime() where month or day values may be
ignored.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Checking input range in time.asctime and time.ctime
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 3, 2011 at 4:06 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
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 (superseded by #8013)
I have a patch ready at issue 8013 that adds a check for large values
and causes time.asctime and time.ctime raise ValueError instead of
producing system-dependent results or in some cases crashing or
corrupting the python process.
There is little dispute that python should not crash on invalid input,
but I would like to ask for a second opinion on whether it would be
better to produce some distinct 24-character string, say 'Mon Jan 1
00:00:00 *999', instead of raising an exception.
Note that on some Windows systems, the current behavior is to produce
'%c999' % (year // 1000 + ord('0')) for at least some large values of
year. Linux asctime produces strings that are longer than 26
characters, but I don't think we should support this behavior because
POSIX defines asctime() result as a 26 character string and Python
manual defines time.asctime() result as a 24 character string.
Producing longer timestamps is likely to break as many applications as
accepting large years will fix. OSX asctime returns a NULL pointer for
large years.
My position is that raising an error is the right solution. This is
consistent with year range supported by datetime.
Another small issue that I would like to raise here is issue6608 patch
resulting in time.asctime() accepting 0 as a valid entry at any
position of the timetuple. This is consistent with the behavior of
time.strftime(), but was overlooked when issue6608 was reviewed. I
find the case for accepting say 0 month or 0 day in time.asctime()
weaker than that for time.strftime() where month or day values may be
ignored.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3333: wsgi_string() function
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):
environ = {k: wsgi_string(v) for k,v in os.environ.items()}
environ['wsgi.input']= sys.stdin
environ['wsgi.errors'] = sys.stderr
environ['wsgi.version'] = (1, 0)
...
--
What is this horrible encoding bytes-as-unicode? os.environ is
supposed to be correctly decoded and contain valid unicode characters.
If WSGI uses another encoding than the locale encoding (which is a bad
idea), it should use os.environb and decodes keys and values using its
own encoding.
If you really want to store bytes in unicode, str is not the right type:
use the bytes type and use os.environb instead.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
