[issue8998] add crypto routines to stdlib
Martin v. Löwis mar...@v.loewis.de added the comment: * I'd prefer if the crypto API didn't become OpenSSL specific (like the SSL one is), which would theoretically allow switching in other crypto provider(s). I agree in theory, although I'm not sure how important this is likely to be in practice. I always wanted to drop OpenSSL from the Windows binaries, and use MS CryptoAPI instead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Daniel Urban urban.dani...@gmail.com added the comment: * When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.) I think there is a relevant PEP: PEP 272 -- API for Block Encryption Algorithms v1.0 (http://www.python.org/dev/peps/pep-0272/ ) It describes an API somewhat similar to hashlib. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
geremy condra debat...@gmail.com added the comment: On Fri, Jun 18, 2010 at 2:19 AM, Martin v. Löwis rep...@bugs.python.org wrote: Martin v. Löwis mar...@v.loewis.de added the comment: * I'd prefer if the crypto API didn't become OpenSSL specific (like the SSL one is), which would theoretically allow switching in other crypto provider(s). I agree in theory, although I'm not sure how important this is likely to be in practice. I always wanted to drop OpenSSL from the Windows binaries, and use MS CryptoAPI instead. My familiarity with the CryptoAPI is limited, but I think doing this for something like evpy would be possible. I also suspect that doing it for anything that exposed much more than evpy does would grow very quickly in complexity where it was possible at all. Geremy Condra -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
geremy condra debat...@gmail.com added the comment: On Fri, Jun 18, 2010 at 2:39 AM, Daniel Urban rep...@bugs.python.org wrote: Daniel Urban urban.dani...@gmail.com added the comment: * When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.) I think there is a relevant PEP: PEP 272 -- API for Block Encryption Algorithms v1.0 (http://www.python.org/dev/peps/pep-0272/ ) It describes an API somewhat similar to hashlib. Again, I'm not entirely opposed to this, but I think it represents a lower-level API than most developers can really be safely trusted to handle. Geremy Condra -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Antoine Pitrou pit...@free.fr added the comment: Le vendredi 18 juin 2010 à 06:46 +, geremy condra a écrit : geremy condra debat...@gmail.com added the comment: On Fri, Jun 18, 2010 at 2:39 AM, Daniel Urban rep...@bugs.python.org wrote: Daniel Urban urban.dani...@gmail.com added the comment: * When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.) I think there is a relevant PEP: PEP 272 -- API for Block Encryption Algorithms v1.0 (http://www.python.org/dev/peps/pep-0272/ ) It describes an API somewhat similar to hashlib. Again, I'm not entirely opposed to this, but I think it represents a lower-level API than most developers can really be safely trusted to handle. If there is a contention or disagreement between different API styles, it may be wise to seek opinions on python-dev or python-ideas. I'd point out that the ssl module itself seems to have evolved from a trivial wrapper API (in the 2.5 docs I can only find a single 3-parameter function, socket.ssl()) to a more comprehensive API in 3.2, because people ultimately need the functionalities. (and yet the ssl API in 3.2 is still much less featureful than M2Crypto or pyOpenSSL are) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
geremy condra debat...@gmail.com added the comment: On Fri, Jun 18, 2010 at 3:09 AM, Antoine Pitrou rep...@bugs.python.org wrote: Antoine Pitrou pit...@free.fr added the comment: Le vendredi 18 juin 2010 à 06:46 +, geremy condra a écrit : geremy condra debat...@gmail.com added the comment: On Fri, Jun 18, 2010 at 2:39 AM, Daniel Urban rep...@bugs.python.org wrote: Daniel Urban urban.dani...@gmail.com added the comment: * When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.) I think there is a relevant PEP: PEP 272 -- API for Block Encryption Algorithms v1.0 (http://www.python.org/dev/peps/pep-0272/ ) It describes an API somewhat similar to hashlib. Again, I'm not entirely opposed to this, but I think it represents a lower-level API than most developers can really be safely trusted to handle. If there is a contention or disagreement between different API styles, it may be wise to seek opinions on python-dev or python-ideas. I'm not sure there's a disagreement here except what the top-level API should be. If someone is really determined to use the lower-level API I have no issue with it, and (within the bounds of time and ability) am willing to write the code to support it. I'd point out that the ssl module itself seems to have evolved from a trivial wrapper API (in the 2.5 docs I can only find a single 3-parameter function, socket.ssl()) to a more comprehensive API in 3.2, because people ultimately need the functionalities. (and yet the ssl API in 3.2 is still much less featureful than M2Crypto or pyOpenSSL are) I'm not sure I'm understanding what you mean. Are you saying it should start as a comprehensive wrapper because that's what ssl is headed towards or that it should start simply because such functionality will evolve organically as the need arises? Geremy Condra -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Antoine Pitrou pit...@free.fr added the comment: I'd point out that the ssl module itself seems to have evolved from a trivial wrapper API (in the 2.5 docs I can only find a single 3-parameter function, socket.ssl()) to a more comprehensive API in 3.2, because people ultimately need the functionalities. (and yet the ssl API in 3.2 is still much less featureful than M2Crypto or pyOpenSSL are) I'm not sure I'm understanding what you mean. Are you saying it should start as a comprehensive wrapper because that's what ssl is headed towards or that it should start simply because such functionality will evolve organically as the need arises? The former. Evolving organically has quite a few issues, because the original API may be far from ideal to build on, and yet you have to ensure compatibility with that API. (comprehensive doesn't have to equate exhaustive of course. But any API which tries to simplify things too much might also be a roadblock when it comes to exposing more features) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9023] distutils relative path errors
New submission from Greg Hazel gha...@users.sourceforge.net:
Probably applies to more versions, but I only tested on 2.5.2 and 2.6.5.
Distutils incorrectly constructs paths for the build/temp directory when
relative paths are used in the sources list. This can result in failing to
make the build/temp directory at all, and placing files in outside of the
build/temp directory.
Consider the following example:
g...@duma:~$ mkdir libfoo
g...@duma:~$ cd libfoo
g...@duma:~/libfoo$ echo foo.c
g...@duma:~/libfoo$ mkdir pyfoo
g...@duma:~/libfoo$ cd pyfoo
g...@duma:~/libfoo/pyfoo$ echo from setuptools import setup, Library;
setup(name='foo', ext_modules=[Library(name='foo',sources=['../foo.c'])])
setup.py
g...@duma:~/libfoo/pyfoo$ python setup.py build
running build
running build_ext
building 'foo' extension
creating build
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -I/usr/include/python2.5 -c ../foo.c -o
build/temp.linux-i686-2.5/../foo.o
Assembler messages:
Fatal error: can't create build/temp.linux-i686-2.5/../foo.o: No such file or
directory
error: command 'gcc' failed with exit status 1
Using os.path.abspath('../foo.c') in the sources causes distutils to create
build/temp.linux-i686-2.5/home/gah/libfoo/foo.o which is fine. However as a
user, this situation is quite surprising, since distutils is responsible for
managing the build and temp directories itself.
--
assignee: tarek
components: Distutils
messages: 108085
nosy: ghazel, tarek
priority: normal
severity: normal
status: open
title: distutils relative path errors
type: behavior
versions: Python 2.5, Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9023
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9024] PyDateTime_IMPORT macro incorrectly marked up
New submission from Tim Golden m...@timgolden.me.uk: The reference to PyDateTime_IMPORT in the C API datetime docs is marked up as cfunction, giving it a pair of brackets which render it invalid. There is also no indication of where in the code it should be invoked. Patch attached. -- files: pydatetime_import.patch keywords: patch messages: 108086 nosy: tim.golden priority: normal severity: normal status: open title: PyDateTime_IMPORT macro incorrectly marked up Added file: http://bugs.python.org/file17703/pydatetime_import.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9024 ___Index: c-api/datetime.rst === --- c-api/datetime.rst (revision 82013) +++ c-api/datetime.rst (working copy) @@ -8,9 +8,9 @@ Various date and time objects are supplied by the :mod:`datetime` module. Before using any of these functions, the header file :file:`datetime.h` must be included in your source (note that this is not included by :file:`Python.h`), -and the macro :cfunc:`PyDateTime_IMPORT` must be invoked. The macro puts a -pointer to a C structure into a static variable, ``PyDateTimeAPI``, that is -used by the following macros. +and the macro :cmacro:`PyDateTime_IMPORT` must be invoked, usually as part of +the module initialisation function. The macro puts a pointer to a C structure +into a static variable, ``PyDateTimeAPI``, that is used by the following macros. Type-check macros: ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
geremy condra debat...@gmail.com added the comment: On Fri, Jun 18, 2010 at 3:28 AM, Antoine Pitrou rep...@bugs.python.org wrote: Antoine Pitrou pit...@free.fr added the comment: I'd point out that the ssl module itself seems to have evolved from a trivial wrapper API (in the 2.5 docs I can only find a single 3-parameter function, socket.ssl()) to a more comprehensive API in 3.2, because people ultimately need the functionalities. (and yet the ssl API in 3.2 is still much less featureful than M2Crypto or pyOpenSSL are) I'm not sure I'm understanding what you mean. Are you saying it should start as a comprehensive wrapper because that's what ssl is headed towards or that it should start simply because such functionality will evolve organically as the need arises? The former. Evolving organically has quite a few issues, because the original API may be far from ideal to build on, and yet you have to ensure compatibility with that API. (comprehensive doesn't have to equate exhaustive of course. But any API which tries to simplify things too much might also be a roadblock when it comes to exposing more features) Well, like I say, I'm willing to contribute what time and ability allow. Are you thinking of adding a comprehensive wrapper to the ssl module? Geremy Condra -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Antoine Pitrou pit...@free.fr added the comment: Well, like I say, I'm willing to contribute what time and ability allow. Are you thinking of adding a comprehensive wrapper to the ssl module? Hmm, no, I was just providing an existing datapoint to help us deciding on a crypto API. AFAICT this issue hasn't much to do with the ssl module, except perhaps for (positive or negative) inspiration ;-) (and except that it will also - most likely - interface with OpenSSL) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9024] PyDateTime_IMPORT macro incorrectly marked up
Changes by Tim Golden m...@timgolden.me.uk: -- assignee: - d...@python components: +Documentation nosy: +d...@python stage: - patch review versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9024 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Add pure Python implementation of datetime module to CPython
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: One, we should not blindly pull in the PyPy code without some core PyPy developer being in on this You can count me among the PyPy developers. I concur. Much of PyPy code is written for a restricted subset of Python instead of clean, idiomatic modern Python. Not this part. The module datetime.py is meant to be imported by the interpreter, and has no limitation (we call it application-level code, opposed to interpreter-level code which is translated to C and which indeed has serious constraints) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Add pure Python implementation of datetime module to CPython
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: If both implementations can exist in the same interpreter, how will they cooperate? For example, Time instances created with datetime.py won't pass PyTime_Check(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
geremy condra debat...@gmail.com added the comment: On Fri, Jun 18, 2010 at 4:53 AM, Antoine Pitrou rep...@bugs.python.org wrote: Antoine Pitrou pit...@free.fr added the comment: Well, like I say, I'm willing to contribute what time and ability allow. Are you thinking of adding a comprehensive wrapper to the ssl module? Hmm, no, I was just providing an existing datapoint to help us deciding on a crypto API. AFAICT this issue hasn't much to do with the ssl module, except perhaps for (positive or negative) inspiration ;-) (and except that it will also - most likely - interface with OpenSSL) The question in my mind then is whether anybody willing to contribute time knows enough about the CryptoAPI, or NSS, or what-have-you, to help craft an API that makes the waterfall model look manageable. If not, I would suggest that we focus on defining and building a lower-level interface along the lines of the PEP noted earlier, integrating that with evpy, and getting it in shape to go into the stdlib. At that point, if demand arises for an even lower level API, we already have the wrapping functions for a lot of the calls into OpenSSL or whatever, and we can build on those in the aforementioned evolutionary fashion. If somebody does, then perhaps a four-tiered model makes more sense, with the bottom one being the raw wrappers around the various libs, the second from the bottom being compatibility shims, and the top two matching the other proposal. Having said that, it's not something I could take on alone. Geremy Condra -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Antoine Pitrou pit...@free.fr added the comment: I would suggest that we focus on defining and building a lower-level interface along the lines of the PEP noted earlier, integrating that with evpy, and getting it in shape to go into the stdlib. That sounds reasonable to me. (although I would be also content with the lower-level interface alone :-)) If somebody does, then perhaps a four-tiered model makes more sense, with the bottom one being the raw wrappers around the various libs, the second from the bottom being compatibility shims, and the top two matching the other proposal. That sounds much too complicated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
geremy condra debat...@gmail.com added the comment: On Fri, Jun 18, 2010 at 5:37 AM, Antoine Pitrou rep...@bugs.python.org wrote: Antoine Pitrou pit...@free.fr added the comment: I would suggest that we focus on defining and building a lower-level interface along the lines of the PEP noted earlier, integrating that with evpy, and getting it in shape to go into the stdlib. That sounds reasonable to me. Great, I'm thinking more-or-less the API proposed in PEP 272- the exception I'm thinking of is that 'strings' should be substituted for 'bytes'- for AES and DES. It gets trickier when talking about public key crypto, though. Perhaps something along the lines of RSA.new(public_key=None, private_key=None,...), with the resulting object supporting encrypt/decrypt/sign/verify operations? (although I would be also content with the lower-level interface alone :-)) If somebody does, then perhaps a four-tiered model makes more sense, with the bottom one being the raw wrappers around the various libs, the second from the bottom being compatibility shims, and the top two matching the other proposal. That sounds much too complicated. If we're likely to have openssl taken out from under us it could save us a lot of hassle to plan for that up front. If not, then why worry, and ISTM we should go the simpler route. Geremy Condra -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
Antoine Pitrou pit...@free.fr added the comment: Great, I'm thinking more-or-less the API proposed in PEP 272- the exception I'm thinking of is that 'strings' should be substituted for 'bytes'- for AES and DES. It gets trickier when talking about public key crypto, though. Perhaps something along the lines of RSA.new(public_key=None, private_key=None,...), with the resulting object supporting encrypt/decrypt/sign/verify operations? I don't have any opinion right now. I think a concrete proposal should be initiated and we can iterate from that. (that's assuming other people agree on the principle, of course) If we're likely to have openssl taken out from under us it could save us a lot of hassle to plan for that up front. It doesn't seem very likely in the middle term. In particular, the ssl module itself is quite tied to OpenSSL's socket wrapping semantics (including error codes and non-blocking behaviour), so OpenSSL will probably still be required for SSL sockets. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
New submission from Mark Dickinson dicki...@gmail.com:
Not a serious bug, but worth noting:
The result of randrange(n) is not even close to uniform for large n. Witness
the obvious skew in the following (this takes a minute or two to run, so you
might want to reduce the range argument):
Python 3.2a0 (py3k:81980, Jun 14 2010, 11:23:36)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type help, copyright, credits or license for more information.
from random import randrange
from collections import Counter
Counter(randrange(6755399441055744) % 3 for _ in range(1))
Counter({1: 37508130, 0: 33323818, 2: 29168052})
(The actual probabilities here are, as you might guess from the above numbers:
{0: 1/3, 1: 3/8, 2: 7/24}.)
The cause: for n 2**53, randrange(n) is effectively computed as int(random()
* n). For small n, there's a tiny bias involved, but this is still an
effective method. However, as n increases towards 2**53, the bias increases
significantly. (For n = 2**53, the random module uses a different strategy
that *does* produce uniformly distributed results.)
A solution would be to lower the cutoff point where randrange() switches from
using int(random() * n) to using the _randbelow method.
--
components: Library (Lib)
messages: 108095
nosy: mark.dickinson, rhettinger
priority: low
severity: normal
status: open
title: Non-uniformity in randrange for large arguments.
type: behavior
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9025
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
New submission from Javier javier.coll...@gmail.com:
What steps will reproduce the problem?
1. Run 'python subcommands.py -h' (attached file)
2. Check the ordering of the subcommands in the output:
subcommands:
{a,c,b,e,d}
a a subcommand help
b b subcommand help
c c subcommand help
d d subcommand help
e e subcommand help
The ordering between brackets is different than the ordering in the one-line
help for each command below. This could be a little confusing to the user.
What is the expected output? What do you see instead?
The expected output would be to use the same ordering in both places. In
particular the same ordering that was used in the code when using the
_SubParsersAction.add_parser method:
subcommands:
{a,b,c,d,e}
a a subcommand help
b b subcommand help
c c subcommand help
d d subcommand help
e e subcommand help
What version of the product are you using? On what operating system?
OS: Ubuntu
Version: source code (rev. 87)
Python: 2.6.5
Please provide any additional information below.
Please have a look at the attached diff. It contains a patch that worked for me
to preserve the ordering used in the code.
To make that possible it uses action._choices_actions (a list) instead of
action.choices (a dictionary).
--
components: Library (Lib)
files: subcommands.py
messages: 108096
nosy: jcollado
priority: normal
severity: normal
status: open
title: [argparse] Subcommands not printed in the same order they were added
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file17704/subcommands.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9026
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Mark Dickinson dicki...@gmail.com added the comment: Note: the number 6755399441055744 is special: it's 0.75 * 2**53, and was deliberately chosen so that the non-uniformity is easily exhibited by looking at residues modulo 3. For other numbers of this size, the non-uniformity is just as bad, but demonstrating the non-uniformity clearly would have taken a little more work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
Javier javier.coll...@gmail.com added the comment: It contains a patch that worked for me to preserve the ordering used in the code. To make that possible it uses action._choices_actions (a list) instead of action.choices (a dictionary). -- keywords: +patch Added file: http://bugs.python.org/file17705/ordered_subcommands.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6884] Impossible to include file in sdist that starts with 'build' on Win32
Chris Withers ch...@simplistix.co.uk added the comment: I guess not... Maybe try catching Tarek on irc or drop him a mail? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6884 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
Changes by Steven Bethard steven.beth...@gmail.com: -- assignee: - bethard nosy: +bethard ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9027] add test_support.run_unittest command line options and arguments
New submission from anatoly techtonik techto...@gmail.com: Need --help, --list options and TestSute.testcase args for test_support.run_unittest User story: I am covering CGIHTTPServer with tests according to http://www.rfc-editor.org/rfc/rfc3875.txt speccy and want to run a single test in a cycle. I am running test cases like: python test_httpservers.py I want to get all available tests in file and execute only the one I need, but test_support.run_unittest doesn't accept any params. python test_httpservers.py --help just runs the test. I propose to: 1. add list option -l, --listlist the names of test to be executed and exit example: python test_httpservers.py --list BaseHTTPServer::command BaseHTTPServer::handler I omit `test_` prefix and `TestCase` suffixes as they don't bear any value and just clutter the console. This is my idealistic view. 2. add arguments of test names with wildcards python test_httpservers.py --list BaseHTTP* BaseHTTPServer::command BaseHTTPServer::handler python test_httpservers.py --list *auth* BaseHTTPServer::handler -- components: Tests messages: 108100 nosy: techtonik priority: normal severity: normal status: open title: add test_support.run_unittest command line options and arguments versions: Python 2.6, Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9027 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Mark Dickinson dicki...@gmail.com added the comment: Here's an example patch that removes any bias from randrange(n) (except for bias resulting from the imperfectness of the core MT generator). I added a small private method to Modules/_randommodule.c to aid the computation. This only fixes one instance of int(random() * n) in the Lib/random.py source; the other instances should be modified accordingly. With this patch, randrange is a touch faster than before (20-30% speedup) for small arguments. Is this worth pursuing? -- keywords: +patch Added file: http://bugs.python.org/file17706/issue9025.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9027] add test_support.run_unittest command line options and arguments
anatoly techtonik techto...@gmail.com added the comment: 3. The final goal is to be able to run single test as: python test_httpservers.py BaseHTTPServer::handler -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9027 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9027] add test_support.run_unittest command line options and arguments
anatoly techtonik techto...@gmail.com added the comment: The example in first post should read: python test_httpservers.py --list *auth* CGIHTTPServerTestCase::authorization (several distractions a minute can drive anyone mad) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9027 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9028] test_support.run_unittest cmdline options and arguments
New submission from anatoly techtonik techto...@gmail.com: Need --help, --list options and TestSute::testcase args for test_support.run_unittest User story: I am covering CGIHTTPServer with tests according to http://www.rfc-editor.org/rfc/rfc3875.txt speccy and want to run a single test in a cycle. I am running test cases like: python test_httpservers.py I want to get all available tests in file and execute only the one, but test_support.run_unittest doesn't accept any params. python test_httpservers.py --help just runs all the tests. I propose to: 1. add list option -l, --listlist the names of test to be executed and exit python test_httpservers.py --list BaseHTTPServer::command BaseHTTPServer::handler CGIHTTPServerTestCase::authorization I omit `test_` prefix and `TestCase` suffixes as they don't hold any value and just clutter the console. My idealistic vision thinks it is better this way. 2. add arguments of test names with wildcards python test_httpservers.py --list BaseHTTP* BaseHTTPServer::command BaseHTTPServer::handler python test_httpservers.py --list *auth* CGIHTTPServerTestCase::authorization 3. The final goal is to be able to run single test as: python test_httpservers.py BaseHTTPServer::handler CGIHTTPServer::url_collapse_path_split ... ok This format will allow to copy/paste single test name for easy execution, which is impossible with current format: test_url_collapse_path_split (__main__.CGIHTTPServerTestCase) ... ok One step to make stdlib module debug more intuitive. -- components: Tests messages: 108104 nosy: techtonik priority: normal severity: normal status: open title: test_support.run_unittest cmdline options and arguments versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9028] test_support.run_unittest cmdline options and arguments
anatoly techtonik techto...@gmail.com added the comment: Damn. I still failed to forge last use case. In should of course read: python test_httpservers.py CGIHTTPServer::url_collapse_path_split CGIHTTPServer::url_collapse_path_split ... ok Wave develops bad habits. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9027] add test_support.run_unittest command line options and arguments
anatoly techtonik techto...@gmail.com added the comment: Too many errors in description. Please close this ticket with #9028 as a superceder. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9027 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9028] test_support.run_unittest cmdline options and arguments
Jean-Paul Calderone exar...@twistedmatrix.com added the comment: These sound more like features for the unittest runner (one of which is implemented already). Also, please don't propagate :: as a namespace separator in Python. That's what . is for. -- nosy: +exarkun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Mark Dickinson dicki...@gmail.com added the comment:
The nonuniformity of randrange has a knock-on effect in other random module
functions. For example, take a sample of 100 elements from
range(6004799503160661), and take the smallest element from that sample. Then
the exact distribution of that smallest element is somewhat complicated, but
you'd expect it to be even with probability very close to 50%. But it turns
out that it's roughly twice as likely to be even as to be odd.
from random import sample
from collections import Counter
population = range(6004799503160661)
Counter(min(sample(population, 100)) % 2 for _ in range(10))
Counter({0: 66810, 1: 33190})
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9025
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9028] test_support.run_unittest cmdline options and arguments
R. David Murray rdmur...@bitdance.com added the comment: Yes, running individual tests has already been implemented as part of unittest (where it belongs): ./python -m unittest test.test_httpservers.BaseHTTPServerTestCase.test_handler . -- Ran 1 test in 0.102s OK The 'TestCase' marks classes that are actually test cases rather than helper classes, and test_ is how unittest determines which methods are test methods and which are support methods. These strings are not fixed from test file to test file, so it is necessary to specify the full name (and should be). the --list option that prints the test name in a cut and paste friendly fashion is somewhat interesting, perhaps you could open a new issue to propose adding that to unittest. If you do open an issue, make michael.foord nosy on it. -- nosy: +r.david.murray resolution: - out of date stage: - committed/rejected status: open - closed type: - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9027] add test_support.run_unittest command line options and arguments
Changes by R. David Murray rdmur...@bitdance.com: -- resolution: - duplicate stage: - committed/rejected superseder: - test_support.run_unittest cmdline options and arguments ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9027 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Mark Dickinson dicki...@gmail.com added the comment: Here's a more careful Python-only patch that fixes the bias in randrange and randint (but not in shuffle, choice or sample). It should work well both for Mersenne Twister and for subclasses of Random that use a poorer PRNG with badly-behaved low-order bits. -- Added file: http://bugs.python.org/file17707/issue9025_v2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
Javier javier.coll...@gmail.com added the comment: While the ordered dict is a nice option, the one-line patch that is attached to the report works in python 2.7 without adding any external dependency. In my opininion, that's interesting for those using argparse with earlier versions of python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9026] [argparse] Subcommands not printed in the same order they were added
R. David Murray rdmur...@bitdance.com added the comment: Sorry, simpler was the wrong choice of word :) Anyway, it's up to Steven. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1368368] prompt_user_passwd() in FancyURLopener masks 401 Unauthorized error page
Senthil Kumaran orsent...@gmail.com added the comment: Fixed in r82068 and r82069. As mentioned in msg107883, this functionality is should not be relied upon. It is present for legacy apps. I have added a NEWS note mentioning that there is a change in behavior (if legacy apps owners can catch it) -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1368368 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6641] datetime.strptime doesn't support %z format ?
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Reopening because the patch introduced a regression with respect to datetime
subclasses:
class DT(datetime): pass
...
DT.strptime('', '')
datetime.datetime(1900, 1, 1, 0, 0)
a DT instance expected. Need tests covering subclasses.
--
stage: committed/rejected - unit test needed
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6641
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6641] datetime.strptime doesn't support %z format ?
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Attaching issue6641b.diff that fixes subclassing issue. Added tests for datetime subclass only to keep the patch focused. Adding tests for datetime and time subclasses will be natural in issue 1100942. -- Added file: http://bugs.python.org/file17708/issue6641b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9028] test_support.run_unittest cmdline options and arguments
Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6641] datetime.strptime doesn't support %z format ?
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Replacing issue6641b.diff after fixing some spelling errors. Thanks, Ezio. -- Added file: http://bugs.python.org/file17709/issue6641b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6641] datetime.strptime doesn't support %z format ?
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: Removed file: http://bugs.python.org/file17708/issue6641b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- assignee: - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6641] datetime.strptime doesn't support %z format ?
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: Added file: http://bugs.python.org/file17710/issue6641b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6641] datetime.strptime doesn't support %z format ?
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: Removed file: http://bugs.python.org/file17709/issue6641b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Will take a look at this in the next few days. Am tempted to just either provide a recipe or provide a new method. That way sequences generated by earlier python's are still reproducible. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9020] 2.7: eval hangs on AIX because sizeof(char) == 32
Sridhar Ratnakumar sridh...@activestate.com added the comment: Ok, I now have a fix for this issue. The reason for sizeof(c) being 4 bytes is because it is defined as `register int` ... and yet `Py_CHARMASK` fails to type-cast `c` to a `char` type, which is exactly what the attached patch does. -- keywords: +patch title: 2.7: eval hangs on AIX - 2.7: eval hangs on AIX because sizeof(char) == 32 Added file: http://bugs.python.org/file17711/tok_get_infinite_loop_fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9020 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: I would prefer to see correct algorithm in stdlib and a recipe for how to reproduce old sequences for the users who care. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9020] 2.7: eval hangs on AIX because sizeof(char) == 32
Sridhar Ratnakumar sridh...@activestate.com added the comment: David, to answer your question How does it behave with the head of the current 2.6 maintenance branch, by the way?, since this bug appears to be in Include/pyctype.h, which file was available only in 2.7+ and 3.x, I don't believe it will reproduce in 2.6 maint branch that doesn't even have pyctype.h. I am also adding Eric Smith, the original author of pyctype.h that got added as a fix for issue5793, to this bug. Eric, I've attached a patch ... can you review it please? -- nosy: +eric.smith versions: +Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9020 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9020] 2.7: eval hangs on AIX
Changes by Sridhar Ratnakumar sridh...@activestate.com: -- title: 2.7: eval hangs on AIX because sizeof(char) == 32 - 2.7: eval hangs on AIX ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9020 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9020] 2.7: eval hangs on AIX
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +loewis stage: - patch review type: resource usage - crash versions: +Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9020 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Add pure Python implementation of datetime module to CPython
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: I've been thinking about this feature request and am starting to question whether it is necessary. Usually we need a pure python version when 1) the python module is developed first, with the subsequent C code needing to match, or 2) we expect a porting issue, or 3) for pedagogical purposes (i.e. showing how heaps work). For example, sets.py preceded setobject.c and ultimately we dropped sets.py. In the case of heapq.py, it was kept because of its teaching value and because some other implementations like Jython used it. In other cases like collections.deque, the pure python version is maintained off-line in an ASPN recipe and we may provide a link to it in the docs. For the datetime module, I don't think we get much value from having pure python and C version in the distribution. The semantics were worked out a long time ago, the algorithms aren't interesting, and other implementations already have their own conforming versions. ISTM, a pure python version in our standard distribution would never be run and rarely looked at. While it may seem like a cool thing to do, no one has actually requested this feature (I use quotes here because no new functionality is added). The addition would be mostly harmless but it would increase the maintenance burden (I know because I've actively maintained pure python equivalents for itertools and it has been a PITA). If this is a step in your development process, I recommend keeping it in a sandbox or publishing it on PyPI. If we were to invest some efforts in writing pure python equivalents, I would like to see the docs include an equivalent of str.split() whose behavior is difficult to fully and correctly describe in plain English. In contrast, the availability of a pure python version of datetime wouldn't add much that isn't already covered in the docs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: FWIW, we spent ten years maintaining the ability to reproduce sequences. It has become an implicit promise. I'll take a look at the patch in the next few days. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Add pure Python implementation of datetime module to CPython
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Let me just add a story to show how an alternate python implementation may be useful for users. As I was porting datetime.py to 3.x, I saw many failures from pickle tests. It was not easy to figure out what was going on because C pickle code was calling buggy Python and pdb was unable to trace the full chain of calls. To work around that, I added sys.modules['_pickle'] = None to my test run and there you go - the problem was found in minutes. I am sure that someone debugging his tzinfo implementation, for example, may find datetime.py easier to work with. The story may be a bit self-serving, but I was against this feature myself, but now I see enough use that I am actually working on it. Yes, the work is in the sandbox, but I want to have py3k working version before I announce it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9020] 2.7: eval hangs on AIX
Eric Smith e...@trueblade.com added the comment: I suppose that's correct, although I have no way to test it. I haven't spent a lot of time looking at the code in tokenizer.c, but if there's a problem with sign-extending signed chars, it wouldn't surprise me if it shows up in more than one place. Does anyone know what other compilers use signed chars? I would think this would be a problem on those platforms, too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9020 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Add pure Python implementation of datetime module to CPython
R. David Murray rdmur...@bitdance.com added the comment: My understanding is that the desire to have pure python versions of standard library modules is to decouple the standard library from dependency on CPython as far as practical. Perhaps all existing Python implementations have dealt with datetime somehow, but what about new implementations? Having a pure Python version would help developers of new implementations get started, even if they later decided to reimplement it more natively (as CPython has done). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6641] datetime.strptime doesn't support %z format ?
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Committed in r82073. -- stage: unit test needed - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9020] 2.7: eval hangs on AIX
Eric Smith e...@trueblade.com added the comment: It would also be good to get a test case for this. I realize it's difficult, but that's the sort of change that might get undone some day by someone going through and optimizing the code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9020 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Add pure Python implementation of datetime module to CPython
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: My understanding is that the desire to have pure python versions of standard library modules is to decouple the standard library from dependency on CPython as far as practical. That is a bit of a broad brush. I do not know of an approved project to give all C modules a pure python equivalent (in fact modules like pickle presented a long-term maintenance problem in that the two versions differed and modules like sets.py were dropped entirelly). Looking at svn.python.org/view/python/trunk/Modules/ I see some which are good candidates and many which aren't. We need to show judgment on which one to do and recognize that maintaining dual code is a heavy maintenance burden and only do so where there is a clear value add. In my judgment, something like str.split() would benefit quite a bit from a pure python equivalent because its spec is somewhat opaque and hidden in C code and because both docs and the test coverage are incomplete. In contrast, I believe that dual code for datetime is a net loss. There is a reason that Uncle Timmy didn't put it in in the first place. Also, for those who haven't tried it before, it is not always easy to get good pure python equivalents (i.e. C iterators check their arguments when first called and Python versions do their argument checking when next() is first called; C functions sometimes do interesting keyword argument handling that cannot be done in pure python; and pure python versions differ in their tracebacks). Also, it's easy to make a mistake and misspecify the pure python version. You're relying on the test suite to catch all semantic differences. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9029] errors='replace' works in IDLE, fails at Windows command line.
New submission from John Van Praag j...@jvp247.com: Platforms: Windows Vista Ultimate 64 bit Python v3.1.2 Goal is to read a tab-separated CSV file. Some records have garbage characters in them. The following code fragment works when the program is run in IDLE, but fails when run from the Windows command line. ... fh_read = open(company_info, encoding='utf_8', errors='replace') fh_write = open(quotes_file, 'w') count = 0 try: rdr = csv.reader(fh_read, delimiter='\t') wrt = csv.writer(fh_write, delimiter='\t', quotechar='', lineterminator='\n') for row in rdr: ... Within IDLE the code works with or without the encoding='utf_8' declaration; and it fails with or without the declaration when run from the Windows command line. The error message from the Windows command line is as follows: 'charmap' codec can't encode character '\u2019' in position 207: character maps to undefined -- components: Windows messages: 108130 nosy: jvanpraag priority: normal severity: normal status: open title: errors='replace' works in IDLE, fails at Windows command line. type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9029 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8972] subprocess.list2cmdline doesn't quote the character
shypike shyp...@sabnzbd.org added the comment: I see your point about passing a command line as a single string instead of a list. Too bad that Popen doesn't just do the obvious thing (assemble the list into a string in a shell/cmd.exe compatible way). Issue 1300 should indeed be reversed. Raising ValueError will result in breaking some existing programs. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8972 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7951] Should str.format allow negative indexes when used for __getitem__ access?
Germán L. Osella Massa gose...@gmail.com added the comment:
I finally managed to get the time to finish the patch that allows negative
indexes inside square brackets so now they work with the same semantics as in a
python expression:
'{0[-1]}'.format(['abc', 'def'])
'def'
'{0[-2]}'.format(['abc', 'def'])
'abc'
'{0[-1][-1]}'.format(['abc', ['def']])
'def'
They work auto-numbered fields too:
'{[-1]}'.format(['abc', 'def'])
'def'
Also, a positive sign is now accepted as part of a valid integer:
'{0[+1]}'.format(['abc', 'def'])
'def'
As a bonus, negatives indexes are also allowed to refer to positional arguments:
'{-1}'.format('abc', 'def')
'def'
'{-2}'.format('abc', 'def')
'abc'
I'm attaching a patch against trunk. I added some tests for this functionality
in test_str.py.
By the way, this code doesn't work anymore:
{[-1]}.format({'-1': 'X'})
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: -1L
But now it behaves in the same way as:
{[1]}.format({'1': 'X'})
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: 1L
I didn't attempt to ignore whitespaces when trying to parse the index as an
integer (to allow that { 0 } can be treated as {0} and {0[1]} as { 0 [ 1
] }) because I'm not sure if this behavior is desirable.
--
keywords: +patch
Added file: http://bugs.python.org/file17712/format_negative_indexes-2.7.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7951
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7951] Should str.format allow negative indexes when used for __getitem__ access?
Changes by Germán L. Osella Massa gose...@gmail.com: Added file: http://bugs.python.org/file17713/format_negative_indexes-3.2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6884] Impossible to include file in sdist that starts with 'build' on Win32
Changes by Tarek Ziadé ziade.ta...@gmail.com: -- components: +Distutils2 versions: -Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6884 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7951] Should str.format allow negative indexes when used for __getitem__ access?
Germán L. Osella Massa gose...@gmail.com added the comment: I forgot to mention that I also made a patch against py3k (was the same code). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1300] subprocess.list2cmdline doesn't do pipe symbols
Jean-Paul Calderone exar...@twistedmatrix.com added the comment: I reverted r60115 from trunk (2.7) in r82075 and from py3k in r82076. -- nosy: +exarkun resolution: fixed - invalid ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9030] ctypes variable limits
Changes by Pauli Rikula pauli.rik...@gmail.com: -- assignee: theller components: ctypes nosy: kumma, theller priority: normal severity: normal status: open title: ctypes variable limits ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9030 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8972] subprocess.list2cmdline doesn't quote the character
Jean-Paul Calderone exar...@twistedmatrix.com added the comment: I've reverted the issue1300 revision from 2.6, 2.7, 3.1, and 3.2. I hope 7839 is resolved soon. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8972 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9031] distutils uses invalid -Wstrict-prototypes flag when compiling C++ extension module
New submission from Matteo Vescovi matteo.vesc...@yahoo.co.uk: Hi, It seems like distutils passes an invalid -Wstrict-prototypes flag when compiling a C++ extension module on Linux (tested on Debian lenny and sid). running build running build_py creating build creating build/lib.linux-i686-2.6 copying presage.py - build/lib.linux-i686-2.6 running build_ext building '_presage' extension creating build/temp.linux-i686-2.6 gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -g -O2 -g -Wall -O2 -fPIC -I../../src/lib -I/usr/include/python2.6 -c presage_wrap.cpp -o build/temp.linux-i686-2.6/presage_wrap.o cc1plus: warning: command line option -Wstrict-prototypes is valid for Ada/C/ObjC but not for C++ g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -L/usr/local/lib -Wl,--as-needed -g -O2 -g -Wall -O2 build/temp.linux-i686-2.6/presage_wrap.o -L../../src/lib/.libs -lpresage -o build/lib.linux-i686-2.6/_presage.so running build_scripts creating build/scripts-2.6 copying and adjusting presage_python_demo - build/scripts-2.6 changing mode of build/scripts-2.6/presage_python_demo from 644 to 755 I did a bit of digging on this one. It looks like distutils reuses whatever flags python was built with. m...@burrow:/usr/lib/python2.5/distutils$ python2.5 Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14) [GCC 4.3.2] on linux2 Type help, copyright, credits or license for more information. import sysconfig sysconfig.get_config_var(CFLAGS) '-fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes' In /usr/lib/python2.5/distutils/unixcompiler.py I found this comment: # XXX Things not currently handled: # * optimization/debug/warning flags; we just use whatever's in Python's # Makefile and live with it. Is this adequate? If not, we might # have to have a bunch of subclasses GNUCCompiler, SGICCompiler, # SunCCompiler, and I suspect down that road lies madness. It would be nice is distutils was smart enough to recognize that a c++ module was being built and to strip the unneeded flags. Please consider this as a wishlist request, as this causes only a warning, not a failure. Cheers, - Matteo -- assignee: tarek components: Distutils messages: 108136 nosy: matteo.vescovi, tarek priority: normal severity: normal status: open title: distutils uses invalid -Wstrict-prototypes flag when compiling C++ extension module type: feature request versions: Python 2.5, Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9030] ctypes variable limits
New submission from Pauli Rikula pauli.rik...@gmail.com: ctypes should have nice interface from which one could get maximum and minimum values etc information about numeric's data types. for integers this is quite trivial, but at least long double is a bit trickier one. -- type: - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9030 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9025] Non-uniformity in randrange for large arguments.
Mark Dickinson dicki...@gmail.com added the comment: Hmm. I hadn't considered the reproducibility problem. Does the module aim for reproducibility across all platforms *and* all versions of Python? Or just one of those? For small n, I think the patched version of randrange(n) produces the same sequence as before with very high probability, but not with certainty. Since that sounds like a recipe for hard-to-find bugs, it might be better to deliberately perturb the outputs somehow so that the sequence is obviously different from before, rather than subtly different. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9025 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9031] distutils uses invalid -Wstrict-prototypes flag when compiling C++ extension module
Changes by Tarek Ziadé ziade.ta...@gmail.com: -- priority: normal - low versions: -Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9031 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9020] 2.7: eval hangs on AIX
Sridhar Ratnakumar sridh...@activestate.com added the comment: On 2010-06-18, at 11:47 AM, Eric Smith wrote: Eric Smith e...@trueblade.com added the comment: I suppose that's correct, although I have no way to test it. I have tested it on Linux 64-bit by running `test.regrtest`. It doesn't seem to break anything. I haven't spent a lot of time looking at the code in tokenizer.c, but if there's a problem with sign-extending signed chars, it wouldn't surprise me if it shows up in more than one place. My conclusive understanding of the problem: `register int` is 4 bytes in size, and this (`c`) is used without any cast as an index to the array _Py_ctype_table (in pyctype.c) ... by passing it to `Py_CHARMASK` which, if CHAR_UNSIGNED is defined (as is the case with AIX compiler), *assumes* that `c` will always be a char. And that assumption is not respected by tokenizer.c:tok_get which (indirectly) passes `register int` to this macro. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9020 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9020] 2.7: eval hangs on AIX
Sridhar Ratnakumar sridh...@activestate.com added the comment: On 2010-06-18, at 11:49 AM, Eric Smith wrote: It would also be good to get a test case for this. I realize it's difficult, but that's the sort of change that might get undone some day by someone going through and optimizing the code. Running existing tests (some of which use `eval`) on a platform/compiler combination (eg: AIX/xlc_r) where __CHAR_UNSIGNED__ gets defined should be enough. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9020 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9009] Improve quality of Python/dtoa.c
Mark Dickinson dicki...@gmail.com added the comment: r82079: Apply a version of the parsing patch to pull the parsing code out into a separate function. Alexander, I agree about the names; I'll do a mass renaming later on. I'm trying not to mix the significant algorithm-changing commits with trivial renaming/reindenting/commenting commits, to make it easier to review each independent change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9009 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9009] Improve quality of Python/dtoa.c
Eric Smith e...@trueblade.com added the comment: It would be easier for me to review if you did it in the other order: fix the variable names first. Although I'm still pretty busy and won't have much time to review, so my needs shouldn't be your first priority. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9009 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7951] Should str.format allow negative indexes when used for __getitem__ access?
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Perhaps this ought to be discussed on python-ideas or python-dev for a bit. It is not entirely clear that this is a GoodThingToDo(tm) nor is it clear that we want other Python implementations to have to invest the same effort. The spirit of the language freeze suggests that we shouldn't add this unless we really need it. The goal was to let other implementations catch up, not to add to their list of incompatabilites. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7951] Should str.format allow negative indexes when used for __getitem__ access?
Eric Smith e...@trueblade.com added the comment: I agree with Raymond. I'm not convinced it allows you to write any code that you can't currently write, and I'm fairly sure it violates the moratorium. Implementing this would clearly put a burden on other implementations. Marking as after moratorium. -- keywords: +after moratorium -patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1744] readline module - set/get quote delimiters
Cédric Delfosse ced...@delfosse.org added the comment: Here is an updated patch against current trunk. It also contains documentation update and a unit test. -- nosy: +cdelfosse Added file: http://bugs.python.org/file17714/trunk-readline.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1744 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9032] xmlrpc: Transport.request() should also catch socket.error(EPIPE)
New submission from STINNER Victor victor.stin...@haypocalc.com: Since Python 2.7 / 3.2, httplib supports HTTP(S)/1.1 (keep-alive). This version of HTTP is much faster because the connection is kept between two requests. I'm using it with XML-RPC + SSL (M2Crypto). It works nice. My problem is when the server closes the connection (eg. the server restarts). If I send a small (XML-RPC) request, sending the request works (I don't understand why, maybe because of a buffer somewhere), but getting the response raises a BadStatusLine because the response is empty (0 byte). If I send a big (XML-RPC) request, sending the request fails with a SSLError(EPIPE, '...') and Transport.request() doesn't retry with a new connection. I patched my copy of M2Crypto to ensure that SSLError inherits from socket.error, but it's not enough: Transport.request() only catchs errno.ECONNRESET and errno.ECONNABORTED socket errors. Attached patch catchs also errno.EPIPE. This error is received on sending to the socket whereas the server closed the socket. -- components: Library (Lib) files: xmlrpc_request_epipe.patch keywords: patch messages: 108146 nosy: haypo priority: normal severity: normal status: open title: xmlrpc: Transport.request() should also catch socket.error(EPIPE) versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file17715/xmlrpc_request_epipe.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9032 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9032] xmlrpc: Transport.request() should also catch socket.error(EPIPE)
STINNER Victor victor.stin...@haypocalc.com added the comment: See also r70643 (from issue #5542): Remove special logic that closes HTTPConnection socket on EPIPE. If the socket is closed, the client has no chance to read the response from the server. EPIPE means that it isn't possible to write more data from the socket, but not that it is impossible to read. This commit didn't updated the following comment. I think that it should be fixed (maybe removed?) because the socket is no more closed on broken pipe error. # send the data to the server. if we get a broken pipe, then close # the socket. we want to reconnect when somebody tries to send again. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9032 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9020] 2.7: eval hangs on AIX
Martin v. Löwis mar...@v.loewis.de added the comment: Does anyone know what other compilers use signed chars? Most of them do, including gcc, on most platforms. unsigned char is really the uncommon case. The patch is incorrect; Py_CHARMASK is correct as it stands. It is *not* the objective of Py_CHARMASK to produce a char, but (as the comment above its definition explains) to produce an int. The question really is why you get a value of -1 into c in the first place. Could it be that you are past the end of file, and reading EOF characters? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9020 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue850997] mbcs encoding ignores errors
STINNER Victor victor.stin...@haypocalc.com added the comment: Close this issue: nothing special on the buildbots. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue850997 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4352] imp.find_module() fails with a UnicodeDecodeError when called with non-ASCII search paths
STINNER Victor victor.stin...@haypocalc.com added the comment:
I closed issue #850997, mbcs is now really strict by default:
'h\u00e4kkinen'.encode('mbcs')
UnicodeEncodeError: ...
'h\u00e4kkinen'.encode('mbcs', 'replace')
b'hakkinen'
PyUnicode_EncodeFSDefault(), PyUnicode_DecodeFSDefault() and os.fsencode() use
mbcs with strict error handler on Windows. On other OS, these functions use
surrogateescape error handler, but mbcs only supports strict and replace (to
encode, and strict and ignore to decode).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4352
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8775] Use locale encoding to decode sys.argv, not the file system encoding
STINNER Victor victor.stin...@haypocalc.com added the comment: Attached patch is a draft adding a new encoding: command line encoding. It is used to encode (subprocess) and decode (python) the command line arguments. It adds sys.getcmdlineencoding(). -- keywords: +patch Added file: http://bugs.python.org/file17716/cmdline_encoding.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8949] PyArg_Parse*(): z should not accept bytes
STINNER Victor victor.stin...@haypocalc.com added the comment: @lemburg: So what is your opinion on this issue? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created
Changes by STINNER Victor victor.stin...@haypocalc.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8775] Use locale encoding to encode command line arguments (subprocess, os.exec*(), etc.)
Changes by Martin v. Löwis mar...@v.loewis.de: -- title: Use locale encoding to decode sys.argv, not the file system encoding - Use locale encoding to encode command line arguments (subprocess, os.exec*(), etc.) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8775] Use locale encoding to encode command line arguments (subprocess, os.exec*(), etc.)
Martin v. Löwis mar...@v.loewis.de added the comment: I'm still -1, failing to see the problem that is solved. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8775] Use locale encoding to encode command line arguments (subprocess, os.exec*(), etc.)
STINNER Victor victor.stin...@haypocalc.com added the comment: I'm still -1, failing to see the problem that is solved. I know (and I agree), but I don't want to loose the patch :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8939] Use C type names (PyUnicode etc;) in the C API docs
STINNER Victor victor.stin...@haypocalc.com added the comment: r82084 (in 3.2 and r82085 in 3.1) fixes some of the reported issues. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8939 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8863] Segfault handler: display Python backtrace on segfault
STINNER Victor victor.stin...@haypocalc.com added the comment: New version of the patch: - catch also SIGFPE - add segfault.o to Makefile.pre.in - use abort() to quit instead of _exit(1) - call DebugBreak() on Windows before the abort(), as done by Py_FatalError() TODO: Patch configure to only enable segfault handler if sigaltstack() is available. The alternate stack is maybe not needed for the SIGFPE handler. -- Added file: http://bugs.python.org/file17717/segfault_handler-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8998] add crypto routines to stdlib
geremy condra debat...@gmail.com added the comment: On Fri, Jun 18, 2010 at 6:05 AM, Antoine Pitrou rep...@bugs.python.org wrote: Antoine Pitrou pit...@free.fr added the comment: Great, I'm thinking more-or-less the API proposed in PEP 272- the exception I'm thinking of is that 'strings' should be substituted for 'bytes'- for AES and DES. It gets trickier when talking about public key crypto, though. Perhaps something along the lines of RSA.new(public_key=None, private_key=None,...), with the resulting object supporting encrypt/decrypt/sign/verify operations? I don't have any opinion right now. I think a concrete proposal should be initiated and we can iterate from that. (that's assuming other people agree on the principle, of course) I assume that by a concrete proposal you're talking about code? Or API docs? Also, what more needs to be done to ensure that other people agree on the principle? If we're likely to have openssl taken out from under us it could save us a lot of hassle to plan for that up front. It doesn't seem very likely in the middle term. In particular, the ssl module itself is quite tied to OpenSSL's socket wrapping semantics (including error codes and non-blocking behaviour), so OpenSSL will probably still be required for SSL sockets. I'm fine with doing it the simpler way and adding in support for other systems PRN. Having said that, Martin, if this is high priority for you let me know. Geremy Condra -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Add pure Python implementation of datetime module to CPython
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: I was probably misled by Brett's assertion that 'it's not a matter of if but when datetime will get a pure Python version.' (msg106498) It looks like this is not a universally shared opinion. I am not ready to form a final opinion on datetime.py. I have ported it to 3.2 to the point where it passes the regression tests, but did not attempt to clean up the code in any way or match C implementation on the level of doc strings and error messages. I am attaching the diff between PyPy-2.7 and 3.2 port as issue7989-2.7-3.2.diff here. You can find the full source in the sandbox/py3k-datetime at r82083. I think having a working implementation will help making a decision here. Here are some random thoughts based on the experience with datetime.py. The datetime module have seen very little development in the last six years. Tracker RFEs and bug reports were languishing for years while people have been ranting about how much better other languages handle date/time than Python. Python-dev discussions would run into dozens of posts with an inevitable conclusion that the situation is a mess and cannot be fixed. It is posible that one of the reasons for the current state of affairs was that people with the problem domain expertise did not have C skills and people with the requisite C skills were conditioned by the C approach to time which is an even bigger mess than what we have. I cannot rule out that if datetime.py was easily available, we would see more patches proposed and more informed discussions about desired features. Raymond argues that datetime documentation is good enough and python implementation will not add to it. I disagree. Consider this passage from tzinfo documentation: When a datetime object is passed in response to a datetime method, dt.tzinfo is the same object as self. tzinfo methods can rely on this, unless user code calls tzinfo methods directly. Is this as clear as the following code that makes use of this? def fromutc(self, dt): .. if dt.tzinfo is not self: raise ValueError(dt.tzinfo is not self) Documentation for datetime module is indeed extensive. The reST file is over 1700 lines long. This is comparable to about 1900 lines in datetime.py (not counting a long treatise on timezone calculations at the end of the file.) It may be easier to find an answer in the code than in the documentation. After all you cannot step through documentation in a debugger. I am still between -0 and +0 about including datetime.py in the main tree. For my own development purposes having sandbox version is adequate and maintaining it there is easier than in-tree. It would be great, however if this discussion would lead to clear guidelines about cases when parallel C and Python implementations are desired and how to maintain such arrangements -- Added file: http://bugs.python.org/file17718/issue7989-2.7-3.2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8990] array constructor and array.fromstring should accept bytearray.
Terry J. Reedy tjre...@udel.edu added the comment:
Summary: real bug, needs test, patch provided, looks plausible but I am not
qualified to even read-review it, let alone apply and test.
(I am removing 3.3 because that is only listed for syntax feature requests that
cannot go into 3.2 because of its moratorium on such.)
I agree that this is a bug. For 3.1, the '8.6. array' doc says
class array.array(typecode[, initializer])
A new array whose items are restricted by typecode, and initialized from the
optional initializer value, which must be a list, object supporting the buffer
interface, or iterable over elements of the appropriate type.
I believe bytearray 'supports the buffer interface', whatever that means in
3.x. 'Readonly' is definitely *not* specified. Even if bytearray did not
qualify on that, instances are *definitely* iterable.
The doc goes on: If given a list or string, the initializer is passed to the
new array’s fromlist(), fromstring(), or fromunicode() method (see below) to
add initial items to the array. Otherwise, the iterable initializer is passed
to the extend() method.
For 3.x, this is pretty bad as it is copied without change from 2.x and uses
'string' in the 2.x sense. It seems to me that fromstring/fromunicode should
have been renamed to frombytes/fromstring with a 2to3 fixer. Too late now, I
suppose. However, if indeed 'fromstring' is intended to mean 'from bytes only
and not bytearrays', then bytearrays should be passed on to .extend, which
accepts them as well as anything else.
from array import array
a=array('h')
a.extend(bytearray(b'xjxjx'))
a
array('h', [120, 106, 120, 106, 120])
The two possible fixes:
1. Extend .fromstring to accept bytearrays. Its current doc Appends items from
the string, interpreting the string as an array of machine values to me
supports doing that. This is what Thomas's patch does.
2. If that is rejected, then bytearray initializers should be passed to .extend.
Thomas: a complete patch needs to include a update to the array unit test
suite. This can then move to the patch review stage.
--
nosy: +tjreedy
stage: - unit test needed
versions: -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8990
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8990] array constructor and array.fromstring should accept bytearray.
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Thomas' patch does more than just allow bytearray. It allows any object that can present itself as a buffer with byte-size items. It is a bit unfortunate that such method will end up being called fromstring in 3.x.With string being unicode, this is hopelessly ambiguous. Is the string interpreted as array of bytes, UTF-8 style, 16 or 32-bit integers? It would be much better to have frombuffer, and even better extendfrombuffer method with this functionality. I am +1 on Terry's option 2. It may be possible to optimize .extend to detect objects that support buffer interface and bypass iterator protocol. Of course, when receiving array is not type 'b', extend and fromxyz are not the same, so maybe we should just rename fromunicode to fromstring and fromstring to frombytes? -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8990 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
