[issue46083] PyUnicode_FSConverter() has confusing reference semantics
New submission from Thomas Wouters : The PyUnicode_FSConverter function has confusing reference semantics, and confusing documentation. https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_FSConverter says the output argument "must be a PyBytesObject* which must be released when it is no longer used." That seems to suggest one must pass a PyBytesObject to it, and indeed one of the error paths assumes an object was passed (https://github.com/python/cpython/blob/main/Objects/unicodeobject.c#L4116-- 'addr' is called 'result' in the docs). Not passing a valid object would result in trying to DECREF NULL, or garbage. However, the function doesn't actually use the object, and later in the function overwrites the value *without* DECREFing it, so passing a valid object would in fact cause a leak. I understand the function signature is the way it is so it can be used with PyArg_ParseTuple's O& format, but there are reasons to call it directly (e.g. with METH_O functions), and it would be nice if the semantics were more clear. -- components: C API messages: 408604 nosy: twouters priority: normal severity: normal status: open title: PyUnicode_FSConverter() has confusing reference semantics versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46083> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46150] test_pathlib assumes "fakeuser" does not exist as user
New submission from Thomas Wouters : test_pathlib contains, in PosixPathTest.test_expanduser, a check that expanduser on a nonexistent user will raise RuntimeError. Leaving aside the question why that's a RuntimeError (which is probably too late to fix anyway), the test performs this check by assuming 'fakeuser' is a nonexistent user. This test will fail when such a user does exist. (The test already uses the pwd module for other reasons, so it certainly could check that first.) -- components: Tests messages: 409030 nosy: twouters priority: normal severity: normal status: open title: test_pathlib assumes "fakeuser" does not exist as user versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46885] Ensure PEP 663 changes are reverted from 3.11
Change by Thomas Wouters : -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue46885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617699] slice-object support for ctypes Pointer/Array
Thomas Wouters added the comment: I'd like to check this into the trunk, without the non-step-1 support for now, so that we can remove simple slicing from the py3k branch. We can always add non-step-1 support later (all the sooner if someone who isn't me volunteers to do the painful bits of that support, probably by copy-pasting from the array module ;-) _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617699> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617687] specialcase simple sliceobj in list (and bugfixes)
Thomas Wouters added the comment: I prefer the current method, as it's more obviously walking in two strides across the same array. I also dislike hiding the final memmove() of the tail bit inside the loop. As for which is more obvious, I would submit neither is obvious, as it took me quite a bit of brainsweat to figure out how either version was supposed to work after not looking at the code for months :) Committed revision 57619. -- assignee: -> twouters resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617687> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617702] extended slicing for buffer objects
Thomas Wouters added the comment: Committed revision 57619. -- assignee: -> twouters resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617702> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617701] extended slicing for structseq
Thomas Wouters added the comment: Committed revision 57619. -- assignee: -> twouters resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617701> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617698] Extended slicing for array objects
Thomas Wouters added the comment: Committed revision 57619. -- assignee: -> twouters resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617698> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617682] specialcase simple sliceobj in tuple/str/unicode
Thomas Wouters added the comment: Committed revision 57619. -- assignee: -> twouters resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617682> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617691] Extended slicing for UserString
Thomas Wouters added the comment: Committed revision 57619. -- assignee: -> twouters resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617691> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617700] slice-object support for mmap
Thomas Wouters added the comment: Committed revision 57619. -- assignee: -> twouters resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617700> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1056] test_cmd_line starts python without -E
New submission from Thomas Wouters: test_cmd_line tests various things by spawning sys.executable. Unfortunately it does so without passing the -E argument (which 'make test' does do) so environment variables like PYTHONHOME and PYTHONPATH can cause the test to fail. -- assignee: ncoghlan components: Tests messages: 55418 nosy: twouters priority: high severity: normal status: open title: test_cmd_line starts python without -E type: crash versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1056> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617699] slice-object support for ctypes Pointer/Array
Thomas Wouters added the comment:
Added tests (by duplicating any slicing operations in the test suite
with extended slice syntax, to force the use of slice-objects ;)
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1617699>
_Index: Lib/ctypes/test/test_cast.py
===
--- Lib/ctypes/test/test_cast.py (revision 57617)
+++ Lib/ctypes/test/test_cast.py (working copy)
@@ -50,12 +50,16 @@
def test_other(self):
p = cast((c_int * 4)(1, 2, 3, 4), POINTER(c_int))
self.failUnlessEqual(p[:4], [1,2, 3, 4])
+self.failUnlessEqual(p[:4:], [1,2, 3, 4])
c_int()
self.failUnlessEqual(p[:4], [1, 2, 3, 4])
+self.failUnlessEqual(p[:4:], [1, 2, 3, 4])
p[2] = 96
self.failUnlessEqual(p[:4], [1, 2, 96, 4])
+self.failUnlessEqual(p[:4:], [1, 2, 96, 4])
c_int()
self.failUnlessEqual(p[:4], [1, 2, 96, 4])
+self.failUnlessEqual(p[:4:], [1, 2, 96, 4])
def test_char_p(self):
# This didn't work: bad argument to internal function
Index: Lib/ctypes/test/test_buffers.py
===
--- Lib/ctypes/test/test_buffers.py (revision 57617)
+++ Lib/ctypes/test/test_buffers.py (working copy)
@@ -15,6 +15,7 @@
self.failUnless(type(b[0]) is str)
self.failUnlessEqual(b[0], "a")
self.failUnlessEqual(b[:], "abc\0")
+self.failUnlessEqual(b[::], "abc\0")
def test_string_conversion(self):
b = create_string_buffer(u"abc")
@@ -23,6 +24,7 @@
self.failUnless(type(b[0]) is str)
self.failUnlessEqual(b[0], "a")
self.failUnlessEqual(b[:], "abc\0")
+self.failUnlessEqual(b[::], "abc\0")
try:
c_wchar
@@ -41,6 +43,7 @@
self.failUnless(type(b[0]) is unicode)
self.failUnlessEqual(b[0], u"a")
self.failUnlessEqual(b[:], "abc\0")
+self.failUnlessEqual(b[::], "abc\0")
def test_unicode_conversion(self):
b = create_unicode_buffer("abc")
@@ -49,6 +52,7 @@
self.failUnless(type(b[0]) is unicode)
self.failUnlessEqual(b[0], u"a")
self.failUnlessEqual(b[:], "abc\0")
+self.failUnlessEqual(b[::], "abc\0")
if __name__ == "__main__":
unittest.main()
Index: Lib/ctypes/test/test_arrays.py
===
--- Lib/ctypes/test/test_arrays.py (revision 57617)
+++ Lib/ctypes/test/test_arrays.py (working copy)
@@ -95,6 +95,7 @@
p = create_string_buffer("foo")
sz = (c_char * 3).from_address(addressof(p))
self.failUnlessEqual(sz[:], "foo")
+self.failUnlessEqual(sz[::], "foo")
self.failUnlessEqual(sz.value, "foo")
try:
@@ -106,6 +107,7 @@
p = create_unicode_buffer("foo")
sz = (c_wchar * 3).from_address(addressof(p))
self.failUnlessEqual(sz[:], "foo")
+self.failUnlessEqual(sz[::], "foo")
self.failUnlessEqual(sz.value, "foo")
if __name__ == '__main__':
Index: Lib/ctypes/test/test_structures.py
===
--- Lib/ctypes/test/test_structures.py (revision 57617)
+++ Lib/ctypes/test/test_structures.py (working copy)
@@ -236,7 +236,9 @@
# can use tuple to initialize array (but not list!)
self.failUnlessEqual(SomeInts((1, 2)).a[:], [1, 2, 0, 0])
+self.failUnlessEqual(SomeInts((1, 2)).a[::], [1, 2, 0, 0])
self.failUnlessEqual(SomeInts((1, 2, 3, 4)).a[:], [1, 2, 3, 4])
+self.failUnlessEqual(SomeInts((1, 2, 3, 4)).a[::], [1, 2, 3, 4])
# too long
# XXX Should raise ValueError?, not RuntimeError
self.assertRaises(RuntimeError, SomeInts, (1, 2, 3, 4, 5))
Index: Lib/ctypes/test/test_strings.py
===
--- Lib/ctypes/test/test_strings.py (revision 57617)
+++ Lib/ctypes/test/test_strings.py (working copy)
@@ -121,6 +121,7 @@
def XX_test_initialized_strings(self):
self.failUnless(c_string("ab", 4).raw[:2] == "ab")
+self.failUnless(c_string("ab", 4).raw[:2:] == "ab")
self.failUnless(c_string("ab", 4).raw[-1] == "\000")
self.failUnless(c_string("ab", 2).raw == "a\000")
Index: Lib/ctypes/test/test_memfunctions.py
===
--- Lib/ctypes/test/test_memfunctions.p
[issue1617699] slice-object support for ctypes Pointer/Array
Changes by Thomas Wouters: _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617699> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617699] slice-object support for ctypes Pointer/Array
Changes by Thomas Wouters: _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617699> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617699] slice-object support for ctypes Pointer/Array
Thomas Wouters added the comment:
Well, that's not quite how I implemented the slicing, and it's also not
how the existing simple-slicing was implemented: A negative start index
is taken to mean 0, and a stop index below the start index is taken to
mean 'the start index' (leading to an empty slice.)
However, it isn't too hard to do what I think you want done: a negative
index means indexing before the pointer, not from the end of the
pointer, and missing indices are only okay if they clearly mean '0'
('start' when step > 0, 'stop' when step < 0.)
So:
P[5:10] would slice from P[5] up to but not including P[10],
P[-5:5] would slice from P[-5] up to but not including P[5],
P[:5] would slice from P[0] up to but not including P[5],
P[5::-1] would slice from P[5] down to *and including* P[0]
but the following would all be errors:
P[5:]
P[:5:-1]
P[:]
P[::-1]
Does that sound like what you wanted?
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1617699>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617699] slice-object support for ctypes Pointer/Array
Thomas Wouters added the comment: Hmmm Well, that's fine by me, but it changes current behaviour, and in a way that ctypes own testsuite was testing, even ;) (it does, e.g., 'p[:4]' in a couple of places.) Requiring the start always would possibly break a lot of code. We could make only the start (and step) optional, and the start only if the step is positive, perhaps? That would change no existing, sane behaviour. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617699> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617699] slice-object support for ctypes Pointer/Array
Thomas Wouters added the comment: Checked in a slightly newer version. -- resolution: accepted -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617699> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1067] test_smtplib failures (caused by asyncore)
New submission from Thomas Wouters: test_smtplib fails because asyncore uses bytes(data) where data may be bytes or str or some undefined type. The attached patch fixes it to the extend that test_smtplib works again (plus a small fix in test_smtplib itself.) I'm not sure if this is the right thing to do -- maybe it should be using iso-8859-1, or maybe asyncore and asynchat should be ripped out by the roots and burned at the stake. -- assignee: gvanrossum files: asyncore.diff keywords: patch messages: 55520 nosy: gvanrossum, twouters severity: normal status: open title: test_smtplib failures (caused by asyncore) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1067> __ asyncore.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1067] test_smtplib failures (caused by asyncore)
Thomas Wouters added the comment: Checked in. -- resolution: accepted -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1067> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1067] test_smtplib failures (caused by asyncore)
Thomas Wouters added the comment: I agree, but the change wasn't actually mine. I merely adjusted the already-implemented strategy to the fact that bytes(str) no longer works. I think the original change was Jeremy H's. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1067> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12383] subprocess.Popen(..., env={}) fails to pass empty env.
New submission from Thomas Wouters :
The addition of the _posixsubprocess module in 3.2 introduced a change of
behaviour when passing an empty dict (or other false value besides None) as env:
python3.1 -c 'import subprocess; print(subprocess.Popen(["env"], env={},
stdout=subprocess.PIPE).communicate())'
(b'', None)
python3.2 -c 'import subprocess; print(subprocess.Popen(["env"], env={},
stdout=subprocess.PIPE).communicate())'
(b'LC_MONETARY=C\nSHELL=/bin/bash\nTERM=scr', None)
The test for 'env' being the default (None) is not explicit enough.
--
assignee: gregory.p.smith
components: Library (Lib)
files: subprocess.diff.txt
keywords: needs review, patch
messages: 138787
nosy: gregory.p.smith, twouters
priority: high
severity: normal
stage: patch review
status: open
title: subprocess.Popen(..., env={}) fails to pass empty env.
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22419/subprocess.diff.txt
___
Python tracker
<http://bugs.python.org/issue12383>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11561] "coverage" of Python regrtest cannot see initial import of libs
Thomas Wouters added the comment: For what it's worth, the need for a bootstrap-module has also come up within Google, where we have... somewhat different requirements than most. In order to fix import paths in a way that works even when using "python -S", I had a need to patch the very first module that gets imported. Unfortunately the actual first module that gets imported depends on the arguments passed to Python. So, I wrote the attached stdlib_landmark.diff patch, which makes a 'stdlib_landmark.py' file that is both the stdlib landmark (used by Python to find the stdlib itself, currently 'os.py') *and* the very first module that is imported, always. (The 'stdlib_landmark' name may be a little clunky; a better name, mirroring sitecustomize, may be "stdlibcustomize" or such.) And yes, this could have been fixed in other ways. I could've patched the interpreter directly, or made Python understand symlinks to .py/.pyc files better, or tried to make a bunch of other tools work better with symlinks. This has turned out the most convenient solution for a number of reasons, though. -- nosy: +twouters Added file: http://bugs.python.org/file23107/stdlib_landmark.diff ___ Python tracker <http://bugs.python.org/issue11561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12919] Control what module is imported first
Thomas Wouters added the comment: Here's the patch implementing this, which I'd attached to Issue11561 (although I noticed 'hg diff' omitted the empty stdlib_landmark.py file.) -- keywords: +patch nosy: +twouters Added file: http://bugs.python.org/file23113/stdlib_landmark.diff ___ Python tracker <http://bugs.python.org/issue12919> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4684] sys.exit() exits program when non-daemonic threads are still running
Changes by Thomas Wouters : -- resolution: -> fixed status: open -> closed superseder: -> Thread shutdown exception in Thread.notify() ___ Python tracker <http://bugs.python.org/issue4684> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11410] Use GCC visibility attrs in PyAPI_*
New submission from Thomas Wouters : This patch adds support for the GCC visibility attributes to the PyAPI_* macros (currently only used for Windows.) GCC's default visibility is 'public', but can be changed to 'hidden' with the '-fvisibility=hidden' argument; see http://gcc.gnu.org/wiki/Visibility. This patch does not make the build use that, it merely makes Python function correctly when the default visibility *is* changed. (The benefit of building Python with -fvisibility=hidden is very small, as it causes only a handful of symbols to not be exported. When embedding Python, though, this can make a lot of difference.) The patch also fixes a few modules that don't use PyMODINIT_FUNC for their module-init function definitions, like they should. -- files: gcc-visibility.diff keywords: needs review, patch messages: 130143 nosy: twouters priority: normal severity: normal status: open title: Use GCC visibility attrs in PyAPI_* Added file: http://bugs.python.org/file21014/gcc-visibility.diff ___ Python tracker <http://bugs.python.org/issue11410> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11410] Use GCC visibility attrs in PyAPI_*
Thomas Wouters added the comment: This patch adds support for the GCC visibility attributes to the PyAPI_* macros (currently only used for Windows.) GCC's default visibility is 'public', but can be changed to 'hidden' with the '-fvisibility=hidden' argument; see http://gcc.gnu.org/wiki/Visibility. This patch does not make the build use that, it merely makes Python function correctly when the default visibility *is* changed. (The benefit of building Python with -fvisibility=hidden is very small, as it causes only a handful of symbols to not be exported. When embedding Python, though, this can make a lot of difference.) The patch also fixes a few modules that don't use PyMODINIT_FUNC for their module-init function definitions, like they should. -- ___ Python tracker <http://bugs.python.org/issue11410> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11410] Use GCC visibility attrs in PyAPI_*
Changes by Thomas Wouters : -- Removed message: http://bugs.python.org/msg130144 ___ Python tracker <http://bugs.python.org/issue11410> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11410] Use GCC visibility attrs in PyAPI_*
Thomas Wouters added the comment: Uploaded to Rietveld, too: http://codereview.appspot.com/4260052/ -- ___ Python tracker <http://bugs.python.org/issue11410> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11411] Fix typo in Makefile
New submission from Thomas Wouters : Fix a (double) typo in the Makefile, which prevents 'make DESTDIR=relative/path' from working correctly. -- files: destdir.diff keywords: easy, needs review, patch messages: 130146 nosy: twouters priority: normal severity: normal status: open title: Fix typo in Makefile Added file: http://bugs.python.org/file21015/destdir.diff ___ Python tracker <http://bugs.python.org/issue11411> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11411] Fix typo in Makefile
Thomas Wouters added the comment: Checked into 2.7, 3.1, 3.2 and default (d121681ed1cc, 12f0da000dc4, 686df11f0a14, bb2a9ea5c7d0.) -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue11411> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11410] Use GCC visibility attrs in PyAPI_*
Thomas Wouters added the comment: The cygwin changes are no-ops, just refactoring the needlessly nested if statement for clarity. I can revert them. The getargs.c change *is* necessary, although it doesn't have to be that exact change. The problem is that the functions in that block are not declared in any file in Include/, although I don't know why not (it's true that these function shouldn't be called directly, but they are symbols that should be exported. The ifdef the patch removes makes the export happen only for Windows, but I see no reason to do that conditionally.) To be clear, the #define of (for example) PyArg_Parse to _PyArg_Parse_SizeT in Include/modsupport.h doesn't apply, because Python/getargs.c does not (and must not) define PY_SSIZE_T_CLEAN (or we wouldn't be able to define both PyArg_Parse and _PyArg_Parse_SizeT.) We could just list these functions in Include/modsupport.h, along with the 'public' (non-PY_SSIZE_T_CLEAN) ones -- but that only makes sense if we want code to call the ssize_t functions directly, which I don't think we want. -- ___ Python tracker <http://bugs.python.org/issue11410> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11417] distutils' bdist_rpm fails when running with PYTHONDONTWRITEBYTECODE
New submission from Thomas Wouters : According to distutils' test_bdist_rpm, bdist_rpm fails when running Python with -B/PYTHONDONTWRITEBYTECODE. (bdist_rpm or its test doesn't pass -B along but also doesn't use -E, so the test-failure shows up when setting the PYTHONDONTWRITEBYTECODE environment variable.) It looks like (somewhere in distutils) something relies on .pyc files being written, instead of explicitly using (say) py_compile.compile(). -- assignee: tarek components: Distutils messages: 130198 nosy: eric.araujo, tarek, twouters priority: normal severity: normal status: open title: distutils' bdist_rpm fails when running with PYTHONDONTWRITEBYTECODE ___ Python tracker <http://bugs.python.org/issue11417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11420] Make testsuite pass with -B/DONTWRITEBYTECODE set.
New submission from Thomas Wouters : This patch tweaks a few tests that currently rely on .pyc files being written, causing them to fail (or crash) when running 'make test TESTPYTHONOPTS=-B'. All these are purely test failures, not failures in the tested code (unlike issue #11417, which is a failure in bdist_rpm instead of the test.) (This patch is for 3.1; the patch for 3.2/default is slightly different. I also have the same patch for Python 2.6/2.7, but I'm not sure if it's worth applying.) -- components: Tests files: py31-dontwritebytecode.diff keywords: patch messages: 130204 nosy: twouters priority: normal severity: normal status: open title: Make testsuite pass with -B/DONTWRITEBYTECODE set. versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file21022/py31-dontwritebytecode.diff ___ Python tracker <http://bugs.python.org/issue11420> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11420] Make testsuite pass with -B/DONTWRITEBYTECODE set.
Changes by Thomas Wouters : Added file: http://bugs.python.org/file21023/py32-dontwritebytecode.diff ___ Python tracker <http://bugs.python.org/issue11420> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11410] Use GCC visibility attrs in PyAPI_*
Thomas Wouters added the comment: Windows/Cygwin parts of the patch reverted and new patch uploaded. My point about the _Py*_SizeT functions is that they're only declared when you define PY_SSIZE_T_CLEAN, and I don't know if we want to change that (I don't think it makes sense to.) -- Added file: http://bugs.python.org/file21024/gcc-visibility.diff ___ Python tracker <http://bugs.python.org/issue11410> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11410] Use GCC visibility attrs in PyAPI_*
Changes by Thomas Wouters : Removed file: http://bugs.python.org/file21014/gcc-visibility.diff ___ Python tracker <http://bugs.python.org/issue11410> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11417] distutils' bdist_rpm fails when running with PYTHONDONTWRITEBYTECODE
Thomas Wouters added the comment: I couldn't really care less about bdist_rpm, I'm just reporting a bug in it when not writing .pyc files (through PYTHONDONTWRITEBYTECODE.) I encountered it while making the testsuite do the right thing when not writing bytecode (see issue #11420.) To me, a perfectly acceptable "fix" would be for the bdist_rpm tests to be skipped when not writing bytecode. -- ___ Python tracker <http://bugs.python.org/issue11417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11417] distutils' bdist_rpm fails when running with PYTHONDONTWRITEBYTECODE
Thomas Wouters added the comment: I'll incorporate that change into issue #11420 then, and close this (and harp on bdist_rpm2 if it ever lands in the stdlib and has the same issue :-) -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue11417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11420] Make testsuite pass with -B/DONTWRITEBYTECODE set.
Changes by Thomas Wouters : Removed file: http://bugs.python.org/file21022/py31-dontwritebytecode.diff ___ Python tracker <http://bugs.python.org/issue11420> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11420] Make testsuite pass with -B/DONTWRITEBYTECODE set.
Changes by Thomas Wouters : Removed file: http://bugs.python.org/file21023/py32-dontwritebytecode.diff ___ Python tracker <http://bugs.python.org/issue11420> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11420] Make testsuite pass with -B/DONTWRITEBYTECODE set.
Thomas Wouters added the comment: As per issue #11417, updated to also skip the tests in distutils/tests/test_bdist_rpm.py when not writing bytecode. -- Added file: http://bugs.python.org/file21036/py31-dontwritebytecode.diff ___ Python tracker <http://bugs.python.org/issue11420> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11420] Make testsuite pass with -B/DONTWRITEBYTECODE set.
Changes by Thomas Wouters : Added file: http://bugs.python.org/file21037/py32-dontwritebytecode.diff ___ Python tracker <http://bugs.python.org/issue11420> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11470] Flag inappropriate uses of callable class attributes
New submission from Thomas Wouters :
As discussed at the language summit at PyCon 2011, some code takes some
liberties with setting class attributes to callable objects, like CFunctions,
that (C)Python does not turn into methods. This is problematic because 1)
CPython can't then turn that CFunction into a regular function, and 2) other
implementations have to specialcase the builtins to emulate the behaviour.
This patch adds a warning when a non-descriptor, non-class callable attribute
is accessed in a context that would have fired the descriptor. It also fixes a
bunch of these warnings that show up when running the testsuite. Some of these
warnings are obviously (to me) incorrect code -- like the io testsuite, which
uses staticmethod around pyio.open but not io.open, or the encoding classes
that use an encode function from an extension module as a class attribute. Some
of the warnings are debatable, but have an obvious fix (wrap in staticmethod.)
Some could be considered false-positives because they actually use (what
amounts to) a a bound instance method as a class attribute (for example,
re.compile('...').match.)
The patch is still a work in progress, I'm just uploading to start the
discussion sooner rather than later.
--
components: Interpreter Core
files: nonmethod-warn.diff
keywords: patch
messages: 130606
nosy: twouters
priority: normal
severity: normal
status: open
title: Flag inappropriate uses of callable class attributes
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21085/nonmethod-warn.diff
___
Python tracker
<http://bugs.python.org/issue11470>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11462] Peephole creates duplicate and unused constants
Changes by Thomas Wouters : Added file: http://bugs.python.org/file21086/nonmethod-warn-nongit.diff ___ Python tracker <http://bugs.python.org/issue11462> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11462] Peephole creates duplicate and unused constants
Changes by Thomas Wouters : Removed file: http://bugs.python.org/file21086/nonmethod-warn-nongit.diff ___ Python tracker <http://bugs.python.org/issue11462> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11470] Flag inappropriate uses of callable class attributes
Changes by Thomas Wouters : Added file: http://bugs.python.org/file21087/nonmethod-warn-nongit.diff ___ Python tracker <http://bugs.python.org/issue11470> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11470] Flag inappropriate uses of callable class attributes
Changes by Thomas Wouters : Removed file: http://bugs.python.org/file21085/nonmethod-warn.diff ___ Python tracker <http://bugs.python.org/issue11470> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11470] Flag inappropriate uses of callable class attributes
Changes by Thomas Wouters : Added file: http://bugs.python.org/file21088/nonmethod-warn-nongit.diff ___ Python tracker <http://bugs.python.org/issue11470> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11470] Flag inappropriate uses of callable class attributes
Changes by Thomas Wouters : Removed file: http://bugs.python.org/file21087/nonmethod-warn-nongit.diff ___ Python tracker <http://bugs.python.org/issue11470> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11462] Peephole creates duplicate and unused constants
Thomas Wouters added the comment: What is the actual performance impact of this change? As far as I can see the difference is almost entirely in .pyc (on-disk) size, as when loading most of these constants are interned anyway. Even the on-disk change is minimal - and I say that as a person who actually cares a lot about the size of .pyc files. Considering the extra work that needs to be done, I expect planA to be a measurable performance drop, and planB to be indistinguishable. Perhaps I'm wrong, so feel free to prove it so by providing some (unladen-swallow) benchmarks :) I'm not sure this change is worth it unless there's a clear performance benefit. The peephole optimizer is very limited, fragile, and an uncomfortable place to edit (and I say *that* as a person who has introduced way too many subtle, stupid bugs in the past.) As Raymond says, the right thing to do with the peepholer is to rip it out and replace it with an AST-based optimizer, which wouldn't bypass or duplicate all manner of sanity- and safety-checks. Perhaps this should be a GSoC project. About the patches themselves: the plan-A patch is a bad idea, I wouldn't consider it; duplicating the compiler checks seems pointless. In the plan-B patch, PyCode_Optimize is an exported symbol so it should not change; you need to change the name and provide the old interface in a macro. The extern declaration of _PyCode_AddObj in peephole.c is now unnecessary. The name of that function is rather non-obvious, since it doesn't do anything with a code object at all -- but I don't have a better suggestion. -- ___ Python tracker <http://bugs.python.org/issue11462> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11478] Docs list nonexistant PyObject_CopyToData function
New submission from Thomas Wouters : The buffer docs on http://docs.python.org/c-api/buffer.html list PyObject_CopyToData, but no such function seems to exist. -- assignee: docs@python components: Documentation messages: 130717 nosy: docs@python, twouters priority: normal severity: normal status: open title: Docs list nonexistant PyObject_CopyToData function ___ Python tracker <http://bugs.python.org/issue11478> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11478] Docs list nonexistant PyObject_CopyToData function
Thomas Wouters added the comment: Eh, I mean PyObject_CopyToObject. -- ___ Python tracker <http://bugs.python.org/issue11478> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11478] Docs list nonexistant PyObject_CopyToObject function
Changes by Thomas Wouters : -- title: Docs list nonexistant PyObject_CopyToData function -> Docs list nonexistant PyObject_CopyToObject function ___ Python tracker <http://bugs.python.org/issue11478> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11470] Flag inappropriate uses of callable class attributes
Thomas Wouters added the comment: New version of the patch; instead of triggering at attribute *access*, this just checks when creating types and in type_setattro. It also makes the warning a newly added CompatibilityWarning. Also, instead of warning for all non-descriptors, it now only warns for PyCFunctionObjects that do not have a __self__ set, or of which __self__ is a module. (The reason for the latter being the new-ish behaviour of functions defined in modules in C getting passed something as __self__, defaulting to the module.) I've removed a few staticmethod calls from cases that do not trigger the new warning. This patch still lacks tests and doc updates, but I'm uploading right now because the sprints apparently lose internet soonish. -- Added file: http://bugs.python.org/file21271/nonmethod-warn.diff ___ Python tracker <http://bugs.python.org/issue11470> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11470] Flag inappropriate uses of callable class attributes
Changes by Thomas Wouters : Removed file: http://bugs.python.org/file21088/nonmethod-warn-nongit.diff ___ Python tracker <http://bugs.python.org/issue11470> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5438] test_bigmem.test_from_2G_generator uses more memory than expected
Thomas Wouters added the comment: I'm not surprised this test takes up more memory... It claims to take up 9 times the test size in memory, with a minimum useful test size of 1G. With a limit of 12G that would make the test size about 1.33G. However, it then proceeds to build a tuple of 159 million distinct integers and stuffs them into a tuple. Each integer is at least 24 bytes long, plus the 8 of the pointer in the tuple, making the total memory use over 32 times the test size. I'll fix the test. -- assignee: -> twouters nosy: +twouters versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue5438> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7915] A lists which list.sort seems to leave out of order.
Thomas Wouters added the comment: You have a nan in your list of tuples, which screws up the sorting. After the first sort, elements 580395-7 are: (0.99257340581672904, 551095), (nan, 551371), (6.6494600485570754e-14, 551526), -- nosy: +twouters resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue7915> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8111] docs.python.org/download.html unhelpful.
New submission from Thomas Wouters : docs.python.org is showing the docs for 2.6.5c2. As its most obvious bad consequence, docs.python.org/download.html doesn't offer any actual downloads, and there are no obvious (to newbies looking to download docs) links to working downloads. -- assignee: georg.brandl components: Documentation messages: 100797 nosy: georg.brandl, twouters severity: normal status: open title: docs.python.org/download.html unhelpful. ___ Python tracker <http://bugs.python.org/issue8111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8111] docs.python.org/download.html unhelpful.
Thomas Wouters added the comment: Things getting worse before they get better? http://docs.python.org/ now shows the 2.7a4 documentation, which is really not good. Perhaps we need some safeguards to make sure that http://docs.python.org/ is a *stable* version of the docs? :P -- priority: -> high ___ Python tracker <http://bugs.python.org/issue8111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8111] docs.python.org/download.html unhelpful.
Thomas Wouters added the comment: Oh, actually, looks like something was redirecting from docs.python.org to docs.python.org/dev. It seems fixed now. (It wasn't just me, though, I got complaints from others that it was 2.7a4 for at least an hour.) -- ___ Python tracker <http://bugs.python.org/issue8111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8111] docs.python.org/download.html unhelpful.
Changes by Thomas Wouters : -- ___ Python tracker <http://bugs.python.org/issue8111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8111] docs.python.org/download.html unhelpful.
Changes by Thomas Wouters : -- ___ Python tracker <http://bugs.python.org/issue8111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8111] docs.python.org/download.html unhelpful.
Thomas Wouters added the comment: Nevermind the 2.7a4 comments, I think I'm just not all awake yet. The complaints I got were about it being 2.6.5c2, my browser showing me 2.7a4 may have been stupid autocompletion or something. (Still, please fix :) -- ___ Python tracker <http://bugs.python.org/issue8111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1067] test_smtplib failures (caused by asyncore)
Changes by Thomas Wouters: -- assignee: twouters -> nobody nosy: +nobody __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1067> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1067] test_smtplib failures (caused by asyncore)
Thomas Wouters added the comment: I thought I already had, in my reply to Martin and the original comment: he's right, but I don't care about asyncore or asynchat. I merely perpetuated the fix that was already in place. The real 'fix' is to teach both modules about unicode; have them handle in bytes, and add a new API for strings (in which the user has to supply encodings.) But I don't think asyncore and asynchat are worth keeping, let alone fixing, so I'm not the right person to look at this. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1067> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1967] Backport dictviews to 2.6
New submission from Thomas Wouters: Patch to backport dictviews to trunk. Consists of some trickery: - new 'viewkeys', 'viewvalues' and 'viewitems' methods of dicts, returning exactly what 'keys', 'values' and 'items' return in 3.0: three new types defined in dictobject.c - a future import (dictviews) that changes which opcodes are generated for (some) attribute access - special opcodes for getting and setting 'keys', 'values' and 'items' attributes from an object. These opcodes do nothing special unless a future import is in effect in the calling code block *and* the type they are called on is a dict subclass, in which case they translate 'keys', 'values' and 'items' to 'viewkeys', 'viewvalues' and 'viewitems'. - similar specialcasing in getattr() and setattr() -- components: Interpreter Core files: dictviews_backport.diff keywords: patch messages: 61834 nosy: twouters severity: normal status: open title: Backport dictviews to 2.6 versions: Python 2.6 Added file: http://bugs.python.org/file9320/dictviews_backport.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1967> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1967] Backport dictviews to 2.6
Changes by Thomas Wouters: Removed file: http://bugs.python.org/file9320/dictviews_backport.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1967> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1967] Backport dictviews to 2.6
Thomas Wouters added the comment: After talking to Guido, got rid of the future import magic in favour of just providing 'viewkeys', 'viewitems' and 'viewvalues' methods of dicts. This makes efficient 2.6-and-3.0 dict-using code possibly by making 2to3 translate the view-methods directly to keys/values/items in 3.0, and not wrapping everything in list(). Added file: http://bugs.python.org/file9336/dictviews_backport.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1967> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
New submission from Thomas Wouters <[EMAIL PROTECTED]>:
The attached patch adds the missing *-unpacking generalizations.
Specifically:
>>> a, b, *c = range(5)
>>> *a, b, c = a, b, *c
>>> a, b, c
([0, 1, 2], 3, 4)
>>> [ *a, b, c ]
[0, 1, 2, 3, 4]
>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>> [ *item for item in L ]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Also, yielding everything from an iterator:
>>> def flatten(iterables):
... for it in iterables:
... yield *it
...
>>> L = [ a, (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
>>> flatten(L)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
--
assignee: gvanrossum
components: Interpreter Core
files: morestar.diff
keywords: patch, patch
messages: 63548
nosy: gvanrossum, twouters
severity: normal
status: open
title: Missing *-unpacking generalizations
versions: Python 3.0
Added file: http://bugs.python.org/file9673/morestar.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2292>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Thomas Wouters <[EMAIL PROTECTED]> added the comment:
On Sat, Mar 15, 2008 at 9:12 AM, Guido van Rossum <[EMAIL PROTECTED]>
wrote:
>
> Guido van Rossum <[EMAIL PROTECTED]> added the comment:
>
> Didn't you say it does sets too? Does this work?
> a = [1, 2, 3]
> {1, *a, 0, 4} # {0, 1, 2, 3, 4}
Yes.
>
>
> How about dicts?
> kwds = {'z': 0, 'w': 12}
> {'x': 1, 'y': 2, **kwds} # {'x': 1, 'y': 2, 'z': 0, 'w': 12}
Not yet.
>
>
> Also, now that we support
>
> [*a, b, c]
>
> shouldn't we also support
>
> foo(*a, b, c)
>
Sure. (And also 'foo(*a, *b, *c)'?) But have you taken a look lately at the
function definition grammar? I need some time to sort it out :)
Added file: http://bugs.python.org/file9674/unnamed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2292>
__On Sat, Mar 15, 2008 at 9:12 AM, Guido van
Rossum <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]>
wrote:
Guido van Rossum <mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]> added the comment:
Didn't you say it does sets too? Does this work?
a = [1, 2, 3]
{1, *a, 0, 4} # {0, 1, 2, 3,
4}Yes.
How about dicts?
kwds = {'z': 0, 'w': 12}
{'x': 1, 'y': 2, **kwds} # {'x': 1, 'y':
2, 'z': 0, 'w': 12}Not
yet.
Also, now that we support
[*a, b, c]
shouldn't we also support
foo(*a, b, c)
Sure.
(And also 'foo(*a, *b, *c)'?) But have you taken a look lately at the
function definition grammar? I need some time to sort it out :)
-- Thomas Wouters <mailto:[EMAIL
PROTECTED]">[EMAIL PROTECTED]>Hi! I'm a .signature virus!
copy me into your .signature file to help me spread!
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Thomas Wouters <[EMAIL PROTECTED]> added the comment: On Sat, Mar 15, 2008 at 9:18 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Guido van Rossum <[EMAIL PROTECTED]> added the comment: > > Looking at the flatten() example I'm curious -- how come the output of > > >>> flatten(L) > > is displayed as a list rather than as ? > It's a typo. It should've been list(flatten(L)) :-) (see the tests included in the patch.) Added file: http://bugs.python.org/file9675/unnamed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2292> __On Sat, Mar 15, 2008 at 9:18 AM, Guido van Rossum <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Guido van Rossum <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> added the comment: Looking at the flatten() example I'm curious -- how come the output of >>> flatten(L) is displayed as a list rather than as <generator at xx> ? It's a typo. It should've been list(flatten(L)) :-) (see the tests included in the patch.) -- Thomas Wouters <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Thomas Wouters <[EMAIL PROTECTED]> added the comment: Updated patch: reworked some internals, and added generalization of functioncalls after talking with Guido. *args is now considered just another positional argument, and can occur anywhere in the positional argument section. It can also occur more than once. Keyword arguments now have to appear after *args, and **kwargs can now occur multiple times at any position in the keyword argument list. test_extcall has some examples. (The opcodes are largely unaffected; just the order of '*args' and keyword arguments is changed. Behind the scenes, anything after the first '*args' argument is collapsed into a single *args, and everything after the first '**kwargs' is likewise collapsed. The common case (meaning any currently valid syntax, barring the 2to3 fix to swap *args and keyword arguments) does not change in meaning or codepath, just the complex cases are handled differently.) This is still Work In Progress. To do: implement the dict unpacking syntax (the mechanics are already there for keyword arguments to functioncalls), make sure the precendence of * is correct, get more complete test coverage, iron out the cosmetic bugs in the 2to3 fixer. Bzr branch for this patch is http://code.python.org/python/users/twouters/starunpack . There is also a branch with just the functioncall changes (although the starunpack changes are a small sprinkling on top of that branch, as it uses the same new mechanics): http://code.python.org/python/users/twouters/funcargs . Added file: http://bugs.python.org/file9955/starunpack.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2292> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Thomas Wouters <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9673/morestar.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2292> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Thomas Wouters <[EMAIL PROTECTED]> added the comment:
No, it's what you asked for in msg63551:
> How about dicts?
> kwds = {'z': 0, 'w': 12}
> {'x': 1, 'y': 2, **kwds} # {'x': 1, 'y': 2, 'z': 0, 'w': 12}
(unpacking of dicts in dicts.)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2292>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Thomas Wouters <[EMAIL PROTECTED]> added the comment: Agreed. A PEP was already on my TODO list (although I don't mind if someone else picks it up :-) I implemented the dict-unpacking-in-dict-literal syntax in the mean time; it's pushed to the starunpack bzr branch, but I'll add some actual tests before I upload the patch. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2292> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Thomas Wouters <[EMAIL PROTECTED]> added the comment:
On Mon, Apr 7, 2008 at 9:00 PM, Alexander Belopolsky <[EMAIL PROTECTED]>
wrote:
>
> Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
>
> Thomas,
>
> Could you add BUILD_*_UNPACK opcodes documentation to
> Doc/library/dis.rst? It would also help if you modify CALL_FUNCTION_*
> opcodes' documentation to explain how they will interact with unpacking
> opcodes.
They don't interact. They're separate opcodes. The CALL_FUNCTION_* opcodes
are almost untouched, except the _VAR and _VAR_KW versions: previously, they
expected, on the stack, positional arguments followed by keyword/argument
pairs followed by the *args sequence followed by the **kwargs mapping (for
_VAR_KW.) I just changed the order so *args is before the keyword/argument
pairs. The change is not related to the BUILD_*_UNPACK opcodes, but rather
to Guido's request that the order of keyword arguments and *args in the
functioncall syntax changes. For the order of execution to remain sane, the
arguments need to be pushed on the stack in that order, and keeping the
_VAR* opcode order the same would mean a large amount of ROT_* opcodes ;-P
Updating the docs is on the TODO list.
>
> Do I understand correctly that non-starred arguments are packed into
> intermediate tuples/sets in the presence of starred arguments so that
> {a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a
> problem for tuples, but with sets, it means that {a,b,c} may behave
> subtly differently from {a,*(b,c)}.
>
Yes, that's what happens, but only in the presence of *args. For
functioncalls, it only happens to everything after the first *args
(inclusive.) That means '{a, b, c}' does not change, and neither does
'func(a, b, c)' or 'func(a, b, *c)'. As for sets, I don't see why this would
be a problem; there is no difference in the set created by {a, b, c} and the
set created by {a, *{b, c}} or {a, *(b, c)}. The arguments are all
evaluated in the same order (left to right), and c replaces b, b replaces a
if they are considered equal by sets.
Added file: http://bugs.python.org/file9970/unnamed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2292>
__On Mon, Apr 7, 2008 at 9:00 PM, Alexander
Belopolsky <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]>
wrote:
Alexander Belopolsky <mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]> added the comment:
Thomas,
Could you add BUILD_*_UNPACK opcodes documentation to
Doc/library/dis.rst? It would also help if you modify CALL_FUNCTION_*
opcodes' documentation to explain how they will interact with unpacking
opcodes.They don't interact. They're separate
opcodes. The CALL_FUNCTION_* opcodes are almost untouched, except the _VAR and
_VAR_KW versions: previously, they expected, on the stack, positional arguments
followed by keyword/argument pairs followed by the *args sequence followed by
the **kwargs mapping (for _VAR_KW.) I just changed the order so *args is before
the keyword/argument pairs. The change is not related to the BUILD_*_UNPACK
opcodes, but rather to Guido's request that the order of keyword arguments
and *args in the functioncall syntax changes. For the order of execution to
remain sane, the arguments need to be pushed on the stack in that order, and
keeping the _VAR* opcode order the same would mean a large amount of ROT_*
opcodes ;-P
Updating the docs is on the TODO list.
Do I understand correctly that non-starred arguments are packed into
intermediate tuples/sets in the presence of starred arguments so that
{a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a
problem for tuples, but with sets, it means that {a,b,c} may behave
subtly differently from {a,*(b,c)}.
Yes,
that's what happens, but only in the presence of *args. For functioncalls,
it only happens to everything after the first *args (inclusive.) That means
'{a, b, c}' does not change, and neither does 'func(a, b, c)'
or 'func(a, b, *c)'. As for sets, I don't see why this would be a
problem; there is no difference in the set created by {a, b, c} and the set
created by {a, *{b, c}} or {a, *(b, c)}. The arguments are all evaluated
in the same order (left to right), and c replaces b, b replaces a if they are
considered equal by sets.
-- Thomas Wouters <mailto:[EMAIL
PROTECTED]">[EMAIL PROTECTED]>Hi! I'm a .signature virus!
copy me into your .signature file to help me spread!
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Thomas Wouters <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9970/unnamed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2292> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Thomas Wouters <[EMAIL PROTECTED]> added the comment: I'm not sure how this matters. The order of evaluation is the same, the BUILD_SET implementation just hashes the evaluated items in a different order. You can't really rely on that particular order as it's tied closely to the stack representation CPython uses. I also see no practical reason -- or even practical *way* -- to abuse the hashing order. But you have given me an idea on how to improve some of the code in the BUILD_*_UNPACK opcodes, hmm. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2292> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Thomas Wouters <[EMAIL PROTECTED]> added the comment: I don't think the order in which the items are hashed is really what Raymond was worried about. Rather, the size of the stack was, and the effect of having all the items on the stack at the same time. I think Raymond is wrong in this case; while the stack may grow relatively big, we're only talking two pointers here. The items will all have to be created anyway, and in the usual case the number of duplicate keys is low. My patch actually includes pretty much the same change to BUILD_MAP, because it greatly simplifies the compiler code and gets rid of a lot of extra opcodes -- causing an overal speedup even in the face of large dict literals. But I guess we should take it up with Raymond at some point, perhaps as part of the PEP discussion. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2292> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37589] Missing dependences in the Makefile
Change by Thomas Wouters : -- keywords: +patch pull_requests: +15410 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15757 ___ Python tracker <https://bugs.python.org/issue37589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37589] Missing dependences in the Makefile
Thomas Wouters added the comment: New changeset b4612f5d54aced5bc37f1b85bf50b4cafa2480f0 by T. Wouters in branch 'master': bpo-37589: Add a few missing dependencies on .h files in the Makefile. (GH-15757) https://github.com/python/cpython/commit/b4612f5d54aced5bc37f1b85bf50b4cafa2480f0 -- ___ Python tracker <https://bugs.python.org/issue37589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37589] Missing dependences in the Makefile
Change by Thomas Wouters : -- pull_requests: +15422 pull_request: https://github.com/python/cpython/pull/15769 ___ Python tracker <https://bugs.python.org/issue37589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37589] Missing dependences in the Makefile
Change by Thomas Wouters : -- assignee: -> twouters resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints
Thomas Wouters added the comment: New changeset 3cbc23aa229bc5ec04845053df78eae5f54e0497 by T. Wouters (Greg Price) in branch 'master': bpo-37758: Cut always-constant conditionals on sys.maxunicode. (GH-15302) https://github.com/python/cpython/commit/3cbc23aa229bc5ec04845053df78eae5f54e0497 -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue37758> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36279] os.wait3() leaks some uninitialized stack when no processes exist
Thomas Wouters added the comment: New changeset 682107cf458578ee6bd92b7cc6862113034a4fad by T. Wouters (Zackery Spytz) in branch 'master': bpo-36279: Ensure os.wait3() rusage is initialized (GH-15111) https://github.com/python/cpython/commit/682107cf458578ee6bd92b7cc6862113034a4fad -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue36279> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37840] bytearray_getitem() handles negative index incorrectly
Thomas Wouters added the comment: New changeset 92709a263e9cec0bc646ccc1ea051fc528800d8d by T. Wouters (Sergey Fedoseev) in branch 'master': bpo-37840: Fix handling of negative indices in bytearray_getitem() (GH-15250) https://github.com/python/cpython/commit/92709a263e9cec0bc646ccc1ea051fc528800d8d -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue37840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33418] Memory leaks in functions
Thomas Wouters added the comment: New changeset ccaea525885e41c5f1e566bb68698847faaa82ca by T. Wouters (Victor Stinner) in branch '3.8': Revert "bpo-33418: Add tp_clear for function object (GH-8058)" (GH-15826) https://github.com/python/cpython/commit/ccaea525885e41c5f1e566bb68698847faaa82ca -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue33418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38083] Minor improvements in asdl_c.py and Python-ast.c
Thomas Wouters added the comment: New changeset 43c9731334470573209464b7f67914d386457efc by T. Wouters (Serhiy Storchaka) in branch 'master': bpo-38083: Minor improvements in asdl_c.py and Python-ast.c. (GH-15824) https://github.com/python/cpython/commit/43c9731334470573209464b7f67914d386457efc -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue38083> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38083] Minor improvements in asdl_c.py and Python-ast.c
Thomas Wouters added the comment: This doesn't feel like a change that's worth backporting to 3.8 at this point. Do you agree? Is there anything left to do for this bug? -- ___ Python tracker <https://bugs.python.org/issue38083> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38076] Make struct module PEP-384 compatible
Thomas Wouters added the comment: New changeset 4f384af067d05b16a554bfd976934fca9f87a1cf by T. Wouters (Dino Viehland) in branch 'master': bpo-38076: Make struct module PEP-384 compatible (#15805) https://github.com/python/cpython/commit/4f384af067d05b16a554bfd976934fca9f87a1cf -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue38076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38074] Make zlib PEP-384 compatible
Thomas Wouters added the comment: New changeset a1ffad07195b8b976f8c371a92028240946d4e76 by T. Wouters (Dino Viehland) in branch 'master': bpo-38074: Make zlib extension module PEP-384 compatible (GH-15792) https://github.com/python/cpython/commit/a1ffad07195b8b976f8c371a92028240946d4e76 -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue38074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38071] Make termios PEP-384 compatible
New submission from Thomas Wouters : New changeset bd0c7a12d9e28ce74bfc16244d7694aca906838c by T. Wouters (Dino Viehland) in branch 'master': bpo-38071: Make termios PEP-384 compatible (GH-15785) https://github.com/python/cpython/commit/bd0c7a12d9e28ce74bfc16244d7694aca906838c -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue38071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38072] Make grp module PEP-384 compatible
New submission from Thomas Wouters : New changeset 40a5313edfc18173d136bb5e19495880934b7d83 by T. Wouters (Dino Viehland) in branch 'master': bpo-38072: PEP-384 grpmodule (GH-15788) https://github.com/python/cpython/commit/40a5313edfc18173d136bb5e19495880934b7d83 -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue38072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38068] clean up configure logic for gettimeofday
Thomas Wouters added the comment: New changeset f1c19031fd5f4cf6faad539e30796b42954527db by T. Wouters (Benjamin Peterson) in branch 'master': bpo-38068: Clean up gettimeofday configure logic. (GH-15775) https://github.com/python/cpython/commit/f1c19031fd5f4cf6faad539e30796b42954527db -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue38068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37619] update_one_slot() should not ignore wrapper descriptors for wrong type
Thomas Wouters added the comment: New changeset 57ea33560662e0f20a3b0334bb20065771edf4da by T. Wouters (Jeroen Demeyer) in branch 'master': bpo-37619: update_one_slot() should not ignore wrapper descriptors for wrong type (GH-14836) https://github.com/python/cpython/commit/57ea33560662e0f20a3b0334bb20065771edf4da -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue37619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37619] update_one_slot() should not ignore wrapper descriptors for wrong type
Thomas Wouters added the comment: New changeset eb1bc48c74f4f8af88b5276729f9652201e46324 by T. Wouters (Miss Islington (bot)) in branch '3.8': bpo-37619: update_one_slot() should not ignore wrapper descriptors for wrong type (GH-15838) https://github.com/python/cpython/commit/eb1bc48c74f4f8af88b5276729f9652201e46324 -- ___ Python tracker <https://bugs.python.org/issue37619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37619] update_one_slot() should not ignore wrapper descriptors for wrong type
Thomas Wouters added the comment: I don't think this should be backported to 3.7 at this point; if you disagree feel free to reopen the bug. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36253] Use after free in ctypes test suite
Thomas Wouters added the comment: New changeset a9b6033179b64b985394ad351501089a6a94fc9d by T. Wouters (Ben Harper) in branch 'master': bpo-36253: Remove use after free reference in ctypes test suite (GH-12257) https://github.com/python/cpython/commit/a9b6033179b64b985394ad351501089a6a94fc9d -- nosy: +twouters ___ Python tracker <https://bugs.python.org/issue36253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28494] is_zipfile false positives
Thomas Wouters added the comment: New changeset 3f4db4a0bab073b768fae958e93288bd5d24eadd by T. Wouters (Gregory P. Smith) in branch 'master': bpo-28494: Test existing zipfile working behavior. (GH-15853) https://github.com/python/cpython/commit/3f4db4a0bab073b768fae958e93288bd5d24eadd -- ___ Python tracker <https://bugs.python.org/issue28494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
