[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

Ezio Melotti ezio.melo...@gmail.com added the comment: Benjamin already replaced hasattr(x, __call__) with hasattr(type(x), __call__) in the Python 3.0 What's New in r75090 and r75094, but this still doesn't match completely the behavior of callable(): class Foo(object): pass ... foo = Foo()

[issue7042] test_signal fails on os x 10.6

Jan Hosang jan.hos...@gmail.com added the comment: This is a 64 bit machine and the test failed for the checkout of the python26-maint branch. I just configured and made it without any flags. (Does that produce a 64 bit build?) -- ___ Python

[issue7019] unmarshaling of artificial strings can produce funny longs.

Mark Dickinson dicki...@gmail.com added the comment: 2.6 fix applied in r75203. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7019 ___

[issue7045] utf-8 encoding error

Martin v. Löwis mar...@v.loewis.de added the comment: I can't reproduce that; it prints fine for me. Notice that it is perfectly fine for Python to represent this as two code points in UCS-2 mode (so that len(s)==2); this is called UTF-16. -- nosy: +loewis

[issue7042] test_signal fails on os x 10.6

Ned Deily n...@acm.org added the comment: By default, 10.6 prefers to run 64-bit architectures when available. You can easily tell whether a python 2.x is running as 32-bit or 64-bit by checking sys.maxint: $ /usr/local/bin/python2.6 -c 'import sys; print sys.maxint' 2147483647 $

[issue7033] C/API - Document exceptions

Georg Brandl ge...@python.org added the comment: Sounds like a useful new API. Two comments: * The version without *base* is not needed. Passing an explicit NULL for *base* is easy enough. * The name PyErr_Create is needlessly different from PyErr_NewException. Something like

[issue7042] test_signal fails on os x 10.6

Jan Hosang jan.hos...@gmail.com added the comment: $ ./python.exe -c 'import sys; print sys.maxint' 9223372036854775807 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7042 ___

[issue7045] utf-8 encoding error

Ezio Melotti ezio.melo...@gmail.com added the comment: I can't reproduce it either on Ubuntu 9.04 32-bit. I tried both from the terminal and from the file, using Py3.2a0. As Martin said, the fact that in narrow builds of Python the codepoints outside the BMP are represented with two surrogate

[issue7028] Add int.hex for symmetry with float.hex

Mark Dickinson dicki...@gmail.com added the comment: Rejecting the request to add int.hex. I've added a note to the hex() docs pointing to float.hex(), in revisions r75025 through r75028. It doesn't really seem worth adding pointers from float.hex and float.fromhex back to integer analogues:

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

Trundle andy-pyt...@hammerhartes.de added the comment: As every type is an instance of `type`, every type also has a `__call__` attribute which means ``hasattr(type(x), '__call__')`` is always true. `callable()` checks whether `tp_call` is set on the type, which cannot be done in Python

[issue7045] utf-8 encoding error

Arc Riley arcri...@gmail.com added the comment: Python 3.1.1 (r311:74480, Sep 13 2009, 22:19:17) [GCC 4.4.1] on linux2 Type help, copyright, credits or license for more information. import sys sys.maxunicode 1114111 u = 'ё' print(u) Traceback (most recent call last): File stdin, line 1, in

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

New submission from Stefan Krah stefan-use...@bytereef.org: In many cases, decimal.py sets InvalidOperation instead of DivisionImpossible or DivisionUndefined. Mark, could I persuade you to isolate these cases by running a modified deccheck2.py from mpdecimal (See attachment), which does not

[issue7047] decimal.py: NaN payload conversion

New submission from Stefan Krah stefan-use...@bytereef.org: decimal.py sets InvalidOperation if the payload of a NaN is too large: c = getcontext() c.prec = 4 c.create_decimal(NaN12345) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.7/decimal.py,

[issue7047] decimal.py: NaN payload conversion

Changes by Stefan Krah stefan-use...@bytereef.org: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7047 ___ ___

[issue7048] decimal.py: logb: round the result if it is greater than prec

New submission from Stefan Krah stefan-use...@bytereef.org: from decimal import * c = getcontext() c.prec = 2 c.logb(Decimal(1E123456)) Decimal('123456') This result agrees with the result of decNumber, but the spec says: All results are exact unless an integer result does not fit in the

[issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1

New submission from Stefan Krah stefan-use...@bytereef.org: If precision 1 is aupported, the following results should not be NaN: Python 2.7a0 (trunk:74738, Sep 10 2009, 11:50:08) [GCC 4.3.2] on linux2 Type help, copyright, credits or license for more information. from decimal import *

[issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1

Changes by Stefan Krah stefan-use...@bytereef.org: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7049 ___ ___

[issue2821] unittest.py sys.exit error

Mark Fitzgerald mark.fitzgera...@sympatico.ca added the comment: Agreed that this is clearly not a bug. One way to get the desired behavior from IDLE is to move up to Python 2.7a0+ or Python 3.1.1+, where the 'exit' parameter of unittest.main(), which when set to False, disables the sys.exit()

[issue7050] (x,y) += (1,2) crashes IDLE

New submission from Mark Fitzgerald mark.fitzgera...@sympatico.ca: Start up IDLE. Type (x,y) += (1,2) (without the double-quotes), then press Enter. IDLE unexpectedly terminates without message, pop-up, or warning. Admittedly, this line of code is likely not legal, but shouldn't it just raise

[issue7050] Augmented assignment of tuple crashes IDLE

Changes by Mark Fitzgerald mark.fitzgera...@sympatico.ca: -- title: (x,y) += (1,2) crashes IDLE - Augmented assignment of tuple crashes IDLE ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7050

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Mark Dickinson dicki...@gmail.com added the comment: Just to be clear, the decimal context doesn't (and shouldn't) know about DivisionImpossible: there's no DivisionImpossible signal or trap described in the specification, but just a DivisionImpossible heading in the 'exceptional

[issue7047] decimal.py: NaN payload conversion

Mark Dickinson dicki...@gmail.com added the comment: This is essentially the same issue as issue 7046: the relevant lines in decimal.py read: if d._isnan() and len(d._int) self.prec - self._clamp: return self._raise_error(ConversionSyntax,

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Mark Dickinson dicki...@gmail.com added the comment: Closed issue 7047 as a duplicate of this one: _raise_error(ConversionSyntax) also raises (if trapped) the InvalidOperation exception, when it could reasonably raise ConversionSyntax instead. It's the same cause as above: _raise_error

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Changes by Mark Dickinson dicki...@gmail.com: -- assignee: - mark.dickinson priority: - normal stage: - needs patch type: - behavior versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org

[issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1

Mark Dickinson dicki...@gmail.com added the comment: This behaviour was deliberate: since the standard doesn't cover three- argument pow, I more-or-less made up my own rules here. :) In this case, I (somewhat arbitrarily) decided that to ensure that any possible pow(a, b, m) result could be

[issue7048] decimal.py: logb: round the result if it is greater than prec

Mark Dickinson dicki...@gmail.com added the comment: Hmm. The problem here is that the specification says nothing at all about what should happen if the integer result does *not* fit in the available precision, so in this case we went with the decNumber behaviour. Rather than rounding, I'd

[issue5911] built-in compile() should take encoding option.

Naoki INADA songofaca...@gmail.com added the comment: add sample implementation. -- keywords: +patch Added file: http://bugs.python.org/file15030/compile_with_encoding.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5911

[issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1

Mark Dickinson dicki...@gmail.com added the comment: Unless anyone else disagrees, I'm going to call this a 'won't fix': I'm happy with the current behaviour. I would like to relax the condition on the modulus from 'modulus 10**prec' to 'modulus = 10**prec', though, so I'm leaving the

[issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1

Mark Dickinson dicki...@gmail.com added the comment: Here's a patch. -- keywords: +patch Added file: http://bugs.python.org/file15031/issue7049.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7049

[issue7051] 'g'/'G' format docs need a little more explanation

New submission from Benjamin Peterson benja...@python.org: The docs for 'g' say This prints the number as a fixed-point number, unless the number is too large. Could you please explain what exactly constitutes too large? -- assignee: eric.smith messages: 93504 nosy: benjamin.peterson,

[issue7051] 'g'/'G' format docs need a little more explanation

Changes by Mark Dickinson dicki...@gmail.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7051 ___ ___ Python-bugs-list

[issue7050] Augmented assignment of tuple crashes IDLE

Amaury Forgeot d'Arc amaur...@gmail.com added the comment: From the plain console: a, b +=2 SystemError: invalid node type (24) for augmented assignment Python 3.0 used to be correct: SyntaxError: illegal expression for augmented assignment -- assignee: - benjamin.peterson nosy:

[issue7050] Augmented assignment of tuple crashes IDLE

Benjamin Peterson benja...@python.org added the comment: Good catch! Fixed in r75223. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7050 ___

[issue7051] 'g'/'G' format docs need a little more explanation

Mark Dickinson dicki...@gmail.com added the comment: For 'g' formatting (either {} style or %-style) with precision p = 1, I believe fixed- point is used if and only if the formatted value satisfies 1e-4 = abs(formatted_value) 10**precision. Note that the 'formatted value' refers to the

[issue6992] PEP 314 inconsistency (authors/author/maintainer)

anatoly techtonik techto...@gmail.com added the comment: I wonder what does Guido think about this bikeshed? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6992 ___

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Stefan Krah stefan-use...@bytereef.org added the comment: Thanks for the explanation, and I agree that decimal.py is perfectly correct. I based the report on the fact that decNumber updates the context status with e.g. Division_impossible. But Division_impossible is one of the flags that form

[issue5395] array.fromfile not checking I/O errors

Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5395 ___ ___ Python-bugs-list

[issue7045] utf-8 encoding error

Amaury Forgeot d'Arc amaur...@gmail.com added the comment: The page: http://www.fileformat.info/info/unicode/char/d801/index.htm has a big warning saying that U+D801 is not a valid unicode character. The problem is similar to issue6697, and lead to the same question: should python validate

[issue6697] Python 3.1 segfaults when invalid UTF-8 characters are passed from command line

Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6697 ___ ___ Python-bugs-list

[issue7049] decimal.py: NaN result in pow(x, y, z) with prec 1

Stefan Krah stefan-use...@bytereef.org added the comment: I don't think early abortion based on m and the current precision is a good idea. Then we have the situation that this works (prec=4): (Decimal(7) ** 2) % 10 But this does not: pow(Decimal(7), 2, 10) --

[issue1462525] URI parsing library

Paul Jimenez p...@place.org added the comment: Senthil wrote: Senthil orsent...@gmail.com added the comment: Hello Paul, Have you beeing keeping track of urlparse changes in Python2.6? No - do you have pointers to the particular changes you're referring to? I've done a bit of trying

[issue7045] utf-8 encoding error

Arc Riley arcri...@gmail.com added the comment: Amaury, you are absolutely correct, \ud801 is not a valid unicode glyph, however I am not giving Python \ud801, I am giving Python 'ё' (== '\U00010451'). I am attaching a different short example that demonstrates that Python is mishandling UTF-8

[issue7045] utf-8 encoding error

Adam Olsen rha...@gmail.com added the comment: I believe this is a duplicate of issue #3297. When given a high unicode scalar value directly in the source (rather than in escaped form) python will split it into surrogates, even on a UTF-32 build where those surrogates are nonsensical and

[issue7045] utf-8 encoding error

Arc Riley arcri...@gmail.com added the comment: This behavior is identical whether u.py or u.pyc is run on my systems, where that previous ticket concerns differing behavior. Though it is obviously related. -- versions: -Python 2.6, Python 3.0 ___

[issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created

Adam Olsen rha...@gmail.com added the comment: Looks like the failure mode has changed here, presumably due to issue #3672 patches. It now always fails, even after loading from a .pyc. This is using py3k via bzr, which reports itself as 3.2a0 $ rm unicodetest.pyc $ ./python -c 'import

[issue6963] Add worker process lifetime to multiprocessing.Pool - patch included

Charles Cazabon charlesc-pyt...@pyropus.ca added the comment: Jesse: this is ready for your review now. Thanks, Charles -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6963 ___

[issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created

Adam Olsen rha...@gmail.com added the comment: I've traced down the biggest problem to decode_unicode in ast.c. It needs to convert everything into a form of escapes so it becomes pure ascii, which then become evaluated back into a unicode object. Unfortunately, it uses UTF-16-BE to do so,