[issue2477] parser support for future import of unicode_strings
New submission from Neal Norwitz [EMAIL PROTECTED]: This is a patch that modifies the parser to allow getting the future import flags into the AST. There are 2 approaches that are embedded within the patch. Both approaches can be seen in Python/pythonrun.c. 1) update_flags_from_node() - this pulls the __future__ import out of the parser nodes. It is not complete, but should give an idea of how this approach could be generalized. 2) Add APIS such as PyParser_ParseFileFlagsEx that returns the flags from the parser The first approach is somewhat fragile and kinda breaks encapsulation. It's nice that all the changes are internal and localized. The second approach is probably a better long term solution, but adds even more APIs where there are already too many. -- components: Interpreter Core files: uni-strs.diff keywords: patch messages: 64458 nosy: nnorwitz priority: critical severity: normal status: open title: parser support for future import of unicode_strings versions: Python 2.6 Added file: http://bugs.python.org/file9844/uni-strs.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2477 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1054434] automatic XMLRPC boxcarring via multicall for xmlrpclib
Ralf Schmitt [EMAIL PROTECTED] added the comment: I personally have no need for it (not even for non-automatic boxcarring). Note that you would also have to write documentation. -- type: - feature request versions: +Python 2.6 -Python 2.5 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1054434 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2330] Update PEP 3000 with new release schedule
Georg Brandl [EMAIL PROTECTED] added the comment: PEP 3000 refers to PEP 361 which has the schedule for both 2.6 and 3.0. -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2330 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2355] Using buffer() should raise a Py3K warning
Georg Brandl [EMAIL PROTECTED] added the comment: Added test and committed as r61878. -- nosy: +georg.brandl resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2355 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning
Georg Brandl [EMAIL PROTECTED] added the comment: I'd say that since this is so easy for a fixer to spot and fix, no convoluted effort to add a Py3k warning is necessary. (The same goes for sys.exitfunc, #2356). -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2357 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning
Jack Diederich [EMAIL PROTECTED] added the comment: +1, I'll burn my _apply_evil(ModuleObject *) function patch to moduleobject.c which did a memcpy on a type object and several other heresies. On Tue, Mar 25, 2008 at 4:27 AM, Brett Cannon [EMAIL PROTECTED] wrote: Brett Cannon [EMAIL PROTECTED] added the comment: I agree with Georg; a 2to3 fixer is enough. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2357 __ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2357 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2476] optparse docs should mention %default being new in 2.4
Georg Brandl [EMAIL PROTECTED] added the comment: Fixed in r61882. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2476 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2477] parser support for future import of unicode_strings
Christian Heimes [EMAIL PROTECTED] added the comment: I'll check it out today. -- assignee: - tiran nosy: +tiran __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2477 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2359] A Py3K warning for array.array.{read,write} is needed
Georg Brandl [EMAIL PROTECTED] added the comment: Committed patch as r61881. -- nosy: +georg.brandl resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2359 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2477] parser support for future import of unicode_strings
Changes by Eric Smith [EMAIL PROTECTED]: -- nosy: +eric.smith __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2477 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251748] compiler package: global a; a=5
Armin Rigo [EMAIL PROTECTED] added the comment: Thanks Antoine for the clarification. The situation is that by now PyPy has found many many more bugs in trying to use the compiler package to run the whole stdlib and real-world applications. What I can propose is to extract what we have got and put it back into CPython's stdlib, keeping the current documented API. This will require a little bit of work (e.g. first finishing to add all new 2.5 and 2.6 features into PyPy's compiler) but IMHO it's more worthwhile than going through the process of rediscovering and fixing all the current bugs one by one. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251748 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2470] Need fixer for dl (removed) - ctypes module
Thomas Heller [EMAIL PROTECTED] added the comment: In the simplest case, convert import dl libc = dl.open(libc.so.6) iconv = libc.call(iconv_open, ISO-8859-1, ISO-8859-2) print(iconv) to import ctypes libc = ctypes.CDLL(libc.so.6) iconv = libc.iconv_open(ISO-8859-1, ISO-8859-2) print(iconv) Notice that dlobject.call has up to 11 arguments, the first one being the function name. Thomas, is it the case that all calls to dl.call can be converted to a ctypes call without parameter conversion? dl supports these parameter types: - byte string, passed as char* - integers, passed as int - None, passed as NULL Yes, this is correct. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2470 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2478] decimal.Decimal( 0 ).sqrt() fails
Changes by glathoud [EMAIL PROTECTED]: -- components: Library (Lib) nosy: glathoud severity: normal status: open title: decimal.Decimal( 0 ).sqrt() fails type: crash versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2478 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2478] decimal.Decimal( 0 ).sqrt() fails
New submission from glathoud [EMAIL PROTECTED]: I got a crash with Python 2.5.2 : Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import decimal decimal.Decimal( 0 ).sqrt() Traceback (most recent call last): File stdin, line 1, in module File f:\Python25\lib\decimal.py, line 2330, in sqrt return ans._fix(context) File f:\Python25\lib\decimal.py, line 1461, in _fix Etiny = context.Etiny() AttributeError: 'NoneType' object has no attribute 'Etiny' __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2478 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2477] parser support for future import of unicode_strings
Christian Heimes [EMAIL PROTECTED] added the comment: I've carefully examined both version. I agree that update_flags_from_node is too fragile. I haven't verified my theory but I *think* the current code does neither support from __future__ import egg, spam nor from __future__ import egg from __future__ import spam The PyParser_ParseFileFlagsEx() is easier and more stable. I'll go with it. By the way I also like your name unicode_strings. Should we stay with it or use my idea unicode_literals? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2477 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2472] Fixed block ordering code in compiler.pyassem
Antoine Pitrou [EMAIL PROTECTED] added the comment: Neal, I don't have sufficient permissions to assign bugs to anybody, but here you are in the nosy list. :) -- nosy: +nascheme __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2472 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251748] compiler package: global a; a=5
Antoine Pitrou [EMAIL PROTECTED] added the comment: Armin, it would be nice to merge back your work indeed. If you submit a patch I can take a look at it. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251748 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2479] Bytearray and io backport
New submission from Christian Heimes [EMAIL PROTECTED]: Fix the remaining tests and merge the branch into 2.6 svn+ssh://[EMAIL PROTECTED]/python/branches/trunk-bytearray So far 5 unit tests are failing. Two are related to pickling/copy and two to subclassing. -- components: Interpreter Core, Library (Lib), Tests keywords: 26backport messages: 64475 nosy: tiran priority: critical severity: normal status: open title: Bytearray and io backport versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2479 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2477] parser support for future import of unicode_strings
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: The flag should be named unicode_literals since that what changes. Unicode strings are already available in Python 2.x :-) BTW: I'm not convinced that these future imports are all that useful - the ratio between usefulness and added complexity leans a lot towards the latter. -- nosy: +lemburg __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2477 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2224] branches/trunk-math patch
Changes by Christian Heimes [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9594/trunk-math.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2224 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2224] branches/trunk-math patch
Christian Heimes [EMAIL PROTECTED] added the comment: Merge Mark's and my math branch into 2.6. IMHO it's ready and stable but I like to get the opinion of yet another core developer first. Merge recipe Since svnmerge.py causes too many conflicts I've created a patch. However the patch doesn't include copied files from the trunk-math branch. In order to apply the patch one has to copy some files from the trunk-math branch into the trunk. COPY: Python/pymath.c Include/pymath.h Lib/test/cmath_testcases.txt Lib/test/ieee754.txt DELETE: Python/hypot.c Objects/doubledigits.c -- priority: high - critical Added file: http://bugs.python.org/file9845/trunk-math-integration.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2224 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2026] test_largefile.py converted to unittest
Giampaolo Rodola' [EMAIL PROTECTED] added the comment: Uh! This report is still open. Facundo could you close it? :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2026 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2478] decimal.Decimal( 0 ).sqrt() fails
Changes by Georg Brandl [EMAIL PROTECTED]: -- assignee: - rhettinger nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2478 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2477] parser support for future import of unicode_strings
Christian Heimes [EMAIL PROTECTED] added the comment: Working patch I had to introduce yet another PyParser Ex method for string parsing. I also renamed the future feature to unicode_literals Added file: http://bugs.python.org/file9846/unicode_literals.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2477 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2477] parser support for future import of unicode_strings
Changes by Ralf Schmitt [EMAIL PROTECTED]: -- nosy: +schmir __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2477 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2478] decimal.Decimal( 0 ).sqrt() fails
Mark Dickinson [EMAIL PROTECTED] added the comment: I'll fix this. -- nosy: +marketdickinson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2478 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2480] pickling of recursive sets of objects fails
New submission from Daniel Darabos [EMAIL PROTECTED]: In the attached demo I create a graph of 250 nodes, all of which are connected to every other node, and this is represented by a set attribute of the Node objects. When I try to pickle this graph, it fails in various ways. In regular pickle it is always a maximum recursion depth exceeded error. In cPickle it is either a KeyError or a silent termination of the process. (As tested on Windows XP 32 bits.) It depends on the size of the graph. For smaller graphs (say 100 nodes) it works fine. If connections are described using a dictionary or even a list, I get the same errors. -- components: Library (Lib) files: bugdemo.py messages: 64481 nosy: cyhawk severity: normal status: open title: pickling of recursive sets of objects fails versions: Python 2.5 Added file: http://bugs.python.org/file9847/bugdemo.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2480 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1524825] ConfigParser: accept leading whitespace on options+comments
Quentin Gallet-Gilles [EMAIL PROTECTED] added the comment: Didn't think a few days would translate into a month. My bad! Anyway, here's the promised patch. -- keywords: +patch Added file: http://bugs.python.org/file9848/cfgparser_comments.patch _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1524825 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2478] decimal.Decimal( 0 ).sqrt() fails
Changes by Mark Dickinson [EMAIL PROTECTED]: -- versions: +Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2478 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2443] uninitialized access to va_list
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
This is not a bug. All the reported functions expect va_list argument
to be initialized before being called. AFAICT, they are consistently
used in this way. For example,
PyObject *
PyObject_CallFunctionObjArgs(PyObject *callable, ...)
{
PyObject *args, *tmp;
va_list vargs;
if (callable == NULL)
return null_error();
/* count the args */
va_start(vargs, callable);
args = objargs_mktuple(vargs);
va_end(vargs);
if (args == NULL)
return NULL;
tmp = PyObject_Call(callable, args, NULL);
Py_DECREF(args);
return tmp;
}
This may need to be clarified in the docs. For example, PyString_FromFormatV
does not mention that vargs needs to be
initialized: http://docs.python.org/dev/c-
api/string.html#PyString_FromFormatV. On the other hand, this may be
obvious to most C programmers.
I suggest to close this issue as invalid.
--
nosy: +belopolsky
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2443
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2481] locale.strxfrm does not work with Unicode strings
New submission from Christoph Zwerschke [EMAIL PROTECTED]: While locale.strcoll seems to work with Unicode strings, locale.strxfrm gives a UnicodeError. Example: ### try: locale.setlocale(locale.LC_ALL, 'de') except locale.Error: # Windoof locale.setlocale(locale.LC_ALL, 'german') s = ['Ägypten', 'Zypern'] print sorted(s, cmp=locale.strcoll) # works print sorted(s, key=locale.strxfrm) # works s = [u'Ägypten', u'Zypern'] print sorted(s, cmp=locale.strcoll) # works print sorted(s, key=locale.strxfrm) # UnicodeError ### Therefore, it is not possible to sort lists of Unicode strings effectively. If possible, this should be fixed. If not possible, this problem should at least be mentioned in the documentation. Currently, the docs do not indicate that strcoll and strxfrm behave differently concerning Unicode. -- components: Unicode messages: 64484 nosy: cito severity: normal status: open title: locale.strxfrm does not work with Unicode strings type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2481 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2478] decimal.Decimal( 0 ).sqrt() fails
Mark Dickinson [EMAIL PROTECTED] added the comment: Fixed in r61892 (2.6) and r61893 (2.5). Thanks for the report! This bug exposes a flaw in the decimal testsuite: the thousands of testcases in Lib/test/decimaltestdata are only ever run with an explicitly given context. Would it be worth having an option to run (almost all) these tests with an implicit context as well, or even to do this by default in addition to the explicit context testing? -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2478 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1714] ConfigParser.py do not allow leading (and trailing) space in values.
Changes by Quentin Gallet-Gilles [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9217/cfgparser_doublequotes.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1714 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2481] locale.strxfrm does not work with Unicode strings
Changes by Georg Brandl [EMAIL PROTECTED]: -- assignee: - loewis nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2481 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2477] parser support for future import of unicode_strings
Nick Coghlan [EMAIL PROTECTED] added the comment: The patch actually isn't all that complicated - the main structural change to make it possible to process the strings correctly is converting the parser functions to have treat the flags argument as an I/O variable, rather than just an input. Other than that, there are just some fairly straightforward updates to the compiler to take advantage of the additional flag information now available from the parser. Being able to write significant pieces of code that run on both 2.6 and 3.0 without modification will be a big win in my opinion. While 2to3 will still be a valuable migration tool, especially for one-way migrations, it will be far far easier to support 2.6 and 3.0 in parallel if that pseudo-compilation step isn't necessary. Also Christian - the posted patch accidentally included your hack to make the version info a bit more non-SVN checkout friendly. -- nosy: +ncoghlan __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2477 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2443] uninitialized access to va_list
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On the second thought the macro dance highlighted by OP belongs to pyport.h. Attached patch defines Py_VA_COPY macro and uses it to simplify va_list copying code. -- keywords: +patch Added file: http://bugs.python.org/file9849/issue2443.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2443 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2482] Decimal(unicode)
New submission from Oleg Broytmann [EMAIL PROTECTED]: Decimal(u'123').to_eng_string() returns unicode in Python 2.5.2. That's probably due to the optimization in decimal module, after which decimal stores coefficient (mantissa) as a str, and doesn't coerce input to str. See the thread at http://mail.python.org/pipermail/python-dev/2008-March/078189.html -- components: Library (Lib) messages: 64488 nosy: phd severity: normal status: open title: Decimal(unicode) type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2482 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2482] Decimal(unicode)
Changes by Mark Dickinson [EMAIL PROTECTED]: -- assignee: - marketdickinson nosy: +marketdickinson versions: +Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2482 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2431] 2to3 is rather slow
Collin Winter [EMAIL PROTECTED] added the comment: With the patch applied, all tests in test_fixers fail. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2431 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2482] Decimal(unicode)
Facundo Batista [EMAIL PROTECTED] added the comment: Decimal needs to grow something like the following near the top of the module: try: _bytes = bytes except NameError: # 2.5 or earlier _bytes = str and then use _bytes instead of str as appropriate throughout the rest of the module. This will solve the actual problem, and scales well with 2.6 and 3k. -- nosy: +facundobatista __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2482 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2478] decimal.Decimal( 0 ).sqrt() fails
Facundo Batista [EMAIL PROTECTED] added the comment: It'd be nice to have it, but actually I'm not sure that this is doable without some heavy editing of decimal's test framework. Thanks! -- nosy: +facundobatista __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2478 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2480] pickling of large recursive structures fails
Daniel Darabos [EMAIL PROTECTED] added the comment: So now I've learned that this is a result of the way Pickler is implemented. I think that it would make sense to create an implementation that is not that recursive and that would handle such structures better. I have now written one such implementation that is a subclass of the original pickler and handles recursive data structures. I presume that it is inferior in a couple of ways (performance and memory efficiency probably), but a complete rewrite could probably create an implementation that handles recursive data structures and is not inferior. -- title: pickling of recursive sets of objects fails - pickling of large recursive structures fails Added file: http://bugs.python.org/file9850/nonrecursivepickler.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2480 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2480] pickling of large recursive structures fails
Changes by Daniel Darabos [EMAIL PROTECTED]: Added file: http://bugs.python.org/file9851/picklertest.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2480 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2480] pickling of large recursive structures fails
Changes by Ralf Schmitt [EMAIL PROTECTED]: -- nosy: +schmir __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2480 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1714] ConfigParser.py do not allow leading (and trailing) space in values.
Changes by Ralf Schmitt [EMAIL PROTECTED]: -- nosy: +schmir __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1714 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2480] pickling of large recursive structures fails
Daniel Darabos [EMAIL PROTECTED] added the comment: Sidenote: If I click edit for nonrecursivepickler.py, I get told that File has been classified as spam. Strange. Should I not use Viagra as a classname? :) (j/k I didn't do anything like that) However I have now fixed a mistake in my code. Added file: http://bugs.python.org/file9852/nonrecursivepickler-fixed.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2480 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2483] int and float accept bytes, complex does not
New submission from Mark Dickinson [EMAIL PROTECTED]: In 3.0, the int and float constructors accepts bytes instances as well as strings: int(b'1') 1 float(b'1') 1.0 but the complex constructor doesn't: complex(b'1') Traceback (most recent call last): File stdin, line 1, in module TypeError: complex() argument must be a string or a number I'd suggest that at least one of these three results is a bug, but I'm not sure which. From a purity point of view, I think int() and float() shouldn't accept bytes. Is this a case of practicality beats purity? What are the pratical reasons to have int() and float() accept bytes? Once this is resolved, the behaviors of Decimal and Fraction should also be considered. -- components: Interpreter Core messages: 64494 nosy: marketdickinson severity: normal status: open title: int and float accept bytes, complex does not type: behavior versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2483 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2431] 2to3 is rather slow
David Wolever [EMAIL PROTECTED] added the comment: Ah, yea -- in my rush to catch my train I must have neglected to look at the _results_ of running test.py... I have updated the patch so the fixers will work. Added file: http://bugs.python.org/file9853/fixer_head_node_lookup_2.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2431 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251748] compiler package: global a; a=5
Neil Schemenauer [EMAIL PROTECTED] added the comment: On Tue, Mar 25, 2008 at 09:18:38AM +, Armin Rigo wrote: The situation is that by now PyPy has found many many more bugs in trying to use the compiler package to run the whole stdlib and real-world applications. What I can propose is to extract what we have got and put it back into CPython's stdlib, keeping the current documented API. I'm not sure it can go back into the stdlib since there doesn't seem to be enough energy available to keep it up-to-date with the Python release schedule. I would like to make it available as an add-on package. This will require a little bit of work (e.g. first finishing to add all new 2.5 and 2.6 features into PyPy's compiler) but IMHO it's more worthwhile than going through the process of rediscovering and fixing all the current bugs one by one. Indeed it would make no sense to redo that work. Can the version in the PyPy tree be used as a direct replacement for the stdlib version or does it need some changes? You had mentioned being able to produce a patch against the stdlib version. Is that easy or would it be better just to take the PyPy version and package it up. Neil _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251748 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2477] parser support for future import of unicode_strings
Christian Heimes [EMAIL PROTECTED] added the comment: Also Christian - the posted patch accidentally included your hack to make the version info a bit more non-SVN checkout friendly. I'm still learning bzr. I just have figured out how to merge changes from the upstream trunk into my branch. It's actually nice ... __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2477 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2483] int and float accept bytes, complex does not
Nick Coghlan [EMAIL PROTECTED] added the comment: I have a couple of use cases for bytes-as-ASCII-text - int, one of which also touches on floats. The other numeric types also accepting bytes as representing ASCII encoded strings would then follow from a consistency of behaviour argument. Use case 1: Decimal implementation The simplest way to retain the 2.x series decimal performance in 3.0 is to switch the mantissa storage from a string to a bytes object. This is only possible if the int constructor accepts bytes objects and treats them as an ASCII-encoded string. Use case 2: Serial protocols with embedded ASCII text I work with a lot of control protocols for different pieces of hardware, and one way the hardware vendors avoid having to write a custom control interface for their hardware is to make their serial interface human readable (so a terminal program like Hyperterminal or Miniterm becomes their user interface). Writing automated control software for these devices is essentially an exercise in screen-scraping the ASCII strings received on the serial port. Having to go through Unicode to convert ASCII digits embedded in these strings to numbers would be a major pain. While these numbers are mostly integers, you do get the occasional floating point value turning up as well, so bytes-float can also be useful. -- nosy: +ncoghlan __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2483 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2484] Cosmetic patch for warning unused variable
New submission from Hirokazu Yamamoto [EMAIL PROTECTED]: int i,j; in inner block is hiding Py_ssize_t i,j; -- components: Extension Modules files: fix_warning.patch keywords: patch, patch messages: 64499 nosy: ocean-city severity: normal status: open title: Cosmetic patch for warning unused variable versions: Python 3.0 Added file: http://bugs.python.org/file9854/fix_warning.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2484 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2443] uninitialized access to va_list
Christian Heimes [EMAIL PROTECTED] added the comment: Looks like a good idea to me -- priority: high - critical resolution: - accepted __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2443 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2431] 2to3 is rather slow
Collin Winter [EMAIL PROTECTED] added the comment: The updated version of the patch passes the tests and yields a 19-20% speed increase in the running time of test_all_fixers and the time taken for 2to3 to translate itself. I've sent David some comments on the patch, and once it's cleaned up some, this will be checked in. I'd like to keep the issue open, since there are clearly additional speed increases to be made. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2431 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2484] Cosmetic patch for warning unused variable
Georg Brandl [EMAIL PROTECTED] added the comment: This seems to be already fixed in trunk. Can you confirm? -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2484 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup loops with better bytecode
Changes by Gregory P. Smith [EMAIL PROTECTED]: -- nosy: +gregory.p.smith __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2459 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2443] Define Py_VA_COPY macro as a cross-platform replacement for gcc __va_copy
Changes by Alexander Belopolsky [EMAIL PROTECTED]: -- title: uninitialized access to va_list - Define Py_VA_COPY macro as a cross-platform replacement for gcc __va_copy type: compile error - feature request __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2443 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup loops with better bytecode
Changes by Fred L. Drake, Jr. [EMAIL PROTECTED]: __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2459 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup loops with better bytecode
Changes by Fred L. Drake, Jr. [EMAIL PROTECTED]: __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2459 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2483] int and float accept bytes, complex does not
Mark Dickinson [EMAIL PROTECTED] added the comment: For both these use cases, don't you still have a problem going the other way, from an integer back to bytes? Is there an easier way than bytes(str(n), 'ascii') ? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2483 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2482] Decimal(unicode)
Mark Dickinson [EMAIL PROTECTED] added the comment: I'm not sure that converting to bytes for Python 3.0 is going to be a simple change. For one thing, most of the arithmetic functions have to do the reverse conversion (int - str/bytes) at some point. At the moment, an int - bytes conversion has to go through unicode (I think); something like bytes(str(n), 'ascii'), so it's not 100% clear that replacing str with bytes is going to produce a speed gain. For now, I'll get the fix for the 2.5/2.6 problem in (it only involves changing 3 lines in decimal.py, along with adding a few extra tests). Changing str - bytes in 3.0 needs more careful thought, and some benchmarking. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2482 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2482] Decimal(unicode)
Mark Dickinson [EMAIL PROTECTED] added the comment: str - unicode regression fixed in r61904, r61906. (I backported the fix to 2.5; it's not absolutely clear that it's worth it, but this *is* a bug, and it seems worth not letting the various decimal.py versions diverge too much.) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2482 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup loops with better bytecode
Antoine Pitrou [EMAIL PROTECTED] added the comment: By the way, the compiler package fix has been isolated and cleaned up as part of #2472. Maybe it would be nice to start with that one. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2459 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251748] compiler package: global a; a=5
Antoine Pitrou [EMAIL PROTECTED] added the comment: It seems to me that releasing it as a third-party package would be a little contradictory, since the compiler package is supposed to follow the CPython core (compile.c etc.) evolutions. In any case, whatever the decision (stdlib package or separate releases), I think it would be nice if there was a slightly more comprehensive test suite. :) Something like running some selected non-controversial parts of the test suite compiled with the compiler package (like PyPy does apparently) could be a good start. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251748 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2477] parser support for future import of unicode_strings
Christian Heimes [EMAIL PROTECTED] added the comment: Slightly better patch * removed bzr hack * simplified parsestr() * updated NEWS Added file: http://bugs.python.org/file9855/unicode_literals2.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2477 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2390] Merge 2.6 ACKS with 3.0 ACKS
Benjamin Peterson [EMAIL PROTECTED] added the comment: Since the ACKS have changed since I did this merge, shall I remerge and commit the changes to both branches? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2026] test_largefile.py converted to unittest
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2026 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2390] Merge 2.6 ACKS with 3.0 ACKS
Christian Heimes [EMAIL PROTECTED] added the comment: Yes, please sync the ACKS files again. -- assignee: tiran - benjamin.peterson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2390] Merge 2.6 ACKS with 3.0 ACKS
Benjamin Peterson [EMAIL PROTECTED] added the comment: Commited in r61913 and r61914. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2390] Merge 2.6 ACKS with 3.0 ACKS
Christian Heimes [EMAIL PROTECTED] added the comment: For the record You don't have to merge changes from 2.6 to 3.0 manually. In fact you mustn't unless you explicitly block the revision with svnmerge.py. In general you submit a change to 2.6 and it gets merged into 3.0 later. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2390] Merge 2.6 ACKS with 3.0 ACKS
Benjamin Peterson [EMAIL PROTECTED] added the comment: On Tue, Mar 25, 2008 at 4:17 PM, Christian Heimes [EMAIL PROTECTED] wrote: Christian Heimes [EMAIL PROTECTED] added the comment: For the record You don't have to merge changes from 2.6 to 3.0 manually. In fact you mustn't unless you explicitly block the revision with svnmerge.py. In general you submit a change to 2.6 and it gets merged into 3.0 later. Thanks for the heads up. Should I block the revision then? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __ Added file: http://bugs.python.org/file9856/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __brbrdiv class=gmail_quoteOn Tue, Mar 25, 2008 at 4:17 PM, Christian Heimes lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; wrote:brblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; br Christian Heimes lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; added the comment:br br For the recordbr br You don#39;t have to merge changes from 2.6 to 3.0 manually. In fact youbr mustn#39;t unless you explicitly block the revision with svnmerge.py. Inbr general you submit a change to 2.6 and it gets merged into 3.0 later./blockquotedivThanks for the heads up. Should I block the revision then? br/divblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; br divdiv/divdiv class=Wj3C7cbr __br Tracker lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;br lt;a href=http://bugs.python.org/issue2390; target=_blankhttp://bugs.python.org/issue2390/agt;br __br /div/div/blockquote/divbrbr clear=allbr-- brCheers,brBenjamin Peterson ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2390] Merge 2.6 ACKS with 3.0 ACKS
Christian Heimes [EMAIL PROTECTED] added the comment: I think I'll follow a different path here. I may end up with svn rm Misc/ACKS svn copy ../trunk/Misc/ACKS Misc/ It should make future merges easier. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2390] Merge 2.6 ACKS with 3.0 ACKS
Benjamin Peterson [EMAIL PROTECTED] added the comment: On Tue, Mar 25, 2008 at 4:23 PM, Christian Heimes [EMAIL PROTECTED] wrote: Christian Heimes [EMAIL PROTECTED] added the comment: I think I'll follow a different path here. I may end up with svn rm Misc/ACKS svn copy ../trunk/Misc/ACKS Misc/ That's what I did. They are exactly the same file. It should make future merges easier. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __ Added file: http://bugs.python.org/file9857/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __brbrdiv class=gmail_quoteOn Tue, Mar 25, 2008 at 4:23 PM, Christian Heimes lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; wrote:brblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; br Christian Heimes lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; added the comment:br br I think I#39;ll follow a different path here. I may end up withbr br svn rm Misc/ACKSbr svn copy ../trunk/Misc/ACKS Misc//blockquotedivThat#39;s what I did. They are exactly the same file. br/divblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; br br It should make future merges easier.br br __br Tracker lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;br lt;a href=http://bugs.python.org/issue2390; target=_blankhttp://bugs.python.org/issue2390/agt;br __br /blockquote/divbrbr clear=allbr-- brCheers,brBenjamin Peterson ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2481] locale.strxfrm does not work with Unicode strings
Martin v. Löwis [EMAIL PROTECTED] added the comment: FWIW, this is fixed in Python 3.0. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2481 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2390] Merge 2.6 ACKS with 3.0 ACKS
Changes by Benjamin Peterson [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9856/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2485] Traceback changed in 2.6 for unhashable objects
New submission from Martin Geisler [EMAIL PROTECTED]: The traceback message given when trying to hash unhashable objects has changed from Python 2.5 to 2.6: Python 2.5.2a0 (r251:54863, Feb 10 2008, 01:31:28) hash([]) Traceback (most recent call last): File stdin, line 1, in module TypeError: list objects are unhashable Python 2.6a1 (r26a1:61143, Mar 25 2008, 19:41:30) hash([]) Traceback (most recent call last): File stdin, line 1, in module TypeError: unhashable type: 'list' This breaks my Doctests unless I add a somewhat ugly # doctest: +IGNORE_EXCEPTION_DETAIL comment, so if this is not done on purpose, I would prefer Python 2.6 to output the same as 2.5. -- messages: 64517 nosy: mg severity: normal status: open title: Traceback changed in 2.6 for unhashable objects type: behavior versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2485 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2390] Merge 2.6 ACKS with 3.0 ACKS
Changes by Benjamin Peterson [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9857/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2390] Merge 2.6 ACKS with 3.0 ACKS
Christian Heimes [EMAIL PROTECTED] added the comment: Are you absolutely sure you have used svn copy? The logs don't show a svn copy. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2390] Merge 2.6 ACKS with 3.0 ACKS
Benjamin Peterson [EMAIL PROTECTED] added the comment: On Tue, Mar 25, 2008 at 4:29 PM, Christian Heimes [EMAIL PROTECTED] wrote: Christian Heimes [EMAIL PROTECTED] added the comment: Are you absolutely sure you have used svn copy? The logs don't show a svn copy. Oh, no. I copied with cp, so svn doesn't know about it. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __ Added file: http://bugs.python.org/file9858/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2390 __brbrdiv class=gmail_quoteOn Tue, Mar 25, 2008 at 4:29 PM, Christian Heimes lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; wrote:brblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; br Christian Heimes lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; added the comment:br br Are you absolutely sure you have used quot;svn copyquot;? The logs don#39;t show abr svn copy./blockquotedivOh, no. I copied with cp, so svn doesn#39;t know about it. br/divblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; br br __br Tracker lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;br lt;a href=http://bugs.python.org/issue2390; target=_blankhttp://bugs.python.org/issue2390/agt;br __br /blockquote/divbrbr clear=allbr-- brCheers,brBenjamin Peterson ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2486] Consider using bytes type instead of str to store Decimal coefficients
New submission from Mark Dickinson [EMAIL PROTECTED]: The Python 3.0 version of decimal.py currently stores the coefficient of a Decimal number (or the payload of a NaN) as a string, all of whose characters are in the range '0' through '9'. It may be more time-efficient to store the coefficient as a bytes instance instead, since bytes - int conversion is likely to be faster than str - int conversion. On the other hand, int - bytes conversion has to go through str, so may be significantly slower than int - str conversion... Bottom line: this needs testing. One other option: it may even be worth considering storing the coefficient directly as a Python integer. I've argued against this before, on the basis that it makes direct access to the decimal digits of a number harder, and this direct access is useful for rounding as well as for some of the more esoteric Decimal operations (logical operations, shifts and rotations). But it may be worth a look. (I think it's clear what the *right* option is, given unlimited developer time and energy: decimal.py should represent the coefficient using a long integer implementation written in C, with wordsize a power of 10---probably either 10**4 or 10**9.) See related discussion at issue 2482 and at http://mail.python.org/pipermail/python-dev/2008-March/078189.html -- components: Library (Lib) messages: 64521 nosy: facundobatista, marketdickinson, ncoghlan severity: normal status: open title: Consider using bytes type instead of str to store Decimal coefficients type: performance versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2486 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2482] Decimal(unicode)
Mark Dickinson [EMAIL PROTECTED] added the comment: The original bug here is fixed, so I'm closing this issue. I've opened a separate issue (issue 2486) for discussing changing the Decimal coefficient from str to bytes. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2482 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2443] uninitialized access to va_list
Rolland Dudemaine [EMAIL PROTECTED] added the comment:
This is what I meant. The initialization should be done by calling
va_start(count_va); as you described.
In the files and lines I reported though, this is not called.
I'll file a patch for it soon.
--Rolland Dudemaine
Alexander Belopolsky wrote:
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
This is not a bug. All the reported functions expect va_list argument
to be initialized before being called. AFAICT, they are consistently
used in this way. For example,
PyObject *
PyObject_CallFunctionObjArgs(PyObject *callable, ...)
{
PyObject *args, *tmp;
va_list vargs;
if (callable == NULL)
return null_error();
/* count the args */
va_start(vargs, callable);
args = objargs_mktuple(vargs);
va_end(vargs);
if (args == NULL)
return NULL;
tmp = PyObject_Call(callable, args, NULL);
Py_DECREF(args);
return tmp;
}
This may need to be clarified in the docs. For example, PyString_FromFormatV
does not mention that vargs needs to be
initialized: http://docs.python.org/dev/c-
api/string.html#PyString_FromFormatV. On the other hand, this may be
obvious to most C programmers.
I suggest to close this issue as invalid.
--
nosy: +belopolsky
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2443
__
--
title: Define Py_VA_COPY macro as a cross-platform replacement for gcc
__va_copy - uninitialized access to va_list
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2443
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2481] locale.strxfrm does not work with Unicode strings
Martin v. Löwis [EMAIL PROTECTED] added the comment: Sure, although it probably shouldn't be backported to 2.5. -- versions: +Python 2.6 -Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2481 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2457] add --help and -h options to pdb
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- assignee: - benjamin.peterson priority: - low __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2457 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2457] add --help and -h options to pdb
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- assignee: benjamin.peterson - georg.brandl nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2457 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2470] Need fixer for dl (removed) - ctypes module
Thomas Heller [EMAIL PROTECTED] added the comment: Thomas Heller schrieb: Thomas Heller [EMAIL PROTECTED] added the comment: In the simplest case, convert import dl libc = dl.open(libc.so.6) iconv = libc.call(iconv_open, ISO-8859-1, ISO-8859-2) print(iconv) to import ctypes libc = ctypes.CDLL(libc.so.6) iconv = libc.iconv_open(ISO-8859-1, ISO-8859-2) print(iconv) Currently, in py3k, ctypes only passed bytes objects as char*; so the strings should be translated to bytes literals: import ctypes libc = ctypes.CDLL(libc.so.6) iconv = libc.iconv_open(bISO-8859-1, bISO-8859-2) # ^ ^ print(iconv) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2470 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2487] ldexp(x,n) misbehaves when abs(n) is large
New submission from Fredrik Johansson [EMAIL PROTECTED]: Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. from math import ldexp from sys import maxint ldexp(1.234, maxint//2) Traceback (most recent call last): File stdin, line 1, in module OverflowError: math range error ldexp(1.234, maxint) 0.0 ldexp(1.234, -maxint) 0.0 ldexp(1.234, -maxint-2) Traceback (most recent call last): File stdin, line 1, in module OverflowError: long int too large to convert to int The first and third cases seem right. The second is clearly a bug. In the fourth case, it would be more correct to return 0.0 than to raise an exception IMHO. -- components: Library (Lib) messages: 64527 nosy: fredrikj severity: normal status: open title: ldexp(x,n) misbehaves when abs(n) is large type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2487 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2488] Backport sys.maxsize to Python 2.6
New submission from Christian Heimes [EMAIL PROTECTED]: See topic -- components: Extension Modules keywords: 26backport, easy messages: 64528 nosy: tiran priority: high severity: normal status: open title: Backport sys.maxsize to Python 2.6 type: feature request versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2488 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2487] ldexp(x,n) misbehaves when abs(n) is large
Christian Heimes [EMAIL PROTECTED] added the comment: ldexp(1.234, maxint) works as expected in our trunk-math branch. ldexp(1.234, -maxint-2) fails with the same error message. -- assignee: - marketdickinson nosy: +marketdickinson, tiran priority: - normal versions: +Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2487 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2488] Backport sys.maxsize to Python 2.6
Ryan Freckleton [EMAIL PROTECTED] added the comment: Here's a patch including docstring and NEWS update for this backport. -- keywords: +patch nosy: +ryan.freckleton Added file: http://bugs.python.org/file9859/patch.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2488 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2486] Consider using bytes type instead of str to store Decimal coefficients
Mark Dickinson [EMAIL PROTECTED] added the comment: Here's a first try at a patch that converts the Decimal coefficient from type str to type bytes. It needs some work: here are some timings for a complete run of the test suite (best of 3 in each case) on my MacBook. Python 3.0, str: 12.880s Python 3.0, bytes: 13.294s Python 2.6: 9.279s Python 2.5: 9.212s There's still some room for speedup with the bytes patch, but at the moment it doesn't look as though performance alone is a compelling reason to make this change. -- keywords: +patch Added file: http://bugs.python.org/file9860/decimal_bytes.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2486 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2487] ldexp(x,n) misbehaves when abs(n) is large
Mark Dickinson [EMAIL PROTECTED] added the comment: I agree that the second and fourth cases are bugs. The second case looks like a Windows only problem: I get the expected OverflowError on both OS X 10.5.2/Intel and SuSE Linux 10.2/i686. The fourth case is cross-platform, and occurs also for large exponents: ldexp(1.234, maxint+1) Traceback (most recent call last): File stdin, line 1, in module OverflowError: long int too large to convert to int It's still present in Python 3.0. I'll take a look. -- versions: +Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2487 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2489] Patch for bugs in pty.py
New submission from Fergus Henderson [EMAIL PROTECTED]: The attached patch fixes some bugs in the pty.py module: - spawn() would not wait for the invoked process to finish. Also, it did not return a meaningful value, so there was no way to tell if the invoked process failed.After this patch, spawn() now waits for the invoked process, and returns the value returned from os.waitpid(). - There was a bug in the _copy() loop that caused it to spin using 100% CPU rather than blocking after EOF was reached on one of the two file descriptors that it was waiting for. -- components: Library (Lib) files: pty.py.patch keywords: patch messages: 64533 nosy: fergushenderson severity: normal status: open title: Patch for bugs in pty.py type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9861/pty.py.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2489 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2489] Patch for bugs in pty.py
Guilherme Polo [EMAIL PROTECTED] added the comment: Hi Fergus, I would suggest using if not data to check for EOF -- nosy: +gpolo __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2489 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2489] Patch for bugs in pty.py
Fergus Henderson [EMAIL PROTECTED] added the comment: On Tue, Mar 25, 2008 at 9:22 PM, Guilherme Polo [EMAIL PROTECTED] wrote: I would suggest using if not data to check for EOF Good idea. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2489 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup loops with better bytecode
Antoine Pitrou [EMAIL PROTECTED] added the comment: This new patch also updates the code generation for list comprehensions. Here are some micro-benchmarks: ./python -m timeit -s l = range(100) [x for x in l] Before: 10 loops, best of 3: 14.9 usec per loop After: 10 loops, best of 3: 12.5 usec per loop ./python -m timeit -s l = range(100) [x for x in l if x] Before: 1 loops, best of 3: 24.1 usec per loop After: 10 loops, best of 3: 18.8 usec per loop ./python -m timeit -s l = range(100) [x for x in l if not x] Before: 10 loops, best of 3: 15.5 usec per loop After: 10 loops, best of 3: 11.9 usec per loop Please note that this patch is orthogonal with Neal's patch in #2183, so the two combined should be quite interesting for the list comprehensions bytecode. Added file: http://bugs.python.org/file9863/loops5.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2459 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2486] Consider using bytes type instead of str to store Decimal coefficients
Nick Coghlan [EMAIL PROTECTED] added the comment: Hmm, I forgot there wasn't currently a direct path back from int - bytes. I think your numbers *do* show that we need to do something about the performance of the Python 3.0 version of decimal. A 25% increase in runtime is a pretty big performance hit. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2486 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2490] Assertion failure in datetime.strftime()
Benjamin Peterson [EMAIL PROTECTED] added the comment: Can you give us an example of the data that caused the failure? -- nosy: +benjamin.peterson type: - behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2490 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2491] io.open() handles errors differently on different platforms
New submission from Neal Norwitz [EMAIL PROTECTED]: The attached file has a snapshot of the python.org homepage that was causing test_urllibnet to fail on some platforms (2 sparc, and ia64 at least), but not other platforms. This should be handled consistently. I don't know if there are really errors in the attached web page or not. The problem occurs at byte offset 13259: data[13250:13270] 'r - Journ\xc3\xa9es Python' I suppose that's invalid for ASCII, but valid UTF-8. See r61921. There is a problem that the API for fdopen doesn't accept errors, encoding, etc. so it's problematic to handle this condition. -- components: Library (Lib) files: py-org.html messages: 64540 nosy: nnorwitz priority: critical severity: normal status: open title: io.open() handles errors differently on different platforms type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9864/py-org.html __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2491 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2484] Cosmetic patch for warning unused variable
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment: I've confirmed trunk doesn't have this problem. Probably this is merge issue. r57928 changed the position of int i,j in py3k, but not changed in trunk, so when r61864 was merged into py3k some kind of conflict happened. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2484 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
