[issue6760] patch to subprocess docs to better explain Popen's 'args' argument

Changes by Chris Rebert : Removed file: http://bugs.python.org/file14817/subprocess.rst.patch ___ Python tracker ___ ___ Python-bugs-list maili

[issue6760] patch to subprocess docs to better explain Popen's 'args' argument

Chris Rebert added the comment: Ok, changed to "note" directives instead of "warning"s. Anything else that keeps this from being applied? -- Added file: http://bugs.python.org/file15033/subprocess.rst.patch ___ Python tracker

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

Adam Olsen 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, which always split s

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

Charles Cazabon added the comment: Jesse: this is ready for your review now. Thanks, Charles -- ___ Python tracker ___ ___ Python-bu

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

Adam Olsen 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 unicodetest' Result: Fa

[issue7045] utf-8 encoding error

Arc Riley 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 ___ Python tracker

[issue7045] utf-8 encoding error

Adam Olsen 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 ill-formed. Patches fo

[issue7045] utf-8 encoding error

Arc Riley 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 on both the interact

[issue1462525] URI parsing library

Paul Jimenez added the comment: Senthil wrote: > > Senthil 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 to catch up by searching t

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

Stefan Krah 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) -- ___ P

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

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue7045] utf-8 encoding error

Amaury Forgeot d'Arc 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 utf-8 input, and refu

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

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Stefan Krah 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 IEEE_754_Invalid_operation, s

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

anatoly techtonik added the comment: I wonder what does Guido think about this bikeshed? -- ___ Python tracker ___ ___ Python-bugs-lis

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

Mark Dickinson 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 value rounded to p

[issue7050] Augmented assignment of tuple crashes IDLE

Benjamin Peterson added the comment: Good catch! Fixed in r75223. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue7050] Augmented assignment of tuple crashes IDLE

Amaury Forgeot d'Arc 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: +amaury.forgeotdar

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

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

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

New submission from Benjamin Peterson : 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, eric.smith severi

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

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

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

Mark Dickinson 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 issue open for that.

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

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

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

Mark Dickinson 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 say that a more use

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

Mark Dickinson 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 represented, m shou

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Changes by Mark Dickinson : -- 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 ___

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Mark Dickinson 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 translates each excep

[issue7047] decimal.py: NaN payload conversion

Mark Dickinson 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, "diagnostic info too

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

Mark Dickinson 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 conditions' section of the sp

[issue7050] Augmented assignment of tuple crashes IDLE

Changes by Mark Fitzgerald : -- title: (x,y) += (1,2) crashes IDLE -> Augmented assignment of tuple crashes IDLE ___ Python tracker ___ ___

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

New submission from Mark Fitzgerald : 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 SyntaxError? -- co

[issue2821] unittest.py sys.exit error

Mark Fitzgerald 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() call. Alternatively, in 2.5,

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

Changes by Stefan Krah : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

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

New submission from Stefan Krah : 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 * >>> setcontext(Context

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

New submission from Stefan Krah : >>> 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 available

[issue7047] decimal.py: NaN payload conversion

Changes by Stefan Krah : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue7047] decimal.py: NaN payload conversion

New submission from Stefan Krah : 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 "", line 1, in File "/usr/lib/python2.7/decimal.py", line 3797, in create_dec

[issue7046] decimal.py: use DivisionImpossible and DivisionUndefined

New submission from Stefan Krah : 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 suppress differences in the d

[issue7045] utf-8 encoding error

Arc Riley 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 "", line 1, in

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

Trundle 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 directly. -- nosy: +Trundle

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

Mark Dickinson 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: it's the float me

[issue7045] utf-8 encoding error

Ezio Melotti 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 pairs is a known "issue"

[issue7042] test_signal fails on os x 10.6

Jan Hosang added the comment: $ ./python.exe -c 'import sys; print sys.maxint' 9223372036854775807 -- ___ Python tracker ___ ___ Pytho

[issue7033] C/API - Document exceptions

Georg Brandl 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 "PyErr_NewExceptionWithDoc" i

[issue7042] test_signal fails on os x 10.6

Ned Deily 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 $ /usr/bin/python2.6 -c 'i

[issue7045] utf-8 encoding error

Martin v. Löwis 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 ___ Python

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

Mark Dickinson added the comment: 2.6 fix applied in r75203. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ __