[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() callable(foo) False hasattr(type(foo), '__call__') True foo() Traceback (most recent call last): File stdin, line 1, in module TypeError: 'Foo' object is not callable There are also other places where hasattr(x, __call__) is still suggested/used (e.g. PEP3100). -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker rep...@bugs.python.org http://bugs.python.org/issue7042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 $ /usr/bin/python2.6 -c 'import sys; print sys.maxint' 9223372036854775807 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 PyErr_NewExceptionWithDoc is better. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7033 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 pairs is a known
issue. This is how UTF-16 works, even if it has some problematic
side-effects.
In your example 'line[0]' is not equal to 'first' because line[0] is the
codepoint of the first surrogate and 'first' is a scalar value that
represents the SHAVIAN LETTER TOT (U+010451).
Regarding the traceback you pasted in the first post, have you used
print('ё') or print(line[0])?
This is what I get using line[0]:
line = 'ёѧѕёѦљ'
first = 'ё'
print(line[0])
Traceback (most recent call last):
File stdin, line 1, in module
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud801' in
position 0: surrogates not allowed
In this case you are getting an error because lone surrogates are
invalid and they can't be encoded. If you use line[:2] instead it works
because it takes both the surrogates:
print(line[0:2])
ё
first == line[0:2]
True
If you really got that error with print('ћ'), then #3297 could be related.
Can you also try this and see what it prints?
import sys
sys.maxunicode
--
nosy: +ezio.melotti
priority: - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7045
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: it's the float methods that are hard to find, not the int methods. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7028 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 directly. -- nosy: +Trundle ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7006 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 module UnicodeEncodeError: 'utf-8' codec can't encode character '\ud801' in position 0: surrogates not allowed -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 suppress differences in the division functions? -- files: div-deccheck2.py messages: 93490 nosy: mark.dickinson, skrah severity: normal status: open title: decimal.py: use DivisionImpossible and DivisionUndefined Added file: http://bugs.python.org/file15029/div-deccheck2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7046 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, line 3797, in create_decimal diagnostic info too long in NaN) File /usr/lib/python2.7/decimal.py, line 3733, in _raise_error raise error(explanation) decimal.InvalidOperation: diagnostic info too long in NaN decNumber (and fastdec) set ConversionSyntax. -- messages: 93491 nosy: skrah severity: normal status: open title: decimal.py: NaN payload conversion ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7047 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
available precision.
My interpretation is that the result should be 1.2E+5.
--
messages: 93492
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: logb: round the result if it is greater than prec
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7048
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 *
setcontext(Context(prec=1, rounding=ROUND_UP,
Emin=-99, Emax=99, capitals=1, flags=[],
traps=[]))
pow(Decimal(0), Decimal(3), Decimal(70))
Decimal('NaN')
pow(Decimal(3), Decimal(0), Decimal(70))
Decimal('NaN')
--
messages: 93493
nosy: skrah
severity: normal
status: open
title: decimal.py: NaN result in pow(x, y, z) with prec 1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7049
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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() call. Alternatively, in 2.5, just create your own TextTestRunner, as described in the 2.5.2 docs: suite = unittest.TestLoader().loadTestsFromTestCase(TestSequenceFunctions) unittest.TextTestRunner(verbosity=2).run(suite) -- nosy: +mfitz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2821 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 SyntaxError? -- components: IDLE messages: 93495 nosy: mfitz severity: normal status: open title: (x,y) += (1,2) crashes IDLE type: crash versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7050 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 conditions' section of the spec. And that DivisionImpossible condition signals InvalidOperation (according to the spec). (And similarly for DivisionUndefined.) So I don't think decimal.py is in violation of the specification here. But decimal.py could be changed so that a call to _raise_error(context, DivisionImpossible, ...) results in the DivisionImpossible exception being raised instead of the InvalidOperation exception. This shouldn't break anything, since DivisionImpossible is a subclass of InvalidOperation. Note that the appropriate sections of decimal.py do already raise the right conditions (unless some have been missed): e.g., in Decimal._divide, we have the lines: # Here the quotient is too large to be representable ans = context._raise_error(DivisionImpossible, 'quotient too large in //, % or divmod') But the Context._raise_error method currently translates all the exceptional conditions to their corresponding signals, hence raises InvalidOperation in this case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7046 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, diagnostic info too long in NaN) and again, the Context._raise_error method translates the ConversionSyntax exceptional condition to the corresponding InvalidOperation signal. Closing as a duplicate, just so we can keep everything one place. -- resolution: - duplicate status: open - closed superseder: - decimal.py: use DivisionImpossible and DivisionUndefined ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7047 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 translates each exceptional condition to the corresponding signal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7046 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 http://bugs.python.org/issue7046 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 represented, m should be strictly less than 10**current_precision. In general, you'd expect to make lots of pow(a, b, m) calls with the same m and differing a and b; it seems less error-prone to have them all these calls fail/pass together than have those with small results pass, and those with larger results fail. Not that I expect there's a single person on this planet who's using three-argument pow with the Decimal type. :) Looking back at this, I'm not quite sure why I chose 'strictly less than' rather than 'less than or equal to'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7049 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 say that a more useful result in this case would be to signal InvalidOperation, on the basis that an inexact result from logb is likely to invalidate most uses of it. Maybe we should ask Mike Cowlishaw what the intended behaviour here is? IEEE 754-2008 (section 5.3.3) requires that languages define a 'logBFormat' type that's always big enough to hold the logB result. If the result is a Decimal, one way to ensure this would be to place constraints on the allowable values emax and emin for a given precision. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7048 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 issue open for that. -- assignee: - mark.dickinson components: +Library (Lib) priority: - low stage: - needs patch type: - behavior versions: +Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7049 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, eric.smith severity: normal status: open title: 'g'/'G' format docs need a little more explanation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7051 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: +amaury.forgeotdarc, benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7050 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 value rounded to p significant
figures,
not the original value of the number being formatted. For example, in '%.6g' %
9.99e-5, the float rounded to 6 places is 1e-4, so the result is '0.0001',
using
fixed-point. But '%.6g' % 9.94e-5 gives '9.9e-05'.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7051
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 IEEE_754_Invalid_operation, so presumably the intention is to signal IEEE_754_Invalid_operation by means of flagging Division_impossible. On a side note, I find the distinction between signals and exceptional conditions (mandated by the spec, as you pointed out) needlessly complicated and I'm happy to see that note 5 under Abstract representation of context says this might change in the future. I'm all for raising DivisionImpossible, if it is not too much trouble. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7046 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 utf-8 input, and refuse invalid unicode characters? -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7049 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to catch up by searching the mailing list, but want to make sure I know what you're referring to in particular. I anaylzed your patch and read through the RFC3986 and have the following comments: 1) The usage of this module is very diffirent from the current urlparse module's usage. It might be that this module was designed to co-exist with urlparse, providing certain additional functionalities. But inorder to replace urlparse, I find this module is Backward Incompatible with the code base. Some comments extra features provided /claims of this module. Yes, there was no design goal of backward compatibility. 2) The module provides URI handling framework that includes default URI Parsers for common URI Schemes. - RFC3986 specifies that scheme handling part is left to the separate RFC describing the schemes. - uriparse library attempts that by providing default port and default hostname for certain schemes, but that can be made available as a patch to urlparse rather than new library. The need for such a change in urlparse needs to be analyzed, as there has not been any requirement raised as such for proving default port, default host for schemes whenever it is applicable. Okay; It just seemed completist to provide said defaults. 3) urlsplit, urlunsplit, spliting the authority into sub-components is available in the current urlparse library itself and is RFC3986 conformant. Ah... it used to not do this for unknown schemes, which was my original impetus for this. 4) urljoin in the current urlparse ( patched with fixes) is currently RFC3986conformant. What urlparse further requires and this patch also lacks is ( as commented by John J Lee) 1) Handling of IRIs. 2) Python Unicode Strings. 3) Percent- Encodings for IRIs and Python Unicode Strings. ( There is a discussion going on on quote and unquote of unicode, and thatwould be basically be extended to above points as well) - If required, we can adopt the default host and port provision mechanisms as mentioned in this patch to the current urlparse. Other that that, I see that urlparse currently has all changes as mentioned inthis patch and makes the attached patch an obsolete one. Please let me know your comments/ thoughts. It seems that urlparse now works for the case that caused me to rewrite this (see the first comment on this bug for a link to the python-dev archives where I posted about the 'itch' this code 'scratched'), so it's fine with me if it just goes away now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1462525 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 on both the interactive terminal and in scripts, u.py
The output should be the same, but on Python 3.1.1 compiled for wide
unicode it reports two different values. As someone on #python-dev
found 'ё'.encode('utf-16').decode('utf-16') outputs the correct value.
--
Added file: http://bugs.python.org/file15032/u.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7045
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ill-formed. Patches for Issue #3672 probably made this more visible. -- nosy: +Rhamphoryncus ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7045 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created
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 unicodetest' Result: False Len: 2 1 Repr: '\ud800\udd23' '\U00010123' [28877 refs] $ ./python -c 'import unicodetest' Result: False Len: 2 1 Repr: '\ud800\udd23' '\U00010123' [28708 refs] -- versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created
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, which always split surrogates. Switching it to UTF-32-BE is fairly straightforward, and works even on UTF-16 (or narrow) builds. Incidentally, there's no point using the surrogatepass error handler once we actually support surrogates. Unfortunately there's a second problem in repr(). '\U0001010F'.isprintable() returns True on UTF-32 builds and False on UTF-16 builds. This causes repr() to escape it unnecessarily on UTF-16 builds. repr() at least joins surrogate pairs before its internally printable test (unlike .isprintable() or any other str method), but it turns out all of the APIs in unicodectype.c only accept a single 16-bit int in UTF-16 builds anyway. That'll be a bigger patch than the first part. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
