[issue43412] object.h -Wcast-qual warning
New submission from Peter Eisentraut : object.h contains an inline function that causes a -Wcast-qual warning from gcc. Since this file ends up visible in third-party code that includes Python.h, this makes it impossible to use -Wcast-qual in such code. The problem is the change c5cb077ab3c88394b7ac8ed4e746bd31b53e39f1, which replaced ob->ob_type by Py_TYPE(ob), which seems reasonable by itself, but Py_TYPE casts away the const, so it creates this problem. This is a regression in Python 3.10. -- components: Interpreter Core messages: 388167 nosy: petere priority: normal severity: normal status: open title: object.h -Wcast-qual warning versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39615] cpython/abstract.h not compatible with C90
Peter Eisentraut added the comment: 3.9.0a5 fixes my original issue. Thanks. -- ___ Python tracker <https://bugs.python.org/issue39615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39615] cpython/abstract.h not compatible with C90
Peter Eisentraut added the comment: That's fair for code internal to CPython itself, but these are header files included by third-party code that is embedding Python, so a bit more flexibility and adaptability would be welcome there. -- ___ Python tracker <https://bugs.python.org/issue39615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39615] cpython/abstract.h not compatible with C90
Change by Peter Eisentraut : -- keywords: +patch pull_requests: +17851 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18481 ___ Python tracker <https://bugs.python.org/issue39615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39615] cpython/abstract.h not compatible with C90
New submission from Peter Eisentraut : Some inline functions use mixed declarations and code. These end up visible in third-party code that includes Python.h, which might not be using a C99 compiler. Example: In file included from /Users/peter/python-builds/3.9/include/python3.9/abstract.h:843, from /Users/peter/python-builds/3.9/include/python3.9/Python.h:147, from plpython.h:59, from plpy_typeio.h:10, from plpy_cursorobject.h:8, from plpy_cursorobject.c:14: /Users/peter/python-builds/3.9/include/python3.9/cpython/abstract.h:74:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 74 | Py_ssize_t offset = tp->tp_vectorcall_offset; | ^~ -- components: Interpreter Core messages: 361880 nosy: petere priority: normal severity: normal status: open title: cpython/abstract.h not compatible with C90 versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25548] Show the address in the repr for class objects
Peter Eisentraut added the comment: I understand the reasoning here, but I want to say booh to this change in 3.6.0a2 because it breaks my tests. It used to be that type(x) returned a predictable string, and that was an easy way to verify the result types of things. Perhaps a __str__ implementation could be added that avoids the memory address? -- nosy: +petere ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27337] 3.6.0a2 tarball has weird paths
Peter Eisentraut added the comment: The affected tar is indeed a BSD-ish tar (OS X). With GNU tar I can proceed. It says "gtar: Removing leading `../' from member names". So with that I agree that it's not worth rerolling this release. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27337> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27337] 3.6.0a2 tarball has weird paths
New submission from Peter Eisentraut: The file Python-3.6.0a2.tgz contains paths that start with "..", e.g., $ tar tf Python-3.6.0a2.tgz | head ../Python-3.6.0a2/ ../Python-3.6.0a2/Doc/ ../Python-3.6.0a2/Grammar/ ../Python-3.6.0a2/Include/ ../Python-3.6.0a2/LICENSE ../Python-3.6.0a2/Lib/ ../Python-3.6.0a2/Mac/ ../Python-3.6.0a2/Makefile.pre.in ../Python-3.6.0a2/Misc/ ../Python-3.6.0a2/Modules/ This causes tar to error out when unpacking the file. This was not the case in previous tarballs and also not in Python-3.6.0a2.tar.xz. -- components: Build messages: 268684 nosy: petere priority: normal severity: normal status: open title: 3.6.0a2 tarball has weird paths versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27337> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11122] bdist_rpm should use rpmbuild, not rpm
Peter Eisentraut added the comment: No, the second use should not be converted. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11122 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue444582] Finding programs in PATH, adding shutil.which
Changes by Peter Eisentraut pete...@gmx.net: -- nosy: +petere ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue444582 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11122] bdist_rpm should use rpmbuild, not rpm
Peter Eisentraut added the comment: I ran into a similar instance of this problem today and would like to add my support for just getting rid of the rpm calls and just call rpmbuild in all cases. The last release where rpm was used for building was more than 10 years ago. -- nosy: +petere ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16026] csv.DictReader argument names documented incorrectly
New submission from Peter Eisentraut: The documentation for the csv.DictReader constructor is .. class:: DictReader(csvfile, fieldnames=None, restkey=None, restval=None, dialect='excel', *args, **kwds) but the implementation is def __init__(self, f, fieldnames=None, restkey=None, restval=None, dialect=excel, *args, **kwds): The name of the first argument is documented incorrectly, leading to surprise errors when attempting to use key word arguments. -- assignee: docs@python components: Documentation, Library (Lib) messages: 171161 nosy: docs@python, petere priority: normal severity: normal status: open title: csv.DictReader argument names documented incorrectly type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16026 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14689] make PYTHONWARNINGS variable work in libpython
New submission from Peter Eisentraut pete...@gmx.net: The environment variable PYTHONWARNINGS only works with the python interpreter binary, but not with programs embedding libpython. This could be changed by moving the code from Modules/main.c to Python/pythonrun.c. See attached patch (compiles cleanly, tests pass, not tested on Windows). (I have checked all the other environment variables listed on the python man page for whether those that could be usable in the library are actually processed in the library, and all but PYTHONWARNINGS appear to behave reasonably.) -- components: Interpreter Core files: py-pythonwarnings-envvar.patch keywords: patch messages: 159514 nosy: petere priority: normal severity: normal status: open title: make PYTHONWARNINGS variable work in libpython type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25390/py-pythonwarnings-envvar.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14689 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14676] DeprecationWarning missing in default warning filters documentation
New submission from Peter Eisentraut pete...@gmx.net: DeprecationWarning was disabled by default in Python 2.7, but the documentation section Default Warning Filters does not list it as ignored. In the 3.x branches, this was already fixed. Trivial patch attached. -- assignee: docs@python components: Documentation files: py27-default-warning-filters-doc.patch keywords: patch messages: 159398 nosy: docs@python, petere priority: normal severity: normal status: open title: DeprecationWarning missing in default warning filters documentation versions: Python 2.7 Added file: http://bugs.python.org/file25373/py27-default-warning-filters-doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14676 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13236] unittest needs more flush calls
Peter Eisentraut pete...@gmx.net added the comment: Attached is a test file. The key here is that I'm running the unittest suite inside of a long-running server process, so there is no predictable point of exit and cleanup. Therefore, the steps I show at the end of the file should be run in an interactive interpreter. Here is what I see: import unittest import testcase unittest.main(module=testcase) .F. == FAIL: test_three (testcase.test) -- Traceback (most recent call last): File testcase.py, line 35, in test_three self.fail(intentional failure) AssertionError: intentional failure -- Ran 3 tests in 0.002s FAILED (failures=1) That's good. But: import unittest import testcase unittest.main(module=testcase, testRunner=testcase.FunnyTestRunner, exit=False) . F . unittest.main.TestProgram object at 0xf718fd4c You see, the test report at the end is missing. I'm happy to consider other ways of addressing this, if anyone has an idea. -- Added file: http://bugs.python.org/file23527/testcase.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13236] unittest needs more flush calls
New submission from Peter Eisentraut pete...@gmx.net: I'm using the TextTestRunner class in unittest/runner.py with a special file-like object passed in as stream. Doing this loses some output, because the run() method (and some lower-level methods) don't always call flush() on the stream. There is also no obvious cleanup method in the runner class that might do this, so I assume run() should do that itself. Right now, it looks like it assumes that either the stream is effectively unbuffered, like stderr, or that the end of the program might flush things, but that doesn't always apply. It looks like the best fix would be a self.stream.flush() call at the end of run(). Another flush() call at the end of printErrorList() would also help. (In the meantime, I have fixed up my special file-like class to flush its internal buffers when a newline is seen, which kind of works, but a proper cleanup of this matter would still be nice.) -- components: Library (Lib) messages: 146043 nosy: petere priority: normal severity: normal status: open title: unittest needs more flush calls type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13236 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12531] documentation index entries for * and **
New submission from Peter Eisentraut pete...@gmx.net: The existing documentation index entries for * and ** only point to their use in function definitions but not to their use in function calls. I was looking for the latter, and it was difficult to find without this. Here is a small patch to add the additional entries. -- assignee: docs@python components: Documentation files: python-doc-index-**.patch keywords: patch messages: 140113 nosy: docs@python, petere priority: normal severity: normal status: open title: documentation index entries for * and ** versions: Python 3.3 Added file: http://bugs.python.org/file22619/python-doc-index-**.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12531 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12444] accept sets or collections for str.strip/lstrip/rstrip
New submission from Peter Eisentraut pete...@gmx.net:
It appears to be a pretty common mistake to think that the argument of
str.strip/lstrip/rstrip is a substring rather than a set of characters. To
allow a more clearer notation, it would be nice if these functions also
accepted an argument other than a string, for example a set or any collection.
Then you could write, for example:
a.strip({'a', 'b', 'c'})
I suggest to either add support for sets specifically, or more generally
anything that supports the in operator.
I can try to code it up if it sounds acceptable.
--
components: Library (Lib)
messages: 139449
nosy: petere
priority: normal
severity: normal
status: open
title: accept sets or collections for str.strip/lstrip/rstrip
type: feature request
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12444
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12012] _ssl module doesn't compile with OpenSSL 1.0.0d: SSLv2_method is missing
Changes by Peter Eisentraut pete...@gmx.net: -- nosy: +petere ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12012 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11067] Py_LIMITED_API breaks most PySomething_Check() functions
New submission from Peter Eisentraut pete...@gmx.net:
When setting Py_LIMITED_API, functions such as PyUnicode_Check() can no longer
be used. Example:
#define Py_LIMITED_API
#include Python.h
void foo()
{
PyObject *o;
PyUnicode_Check(o);
}
test.c: In function ‘foo’:
test.c:9: error: dereferencing pointer to incomplete type
PEP 384 contains some nested language that suggests that the _Check macros
should be available under the limited API. And it seems to me that they easily
could be, if Py_TYPE were implemented as a function instead of a macro.
--
components: None
messages: 127488
nosy: petere
priority: normal
severity: normal
status: open
title: Py_LIMITED_API breaks most PySomething_Check() functions
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11067
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7111] core dump when stderr is moved
Peter Eisentraut pete...@gmx.net added the comment: For what it's worth, the code in question is used here (using import distutils instead of pass): http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/config/python.m4?rev=1.15;content-type=text%2Fx-cvsweb-markup This is obviously a completely gratuitous variant on 2/dev/null, but it has apparently been working since forever. I'll probably go make the change anyway. Nevertheless, I think Python shouldn't core dump. It may choose to exit doing nothing (useful) if it doesn't want to deal with this case. Check this for possible alternative behaviors: $ ls 1- ls: write error: Bad file descriptor ($? = 2) $ ls 1- 2- ($? = 2, no output) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7111] core dump when stderr is moved
New submission from Peter Eisentraut pete...@gmx.net: bash$ python3.1 -c 'pass' 2- Aborted (core dumped) (I verified, the core dump belongs to python.) If you remove the redirection thingy at the end, it works. Not sure why I ever wrote that code, but it has been working since forever up to python3.0. -- components: Interpreter Core messages: 93891 nosy: petere severity: normal status: open title: core dump when stderr is moved type: crash versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
