[issue37965] CCompiler has_function displays warning
New submission from Maarten :
When using the `has_function` method of a CCompiler object,
the compiler will emit a warning because the main function has no return type
specified.
https://github.com/python/cpython/blob/8c9e9b0cd5b24dfbf1424d1f253d02de80e8f5ef/Lib/distutils/ccompiler.py#L784-L786
This warning is emitted:
/tmp/clockq2_azlzj.c:2:1: warning: return type defaults to ‘int’
[-Wimplicit-int]
2 | main (int argc, char **argv) {
| ^~~~
This happens under Linux, gcc 9
--
components: Distutils
files: 0001-Fix-compiler-warning-of-distutils-CCompiler.test_fun.patch
keywords: patch
messages: 350645
nosy: dstufft, eric.araujo, maarten
priority: normal
severity: normal
status: open
title: CCompiler has_function displays warning
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file:
https://bugs.python.org/file48563/0001-Fix-compiler-warning-of-distutils-CCompiler.test_fun.patch
___
Python tracker
<https://bugs.python.org/issue37965>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37965] CCompiler has_function displays warning
Change by Maarten : -- pull_requests: +15233 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15560 ___ Python tracker <https://bugs.python.org/issue37965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37965] CCompiler has_function displays warning
Maarten added the comment: I have submitted a PR to github: https://github.com/python/cpython/pull/15560 -- ___ Python tracker <https://bugs.python.org/issue37965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10486] http.server doesn't set all CGI environment variables
Maarten added the comment: The CGI examples of urwid (see http://urwid.org/manual/displaymodules.html#cgi-web-display-module-web-display) don't work on http.server because of missing meta variables. Using cgitb, I found out that the webdriver expects the environment variable `HTTP_X_URWID_METHOD` to be set. The javascript sets the "X-Urwid-Method" header (using XmlHttpRequest), but these are not visible by the CGI python script. So some scripts extra Meta-Variables neet to be set. I think section 4.1.18 applied because it is a http header that is being set. The sections says that these meta-variables are optional though. I argue that having access to extra headers is useful. ------ nosy: +maarten ___ Python tracker <https://bugs.python.org/issue10486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41595] curses' window.chgat does not change color when specifying curses.A_COLOR
New submission from Maarten : Or'ing curses.A_COLOR in the `attr` argument of curses.window.chgat ends of with the line not showing. Actual Problem: The text is invisible/hidden/not shown. Using only the attribute curses.A_BLINK is fine. Expected: The color of the line is changed +the text starts blinking. I have attached a small python reproducer and a small c source that shows the correct behavior. The c example should be compiled as `gcc chgat.c -lncurses -o chgat`. This is using ncurses 6.1 The c code is from https://tldp.org/HOWTO/NCURSES-Programming-HOWTO/attrib.html, and the python script is a translation of it. -- components: Library (Lib) files: chgat.py messages: 375681 nosy: maarten priority: normal severity: normal status: open title: curses' window.chgat does not change color when specifying curses.A_COLOR versions: Python 3.7 Added file: https://bugs.python.org/file49407/chgat.py ___ Python tracker <https://bugs.python.org/issue41595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41595] curses' window.chgat does not change color when specifying curses.A_COLOR
Maarten added the comment: Equivalent c script of chgat.py Compile with: gcc chgat.c -lncurses -o chgat -- Added file: https://bugs.python.org/file49408/chgat.c ___ Python tracker <https://bugs.python.org/issue41595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2889] curses for windows (alternative patch)
Maarten added the comment: Current ncurses master is buildable on Visual Studio, using msys2. It should be possible to create a vcxproject and integrate it in the Visual Studio build. -- nosy: +maarten ___ Python tracker <https://bugs.python.org/issue2889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41604] [curses.panel] Failed panel.set_userptr will decrement refcount of original userptr
New submission from Maarten : When ncurses' function `set_panel_userptr` fails, panel.set_userptr should not decrement the reference count of the previous userptr. -- components: Library (Lib) messages: 375738 nosy: maarten priority: normal severity: normal status: open title: [curses.panel] Failed panel.set_userptr will decrement refcount of original userptr versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41604> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1723038] Curses Menu
Change by Maarten : -- nosy: +maarten nosy_count: 5.0 -> 6.0 pull_requests: +21045 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/21933 ___ Python tracker <https://bugs.python.org/issue1723038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41604] [curses.panel] Failed panel.set_userptr will decrement refcount of original userptr
Change by Maarten : -- keywords: +patch pull_requests: +21046 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21933 ___ Python tracker <https://bugs.python.org/issue41604> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1723038] Curses Menu
Change by Maarten : -- pull_requests: -21045 ___ Python tracker <https://bugs.python.org/issue1723038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1723038] Curses Menu
Change by Maarten : -- pull_requests: +21047 pull_request: https://github.com/python/cpython/pull/21933 ___ Python tracker <https://bugs.python.org/issue1723038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31526] Allow setting timestamp in gzip-compressed tarfiles
Maarten added the comment: I have the same issue. The timestamp is inserted here: https://github.com/python/cpython/blob/802726acf6048338394a6a4750835c2cdd6a947b/Lib/tarfile.py#L419-L420 Because I noticed the timestamp was not included in the timestamp, I could zero it by doing: ``` with open(gzipped_tarball,"r+b") as f: f.seek(4, 0) f.write(b"\x00\x00\x00\x00") ``` -- nosy: +maarten ___ Python tracker <https://bugs.python.org/issue31526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31526] Allow setting timestamp in gzip-compressed tarfiles
Maarten added the comment: My previous comment should have contained: Because I noticed the timestamp was not included in the CRC, ... -- ___ Python tracker <https://bugs.python.org/issue31526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41630] Visual Studio does not build the curses and curses.panel module
New submission from Maarten : When building python using Visual Studio, the curses and curses.module, are not getting built. -- components: Build, Library (Lib) messages: 375871 nosy: maarten priority: normal severity: normal status: open title: Visual Studio does not build the curses and curses.panel module ___ Python tracker <https://bugs.python.org/issue41630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41630] Visual Studio does not build the curses and curses.panel module
Change by Maarten : -- keywords: +patch pull_requests: +21060 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21950 ___ Python tracker <https://bugs.python.org/issue41630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42321] Limitations of building a static python library on Windows (MSVC)
New submission from Maarten : `PCbuild/readme.txt` contains a little paragraph about how to build a static python library. The resulting static `python.lib` library contains all python C API functions. Windows DLL's don't allow missing symbols, so C extensions modules must link with a library containing the python C API symbols. When a C extension links to the static python library, it will contain a copy of all python symbols. This means that python C symbols are used twice: once by a static python.exe executable, and once for each C extension (_extension.pyw). Is there a way to use C extensions with a static Windows python.exe wuch that the python symbols are used only once? Does a statically built Windows python.exe support C extension modules at all? Thanks I'm currently working on a conan build recipe for cpython at https://github.com/conan-io/conan-center-index/pull/1510 Fow now, I'm disabling extensions on a static MSVC build. -- components: Windows messages: 380747 nosy: maarten, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Limitations of building a static python library on Windows (MSVC) versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1506] func alloca inside ctypes lib needs #include on solaris
Changes by Maarten Thibaut: -- components: Library (Lib) nosy: mthibaut severity: normal status: open title: func alloca inside ctypes lib needs #include on solaris type: compile error versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1506] func alloca inside ctypes lib needs #include on solaris
New submission from Maarten Thibaut: On Solaris, alloca() is a #define which is inside . Ctypes fails to compile because the #define is missing. Please fix by adding the following at the front of these 2 files: #if defined (__SVR4) && defined (__sun) # include #endif __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1506] func alloca inside ctypes lib needs #include on solaris
Changes by Maarten Thibaut: -- components: +Extension Modules -Library (Lib) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1506] func alloca inside ctypes lib needs #include on solaris
Maarten Thibaut added the comment: forgot to mention the files: Modules/_ctypes/callproc.c Modules/_ctypes/libffi/src/sparc/ffi.c __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1506> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1711] socket functions that should return unsigned int return signed int
New submission from Maarten Thibaut:
Socket library functions such as ntohs() return uint16_t, but inside
Python these return values show up as negative numbers. One possible fix
is to convert these return values using pack:
struct.unpack('H', struct.pack('h', ntohs(number)))[0] & 0x
--
components: Library (Lib)
messages: 59047
nosy: mthibaut
severity: normal
status: open
title: socket functions that should return unsigned int return signed int
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1711>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1711] socket functions that should return unsigned int return signed int
Maarten Thibaut added the comment: Numbers returned from ntohs() turn up as negative. But ntohs() is typed as uint16_t, so they shouldn't be. This is on solaris. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1711> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1711] socket functions that should return unsigned int return signed int
Maarten Thibaut added the comment: Try this on Linux and Solaris: --- from socket import ntohs, htons print ntohs(htons(55000)) --- On Linux: 55000 On Solaris: -10536 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1711> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1711] socket functions that should return unsigned int return signed int
Maarten Thibaut added the comment: Guido, the problem is that my python foo is severely lacking - but I'll have a stab at it. Python believes that the number coming back from the C library is negative. We can fool it by packing the "signed short" into a system-native format, and then unpacking it explicitly into an unsigned short. So I propose to do precisely that on big endian systems using sys.byteorder: wrap these functions with a converter. Would that be acceptible? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1711> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24339] iso6937 encoding missing
Maarten Derickx added the comment: Is there any way to contact John Helour? I would still very much like to put this package on github and pypi. And would like to ask him permission for licensing. Or is there some standard open source license under which all code uploaded to https://bugs.python.org/ can automatically be distributed? https://www.python.org/about/legal/ seems to indicate so, but doesn't mention an explicit license just the things you can do with it. -- nosy: +koffie ___ Python tracker <https://bugs.python.org/issue24339> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24339] iso6937 encoding missing
Maarten Derickx added the comment: Hi Marc-Andre Lemburg, Thanks for your reply. I tried using gencodec.py as could be downloaded from https://github.com/python/cpython/blob/main/Tools/unicode/gencodec.py as you mentioned. However the code in gencodec.py seems to be in a much worse shape than the iso6937.py attached here. The code in gencodec relies on being able to compare integers with tuples. This is caused by the lines: mappings = sorted(map) hinting that this code has never been run using python 3. providing a decent sort key solves this issue. But after that other issues pop up. For example there seems to be some problems handling the 0x-001 by the not appropriately handling of items in the mapping that have MISSING_CODE resulting in things like: 0x80: 0x-001 showing up in the generated code. And then there is the issue that python_mapdef_code has as a side effect that it does 'del map["IDENTITY"]' causing "'IDENTITY' in map" in python_tabledef_code to always evaluate to False even when it should evaluate to True. The problems above can be observed by just running gencodec.py on https://unicode.org/Public/MAPPINGS/VENDORS/APPLE/SYMBOL.TXT . If gencodec.py was a trustworthy and well maintained piece of code, I would happily use it. However at the moment I don't see it as a valid option since debugging gencodec.py would cost me at least as much time as just writing its output myself instead of generating it. Additionally https://unicode.org/ doesn't seem to provide a mapping file for iso6937. I do agree that using codecs.charmap_encode and codecs.charmap_decode is a much better solution then the one in iso6937.py. But I don't understand gencodec.py well enough to actually fix it. -- ___ Python tracker <https://bugs.python.org/issue24339> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24339] iso6937 encoding missing
Maarten Derickx added the comment: The route via gencodec or more generally via charmap_encode and charmap_decode seems to be one that is not possible without some low level CPython code adjustments. The reason for this is that charmap_encode and charmap_decode only seem to support mappings where a single encoded byte corresponds to multiple unicode points. However iso6937 is a mixed length encoding, meaning in this specific case that unicode characters sometimes need to be encoded as a single byte and sometimes with two bytes. For example chr(0x00c0) should be encoded as b'\xc1' + b'A'. -- ___ Python tracker <https://bugs.python.org/issue24339> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24339] iso6937 encoding missing
Maarten Derickx added the comment: Hi Marc-Andre Lemburg, Thanks for your responses and guidance. At least your pointers to charmap_encode and charmap_decode helped, since it shows at least what the general idea is on how to deal with these types of encodings. In the mean time I did produce some successes. I wrote some python code that can create character mappings based on the table in http://webstore.iec.ch/preview/info_isoiec6937%7Bed3.0%7Den.pdf so that we can be sure that there are no human errors in generating the mappings. I think my further approach is to write pure python versions of charmap_encode and charmap_decode that can handle the general case of multi byte encodings to unicode case. This won't be as fast as using the builtins written c. But at least gives maintainable and hopefully reusable code. Maybe later the c-implementation can be updated as well. -- ___ Python tracker <https://bugs.python.org/issue24339> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7946] Convoy effect with I/O bound threads and New GIL
Maarten Breddels added the comment: In case someone finds it useful, I've written a blog post on how to visualize the GIL: https://www.maartenbreddels.com/perf/jupyter/python/tracing/gil/2021/01/14/Tracing-the-Python-GIL.html In the comments (or at https://github.com/maartenbreddels/fastblog/issues/3#issuecomment-760891430 ) I looked specifically at the iotest.py example (no solutions though). -- nosy: +maartenbreddels ___ Python tracker <https://bugs.python.org/issue7946> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21970] Broken code for handling file://host in urllib.request.FileHandler.file_open
Maarten ter Huurne added the comment: Another problem with the current code is that when passed a URL with a host name that is not empty or "localhost", but is one of the alternative names for localhost returned by get_names(), file_open() returns None implicitly instead of opening the file. I think this issue would be fixed by the proposed patch. So it would be good if the patch could be reviewed and adopted. -- nosy: +mthuurne versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue21970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used
Maarten ter Huurne added the comment: Can I please get a review of the pull request? -- ___ Python tracker <https://bugs.python.org/issue17088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30839] Larger and/or configurable _MAX_LENGTH for unittest messages
New submission from Maarten ter Huurne: In a unit test for one of my projects I am comparing tree-structured objects using assertEqual(). Because there can be a few nested levels, the repr() string can exceed the _MAX_LENGTH which is just 80 characters. Not by much, but enough to get shortened and therefore requiring extra effort to figure out where the difference is. I think it is useful to shorten the messages at some point, to avoid accidentally spamming the log with pages of output that no-one is going to read. However, 80 characters is a length that someone debugging a failing test case can easily deal with. So I think the limit could be set an order of magnitude larger. Making the maximum length configurable would also solve the issue, but still it would be good to increase the default maximum then, in my opinion. The discussion of #27432 mentions _MAX_LENGTH customization, but that issue is not primarily about _MAX_LENGTH. -- components: Library (Lib) messages: 297605 nosy: maarten-treewalker priority: normal severity: normal status: open title: Larger and/or configurable _MAX_LENGTH for unittest messages type: enhancement versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue30839> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used
Maarten ter Huurne added the comment: I was working on what I thought would be an elegant solution to this problem: for non-qualified attributes, add the element's namespace before accessing the cache and strip the namespace prefix after accessing the cache if it's equal to the element's prefix. However, this approach doesn't work: even though non-qualified attributes will be processed like they are the element's namespace, they are considered to have no namespace. This means is considered valid XML, even though it effectively defines the same attribute twice. https://www.w3.org/TR/REC-xml-names/#uniqAttrs In my opinion the spec made a silly choice here, but that's probably not something that can fixed anymore. I haven't decided yet whether I'll make another attempt at fixing this issue. In any case, I hope this tale of caution benefits someone. -- nosy: +mthuurne ___ Python tracker <https://bugs.python.org/issue17088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used
Change by Maarten ter Huurne : -- pull_requests: +10286 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue17088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used
Maarten ter Huurne added the comment: I think I have a good solution now, see the pull request for details. It does touch a lot of code, but I split all the changes into small consistent units, so it should be easier to verify whether they are correct. -- ___ Python tracker <https://bugs.python.org/issue17088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
