I'm -1 on the usage of ed25519 in PEP 427. While the PEP proposes to use JSON
Web signatures, this algorithm is not supported by the current JWS draft .
Instead, I suggest to use the ES256 algorithm from JWS, i.e. ECDSA with the
NIST P-256 curve and SHA-256. This has the advantage of using standard
I don't know what the rationale for suggesting ed25519 is; I suppose that
existence of a pure-Python implementation played a role. However:
- ECDSA also has a pure-Python implementation
- ECDSA is well-supported by OpenSSL, i.e. a signature generator may also
invoke the OpenSSL command line for efficient implementation. I believe
M2Crypto also exposes enough of OpenSSL tp perform ECDSA signing and
I'm -0 on the use of JWS; I would prefer a signature format that is already
an established internet standard (such a PGP or S/MIME). However, it does look
that this may become a proper internet standard in the near future, so it's
an ok choice.
If it really must be ed25519, I request that this is registered with IANA
once the PEP is accepted, the RFC is accepted, and the JWS algorithm
registry is open.
How does the pure / plat distinction as outlined in PEP 427 cope with
Debian's system of separating installed files into pyshared (for *.py
and *.egg-info files) and pythonX.Y/dist-packages (for *.pyc and *.so
Am 21.10.2012 17:23, schrieb antoine.pitrou:
> changeset: 79875:ce9c9cbd1b11
> user: Antoine Pitrou <solipsis(a)pitrou.net>
> date: Sun Oct 21 17:21:04 2012 +0200
> Build the _sha3 module with VS 2008.
For VS 2010 I decided against this approach and built the extension as a
separate .pyd extension because the _sha3 module is rather large (> 200
kB). I think your change is going to break VS 2010.
What do the other think? Should the code by built-in by default?
while fixing pypy to pass CPython 3.2 tests, I found what I think it's a
inconsistency in how CPython (both 2.7 and 3.2) handles __complex__:
>>> class Obj:
... def __complex__(self):
... return 2.0
>>> obj = Obj()
>>> import cmath
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: __complex__ should return a complex object
i.e., the complex constructor does not check that __complex__ returns an
actual complex, while the cmath functions do.
To me it looks like a bug in complex_new which should do the check as well;
however, there is a test in test_complex.test_constructor which checks that
returning a float actually works.
Is that the real intended behavior?
What can I use to browse, search and troubleshoot core Python sources online?
Why the question "Where do I find Python core code?" is not the first
in the dev. guide? =)
There is clearly a lot of stuff on http://hg.python.org/ that requires
I'd also include some more technical information at the top.
And FAQ is very strange. "What standards of behaviour are expected in
these communication channels?" - is that really the question people
frequently ask? IMHO the question should be "Where can I get help with
development?" and the answer include a link to dev.guide chapter on
In response to http://bugs.python.org/issue15452, I've created an improved
evaluator in the ast module in my sandbox repo. The evaluator supports lookup of
names in a supplied namespace. The basic interface is
def lookup_eval(source_string_or_ast_node, namespace, allow_imports=False):
# perform limited evaluation of Python expressions
Function calls are not allowed in expressions, but the following are:
* Names (looked up in namespace, and imported if not found there and
allow_imports is True)
* Literals, just as literal_eval() does
* Array indexing and slicing
* Attribute access
* Arithmetic operators
* Bitwise operators
* Comparison operators
* in / not in
* and / or
* Unary operators
The patch is attached to the issue, and includes changes to replace the use
of eval() by logging.config.fileConfig() to use ast.lookup_eval().
I would welcome review of the patch, particularly as there may be security
implications (the issue is titled "Improve the security model for logging
Barring objections, I plan to commit it in a week or so.
With the 3.4 release PEP published using a traditional schedule,
perhaps MvL would care to do the honours as BDFL-Delegate in rejecting
the two "faster release cycle for the standard library" PEPs?
(I know I asked to hold off on that when MvL last brought it up, but
I've since realised that "do the first alpha early" isn't a
stand-alone PEP, it's just a matter of convincing Larry it's
worthwhile and negotiating timing with the release team after there
are some release-worthy features on trunk)
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I'd like to request that PEP 426 is extended to talk about the order
In particular, for the Extension field, is it necessary that all
follow immediately the respective Extension field?
I also request that RFC 2119 terminology is followed strictly. In particular,
the phrasing "Additional tags defined by the extension should be of
the form string/Name:"
is unclear - under what "particular circumstances" can I deviate from that
requirement, i.e. use some form other than string/Name?