[issue12067] Doc: remove errors about mixed-type comparisons.
Chris Jerdonek added the comment: Some minor comments: -The operators , , ``==``, ``=``, ``=``, and ``!=`` compare the +, , ``==``, ``=``, ``=``, and ``!=`` compare the values of two I think it reads better to start a sentence (and in this case a paragraph) with a word rather than a symbol. -values of two objects. The objects need not have the same type. If both are +objects. The two objects don't necessarily have to be of the same type. With The replacement sentence seems wordier to me. +(:meth:`__ge__()` reflects :meth:`__lt__()`, etcetera). Builtin numbers compare +as expected, even when of different types. Builtin sequences compare Built-in is hyphenated in the docs. See, for example, here: http://docs.python.org/dev/library/functions.html -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15972] wrong error message for os.path.getsize
Georg Brandl added the comment: This certainly isn't a release blocker. Check it into default, and it will go into 3.3.1. -- priority: release blocker - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15972 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15949] docs.python.org not getting updated
Georg Brandl added the comment: When the docs don't update, there's usually an error in running Sphinx. In this case, the recently committed patch for #78982 (in the Unicode howto) prevents the LaTeX build (or more exact, the pdflatex run) from completing. Please revert that part of it. (Aside: That is exactly the reason why I don't like these make doctests run at all costs patches.) -- priority: high - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15759] make suspicious doesn't display instructions in case of failure
Georg Brandl added the comment: The error exit code should be preserved though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15759 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15882] _decimal.Decimal constructed from tuple
Georg Brandl added the comment: Done. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15882 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15973] Segmentation fault on timezone comparison
Georg Brandl added the comment: Which commit(s) do I have to pick? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15973 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15895] PyRun_SimpleFileExFlags() can leak a FILE pointer
Georg Brandl added the comment: Now transplanted to release clone. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15895 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15977] Memory leak in _ssl.c
Georg Brandl added the comment: Picked. -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15926] Segmentation fault after multiple reinitializations
Georg Brandl added the comment: Picked as 6708224f8bee. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15926 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15973] Segmentation fault on timezone comparison
Stefan Krah added the comment: This one: 63cb0a642c84 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15973 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15973] Segmentation fault on timezone comparison
Georg Brandl added the comment: Done as ec77f8fb9958. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15973 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15900] Memory leak in PyUnicode_TranslateCharmap()
Georg Brandl added the comment: Done as 89f62f143920. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15900 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Ezio Melotti added the comment: Attached patch adds support for memoryviews to bytes.join: b''.join([memoryview(b'foo'), b'bar']) b'foobar' The implementation currently has some duplication, because it does a first pass to calculate the total size to allocate, and another pass to create the result that calculates the individual sizes again. Py_SIZE(item) can't be used here for memoryviews, so during the first pass it's now necessary to check for memoryviews and extract the len from the memoryview buffer, and then do it again during the second pass. If necessary this could be optimized/improved. I also tried to check for multi-dimensional and non-contiguous buffers, but I didn't manage to obtain a failure so I removed the check for now. More tests should probably be added to cover these cases, and possibly the patch should be adjusted accordingly. If/when the patch is OK I'll do the same for bytearrays. -- keywords: +patch nosy: +ezio.melotti stage: needs patch - patch review Added file: http://bugs.python.org/file27257/issue15958.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Mark Dickinson added the comment: I determined that 'raise TypeError' and 'return NotImplemented' both result in the call of the reflected method Are you sure? raise TypeError *should* result in the operation being abandoned, with the reflected operation not tried. Python 3.3.0rc2+ (default:3504cbb3e1d8, Sep 20 2012, 22:08:44) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type help, copyright, credits or license for more information. class A: ... def __add__(self, other): ... raise TypeError(Don't know how to add) ... def __le__(self, other): ... raise TypeError(Can't compare) ... [65945 refs] class B: ... def __radd__(self, other): ... return 42 ... def __ge__(self, other): ... return False ... [66016 refs] A() = B() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 5, in __le__ TypeError: Can't compare [66064 refs] A() + B() Traceback (most recent call last): File stdin, line 1, in module File stdin, line 3, in __add__ TypeError: Don't know how to add [66065 refs] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15949] docs.python.org not getting updated
Martin v. Löwis added the comment: I think the issue was #15899, and the change 8a40bc71c072. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15949] docs.python.org not getting updated
Ezio Melotti added the comment: I'm working on it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15949] docs.python.org not getting updated
Roundup Robot added the comment: New changeset 0799fd1f8887 by Ezio Melotti in branch '3.2': #15949, 15899: avoid using non-latin1 chars in the doc (they break `make all-pdf`). http://hg.python.org/cpython/rev/0799fd1f8887 New changeset 832999a97e59 by Ezio Melotti in branch 'default': #15949, 15899: merge with 3.2. http://hg.python.org/cpython/rev/832999a97e59 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15949] docs.python.org not getting updated
Ezio Melotti added the comment: This should be fixed now. It would be nice if Sphinx could send a notification mail in case of failure, so that the next time we will notice and fix the problem earlier. -- assignee: docs@python - ezio.melotti resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails
Stefan Krah added the comment:
System: Windows 7 64-bit
Build (unpatched): PCBuild\Win32-pgo\python.exe, trained with profile.bat
In the unpatched version, I stepped through this test case in the debugger:
import array
a = array.array('Q', [1])
m = memoryview(a)
m[0] = 1
At Objects/memoryobject.c:1572: llu == 1
At Objects/memoryobject.c:1782: pylong_as_llu returned value 4294967296
So I think it's pretty safe to say that this is indeed an optimizer bug.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15993
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Mark Dickinson added the comment: Victor: so you want to *deliberately* introduce undefined behaviour for the sake of a minor optimization, while crossing your fingers and *hoping* that that doesn't cause issues with any existing or future compilers? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails
Stefan Krah added the comment: Sorry, the line numbers are messed up. They should be: Objects/memoryobject.c:1569 Objects/memoryobject.c:1776 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15993 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Serhiy Storchaka added the comment: I think memoryview here is example only, and Antoine had in mind arbitrary buffer objects. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2281] Enhanced cPython profiler with high-resolution timer
Kristján Valur Jónsson added the comment: There is another major issue: you have to synchronize the counter of all CPU cores. Windows XP didn't synchronize the counters, and it was a major issue on QueryPerformanceCounter. http://support.microsoft.com/?id=896256 I don't understand why you keep bashing Windows for this. It was actually a problem with CPU drivers. We encountered this problem for a number of our players and the fix was to get the latest intel/amd drivers. The issue you quote is a separate one. This appears to be the correct one: http://support.microsoft.com/kb/895980 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2281 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Ezio Melotti added the comment: Indeed. Attached new patch. Tests still need to be improved; bytearrays are still not changed. -- Added file: http://bugs.python.org/file27258/issue15958-2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Serhiy Storchaka added the comment: Victor, the danger of this approach is that we can't verify that a particular compiler with certain options on a specific platform compiles the source code with undefined behavior in a certain way. If such a test were possible, if this aspect was guaranteed by the compiler manufacturer, or could be checked in the ./configure script, then such an approach would have some meaning. Regardless of _PyLong_IS_SMALL_INT, the rest of patch looks a little cumbersome. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Stefan Krah added the comment:
We would need to release the buffers and also check for format 'B'.
With issue15958-2.diff this is possible:
import array
a = array.array('d', [1.2345])
b''.join([b'ABC', a])
b'ABC\x8d\x97n\x12\x83\xc0\xf3?'
It is unfortunate that a PyBUF_SIMPLE request does not guarantee 'B'.
I think that's probably a mistake, but it's certainly existing practice.
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15958
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15988] Inconsistency in overflow error messages of integer argument
Serhiy Storchaka added the comment: 1) Use PyLong_AsLongAndOverflow instead PyLong_AsLong in PyArg_ParseTuple and in some other functions. 2) Unify an integer overflow error messages in different functions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Stefan Krah added the comment: Also, perhaps we can keep a fast path for bytes and bytearray, but I didn't time the difference. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails
Martin v. Löwis added the comment: Unfortunately (?) I now cannot produce this myself, anymore, either. Given all the problems, I'll stop using PGO on all branches and targets, as the compiler apparently generates bad code. Anybody curious to investigate the issue further who is able to reproduce it might want to look at the generated machine code, to find out where exactly the incorrect processing happens. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15993 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails
Changes by Martin v. Löwis mar...@v.loewis.de: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15993 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Antoine Pitrou added the comment:
Well, given the following works:
import array
a = array.array('d', [1.2345])
b'' + a
b'\x8d\x97n\x12\x83\xc0\xf3?'
It should also work for bytes.join().
I guess that means I'm against the strict-typedness of memoryviews. As the name
suggests, it provides access to some memory area, not some structured array of
data.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15958
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Ezio Melotti added the comment: Attached new refleakless patch. -- Added file: http://bugs.python.org/file27259/issue15958-3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Antoine Pitrou added the comment: Attached new refleakless patch. Your approach is dangerous, because the buffers may change size between two calls to PyObject_GetBuffer(). I think you should keep the Py_buffers alive in an array, and only release them at the end (it may also be slightly faster to do so). A nit: you are adding a lot of newlines in test_bytes.py. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails
Stefan Krah added the comment:
Given all the problems, I'll stop using PGO on all branches and
as the compiler apparently generates bad code.
That is probably the best solution.
The problem in memoryview.c:pack_single() is that Visual Studio optimizes the
memcpy() to mov instructions, but exchanges the low and high dwords:
unsigned __int64 llu = 1;
do { unsigned __int64 x;
x = (unsigned __int64)llu;
// At this point x=llu is in edx=1 and ecx=0.
// The memcpy() is optimized to:
//mov dword ptr [esi], ecx
//mov dword ptr [esi+4], edx
memcpy(ptr, (char *)x, sizeof x);
} while (0);
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15993
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15949] docs.python.org not getting updated
Georg Brandl added the comment: I usually get the result of the cronjob via email if there's a failure; for a few weeks now this went to my spam folder, so I didn't immediately see something was wrong. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Martin v. Löwis added the comment: x+1 x and v = array[0] are not the same checks. In the first test, x is used in both parts. I don't understand. The consequences of undefined behavior are really difficult to understand, it seems. A compiler which evaluates both relational expressions unconditionally to true would be conforming to the C language definition. The reason for that has been said several times before, but let me repeat them. Mathematically, x+1 x for any real number, so it seems natural to assume that this can be determined to be true statically. However, what if x+1 overflows? Shouldn't then it evaluate to false? Not necessarily if x is signed. Then the behavior of overflow is undefined, and *any* result of the comparison would be conforming to the standard: the overflow may trap, the expression may evaluate to false, or the expression may evaluate to true, or your hard disk may get erased - all of these would be conforming to the C language definition. For v = array[0], this is the same issue. If v points into the array, the expression is true. If v doesn't point into the array, the behavior is undefined, so the compiler may chose to give false, or to give true, or to actually compare the pointers as integers, or to erase your hard disk. Of these possible behaviors, only two are plausible. For x+1x, it may be that the compiler actually generates code to perform the addition and the comparison, or it may statically decide that the expression is always true. For v array[0], the compiler may either generate code to perform the comparison, or statically decide that the expression is true. Either implementation would be correct - it's not that the compiler is optimizing incorrectly. In the specific case, a compiler might infer that _PyLong_IS_SMALL_INT is always true, which would give incorrect results in Python. However, it is the patch which is incorrect, not the compiler. I recommend to close the issue as rejected. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails
Martin v. Löwis added the comment: It's interesting that the compiler uses ecx:edx to represent a __int64 quantity when 64-bit registers are available... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15993 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails
Stefan Krah added the comment: Hmm, the bug is in the 32-bit build. The 64-bit build is fine. Or do you mean MMX registers? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15993 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15949] docs.python.org not getting updated
Chris Jerdonek added the comment:
In the future, now that a few more people know, we could always look to see
what doc changes were made since the last publication of the docs (or run the
other `make` commands locally, or ideally, beforehand in cases that warrant
it). The fact that 2.7 published and not the others should have been a tip off
for me.
I wonder if `make patchcheck` could be enhanced to check for unsupported
characters.
Lastly, is there a work-around for the inability to include � in the docs?
That particular difference between u.encode('replace') and
bytes.decode('replace') (? vs. �) seems like an important one to me not to
conflate.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15949
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15964] SyntaxError in asdl when building 2.7 with system Python 3
Chris Jerdonek added the comment: Attaching patch. I started a new section in the FAQ called Build Troubleshooting which is something Nick suggested in the context of addressing this issue. I'm sure we could add a couple more questions to this section right now if we wanted to. -- keywords: +patch Added file: http://bugs.python.org/file27260/issue-15964-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15964 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15964] SyntaxError in asdl when building 2.7 with system Python 3
Chris Jerdonek added the comment: Adding Nick because he is the one that suggested adding a Build Troubleshooting section to the devguide FAQ (meant to add him above). -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15964 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15949] docs.python.org not getting updated
Ezio Melotti added the comment:
I usually get the result of the cronjob via email if there's a failure;
Maybe it should go to python-committers or some other public ML, so that other
devs can see and possibly fix the issue.
I wonder if `make patchcheck` could be enhanced to check
for unsupported characters.
That sounds like a good idea to me.
Lastly, is there a work-around for the inability to include �
in the docs?
'\ufffdabc' is acceptable, and it is what non-utf-8 terminals print.
That particular difference between u.encode('replace') and
bytes.decode('replace') (? vs. �) seems like an important
one to me not to conflate.
Indeed I was confusing the two. I'm not actually even sure that the Unicode
standard mandates these specific replacement characters (IIRC there's even a
way to configure them), and I was under the impression that '?' was sometimes
used during the decoding, but after a few tests it seems I was wrong.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15949
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15949] docs.python.org not getting updated
Chris Jerdonek added the comment: The distinction between ? vs. � for encode() and decode() is in the Python docs, but it's not prominent. It's mentioned in codecs's Codec Base Classes but not in the encode() and decode() docs themselves: http://docs.python.org/dev/library/codecs.html#codec-base-classes -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15949] docs.python.org not getting updated
Ezio Melotti added the comment: The distinction between ? vs. � for encode() and decode() is in the Python docs, but it's not prominent. The point is that I'm not even sure we make any guarantees about the replacement characters that we use. I should check again what the Unicode standard says -- IIRC � was suggested, but it wasn't mandatory. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16000] test_curses should use unittest
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16000 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15978] asyncore: included batteries don't fit
Changes by Benjamin Peterson benja...@python.org: -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15978 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed
Roundup Robot added the comment: New changeset 3b03d31f6a79 by R David Murray in branch 'default': #15925: fix regression: return None for null and non-date strings. http://hg.python.org/cpython/rev/3b03d31f6a79 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15925 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed
R. David Murray added the comment: I don't think it is worth the extra code to convert the TypeError into a ValueError. We aren't very strict about the distinction between those two. Leaving this open for Georg to transplant it to 3.3.0. -- assignee: - georg.brandl resolution: - fixed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15925 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15952] format(value) and value.__format__() behave differently with unicode format
Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15952 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Larry Hastings added the comment: I must be missing something--because I thought Python *already* depended on this apparently-undefined behavior. The small-block object allocator in Objects/obmalloc.c determines whether a pointer belongs to a particular arena using exactly this trick. I quote from the gigantic comment at the top of that file: Let B be the arena base address associated with the pool, B = arenas[(POOL)-arenaindex].address. Then P belongs to the arena if and only if B = P B + ARENA_SIZE Subtracting B throughout, this is true iff 0 = P-B ARENA_SIZE This test is implemented as the following macro: #define Py_ADDRESS_IN_RANGE(P, POOL)\ ((arenaindex_temp = (POOL)-arenaindex) maxarenas \ (uptr)(P) - arenas[arenaindex_temp].address (uptr)ARENA_SIZE \ arenas[arenaindex_temp].address != 0) Why is that permissible but _PyLong_IS_SMALL_INT is not? -- nosy: +larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15951] string.Formatter returns str for empty unicode template
Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15935] clarify argparse docs re: add_argument() type and default arguments
Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: I have finished a solution working for me. It bypasses standard Python interactive interpreter and uses its own repl based on code.interact(). This repl is activated by an ugly hack since PYTHONSTARTUP doesn't apply when some file is run (python -i somefile.py). Why it works like that? Startup script could find out if a file is run or not. If anybody knows how to get rid of time.sleep() used for wait for KeyboardInterrupt or how to get rid of PromptHack, please let me know. The patch can be activated by win_unicode_console_2.enable(change_console=True, use_hack=True) in site or sitecustomize or usercustomize. -- Added file: http://bugs.python.org/file27261/win_unicode_console_2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15987] Provide a way to compare AST nodes for equality recursively
Benjamin Peterson added the comment: Yes, though some things like what to return if one has an entire subtree that the other doesn't have will have to be worked out. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15987 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15964] SyntaxError in asdl when building 2.7 with system Python 3
Nick Coghlan added the comment: We should be able to add the make touch target to the 2.7 Makefile without running afoul of the no new features rule. However, agreed this is mostly a docs problem. We're seeing a couple of common traps that people run into when first getting started, so it will be good to get answers up somewhere where people are likely to look (and where search engines will be able to see the error messages). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15964 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed
Georg Brandl added the comment: This was committed to the release clone as c1e9a1fc6931. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15925 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15925] email.utils.parsedate() and email.utils.parsedate_tz() should return None when date cannot be parsed
Changes by Georg Brandl ge...@python.org: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15925 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15969] faulthandler: drop S from dump_tracebacks_later() function name to have consistent names
Georg Brandl added the comment: Added to release clone as eede0bf3ceac. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15969 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Serhiy Storchaka added the comment: Why is that permissible but _PyLong_IS_SMALL_INT is not? Touchér! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Mark Dickinson added the comment: Ah: nice catch, Larry. I would say that the obmalloc case *shouldn't* be permissible; however, it's already there, and changing that would be an involved task that would also likely risk introducing new bugs. So I guess practicality beats purity on that one. I don't see that as an excuse for introducing *new* undefined behaviour though, especially for a small optimization. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15978] asyncore: included batteries don't fit
chrysn added the comment: i've redirected my request to python-ideas as suggested. for future reference, my email can be found at http://mail.python.org/pipermail/python-ideas/2012-September/016185.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15978 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Serhiy Storchaka added the comment: I recommend to close the issue as rejected. I think _PyLong_IS_SMALL_INT can be rewritten in a safe style. For example, using a checking of several fields ((sdigit)(x)-ob_digit[0] _MAX_SMALL_INT PySIZE(x) = 1) or a special flag. It is possible however that shuch checking will fully destroy the effect of optimization. We need further research. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15958] bytes.join() should allow arbitrary buffer objects
Serhiy Storchaka added the comment: I think you should keep the Py_buffers alive in an array, and only release them at the end (it may also be slightly faster to do so). However allocation of this array may considerably slow down the function. We may need the special-case for bytes and bytearray. Stop, and the bytearray (or bytearray subclass) can change size between two calls to Py_SIZE()? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15996] pow() for complex numbers is rough around the edges
Mark Dickinson added the comment:
(1.0+0j)**(float('inf') + 0j)
Oddly enough, this is nan+nanj on OS X. I haven't investigated what the
difference is due to---probably something to do with the errno results.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9720] zipfile writes incorrect local file header for large files in zip64
Serhiy Storchaka added the comment: No, on the contrary, it is not such easy to fix, and the patch is incorrect. Sorry that it is not clear either. The size of the header with extra args depends on the size of the file. The file size can be changed in the process of compressing, and compressed size may be larger than uncompressed size, exceeding 32-bit boundary. Rewriting the header with extra args, we can overwrite compressed data. I was put off the issue for further more careful research. Thanks for the reminder. One solution is always (even for smallest files) to write 64-bit sizes when allowZip64 is true. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15276] unicode format does not really work in Python 2.x
Chris Jerdonek added the comment: I have a brief documentation patch in mind for this, but it relies on documentation issue 15952 being addressed first (e.g. to say that format(value) returns Unicode when format_spec is Unicode and that value.__format__() can return a string of type str). So I'm marking issue 15952 as a dependency. -- dependencies: +format(value) and value.__format__() behave differently with unicode format ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15276 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Terry J. Reedy added the comment: You are right, I did not look deep enough. I was fooled by the conversion of NotImplemented, returned from object.__le__, etc, to TypeError. Sorry for that noise. For comparison and arithmetic, the actual alternative to defining a function that returns NotImplemented seems to be to not define it at all. class C(): def __ge__(self, other): return True def __add__(self, other): return 44 __radd__ = __add__ class O(): pass # removed NotImplemented defs c = C() o = O() print(c = o, o = c) # True True print(c + o, o + c) # 44 44 (I looked at the codes for binary_op1 in abstract.c and do_richcompare in object.c and do not yet see any effective difference between not defined and a NotImplemented return.) I'll take a look at the patch later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12067 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16002] AIX buildbot compile errors
New submission from Stefan Krah: According to issue #9799 configuring --without-computed-gotos might solve the AIX compile error. -- components: Build keywords: buildbot messages: 171013 nosy: skrah, trent priority: normal severity: normal status: open title: AIX buildbot compile errors type: compile error versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16002 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Martin v. Löwis added the comment: Why is that permissible but _PyLong_IS_SMALL_INT is not? It's *permissable* primarily because it is there. There are many places in Python which invoke undefined behavior already (most notably wrt. signed integers); we should strive to eliminate them. OTOH, obmalloc clearly makes a lot of assumptions on the hardware architecture (including the assumption that there is page-based virtual memory, etc). It's a memory allocator, that gives permission to make such assumptions. If it turns out that they break on some system, obmalloc cannot be used there - hence usage of obmalloc is still a compile-time option. In addition, for the specific macros: it's easy to see that a compiler may optimize _PyLong_IS_SMALL_INT as true by simple static analysis. For Py_ADDRESS_IN_RANGE, the same static analysis is not possible, since the memory doesn't come from a declared array. It would require whole-program analysis to determine that .address always points to a memory block with ARENA_SIZE bytes. If a compiler manages to figure it out, obmalloc cannot be used on that system (and if that happens, I'll recommend to drop or revise obmalloc altogether, perhaps in favor of a system pool allocator). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15997] NotImplemented needs to be documented
Terry J. Reedy added the comment: I was wrong about TypeError; forget that. The seeming equivalent to 'return NotImplement' is not defining the method. My confusion stemed from the fact that NotImplemented returned from special methods gets intercepted and converted to TypeError exceptions by the operator functions that call them -- unless there is an alternate path *and* the alternate does not also return NotImplemented. Changing will try reflected operation to will return the result of the reflected operation called on the swapped arguments is wrong as the latter is not completely correct. If the fallback also returns NotImplemented, it is ignored and TypeError is raised the same as if the fallback did not exist. But as Martin said, the details belong in operator documentation. I would like to more closely parallel the None entry, which has It is used to signify the absence of a value in many situations, e.g. it is returned from functions that don’t explicitly return anything. by replacing Numeric methods and rich comparison methods may return this value if they do not implement the operation for the operands provided. (The interpreter will then try the reflected operation, or some other fallback, depending on the operator.) with It is used to signify that a method does not implement the operation requested for the operands provided. For example, the special methods for arithmetic and and rich comparison may return NotImplemented, and when they do, the interpreter will try the reversed or reflected operation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15997 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10044] small int optimization
Martin v. Löwis added the comment: Zitat von Serhiy Storchaka rep...@bugs.python.org: I recommend to close the issue as rejected. I think _PyLong_IS_SMALL_INT can be rewritten in a safe style. For example, using a checking of several fields ((sdigit)(x)-ob_digit[0] _MAX_SMALL_INT PySIZE(x) = 1) or a special flag. It is possible however that shuch checking will fully destroy the effect of optimization. We need further research. Do we need to keep this issue open while this research is being carried out? This issue is already cluttered with the undefined-behavior discussion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10044 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
