[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
Daniel Stutzbach added the comment: Gladly. :-) -- resolution: -> out of date stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue8654> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13742] Add a key parameter (like sorted) to heapq.merge
Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue13742> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8777] Add threading.Barrier
Changes by Daniel Stutzbach : -- stage: -> committed/rejected ___ Python tracker <http://bugs.python.org/issue8777> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12192] Doc that collection mutation methods return item or None
Daniel Stutzbach added the comment: > Comment: This rule applies to special methods like __getitem__ > and __setitem__. 'lis.append(item)' is equivalent to > lis.__setitem__(len(lis):len(lis), item), so it should not be so > surprising that it has the same return. It's not true for all special methods. __iadd__ and __imul__ return the list itself. That's a minor nitpick though. +1 on adding "and return None" to the docstrings of methods that often trip people up. Not everyone will read them, but some people will. -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue12192> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12345] Add math.tau
Daniel Stutzbach added the comment: On Wed, Jun 15, 2011 at 8:10 PM, Nick Coghlan wrote: > I'd like to add a new constant to the math module: > > tau = 2*math.pi > > Rather than repeating all the reasons for why tau makes more sense than pi > as the fundamental circle constant, I'll just refer interested readers to > http://tauday.com/ (The following is best if read aloud using your best pirate impression) I'd rather name the new constant "matey". Then we have: The circumference of a circle is: r matey The area of a circle is: one-quarter r r matey etc. -- nosy: +stutzbach Added file: http://bugs.python.org/file22397/unnamed ___ Python tracker <http://bugs.python.org/issue12345> ___On Wed, Jun 15, 2011 at 8:10 PM, Nick Coghlan <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: I'd like to add a new constant to the math module:  tau = 2*math.pi Rather than repeating all the reasons for why tau makes more sense than pi as the fundamental circle constant, I'll just refer interested readers to http://tauday.com/"; target="_blank">http://tauday.com/ (The following is best if read aloud using your best pirate impression)I'd rather name the new constant "matey".  Then we have:The circumference of a circle is: r matey The area of a circle is: one-quarter r r mateyetc.-- Daniel Stutzbach ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12434] Strengthen 2.7 io types warning
Daniel Stutzbach added the comment: On Sat, Jul 16, 2011 at 2:04 AM, Eli Bendersky wrote: > Therefore, I propose to change this error message to: > "unicode argument expected, got '%s'" > as Terry suggested. > Sounds good to me. -- Added file: http://bugs.python.org/file22687/unnamed ___ Python tracker <http://bugs.python.org/issue12434> ___On Sat, Jul 16, 2011 at 2:04 AM, Eli Bendersky <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Therefore, I propose to change this error message to:  "unicode argument expected, got '%s'"  as Terry suggested.Sounds good to me. -- Daniel Stutzbach ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11640] Shelve references globals in its __del__ method
Daniel Stutzbach added the comment: Could you add a comment above the lines defining self._BytesIO, describing why they're being set? Someone else might see them as unnecessary and rip them out if there's no explanation. Can a test launch Python in a subprocess, set up the appropriate data structure, let the subprocess Python shutdown, then check the subprocess's stderr for the error? It's a little convoluted, but perhaps it could be built into a general utility function that could be used to test __del__ methods in other modules, too. Not sure that it's worth the effort though. -- ___ Python tracker <http://bugs.python.org/issue11640> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12612] Valgrind suppressions
Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue12612> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12682] Meaning of 'accepted' resolution as documented in devguide
Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue12682> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2521] ABC caches should use weak refs
Daniel Stutzbach added the comment: Benjamin, Thanks for the feedback. Since you only commented on the test case, may I assume that the fix itself looked good to you? I will work on revising the test case based on your comments. Since I ran into the bug while working with the ABCs in the collections module, that biased my thinking when writing the test. :-) I needed to define__len__ because it's an abstract method in the ABC I used in the test (collections.Sized). I found that overriding it again in a sub-sub-class and calling it were necessary to trigger all of the ABC machinery leading to the leak. -- ___ Python tracker <http://bugs.python.org/issue2521> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2521] ABC caches should use weak refs
Changes by Daniel Stutzbach : -- components: +Library (Lib) -Interpreter Core versions: -Python 2.6 ___ Python tracker <http://bugs.python.org/issue2521> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2521] ABC caches should use weak refs
Daniel Stutzbach added the comment: Attached is a new test case, based on Benjamin's comments. -- Added file: http://bugs.python.org/file18567/leak_test2.patch ___ Python tracker <http://bugs.python.org/issue2521> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)
Daniel Stutzbach added the comment: Attached is a patch implementing the change agreed upon in the earlier discussion. This will allow wchar_t <-> Py_UNICODE conversions to use memcpy on systems where wchar_t and Py_UNICODE have the same size but different signs (e.g., Linux). -- keywords: +needs review, patch stage: needs patch -> patch review Added file: http://bugs.python.org/file18569/issue8781.patch ___ Python tracker <http://bugs.python.org/issue8781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)
Daniel Stutzbach added the comment: Thanks. I dug into that a little just now, and it turns out to happen automatically. If ./configure doesn't define HAVE_WCHAR_H then it also will not define SIZEOF_WCHAR_T. If SIZEOF_WCHAR_T is not defined, the preprocessor will treat it as 0 causing it to be unequal to Py_UNICODE_SIZE. In other words, if HAVE_WCHAR_H is not defined then SIZEOF_WCHAR_T == Py_UNICODE_SIZE will be false. -- ___ Python tracker <http://bugs.python.org/issue8781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue808164] socket.close() doesn't play well with __del__
Daniel Stutzbach added the comment: I suspect that it's not possible. I'm uploading patches that fix the .close method to avoid referencing globals that might be None during interpreter shutdown. Since the .close method has changed significantly in py3k, I'm uploading separate patches for py3k and 2.7. -- ___ Python tracker <http://bugs.python.org/issue808164> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue808164] socket.close() doesn't play well with __del__
Changes by Daniel Stutzbach : -- keywords: +needs review, patch stage: unit test needed -> patch review Added file: http://bugs.python.org/file18570/issue808164-27.patch ___ Python tracker <http://bugs.python.org/issue808164> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue808164] socket.close() doesn't play well with __del__
Daniel Stutzbach added the comment: Here is the py3k version of the patch -- ___ Python tracker <http://bugs.python.org/issue808164> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue808164] socket.close() doesn't play well with __del__
Changes by Daniel Stutzbach : Added file: http://bugs.python.org/file18571/issue808164-py3k.patch ___ Python tracker <http://bugs.python.org/issue808164> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2226] Small _abcoll Bugs / Oddities
Daniel Stutzbach added the comment: 3.1 is long gone. Should this be addressed for 3.2? -- ___ Python tracker <http://bugs.python.org/issue2226> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9131] test_set_reprs in test_pprint is fragile
Daniel Stutzbach added the comment: How do we mark a test as implementation specific? Is there a decorator for that? -- ___ Python tracker <http://bugs.python.org/issue9131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9212] dict_keys purports to implement the Set ABC, but is missing the isdisjoint method
Daniel Stutzbach added the comment: Thank you for the patch. We should only iterate over the shorter set if the longer set is really a set and not just a sequence. PySequence_Contains may take O(n) time on a list, making the algorithm an expensive O(n**2) overall. I note that set_isdisjoint doesn't try to examine the lengths. Also, since PyIter_Next returns NULL to indicate the end of the iteration OR to indicate an exception, the end of the function should look like this: Py_DECREF(it); if (PyErr_Occurred()) return NULL; Py_RETURN_TRUE; Other than those two issues, the patch looks good to me. -- ___ Python tracker <http://bugs.python.org/issue9212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9214] Most Set methods of KeysView and ItemsView do not work right
Daniel Stutzbach added the comment: The patch looks good to me, too. The new tests fail without the fix, and pass with the fix. -- assignee: stutzbach -> rhettinger stage: unit test needed -> patch review ___ Python tracker <http://bugs.python.org/issue9214> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9131] test_set_reprs in test_pprint is fragile
Daniel Stutzbach added the comment: Nevermind, I found it: @support.cpython_only I'll work on a patch to add the decorator and a comment about why the test is fragile. -- ___ Python tracker <http://bugs.python.org/issue9131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9131] test_set_reprs in test_pprint is fragile
Changes by Daniel Stutzbach : -- keywords: +needs review, patch resolution: -> accepted stage: needs patch -> patch review Added file: http://bugs.python.org/file18591/issue9131.patch ___ Python tracker <http://bugs.python.org/issue9131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9131] test_set_reprs in test_pprint is fragile
Changes by Daniel Stutzbach : Removed file: http://bugs.python.org/file18591/issue9131.patch ___ Python tracker <http://bugs.python.org/issue9131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9131] test_set_reprs in test_pprint is fragile
Daniel Stutzbach added the comment: errr... ignore that first patch (now deleted) :-) -- Added file: http://bugs.python.org/file18592/issue9131.patch ___ Python tracker <http://bugs.python.org/issue9131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9131] test_set_reprs in test_pprint is fragile
Changes by Daniel Stutzbach : Removed file: http://bugs.python.org/file18592/issue9131.patch ___ Python tracker <http://bugs.python.org/issue9131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9131] test_set_reprs in test_pprint is fragile
Changes by Daniel Stutzbach : Added file: http://bugs.python.org/file18593/issue9131.patch ___ Python tracker <http://bugs.python.org/issue9131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2521] ABC caches should use weak refs
Daniel Stutzbach added the comment: Thanks! :-) -- ___ Python tracker <http://bugs.python.org/issue2521> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9659] frozenset, when subclassed will yield warning upon call to super(...).__init__(iterable)
Daniel Stutzbach added the comment: I can reproduce it in Python 3.1 and 3.2 I don't have a build of Python 2.7 handy at the moment to test it there. In Python 3.2 and 2.7, DeprecationWarnings are silenced by default. I had to start Python 3.2 with "-W always::DeprecationWarning" to see the problem. -- ___ Python tracker <http://bugs.python.org/issue9659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9665] Buid issues on Cygwin - _curses, _curses_panel, and _io
Daniel Stutzbach added the comment: Should release27-maint/Modules/_io/_iomodule.c:172 be: PyAPI_DATA(PyObject *) PyExc_BlockingIOError = (PyObject *)&_PyExc_BlockingIOError; ? -- ___ Python tracker <http://bugs.python.org/issue9665> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9665] Buid issues on Cygwin - _curses, _curses_panel, and _io
Daniel Stutzbach added the comment:
> Why should it be?
The error indicates that the definition in the .c file doesn't match the
declaration in the .h file, with respect to the funky Windows-specific stuff
('dllimport') that PyAPI_DATA adds.
Roumen's patch suggests I had it backwards, and it's the .h file that should be
changed.
--
___
Python tracker
<http://bugs.python.org/issue9665>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9665] Buid issues on Cygwin - _curses, _curses_panel, and _io
Daniel Stutzbach added the comment: > Why would this not be required for the standard exceptions then? It looks like PyAPI_DATA can be defined differently depending on whether we're building code as a built-in or as a loadable module. If _iomodule.c is really being built as a module, that would explain why there's a difference. The standard exceptions are always built-in. In Python 2.7, _io is not the default I/O system for Python, so I could understand why it might be a loadable module there. Of course, if Amaury is right that it's being built both ways then I assume that could be the underlying problem. Also, the definition of PyAPI_DATA has a bunch of conditions specifically for Cygwin, which (partially) explains why the behavior is different from a regular Windows build. I am not an export on the dllimport and dllexport keywords, although I have needed to use them on occasion. I am speculating. -- ___ Python tracker <http://bugs.python.org/issue9665> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8750] Many of MutableSet's methods assume that the other parameter is not self
Daniel Stutzbach added the comment: Committed as r84301, r84302, and r84305. -- keywords: -needs review stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.6 ___ Python tracker <http://bugs.python.org/issue8750> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)
Daniel Stutzbach added the comment: Commited in r84307. -- keywords: -needs review resolution: -> accepted stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue8781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)
Daniel Stutzbach added the comment: Thanks, I will take a look sometime today. -- ___ Python tracker <http://bugs.python.org/issue8781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)
Daniel Stutzbach added the comment: The underlying problem here is that SIZEOF_WCHAR_T is not defined in pyconfig.h on Windows. My patch assumed that it would be defined on all platforms where HAVE_WCHAR_H is defined (I had checked ./configure, but forgotten Windows). This has come up before and caused problems for other projects that assume including python.h will define SIZEOF_WCHAR_T on all platforms with HAVE_WCHAR_H: http://bugs.python.org/issue4474 http://trac.wxwidgets.org/ticket/12013 The problem with my patch can be solved in one of two ways: 1. In PC/pyconfig.h, #define SIZEOF_WCHAR_T 2, or 2. Change the #if's to: HAVE_USABLE_WCHAR_T || Py_UNICODE_SIZE == SIZEOF_WCHAR_T I prefer option #1, but it's also a more visible change than my original patch and may warrant its own issue. Thoughts? -- ___ Python tracker <http://bugs.python.org/issue8781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)
Daniel Stutzbach added the comment: Adding other Windows developers to the nosy list. See msg114893 where your input would be helpful. -- nosy: +brian.curtin, tim.golden ___ Python tracker <http://bugs.python.org/issue8781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)
Daniel Stutzbach added the comment: On Windows, the Python headers define HAVE_USABLE_WCHAR_T and Py_UNICODE_SIZE 2, so we are already relying on sizeof(wchar_t) == 2 on Windows. My patch ran into trouble because it inadvertently disabled that assumption in a few places, causing code to take the slow path and convert between wchar_t * and Py_UNICODE *. The test that failed checks that the fast path was taken on Windows. -- ___ Python tracker <http://bugs.python.org/issue8781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9684] PC/pyconfig.h should define SIZEOF_WCHAR_T
New submission from Daniel Stutzbach : Presently, the pyconfig.h generated by configure defines SIZEOF_WCHAR_T, but PC/pyconfig.h does not, periodically causing problems: http://bugs.python.org/issue8781 http://bugs.python.org/issue4474 http://trac.wxwidgets.org/ticket/12013 Problem and the one-line solution already discussed in Issue8781 (and to a less extent in Issue4474). -- assignee: stutzbach components: Windows messages: 114926 nosy: stutzbach priority: normal severity: normal status: open title: PC/pyconfig.h should define SIZEOF_WCHAR_T type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue9684> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)
Changes by Daniel Stutzbach : -- dependencies: +PC/pyconfig.h should define SIZEOF_WCHAR_T ___ Python tracker <http://bugs.python.org/issue8781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9684] PC/pyconfig.h should define SIZEOF_WCHAR_T
Daniel Stutzbach added the comment: After making a Windows build and running the tests, committed in r84317. -- resolution: -> accepted stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue9684> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8781] 32-bit wchar_t doesn't need to be unsigned to be usable (I think)
Daniel Stutzbach added the comment: I opened a separate issue for the SIZEOF_WCHAR_T issue so I could refer to that issue number in Misc/NEWS. Fixed in r84317. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue8781> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5553] Py_LOCAL_INLINE(type) doesn't actually inline except using MSC
Daniel Stutzbach added the comment: Committed in r84379 -- keywords: -needs review resolution: -> accepted stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue5553> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue808164] socket.close() doesn't play well with __del__
Daniel Stutzbach added the comment: Fixed in r84380 and r84382. -- keywords: -needs review resolution: -> accepted stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue808164> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7141] 2to3 should add from __future__ import print_statement
Daniel Stutzbach added the comment: I don't think I'm familiar enough with 2to3's pattern-matching syntax to write a good patch. Here's a rough outline for how a patch would work. There are two cases: 1) When there is already a "from __future__ import". Currently, this line is stripped by fix_future. fix_future could be changed to remove the other futures, but add/leave "print_statement". This case is probably pretty straightforward. 2) When there is no "from __future__ import". A pattern would need to detect the absence of the __future__ line and insert one in the right place (after initial comments but before anything else). -- stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue7141> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
New submission from Daniel Stutzbach : In Doc/extending/windows.rst, there's the following text: If your module creates a new type, you may have trouble with this line:: PyVarObject_HEAD_INIT(&PyType_Type, 0) Change it to:: PyVarObject_HEAD_INIT(NULL, 0) and add the following to the module initialization function:: MyObject_Type.ob_type = &PyType_Type; Refer to section 3 of the `Python FAQ <http://www.python.org/doc/faq>`_ for details on why you must do this. If I assume that Section 3 means, the third link on the FAQ page, I can't find the FAQ that's being alluded to here. There's a comment in Include/pyport.h that I believe to be related: /* Under Cygwin, auto-import functions to prevent compilation */ /* failures similar to http://python.org/doc/FAQ.html#3.24 */ However, that link no longer goes to a particular question and I can't tell which question it once referred to. I ran into this because I'm trying to understand the cause of the issue which I suspect is related to Issue #6672. -- assignee: d...@python components: Documentation messages: 115285 nosy: brian.curtin, d...@python, stutzbach, tim.golden priority: normal severity: normal stage: needs patch status: open title: Docs point to FAQ Section 3, but FAQs are not numbered ___ Python tracker <http://bugs.python.org/issue9728> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9730] base64 docs refers to strings instead of bytes
Daniel Stutzbach added the comment: The example can be fixed by placing a "b" before the two string literals. However, pretty much the whole document refers to "strings" and should refer to "byte sequences" or the "bytes" type. I thought there were automated tests that exercised the documentation examples. Am I wrong about that? -- nosy: +stutzbach resolution: -> accepted stage: -> needs patch title: base64 encoding takes in bytes rather than string. -> base64 docs refers to strings instead of bytes versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue9730> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7877] Iterators over _winreg EnumKey and EnumValue results
Daniel Stutzbach added the comment: As most of the code in this patch was copied from EnumValue and EnumKey, it includes bugs from those functions that have since been fixed. I'm thinking of Issue #2810, although there might have been other changes. Instead of duplicating code, it would be better to abstract out some of the common elements so that in the future changes only need to be made in one place. While winreg isn't very Pythonic, I imagine most users write a simple wrapper around the functions to give it a more Pythonic feel. I have been using a home-brewed class that implements the MutableMapping ABC. I just posted it as a recipe on ActiveState: http://code.activestate.com/recipes/577381-collectionsmutablemapping-wrapper-around-_winreg/ -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue7877> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8743] set() operators don't work with collections.Set instances
Daniel Stutzbach added the comment: Raymond, do you agree with Ray's analysis? -- ___ Python tracker <http://bugs.python.org/issue8743> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9731] ABCMeta.register should verify that methods are present
New submission from Daniel Stutzbach : In Issue 9212, I mused: > I sort of wonder if .register() should verify that the concrete class > provides all of the methods of the ABC. Éric Araujo suggested I open that as an issue for consideration. I have found a few bugs in the standard library where a concrete class did not actually implement all of the methods of the ABC that it purported to implement. Specifically: dict's keys view claims to implement the Set ABC but doesn't provide the is_disjoint method (Issue 9212) range objects claims to support the Sequence ABC but don't provide the count and index methods (Issue 9213) Should ABCMeta.register verify that the type implements all of the appropriate methods? On the one hand, that would prevent similar bugs from sneaking by. On the other hand, it's extra code that would get executed every time Python started (site.py imports os.py which imports _abcoll.py). Thoughts? -- components: Library (Lib) messages: 115293 nosy: benjamin.peterson, eric.araujo, gvanrossum, stutzbach priority: normal severity: normal status: open title: ABCMeta.register should verify that methods are present type: feature request versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue9731> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9731] ABCMeta.register should verify that methods are present
Daniel Stutzbach added the comment: Would it be useful to provide a separate function to perform the check, which could be used by lint-style tools as well as automated tests? It would be great if every call to .register in the standard library had a corresponding test that verified that the appropriate methods were defined. That would prevent future oversights where methods are missing entirely. -- ___ Python tracker <http://bugs.python.org/issue9731> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9731] Add ABCMeta.has_methods and tests that use it
Daniel Stutzbach added the comment: Re-opening and re-titling the issue to that effect. Proposed syntax and usage: # in Lib/abc.py class ABCMeta(type): # ... def has_methods(cls, subclass): "Returns True iff subclass implements the appropriate methods" # ... Usage within the unit tests: # In Lib/test/test_collections.py def test_methods(self): self.assertTrue(Sequence.has_methods(range)) self.assertTrue(MutableSet.has_methods(set)) # ... and many more -- assignee: -> stutzbach components: +Tests resolution: rejected -> accepted stage: -> needs patch status: closed -> open title: ABCMeta.register should verify that methods are present -> Add ABCMeta.has_methods and tests that use it ___ Python tracker <http://bugs.python.org/issue9731> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9212] dict_keys purports to implement the Set ABC, but is missing the isdisjoint method
Daniel Stutzbach added the comment: I will aim to spend some time with this (and the similar Issue #9213) today and/or tomorrow, so that it can be committed in time for 3.2a2. -- resolution: -> accepted stage: unit test needed -> patch review ___ Python tracker <http://bugs.python.org/issue9212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8685] set(range(100000)).difference(set()) is slow
Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue8685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8425] a -= b should be fast if a is a small set and b is a large set
Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue8425> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue2459> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9155] Reserve COMPARE_OP for rich comparisons
Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue9155> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569291] Speed-up in array_repeat()
Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue1569291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2690] Precompute range length
Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue2690> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5362] Add configure option to disable Py3k warnings
Daniel Stutzbach added the comment: Since this issue doesn't apply in Python 3 and (as I understand it) the 2.7 branch is only open to bug fixes, can we close this performance issue? -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue5362> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7141] 2to3 should add from __future__ import print_statement
Daniel Stutzbach added the comment: Excluding the future fixer would only get me half of the way there. I would still need to add "from __future__ import print_statement" to all of my scripts if I want them to continue to work under 2.6. (Well, for me personally, I have already done exactly that, by hand. Rather tedious.) -- ___ Python tracker <http://bugs.python.org/issue7141> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7141] 2to3 should add from __future__ import print_statement
Daniel Stutzbach added the comment: Well, I grant you that it's a bit of scope-creep, and if you want to reject it on those grounds I can't blame you. To me it seems like a relatively small change that would greatly help people like myself who want to update older code so that it will run under 2.6, 2.7, and 3.1+. Of course, since I don't know how to make the change, I could also be wrong about how easy it would be for a knowledgeable person to fit it into the existing 2to3 framework. -- ___ Python tracker <http://bugs.python.org/issue7141> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8743] set() operators don't work with collections.Set instances
Daniel Stutzbach added the comment: > The operator methods in setobject.c should be liberalized to accept > instances of collections.Set as arguments. Under this plan, set() and collections.Set will still have slightly different behavior. collections.Set will be more liberal and accept any iterable. Are you okay with that? I don't feel strongly about this point; I just want to make sure it's a conscious decision. I do feel strongly that set and collections.Set should be able to inter-operate nicely and the proposal satisfies that requirement so I would be happy with it. > To implement PyObject_IsInstance(other, collections.Set), there may > be a bootstrap issue (with the C code being compiled and runnable > before _abcoll.py is able to create the Set ABC). Alternatively, > the code in setobject.c can lazily (at runtime) lookup > collections.Set by name and cache it so that we only do one > successful lookup per session. I favor the lazy lookup approach. > Whatever approach is taken, it should be done with an eye towards > the larger problem that Python is filled with concrete isinstance() > checks that pre-date ABCs and many of those need to be liberalized > (accepting a registered ABC and providing different execution paths > for known and unknown concrete types). Agreed. Ideally, the "PyObject_IsInstance(other, collections.Set)" logic would be abstracted out as much as possible so other parts of Python can make similar checks without needing tons of boilerplate code in every spot. For what it's worth, I don't think we will find as many inconsistency issues with ABCs other than Set. Set has methods that take another Set and return a third Set. That forces different concrete implementations of the Set ABC to interact in a way that won't come up for a Sequence or Mapping. (I suppose that Sequence.extend or MutableMapping.update are somewhat similar, but list.extend and dict.update are already very liberal in what they accept as a parameter.) -- resolution: -> accepted versions: +Python 3.1 ___ Python tracker <http://bugs.python.org/issue8743> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9212] dict_keys purports to implement the Set ABC, but is missing the isdisjoint method
Daniel Stutzbach added the comment: Committed to py3k in r84435. Raymond, do you want to look the commit over before I merge it into 3.1 and 2.7? -- ___ Python tracker <http://bugs.python.org/issue9212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9212] dict_keys purports to implement the Set ABC, but is missing the isdisjoint method
Daniel Stutzbach added the comment: Meant to add: I made some relatively minor changes to Daniel Urban's patch. Mostly, I rearranged the order of a few things to avoid unnecessary work (e.g., only compute "len_other" if we've already checked that "other" is a set). Thank you Daniel for the patch! :-) -- ___ Python tracker <http://bugs.python.org/issue9212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9212] dict_keys purports to implement the Set ABC, but is missing the isdisjoint method
Daniel Stutzbach added the comment: Also, credited Daniel Urban for the patch in r84436 (forgot that the first time around -- sorry!). -- ___ Python tracker <http://bugs.python.org/issue9212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9213] range purports to implement the Sequence ABC, but is missing index and count methods
Daniel Stutzbach added the comment: Thank you for the patch. The patch doesn't handle the case where the object being searched for is !PyLong_CheckExact. For example, the user might pass in a sub-type of int. The existing range_contains supports that case, so it seems like we should support it in range_index and range_count. The Sequence ABC's .index method doesn't include the optional start and stop parameters that are present on list.index. Since it's not part of the ABC, it's not mandatory that we implement those for range.index. The patch includes support for start and stop. Attached is a greatly revised patch, with two significant changes: - Adds support for !PyLong_CheckExact (using _PySequence_IterSearch) - Drops support for the start and stop parameters to index Dropping support for the start and stop parameters greatly simplified the code. If we want to support start and stop, then the code will need to get more complicated to handle the !PyLong_CheckExact case (since PySequence_IterSearch doesn't support start and stop). My patch abstracts out most of the code that had originally been in range_contains into a new function range_contains_long so that it can be called by range_contains, range_count, and range_index. The diff makes that part look like a large change, but it's mostly a whitespace change (the refactored code lost one indentation level but is otherwise unchanged). I uploaded Daniel Urban's patch and mine to Rietveld: http://codereview.appspot.com/2146041/ Any strong feelings on whether range.index should support the start and stop arguments provided by list.index, tuple.index, and str.index, but not by collections.Sequence.index? -- Added file: http://bugs.python.org/file18714/issue9213b.diff ___ Python tracker <http://bugs.python.org/issue9213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9746] All sequence types support .index and .count
New submission from Daniel Stutzbach : In the list of operations supported by all sequence types, the .index and .count methods should be included. They are defined by the collections.Sequence ABC that all sequences support. (except for range objects, but that will be fixed in Issue9213) -- assignee: d...@python components: Documentation messages: 115397 nosy: d...@python, stutzbach priority: normal severity: normal stage: needs patch status: open title: All sequence types support .index and .count type: behavior versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue9746> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9752] MSVC Compiler warning in Python\import.c
New submission from Daniel Stutzbach : 7>..\Python\import.c(1158) : warning C4013: 'mkdir' undefined; assuming extern returning int -- assignee: stutzbach components: Interpreter Core, Windows keywords: easy messages: 115428 nosy: stutzbach priority: low severity: normal stage: needs patch status: open title: MSVC Compiler warning in Python\import.c versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue9752> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9753] test_socket.testDup, testFromFd fail on Windows
New submission from Daniel Stutzbach : The errors below show up on my XP machine in Python 3.1 as well as a recent build from the py3k branch. I'm not sure why they *don't* show up on the XP buildbot. fromfd() ultimately calls dup(), so the underlying problem is likely the same for all the failures. dup() support was added for Windows in issue1378. == ERROR: testDup (test.test_socket.BasicTCPTest) -- Traceback (most recent call last): File "C:\Python31\lib\test\test_socket.py", line 628, in testDup msg = sock.recv(1024) socket.error: [Errno 10038] An operation was attempted on something that is not a socket == ERROR: testFromFd (test.test_socket.BasicTCPTest) -- Traceback (most recent call last): File "C:\Python31\lib\test\test_socket.py", line 619, in testFromFd msg = sock.recv(1024) socket.error: [Errno 10038] An operation was attempted on something that is not a socket == ERROR: testDup (test.test_socket.BasicTCPTest2) -- Traceback (most recent call last): File "C:\Python31\lib\test\test_socket.py", line 628, in testDup msg = sock.recv(1024) socket.error: [Errno 10045] The attempted operation is not supported for the type of object referenced == ERROR: testFromFd (test.test_socket.BasicTCPTest2) -- Traceback (most recent call last): File "C:\Python31\lib\test\test_socket.py", line 619, in testFromFd msg = sock.recv(1024) socket.error: [Errno 10038] An operation was attempted on something that is not a socket -- -- components: Library (Lib), Windows messages: 115432 nosy: brian.curtin, christian.heimes, roudkerk, stutzbach, tim.golden priority: normal severity: normal status: open title: test_socket.testDup, testFromFd fail on Windows type: behavior versions: Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue9753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
Daniel Stutzbach added the comment: I just noticed that the previous "new" patch I uploaded was actually my original patch. Oops. Anyway... In a discussion on the capi list, a few people objected to compiling in Unicode-agnostic mode by default (e.g., it would be annoying for Cython). Attached is a new patch that compiles in Unicode-agnostic mode only when Py_UNICODE_AGNOSTIC is defined (and brings the patch up to date with other changes to the py3k branch). It includes automated tests, and I have tested UCS2 Linux, UCS4 Linux, and Windows builds. After the patch, trying to import a module with a mismatched Unicode setting looks like this: >>> import _testunicodemismatched Traceback (most recent call last): File "", line 1, in ImportError: module's Unicode representation does not match the interpreter's Here's a birds-eye view of the patch: moduleobject.h: Add a flags field to PyModuleDef_Base moduleobject.c: Detect import with mismatched Unicode setting pyunicode.h: New file; non-agnostic code from unicodeobject.h moved here unicodeobject.h: Deleted ~150 lines of #defines (yay!) Everything else: tests I'm pretty happy with the patch. In the earlier discussion here, there was generally positive feedback for the overall idea. Someone want to do a patch review? -- keywords: +needs review stage: needs patch -> patch review Added file: http://bugs.python.org/file18723/unicode-2.patch ___ Python tracker <http://bugs.python.org/issue8654> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9753] test_socket.testDup, testFromFd fail on Windows
Daniel Stutzbach added the comment: I run it the same way. I wonder what's different? :-( I will try to find some time to investigate further. -- ___ Python tracker <http://bugs.python.org/issue9753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9753] test_socket.testDup, testFromFd fail on Windows
Daniel Stutzbach added the comment: On Windows, socket.dup is implemented using DuplicateHandle. The documentation for DuplicateHandle reads: You should not use DuplicateHandle to duplicate handles to the following objects: * I/O completion ports. No error is returned, but the duplicate handle cannot be used. * Sockets. No error is returned, but the duplicate handle may not be recognized by Winsock at the target process. Also, using DuplicateHandle interferes with internal reference counting on the underlying object. To duplicate a socket handle, use the WSADuplicateSocket function. -- ___ Python tracker <http://bugs.python.org/issue9753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9753] test_socket.testDup, testFromFd fail on Windows
Daniel Stutzbach added the comment: Following the advice of DuplicateHandle's documentation, I reimplemented dup on Windows using WSADuplicateHandle. Attached is a patch. With the patch, the tests pass on my Windows machine. Would someone like to review the patch? -- assignee: -> stutzbach keywords: +needs review, patch resolution: -> accepted stage: -> patch review ___ Python tracker <http://bugs.python.org/issue9753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9753] test_socket.testDup, testFromFd fail on Windows
Changes by Daniel Stutzbach : Added file: http://bugs.python.org/file18724/issue9753.patch ___ Python tracker <http://bugs.python.org/issue9753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9753] test_socket.testDup, testFromFd fail on Windows
Daniel Stutzbach added the comment: Thanks! Updated as you suggested and committed as r84450 and r84451. -- keywords: -needs review stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue9753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
Daniel Stutzbach added the comment: Thanks, Antoine. Those are all good suggestions. Attached is an updated patch. Marc-Andre, Martin: would you like to look this over as well? -- Added file: http://bugs.python.org/file18730/unicode-3.patch ___ Python tracker <http://bugs.python.org/issue8654> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9731] Add ABCMeta.has_methods and tests that use it
Daniel Stutzbach added the comment: I agree that my original name proposal is terrible. :-) method_check and verify_full_api both look fine to me. > If all collection registrations were bundled together in > collections.py, I think I would expect the tests to be in > test_collections. But I could still be presuaded that the range method > check should be in test_range where all the individual methods are > (should be!) tested. All of the registrations are bundled together in _abcoll.py, which collections.py imports into collections.py's namespace. (It's in a separate file to get around some bootstrapping issues.) I favor putting them in test_collections to make it slightly easier to check for a 1:1 correlation between registrations and tests, but it's not something I feel strongly about. -- ___ Python tracker <http://bugs.python.org/issue9731> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9764] Tools/buildbot/external.bat should download and built tix
New submission from Daniel Stutzbach : external.bat and external-common.bat take care of downloading most external packages such as tcl, tk, and openssl. However, the tix package is missing, but needed to build the msi. -- components: Build, Windows messages: 115503 nosy: loewis, stutzbach priority: normal severity: normal stage: needs patch status: open title: Tools/buildbot/external.bat should download and built tix type: feature request versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue9764> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9765] tcl-8 vs tcl8
New submission from Daniel Stutzbach : Tools/buildbot/external-common.bat creates tcl-8.5.2.1, but Tools/msi/msi.py looks for tcl8*. Consequently, Tools/buildbot/buildmsi.py does not work on a fresh machine. tk has the same problem. I encountered this on the py3k branch but have not checked other branches. Attached is a simple patch to Tools/msi/msi.py. -- components: Build, Windows files: tcl.patch keywords: patch messages: 115504 nosy: loewis, stutzbach priority: normal severity: normal stage: needs patch status: open title: tcl-8 vs tcl8 type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file18740/tcl.patch ___ Python tracker <http://bugs.python.org/issue9765> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1303434] Please include pdb with windows distribution
Daniel Stutzbach added the comment: Attached is a slightly improved patch. It cleans up some whitespace issues with James's patch and filters out *_d.pdb files if they exist. I tested it on my system and it correctly produces a .zip file containing the .pdb files, next to the .msi file Martin, do you need this patch to have any other functionality in order to make the python-*-pdb.zip file available after a release? -- Added file: http://bugs.python.org/file18741/pdb.patch ___ Python tracker <http://bugs.python.org/issue1303434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5553] Py_LOCAL_INLINE(type) doesn't actually inline except using MSC
Daniel Stutzbach added the comment: Ned, thanks for bringing that to my attention. I might have missed it otherwise. I had run "autoconf" but had not known to run "autoreconf", so I had missed the failure there. *embarrassed* Benjamin, thanks for fixing my error! -- nosy: +benjamin.peterson ___ Python tracker <http://bugs.python.org/issue5553> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9752] MSVC Compiler warning in Python\import.c
Daniel Stutzbach added the comment: As far as I can tell, _mkdir(name) is equivalent to CreateDirectoryA(name, NULL), except one uses errno and the other uses GetLastErrno. It is definitely possible that there's something I don't know, though, and the documentation doesn't explicitly state that they're equivalent. With regard to the mode parameter, I noticed that the implementation of os.mkdir for Windows doesn't do anything with it, which probably means we can not worry about the mode parameter here as well? os.mkdir's implementation just calls CreateDirectory(path, NULL). The code is in a #ifdef MS_WINDOWS in posix_mkdir() in Modules/posixmodule.c. -- ___ Python tracker <http://bugs.python.org/issue9752> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9609] make cProfile multi-stack aware
Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker <http://bugs.python.org/issue9609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9609] make cProfile multi-stack aware
Changes by Daniel Stutzbach : -- nosy: +georg.brandl stage: -> patch review ___ Python tracker <http://bugs.python.org/issue9609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9752] MSVC Compiler warning in Python\import.c
Daniel Stutzbach added the comment: Committed as r84659. Thanks for the patch! -- stage: patch review -> committed/rejected status: open -> closed type: -> compile error ___ Python tracker <http://bugs.python.org/issue9752> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9213] range purports to implement the Sequence ABC, but is missing index and count methods
Daniel Stutzbach added the comment: Thanks, Georg, for prodding. As a new committer, I have possibly been erring a little too far on the side of having my patches thoroughly reviewed before committing. I'll commit the patch on Monday if no one raises objections (after re-testing, of course). -- resolution: -> accepted ___ Python tracker <http://bugs.python.org/issue9213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9213] range purports to implement the Sequence ABC, but is missing index and count methods
Daniel Stutzbach added the comment: Committed as r84791. Question: should this bugfix be backported to Python 3.1 and to xrange objects in Python 2.7? Since it's a bugfix that adds new methods, it's a gray-area. (same question applies to the closely related Issue #9212) -- ___ Python tracker <http://bugs.python.org/issue9213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
Daniel Stutzbach added the comment: Where does/did the FAQ live in the version control tree? -- ___ Python tracker <http://bugs.python.org/issue9728> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
Daniel Stutzbach added the comment: It looks like the FAQ used be generated using Tools/faqwiz/faqwiz.py (which no longer exists). According to that file: --- This is a CGI program that maintains a user-editable FAQ. It uses RCS to keep track of changes to individual FAQ entries. It is fully configurable; everything you might want to change when using this program to maintain some other FAQ than the Python FAQ is contained in the configuration module, faqconf.py. --- In other words, while the FAQ was under version control, it wasn't the regular repository. I'll ask on python-dev is anyone has a copy. -- ___ Python tracker <http://bugs.python.org/issue9728> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
Daniel Stutzbach added the comment: Nevermind... archive.org has it. :-) -- ___ Python tracker <http://bugs.python.org/issue9728> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9728] Docs point to FAQ Section 3, but FAQs are not numbered
Daniel Stutzbach added the comment: Fixed in r84810, r84811, and 84812. For anyone curious, the old FAQ entry is here: http://web.archive.org/web/20010203161100/http://www.python.org/doc/FAQ.html#3.24 -- resolution: -> accepted stage: needs patch -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue9728> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9213] range purports to implement the Sequence ABC, but is missing index and count methods
Daniel Stutzbach added the comment: Sounds reasonable to me. I'll close this and the related 9212 (both fixes are already committed to the py3k branch). -- stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue9213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9212] dict_keys purports to implement the Set ABC, but is missing the isdisjoint method
Changes by Daniel Stutzbach : -- stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7, Python 3.1 ___ Python tracker <http://bugs.python.org/issue9212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9858] Python and C implementations of io are out of sync
Daniel Stutzbach added the comment: Attached is a script to find all of the mismatches between the C and Python implementations. There are several. Below is the output: RawIOBase C is missing: ['readinto', 'write'] StringIO C is missing: ['name'] StringIO python is missing: ['__getstate__', '__setstate__'] BufferedRandom python is missing: ['raw'] BlockingIOError python is missing: ['characters_written'] TextIOWrapper python is missing: ['buffer'] BufferedReader python is missing: ['raw'] BufferedWriter python is missing: ['raw'] BytesIO python is missing: ['__setstate__'] Since the Python version was the original reference implementation, adding the attributes missing from the C side seems to be a straightforward decision (and it should simply match whatever the Python version does). It looks like a number of new attributes have creeped into the C side, which will require more thoughtful decision making. We should probably double-check that each of these is documented, while we're at it. -- priority: low -> normal resolution: -> accepted title: RawIOBase doesn't define readinto -> Python and C implementations of io are out of sync Added file: http://bugs.python.org/file18889/missing_methods.py ___ Python tracker <http://bugs.python.org/issue9858> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9859] Add tests to verify API match of modules with 2 implementations
New submission from Daniel Stutzbach : Recently it came to light that the classes in C and Python implementations of the io module have slightly different attributes (issue9858). I propose the addition of a helper function in Lib/test/support.py to verify that the classes in two different implementations define the same attributes. Then, we can add tests to use that function to verify that C and Python implementations define the same API (for the io module, but also for other modules where we have two implementations). The script I added to issue9858 could serve as a starting point for such a function. Since CPython's standard library is the de facto reference implementation, it's important that it define one API and not two slightly different ones. :-) -- components: Tests messages: 116445 nosy: stutzbach priority: low severity: normal stage: needs patch status: open title: Add tests to verify API match of modules with 2 implementations type: feature request versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue9859> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9858] Python and C implementations of io are out of sync
Daniel Stutzbach added the comment: FWIW, I just opened Issue9859: Add tests to verify API match of modules with 2 implementations. -- ___ Python tracker <http://bugs.python.org/issue9858> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9859] Add tests to verify API match of modules with 2 implementations
Daniel Stutzbach added the comment: Yes, exactly. :-) (see also Issue9731, which has a similar flavor) -- ___ Python tracker <http://bugs.python.org/issue9859> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9858] Python and C implementations of io are out of sync
Daniel Stutzbach added the comment: > These attributes exist; they're just not properties. Yes, I see. They're added to the instance in the constructor, so they don't exist as attributes of the class. Also in that category: BlockingIOError python is missing: ['characters_written'] That leaves: RawIOBase C is missing: ['readinto', 'write'] StringIO C is missing: ['name'] StringIO python is missing: ['__getstate__', '__setstate__'] BytesIO python is missing: ['__setstate__'] The Python version of StringIO throws an AttributeException on the .name attribute. It's a property inherited from the TextIOWrapper. Effectively, TextIOWrapper provides the .name attribute if the object that it's wrapping provides the .name attribute. This behavior is undocumented. Is that reasonable behavior? Or should TextIOWrapper define .name always and return some suitable value if the wrapped object doesn't define .name? (e.g., None) In any case, it needs documentation. -- ___ Python tracker <http://bugs.python.org/issue9858> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
