[issue45537] Cygwin is unsupported - close all open issues and list them here.
Change by Erik Bray : -- pull_requests: +27359 pull_request: https://github.com/python/cpython/pull/4149 ___ Python tracker <https://bugs.python.org/issue45537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45537] Cygwin is unsupported - close all open issues and list them here.
Change by Erik Bray : -- keywords: +patch nosy: +erik.bray nosy_count: 1.0 -> 2.0 pull_requests: +27357 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14013 ___ Python tracker <https://bugs.python.org/issue45537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31882] Cygwin: asyncio and asyncore test suites hang indefinitely due to bug in Cygwin
Erik Bray added the comment: To my knowledge this issue is *not* fixed upstream. However, my PR no doubt needs rebasing. -- ___ Python tracker <https://bugs.python.org/issue31882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31885] Cygwin: socket test suites hang indefinitely due to bug in Cygwin
Erik Bray added the comment: That person was me--I have the keys to a cygwin buildbot, but it's currently not running. I lost the urgency to make cygwin fully supported, though it's come a long way. In particular the deprecation of distutils should help nix some of the long-standing issues. -- ___ Python tracker <https://bugs.python.org/issue31885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31885] Cygwin: socket test suites hang indefinitely due to bug in Cygwin
Erik Bray added the comment: Thanks for asking. Indeed the fix to that issue was included in https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=5ca28a0cd71436a84797d5d66831790004e0 and as Cygwin obsoletes old releases rather quickly I see no reason to keep this issue open. -- resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31878] Cygwin: _socket module does not compile due to missing ioctl declaration
Change by Erik Bray : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39671] Mention in docs that asyncio.FIRST_COMPLETED does not guarantee the completion of no more than one task
Change by Erik Bray : -- keywords: +patch nosy: +erik.bray nosy_count: 4.0 -> 5.0 pull_requests: +21125 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21918 ___ Python tracker <https://bugs.python.org/issue39671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18876] Problems with files opened in append mode with io module
Erik Bray added the comment: Indeed, this can be closed. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue18876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20082] Misbehavior of BufferedRandom.write with raw file in append mode
Change by Erik Bray : -- pull_requests: +20873 pull_request: https://github.com/python/cpython/pull/21729 ___ Python tracker <https://bugs.python.org/issue20082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()
Erik Bray added the comment:
FWIW (unsurprisingly) the new test added here is broken on Cygwin, whose libc's
(newlib) behavior in this undefined case. So I get:
>>> from datetime import date
>>> t = date(2005, 1, 1)
>>> t.strftime("%Y") # ok
'2005'
>>> t.strftime("%%") # ok
'%'
>>> t.strftime("%") # undefined behavior
''
>>> t.strftime("%Y %") # undefined behavior; discards the whole format string
''
>>> t.strftime("%Y%Q") # undefined format; discards the whole format string
''
This behavior is user-hostile I think; it should raise a ValueError instead of
just return an empty string. I would have suggested the same for the trailing
'%' case, though I understand the goal of this issue was consistency.
Also worth noting that both before and after this patch:
>>> import time
>>> time.strftime('%')
''
So the question of consistency between the interfaces, which was the main point
of this issue, was already resolved in this case, and the *inconsistency*
observed was dependent on system-dependent behavior.
For now I might propose doing away with this test in its current form, and just
test
assert t.strftime('%') == time.strftime('%')
or something like that.
I agree with Victor that trying to make the strftime experience consistent
across system-dependent quirks is a worthy goal, but that goes deeper than just
this trailing '%' case.
--
nosy: +erik.bray
___
Python tracker
<https://bugs.python.org/issue35066>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28459] _pyio module broken on Cygwin / setmode not usable
Change by Erik Bray : -- pull_requests: +13877 pull_request: https://github.com/python/cpython/pull/14013 ___ Python tracker <https://bugs.python.org/issue28459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9665] Buid issues on Cygwin - _curses, _curses_panel, and _io
Erik Bray added the comment: I think this issue can probably be closed. It refers to a very old version of Cygwin as well as old versions of Python. I don't have any problem building the _curses or _io modules on recent versions of Cygwin (>=2.9) and with current cpython master (3.9.0a0). -- nosy: +erik.bray ___ Python tracker <https://bugs.python.org/issue9665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21536] extension built with a shared python cannot be loaded with a static python
Erik Bray added the comment: Thanks everyone. And FWIW I agree the original change is positive overall, if a bit presumptuous about different linkers' behaviors :) -- ___ Python tracker <https://bugs.python.org/issue21536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21536] extension built with a shared python cannot be loaded with a static python
Change by Erik Bray : -- pull_requests: +13463 ___ Python tracker <https://bugs.python.org/issue21536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21536] extension built with a shared python cannot be loaded with a static python
Change by Erik Bray : -- pull_requests: +13461 ___ Python tracker <https://bugs.python.org/issue21536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21536] extension built with a shared python cannot be loaded with a static python
Erik Bray added the comment: I vaguely recall seeing some discussion about this on python-dev or elsewhere and wish I had chimed in sooner, as I didn't realize action was going to be taken on this so soon. This completely breaks building extension modules on Windows-based platforms like Cygwin and MinGW, where it is necessary when building even shared libraries for all global symbols to resolvable at link time. I'm not actually sure this use case can even be achieved on these platforms. I tried several hacks but nothing works. I'll open a follow-up issue... -- nosy: +erik.bray ___ Python tracker <https://bugs.python.org/issue21536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32451] python -m venv activation issue when using cygwin on windows
Erik Bray added the comment: Coincidentally I just encountered this myself when trying to activate a venv created by Python for Windows while in a Cygwin shell. Indeed, bash for Cygwin is just like bash anywhere else, and considers it a syntax error to encounter unexpected CR's. Alas, venv creates //Scripts/activate with CRLFs. After running dos2unix on it, this script can be sourced from Cygwin and otherwise works fine. The issue that arises with interactive mode is a known issue not specific to Python or venv. It can also be worked around by running python with winpty. -- ___ Python tracker <https://bugs.python.org/issue32451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36231] no "proper" header files on macOS 10.14 Mojave
Erik Bray added the comment: Perhaps it would be better if the `xcrun --show-sdk-path` thing were run at configure-time and its result shoved into a variable we can read with sysconfig.get_config_var() -- nosy: +erik.bray ___ Python tracker <https://bugs.python.org/issue36231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34904] Crash in ZipFile.close() when writing zip file to /dev/null
Erik Bray added the comment:
For the sake of completeness, same deal in pure C:
$ cat devnul.c
#include
int main(void) {
FILE *f = fopen("/dev/null", "w");
printf("tell() = %ld\n", ftell(f));
printf("write(\"abcdefgh\") = %zu\n", fwrite("abcdefgh", 1, 8, f));
printf("tell() = %ld\n", ftell(f));
printf("seek(8) = %d\n", fseek(f, 8, 0));
printf("tell() = %ld\n", ftell(f));
return 0;
}
$ gcc devnulc -o devnul
$ ./devnull
tell() = 0
write("abcdefgh") = 8
tell() = 8
seek(8) = 0
tell() = 0
--
___
Python tracker
<https://bugs.python.org/issue34904>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34904] Crash in ZipFile.close() when writing zip file to /dev/null
Erik Bray added the comment:
On Cygwin the same tests give
>>> f = open('/dev/null', 'wb')
>>> f.seekable()
True
>>> f.write(b'abcdefgh')
8
>>> f.tell()
8
>>> f.seek(8)
8
>>> f.tell()
8
I would also try macOS if I could. But yes, I wonder if it's a Linux bug.
--
___
Python tracker
<https://bugs.python.org/issue34904>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34904] Crash in ZipFile.close() when writing zip file to /dev/null
Erik Bray added the comment: The regression was introduced by issue26039. It does seem to be Linux-specific with seek/tell on /dev/null. For example, I cannot reproduce the issue on Cygwin. -- ___ Python tracker <https://bugs.python.org/issue34904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34904] Crash in ZipFile.close() when writing zip file to /dev/null
New submission from Erik Bray :
Not that there is any great reason to write a zip file to /dev/null, but I had
some code that happened to do so which worked on Python 2.7, but at some point
this broke:
Python 3.8.0a0 (heads/master:fc7d1b3, Oct 5 2018, 09:49:57)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import zipfile
>>> f = zipfile.ZipFile('/dev/null', 'w')
>>> f.writestr('foo.txt', 'testtesttesttesttest')
>>> f.close()
Traceback (most recent call last):
File "", line 1, in
File "/home/embray/src/python/cpython/Lib/zipfile.py", line 1813, in close
self._write_end_record()
File "/home/embray/src/python/cpython/Lib/zipfile.py", line 1914, in
_write_end_record
endrec = struct.pack(structEndArchive, stringEndArchive,
struct.error: argument out of range
--
components: Library (Lib)
messages: 327118
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Crash in ZipFile.close() when writing zip file to /dev/null
type: crash
___
Python tracker
<https://bugs.python.org/issue34904>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34212] Cygwin link failure with builtin modules since issue30860
Erik Bray added the comment: I added a new PR modifying makesetup and adding a new variable to Makefile.pre.in, PY_BUILTIN_MODULE_CFLAGS, explicitly for building built-in modules. I think this, or some version of it, is a cleaner solution than my previous brute-force approach. -- ___ Python tracker <https://bugs.python.org/issue34212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34212] Cygwin link failure with builtin modules since issue30860
Change by Erik Bray : -- pull_requests: +8199 ___ Python tracker <https://bugs.python.org/issue34212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Erik Bray added the comment: > To do that, I believe it can be made to work in much the same way it did in > Python 2 if SageMath were to do the following: > > 1. Define a subclass of ExtensionModuleLoader [1] that overrides get_source() > to also look for a ".pyx" file adjacent to the extension module. This would > also look for any of the file suffixes in SOURCE_SUFFIXES if a .pyx file > isn't found. > 2. Create an instance of FileFinder [3] that uses the custom loader subclass > for any of the file suffixes in EXTENSION_SUFFIXES [4] > 3. Replace the regular file finding hook in sys.path_hooks with the > path_hook method from that new FileFinder instance (by default, there's only > one FileFinder hook installed, and it can currently be identified as > "obj.__name__ == 'path_hook_for_FileFinder') > 4. Invalidate importlib's caches, so any future extension module imports will > use the custom extension module loader, rather than the default one This is pretty edifying, because Nick's idea is almost exactly what I did six months ago :) https://git.sagemath.org/sage.git/diff/?id2=0a674fd488dcd7cb779101d263c10a874a13cf77=8b63abe731c510f0de9ef0e3ab9a0bda3669dce1 Turned out to be very non-trivial of course, and I believe it should not have been as complicated as it was. It also still doesn't solve the problem that Loader.get_source does not support multiple source files, which Cython code may have (a .pyx and a .pxd being a common case). I'm glad Paul Moore seems to also agree (now that I've actually read the rest of the thread) that the ExtensionLoader.get_source, at the very least, could be made more useful. Whatever form that takes would be worth extending to other loaders that implement get_source as well... -- ___ Python tracker <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Erik Bray added the comment: To add, while an enhancement just to linecache would make sense in its own right, I don't see the problem with also extending the Loader.get_source() API to be more useful as well. Its current behavior is to just return a string (or None), but it seems to me one could keep that basic behavior, but also extend it to optionally return a more sophisticated source map data structure (that could involve multiple source files as well). This could even be useful for built-in modules. I would love, for example, to be able to get stack traces within extension modules integrated into Python tracebacks if they are compiled with some appropriate debug flags. The case of Cython demonstrates that something like this is perfectly doable. -- ___ Python tracker <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Erik Bray added the comment: Brett: > As Nick said, we have no generalized concept of source maps and I think coming up with that is what will be required to solve this as i personally don't view Loader.get_source() is not meant to be a generalized concept of some form of source code but Python source code. I see what you're saying here, but given that Loader can return Python modules that are ostensibly not actually generated from Python source code, then it's not *obvious* that Loader.get_source() must return Python source. At the very least the documentation [1] should clarify this. But it's also a bit arbitrarily limiting, especially given the demonstrable possibility of providing tracebacks and code inspection for *non-Python* code (as in the case of Cython) that compiles to Python modules. Nick: > 1. Enhance PathFinder to allow specification of which path importer cache and > path_hooks entries to use This would be good. Perhaps veering off-topic, but in an earlier attempt to fix this issue I actually tried to implement a sys.path_hooks hook for importing Cython modules such that I could provide an appropriate Loader for them with a get_source that actually works. This turned out to be very difficult in large part due to the difficulty of customizing the relationship between the default PathFinder on sys.meta_path and the sys.path_hooks entries. I made a post about this to python-ideas [2] but it never gained much traction, probably in large part due to the specialized nature of the problem and the complexity of my solution :) [1] https://docs.python.org/3/library/importlib.html#importlib.abc.InspectLoader.get_source [2] https://mail.python.org/pipermail/python-ideas/2018-February/048905.html -- ___ Python tracker <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34211] Cygwin build broken due to use of _Type in static declaration in _abc module
Erik Bray added the comment: > What makes functions different from variables? Aren't they essentially just > pointers? You're on the right track by noting a difference between functions and data variables. I can tell you off the bat that when it comes to data imported from DLLs, non-functions are handled (somewhat by necessity) quite differently from functions. That said, since you asked, I struggled to articulate *exactly* why this exact problem occurs on Cygwin (actually on Windows in general), so I thought about it for a while and wrote up an explanation in a blog post: http://iguananaut.net/blog/programming/windows-data-import.html The TL;DR though is that limitations of how the runtime dynamic loader on Windows works are such that it's impossible to initialize static data with a pointer to some data in an external library. The compiler knows this and prevents you from doing it. The workaround is simple enough for most cases: Complete the initialization at runtime. In the case of PyType_Type objects, PyType_Ready can set their base type at runtime just fine. -- ___ Python tracker <https://bugs.python.org/issue34211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34211] Cygwin build broken due to use of _Type in static declaration in _abc module
Erik Bray added the comment: > For those who are not very aware of Cygwin issues: what is wrong with > > PyVarObject_HEAD_INIT(_Type, 0); I'm glad you asked, because it actually got me thinking, and since I added a fix (albeit an unsatisfying one) for issue34212, this fix is no longer strictly necessary *so long as* the _abc module is always built as a core built-in (that is, linked into libpython). IIUC that is the case since _abc is required for the core, but I'm not sure. The problem is explained somewhat in issue21124, but what it comes down to is that if the linker can't resolve PyType_Type at link time it will make a complaint like "can't initialize global with a non-constant". Because of issue34212, when compiling _abc.c it was using the wrong external linkage for PyType_Type (treating it as some data that needs to be imported from an other DLL, rather than data in the same DLL). But with a fix for issue34212 this is not a problem (again, so long as the _abc module is included in libpython). -- ___ Python tracker <https://bugs.python.org/issue34211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34212] Cygwin link failure with builtin modules since issue30860
Change by Erik Bray : -- keywords: +patch pull_requests: +7968 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34212] Cygwin link failure with builtin modules since issue30860
New submission from Erik Bray : Since issue30860, libpython is no longer able to be linked as a shared library, because built-in modules are not compiled with the correct external linkage flags. This is due to the removal of -DPy_BUILD_CORE, which in pyport.h is used to control wither __declspec(dllexport) is used as opposed to __declspec(dllimport). Fortunately Eric Snow already added in https://github.com/python/cpython/pull/3458 a new flag Py_BUILD_CORE_BUILTIN which is used sparingly on Windows, and which should also be used, e.g. on Cygwin or MinGW, when compiling modules that are linked into libpython as built-ins. It sets the right external linkage flags without carrying the additional weight of Py_BUILD_CORE. This along with issue34211 need to be fixed in order to get Python 3.7+ building on Cygwin again. -- components: Build keywords: 3.7regression messages: 322316 nosy: erik.bray priority: normal severity: normal status: open title: Cygwin link failure with builtin modules since issue30860 versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34211] Cygwin build broken due to use of _Type in static declaration in _abc module
Change by Erik Bray : -- keywords: +patch pull_requests: +7967 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue34211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34211] Cygwin build broken due to use of _Type in static declaration in _abc module
New submission from Erik Bray : This is essentially the same as issue21124, but introduced more recently with the addition of the _abc_data_type in the _abc module. The workaround is simply to use PyVarObject_HEAD_INIT(NULL, 0) instead of PyVarObject_HEAD_INIT(_Type, 0); PyType_Ready should take care of the rest. P.S. I'm trying to get going again on the project of adding an AppVeyor build, and eventually a buildbot for Cygwin. My previous attempt was doomed because I wanted to fix all failing tests on Cygwin *first*. This time I am going for a more "instant gratification" approach of just skipping the tests that fail (for now) so that I can at least catch new regressions, and then gradually re-enabled skipped tests as I can find fixes for them. However, for that to happen we at least need a minimal build to work. -- components: Build keywords: 3.7regression messages: 322315 nosy: erik.bray priority: normal severity: normal stage: needs patch status: open title: Cygwin build broken due to use of _Type in static declaration in _abc module type: compile error versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31882] Cygwin: asyncio and asyncore test suites hang indefinitely due to bug in Cygwin
Erik Bray added the comment: I originally opened this in https://bugs.python.org/issue29253 but then made a dupe of my own bug! Anyways, there's a (nearly year old) pull request for it now. -- ___ Python tracker <https://bugs.python.org/issue31882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29253] Fix test_asyncore tests on Cygwin
Erik Bray added the comment: Yes, it's a dupe. There was enough time after I later made the PR for this that I forgot I already opened an issue for it. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue29253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29672] `catch_warnings` context manager causes all warnings to be printed every time, even after exiting
Erik Bray added the comment: Yes, I think `catch_warnings` should back up and restore the relevant `__warningregistry__`. At which point it's not even clear to me what value there is in the _filter_version... -- ___ Python tracker <https://bugs.python.org/issue29672> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29672] `catch_warnings` context manager causes all warnings to be printed every time, even after exiting
Erik Bray added the comment: I just encountered this as well. The way catch_warnings is implemented is a bit "dumb" in how it treats _filter_version (it calls _filters_mutated even if the active filters are not actually changed when entering catch_warnings). More significantly, _filter_version is not fine-grained enough. If some warning was already displayed, calling catch_warnings() should not later cause that same warning to be displayed again unless the filters were modified in such a way, during catch_warnings(), that that warning should be displayed (e.g. changed to 'always'). I'm not really sure what to do about that though. Maybe the "filter version" should be per-warning? Currently the value assigned to each warning in __warningregistry__ is not used (it is just set to True), so maybe that could actually be used for this. -- nosy: +erik.bray ___ Python tracker <https://bugs.python.org/issue29672> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33939] Provide a robust O(1) mechanism to check for infinite iterators
Erik Bray added the comment: > Thinking about the generator-iterator case a bit more, "False" would be a bad > default for that. Allowing "NotImplemented" to indicate the ambiguous "Might > be finite, might be infinite" state, and using that as the default for > generator-iterators, would probably make sense. This is why I suggested the converse--something like __finite_iterator__ (nevermind bikeshedding over the name or "yet another dunder method). This is something one would use to mark as iterator as "this is definitely expected to terminate at some point, assuming it is correctly implemented". If __finite_iterator__ == False, which should be the default, it doesn't necessarily mean it is infinite either, it just may or may not be finite, so there's no guarantee. I think that __finite_iterator__ == True is more or less equivalent to returning a non-zero value from __length_hint__, whereas __finite_iterator__ == False is equivalent to raising NotImplemented for __length_hint__. Either way it means adding __length_hint__ to all iterators, and also (as Nick suggested) having a decorator for generators to set the appropriate hint as well. -- ___ Python tracker <https://bugs.python.org/issue33939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33939] Raise TypeError in __length_hint__ for consistently infinite iterators
Erik Bray added the comment: Per the discussion in https://trac.sagemath.org/ticket/24757, it would also be nice if some other common iterables like map and filter implemented a similar __length_hint__ which would interrogate whatever iterables were give as their argument(s). To summarize the discussion in that ticket, it would be nice to at least know if I can expect some iterable to be finite without actually knowing its length. Sure, if I passed in some arbitrary generator there's no way for the intepreter to know a priori if it will terminate. But I would at least like to be able to manually mark whether I expect, as an intelligent developer, that under normal conditions the generator *should* terminate. And this information should filter up to other iterators that I pass my generator to. That way I can code defensively around whether or not I at least expect an iterator to be finite (even if not of a known length). -- nosy: +erik.bray ___ Python tracker <https://bugs.python.org/issue33939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Erik Bray <erik.m.b...@gmail.com> added the comment: +1, that seems obvious to me like better behavior. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20082] Misbehavior of BufferedRandom.write with raw file in append mode
Erik Bray <erik.m.b...@gmail.com> added the comment: I keep forgetting about this (given that it's like 5 years old now). Let me see if I can make a new PR for it... -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit
Erik Bray <erik.m.b...@gmail.com> added the comment: This has a backport PR now for 3.6. Once that PR is merged I think we can close this as fixed. -- stage: patch review -> backport needed versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32797] Tracebacks from Cython modules no longer work
Erik Bray <erik.m.b...@gmail.com> added the comment: On Feb 8, 2018 12:55, "Jeroen Demeyer" <rep...@bugs.python.org> wrote: New submission from Jeroen Demeyer <jdeme...@cage.ugent.be>: Displaying the source code in tracebacks for Cython-compiled extension modules in IPython no longer works due to PEP 302. Various fixes are possible, the two most obvious ones are: To be clear this is nothing to do with PEP 302, but has more to do with details of the import system reimplementation of Python 3.3, which PEP 302 predates by quite a lot. linecache should continue searching for the source file even if loader.get_source() returns None. I don't necessarily agree here. For some modules there may not be a real file associated with it in the first place, much less on sys.path. I'm not exactly sure why that fallback is there in the first place, but if a module does have a __loader__ that should have the say of where the module's source code is found (if at all). 2. the method ExtensionFileLoader.get_source() should be removed (instead of being implemented and returning None). Why? What would that help with? PEP 302 says get_source() can return None of no sources are found. That ExtensionFileLoader does this is not wrong (though it might be nice if it had a way to show C sources). It certainly doesn't know anything about Cython. If anything, as you and I discussed, Cython should be providing its own loader for Cython modules (and perhaps have a way to better distinguish Cython modules from other extension modules). Now why was this broken and how do the above fix that? When IPython needs to display a traceback, it uses linecache.getlines() to get the source code to display. For Cython extensions, the filename is a correct *relative* filename (it must be a relative filename since Cython does not know where the sources will be after installation). Since the filename is relative, linecache does not immediately find it, so it looks for a PEP 302 loader. For extension modules (Cython or not), it finds an instance of ExtensionFileLoader. If the loader has a get_source() method, then it uses that to get the sources. Since ExtensionFileLoader.get_source() returns None, linecache stops looking further for sources. Instead, what should happen is that linecache continues looking for the sources in sys.path where it has a chance of finding them (if they are installed somewhere in sys.path). The problem with this analysis is that the fact that this used to work at all was relying on undocumented behavior. Also in the case of Sage, which was using this to find Cython sources, it's because we were putting Cython sources on a sys.path entry which is not a normal thing to do. I don't think there's a bug in Python here, and that this is a problem that needs to be solved on the Cython end. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30537] Using PyNumber_AsSsize_t in itertools.islice
Erik Bray <erik.m.b...@gmail.com> added the comment: > Users might be better off by not seeing an unhelpful error message when > passing in a numpy.int32, or they might be worse-off by having lost a cue > that they were writing inefficient code (which invisibly creates temporary > integer objects on every call when presumably the whole reason for using > numpy was a concern for efficiency). While it's true there are many Numpy users who don't understand what they're doing, any time they go into the Python interpreter they're losing the benefits of Numpy anyways (which are fast vectorized operations on arrays). -- nosy: +erik.bray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32438] PyLong_ API cleanup
New submission from Erik Bray <erik.m.b...@gmail.com>: Per Serhiy's comment in this thread https://mail.python.org/pipermail/python-ideas/2017-December/048413.html (which I agree with), several of the PyLong_ functions have behavior carried over from Python 2 of calling __int__ on their arguments if the input is not a PyLongObject: PyLong_AsLong PyLong_AsLongAndOverflow PyLong_AsLongLong PyLong_AsLongLongAndOverflow PyLong_AsUnsignedLongMask PyLong_AsUnsignedLongLongMask This behavior should probably be deprecated, and eventually removed. Interfaces that should accept generic number-like objects should use the PyNumber API instead. -- components: Interpreter Core messages: 309119 nosy: erik.bray priority: normal severity: normal status: open title: PyLong_ API cleanup type: behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23428] Use the monotonic clock for thread conditions on POSIX platforms
Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4856 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue23428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32243] Tests that set aggressive switch interval hang in Cygwin on a VM
Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4855 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28459] _pyio module broken on Cygwin / setmode not usable
Erik Bray <erik.m.b...@gmail.com> added the comment: Right, the current patch is really combining several issues. I'll make a PR from it that just fixes the _pyio issue. I'll also open an issue for fixing the ctypes bug (this is a patch I've had in my cygwin branch for ages but just never got around to making a report for...) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32287] Import of _pyio module failed on cygwin
Erik Bray <erik.m.b...@gmail.com> added the comment: Indeed, this is a duplicate of #28459. I'll also update the existing patch to a pull request. -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32243] Tests that set aggressive switch interval hang in Cygwin on a VM
New submission from Erik Bray <erik.m.b...@gmail.com>: This is basically the same as #26939, but rather than Android running in an emulator it is affecting Cygwin running in a slow VM (in this case it's on my university's OpenStack infrastructure--I don't know what hypervisor they're using but probably KVM--either way the point is that it's a Windows VM and relatively slow). With Cygwin on Windows running natively this has never been a problem. FWIW I tried my own version of Victor's patch from #23428 (adapted to the new _PyTime API). This patch would be worth applying regardless and I can attach my version of the patch to that ticket, but alone it did not fix it. On top of that I also added a version of Xavier's patch from #26939 that adjusts the wait interval in PyCOND_TIMEDWAIT to ensure that the deadline is late enough to account for delays. I'm not sure that this is completely fool-proof, but it solved the problem for me. With that patch I was unable to make the system hang again. For some reason in #26939 that more general fix was abandoned in favor of simply setting the switch interval less aggressively for those tests in the particular case of the android emulator. But it seems that the more general fix might still be worthwhile. -- components: Tests messages: 307808 nosy: erik.bray priority: normal severity: normal status: open title: Tests that set aggressive switch interval hang in Cygwin on a VM ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32082] atexit module: allow getting/setting list of handlers directly
New submission from Erik Bray <erik.m.b...@gmail.com>: In Python 2 it was possible to directly manipulate the list of registered atexit handlers through atexit._exithandlers. Obviously I'm not complaining that this went away, as it was an underscored attribute. But this possibility was still useful in the context of testing. For example, we have a test suite that runs many test cases in subprocesses run with multiprocessing.Process. Since these call os._exit() any atexit handlers registered by the code under test are not run. It's useful, however, to test that either a) Expected atexit handlers ran correctly or b) No unexpected atexit handlers were registered To this end we would save and clear atexit._exithandlers, call atexit._run_exitfuncs(), then restore the original atexit._exithandlers. This is not possible on Python 3 since that all lives in the C module state for sub-interpreter support. For the time being it was necessary to work around this with a Cython module, but coding around internal extension module structures is hardly ideal: https://git.sagemath.org/sage.git/diff/src/sage/misc/_context_py3.pyx?id=85b17201255e9919eaa7b5cff367e8bc271c2a3f I think it would be useful--for testing purposes *only*--to add a _get_exitfuncs() function that returns a tuple of the registered handlers, and likewise a _set_exitfuncs(handlers) with sets the registered handlers from an iterable (the latter being little more than a shortcut for `atexit._clear(); for h in handlers: atexit.register(*h)`). I would propose that these be undocumented internal functions to emphasize that they are not how the module should be used in normal circumstances. At the same time it might be worth addressing https://bugs.python.org/issue22867 I can provide a patch if this idea is acceptable. -- components: Library (Lib) messages: 306537 nosy: erik.bray priority: normal severity: normal status: open title: atexit module: allow getting/setting list of handlers directly type: behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"
Erik Bray <erik.m.b...@gmail.com> added the comment: In my PR there's a behavior test for the default, so we don't have to hard-code that on a per-platform basis at least. The C != POSIX thing I'm not sure you can easily test for. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"
Erik Bray <erik.m.b...@gmail.com> added the comment: Yes, I looked at some of the other issues pertaining to this, but it wasn't immediately apparent how to kill multiple birds with one stone, so here I just focused on this one assumption. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"
Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4316 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"
New submission from Erik Bray <erik.m.b...@gmail.com>: Several of the tests in test_c_locale_coercion (particularly LocaleCoercionTests._check_c_locale_coercion) tend to assume that the system default locale used when setting setlocale(category, "") and when all the relevant environment variables are empty/blank will be the "C"/"POSIX" locale. While this is often true POSIX does not require this to be the case. For example on Cygwin it already defaults to "C.UTF-8", so these tests fail because they assume the legacy coercion will be used, when it isn't (e.g. the LC_CTYPE environment variable does not get forced to "C.UTF-8"). In principle this can affect any platform, however, that chooses a different default. -- components: Tests messages: 306019 nosy: erik.bray, ncoghlan priority: normal severity: normal status: open title: test_c_locale_coercion fails when the default LC_CTYPE != "C" type: behavior versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28441] Change sys.executable to include executable suffix
Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4305 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31883] Cygwin: heap corruption bug in wcsxfrm
Erik Bray <erik.m.b...@gmail.com> added the comment: Well, we'll see how long it takes me to get them to respond on that. If it's not too much trouble then I'll be happy to drop this issue. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31883] Cygwin: heap corruption bug in wcsxfrm
Erik Bray <erik.m.b...@gmail.com> added the comment: Well, I agree there's an unfortunate trade-off here: One can skip the test, allowing the test suite to work on slightly older versions of Cygwin, from before this issue was fixed. However, I then lose regression testing on newer versions. My personal feeling in this case is that it's not a very important test and can be skipped in the future (although the bug that this test caught was fairly serious and one would want regression testing for it...) As an alternative I could be more fine-grained and only skip the test on older versions of Cygwin that are affected. I was hoping to avoid putting in too much Cygwin-specific test utilities, though adding a version check for Cygwin is not terribly hard (I do the same for my Cygwin port of psutil). For reference, the current version of Cygwin that comes installed on AppVeyor (for which I'm trying to get a Cygwin build set up) is 2.8.0, which *is* (just barely) affected by this bug. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31883] Cygwin: heap corruption bug in wcsxfrm
Erik Bray <erik.m.b...@gmail.com> added the comment: To be clear, are you saying there shouldn't be a workaround to the underlying issue (I agree), or are you saying the test skip shouldn't even be added? I'm in favor of just skipping the test since it's still a problem on (currently) recent Cygwin versions. And it's not a very critical test so I'm happy to just skip it in this case. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4032] distutils doesn't search ".dll.a" as library on cygwin
Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4120 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue4032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31885] Cygwin: socket test suites hang indefinitely due to bug in Cygwin
Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4119 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31885] Cygwin: socket test suites hang indefinitely due to bug in Cygwin
New submission from Erik Bray <erik.m.b...@gmail.com>: Like issue31882, this is to mention an upstream bug in Cygwin that causes one of the tests in the test_socket test suite to hang indefinitely. That bug is fixed upstream [1], but for now it would still be better to skip the test on Cygwin. The bug is that in some cases a blocking send() (particularly for a large amount data) cannot be interrupted by a signal even if SA_RESTART is not set. Fixes to this issue, along with issue31882, issue31883, and issue31878 provide the bare minimum for Cygwin to at least compile (not necessarily all optional extension modules) and run the test suite from start to finish (though there may be other tests that cause the interpreter to lock up, but that are currently masked by other bugs). [1] https://cygwin.com/ml/cygwin-patches/2017-q2/msg00037.html -- messages: 305123 nosy: erik.bray priority: normal severity: normal status: open title: Cygwin: socket test suites hang indefinitely due to bug in Cygwin type: crash ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31883] Cygwin: heap corruption bug in wcsxfrm
Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4116 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31883] Cygwin: heap corruption bug in wcsxfrm
New submission from Erik Bray <erik.m.b...@gmail.com>: There is an acknowledged bug in Cygwin's implementation of wcsxfrm() [1] that can cause heap corruption in certain cases. This bug has since been fixed in Cygwin 2.8.1-1 [2] and all current and future releases. However, that was relatively recent (July 2017) so it may still crop up. I also have a workaround for this from the Python side, but rather than clutter the code with workarounds for platform-specific bugs I think it suffices just to skip the test in this case. [1] https://cygwin.com/ml/cygwin/2017-05/msg00149.html [2] https://cygwin.com/ml/cygwin-announce/2017-07/msg2.html -- messages: 305120 nosy: erik.bray priority: normal severity: normal status: open title: Cygwin: heap corruption bug in wcsxfrm ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31882] Cygwin: asyncio and asyncore test suites hang indefinitely due to bug in Cygwin
Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4115 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31882] Cygwin: asyncio and asyncore test suites hang indefinitely due to bug in Cygwin
New submission from Erik Bray <erik.m.b...@gmail.com>: Some of the tests for asyncio and asyncore block forever on Cygwin, due to a known (and seemingly difficult to fix) bug [1] in Cygwin involving SO_PEERCRED on UNIX sockets. SO_PEERCRED is a socket option that can be used to exchange file ownership info of the socket at the time the connection was established (specifically on UNIX sockets). This feature is technically supported on Cygwin, but the effect of the bug is that if two sockets are opened on the same process (even without using socketpair()), the credential exchange protocol can cause connect() on the "client" socket to block unless the "server" socket is already listen()-ing. This situation is not all that common in practice (it is not a problem if the "client" and "server" are separate processes). But it does show up in the test suite in a number of places, since both sockets belong to the same process. I have a patch to work around this and will post a PR shortly. [1] https://cygwin.com/ml/cygwin/2017-01/msg00054.html -- messages: 305118 nosy: erik.bray priority: normal severity: normal status: open title: Cygwin: asyncio and asyncore test suites hang indefinitely due to bug in Cygwin type: crash ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16135] Removal of OS/2 support
Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4113 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue16135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16135] Removal of OS/2 support
Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4102 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue16135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31828] Support Py_tss_NEEDS_INIT outside of static initialisation
Change by Erik Bray <erik.m.b...@gmail.com>: -- nosy: +erik.bray ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31878] Cygwin: _socket module does not compile due to missing ioctl declaration
Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4100 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31878] Cygwin: _socket module does not compile due to missing ioctl declaration
New submission from Erik Bray <erik.m.b...@gmail.com>: On Cygwin, ioctl() is found in sys/ioctl.h (as on Darwin). Without adding something to the effect of #ifdef __CYGWIN__ # include #endif the _socket module cannot compile on Cygwin. A fix was this was included in the (rejected) https://bugs.python.org/issue29718; this issue is just as a reminder that it remains an issue and to have a bug report to attach a more focused PR to. -- messages: 305065 nosy: erik.bray priority: normal severity: normal status: open title: Cygwin: _socket module does not compile due to missing ioctl declaration type: compile error ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2445] Use The CygwinCCompiler Under Cygwin
Change by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +4099 stage: commit review -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue2445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31877] Build fails on Cython since issue28180
Change by Erik Bray <erik.m.b...@gmail.com>: -- keywords: +patch pull_requests: +4097 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31877] Build fails on Cython since issue28180
New submission from Erik Bray <erik.m.b...@gmail.com>: I'm trying once again to get the test suite up to snuff on Cygwin so I can start running a buildbot (particularly now that PEP 539 is done). However, as of issue28180 the build fails with: gcc-o python.exe Programs/python.o libpython3.7m.dll.a -lintl -ldl-lm Programs/python.o: In function `main': ./Programs/python.c:81: undefined reference to `_Py_LegacyLocaleDetected' ./Programs/python.c:81:(.text.startup+0x86): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_Py_LegacyLocaleDetected' ./Programs/python.c:82: undefined reference to `_Py_CoerceLegacyLocale' ./Programs/python.c:82:(.text.startup+0x19f): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_Py_CoerceLegacyLocale' collect2: error: ld returned 1 exit status It seems _Py_LegacyLocaleDetected and _PyCoerceLegacyLocale are missing the necessary PyAPI_FUNC declarations in pylifecycle.h. -- messages: 305061 nosy: erik.bray priority: normal severity: normal status: open title: Build fails on Cython since issue28180 type: compile error ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24766] Subclass of property doesn't preserve instance __doc__ when using doc= argument
Changes by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +2546 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like
Erik Bray added the comment: Actually I just finished reading njs's blog post, and as he points out that special case for SETUP_FINALLY is basically broken. There are other cases where it doesn't really work either. For example if you have: if ...: do_something() else: do_something_else() try: ... finally: ... then (ignoring the issue about POP_TOP for a moment) the last instruction in *one* of these branches if followed immediately by SETUP_FINALLY, while in the other branch there's a JUMP_FORWARD, then the SETUP_FINALLY. All the more reason for a more generic solution to this that doesn't depend strictly on the next op locally in the byte code. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like
Erik Bray added the comment: >> Or we could steal a bit in the opcode encoding or something. > That seems like a very reasonable and easy-to-implement solution. It > would > generalize this check: > https://github.com/python/cpython/blob/e82cf8675bacd7a03de508ed11865fc2701dcef5/Python/ceval.c#L1067-L1071 Interesting; I didn't notice that bit before. It seems like that does at least try to guarantee that a signal can't interrupt between: lock.acquire() try: ... which previously I assumed we couldn't make any guarantees about. But CPython at least does, or tries to. It would be good to generalize that. -- nosy: +erik.bray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit
Erik Bray added the comment: Thanks for checking! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit
Erik Bray added the comment: Iryna, I updated the pull request with a slightly updated fix. Could you confirm again, when you get a chance, that it works for arm64? Thanks. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29804] test_ctypes test_pass_by_value fails on arm64 (aarch64) architecture
Changes by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +1760 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit
Erik Bray added the comment: Sure, thanks for pointing that out. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit
Erik Bray added the comment: Thanks for pointing that out. Indeed it's the same symptom, but slightly different cause. libffi has different implementations of its calling routines for different architectures/platforms depending on the machine architecture and calling conventions used. So this case is probably buggy for the arm64 implementation as well, as in #29804. Off the top of my head I don't know a reliable way to check for this case, but this fix would work around the arm64 issue as well if I could check for that architecture easily at compile time. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit
Changes by Erik Bray <erik.m.b...@gmail.com>: -- pull_requests: +1656 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30353] ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit
New submission from Erik Bray: The test ctypes.test.test_structures.StructureTestCase.test_pass_by_value fails on 64-bit Cygwin and MinGW using the system libffi with: == FAIL: test_pass_by_value (ctypes.test.test_structures.StructureTestCase) -- Traceback (most recent call last): File "/home/embray/src/python/cpython/Lib/ctypes/test/test_structures.py", line 416, in test_pass_by_value self.assertEqual(s.first, 0xdeadbeef) AssertionError: 195948557 != 3735928559 It seems that libffi does not handle passing structs by value properly on those platforms as I explained here: https://github.com/libffi/libffi/issues/305 The upstream bug hasn't been confirmed yet by the libffi developers so I could be wrong, but I think this is fairly clearly broken there. I have a PR forthcoming to work around the issue. -- components: ctypes messages: 293556 nosy: erik.bray priority: normal severity: normal status: open title: ctypes: pass by value for structs broken on Cygwin/MinGW 64-bit type: behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29718] Fixed compile on cygwin.
Erik Bray added the comment: This seems to be fixing a number of different Cygwin issues, many of which are known (some of these patches come from the Cygwin port of Python). However, some of these issues are already being handled separately, such as #25658, and I think rather than one big mongo patch it wold be good to break this up into individual issues. I was also just planning to submit some individual patches for review. -- nosy: +erik.bray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21085] Cygwin does not provide siginfo_t.si_band
Erik Bray added the comment: Decorater, since this issue was already closed, could you open a new one? And when you do, please add me to the nosy list. I'm still planning to get a Cygwin built bot up for Python, I've just had other various priorities. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Erik Bray added the comment: Thanks Masayuki for the updated patch, and especially for the additional test cases. Looking at the patch, it occurs to me that this solution seems to be the minimal needed to fix the issue that we were originally trying to fix, without adding too much additional complexity or new semantics to how TLS keys are used in the interpreter. In other words, this preserves the existing usage with minimal changes except to better support opaque key types. So I think it's a point in favor of this change that's managed to remain focused. I'll work on updating the PEP draft to reflect the additions. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29253] Fix test_asyncore tests on Cygwin
New submission from Erik Bray: This patch works around a couple different problems with running the test_asyncore tests in Cygwin, both of which are due to bugs in Cygwin itself and not in Python. As such, I don't think Python should try to work around these issues in general, but I do think they're worth at least working around in the tests so that they can pass and/or skip. The first issue is more severe, as it actually causes the test run to hang indefinitely due to a bug in Cygwin that can cause connect() on a socket to block indefinitely. This occurs only in a situation where a "client" connects to a "server" that is not accept()-ing connections--a situation that occurs specifically in some of the asyncore tests where both the "client" and the "server" are in the same test process. This applies a known workaround to the tests only, allowing them to pass. The other bug simply causes a test failure--the bug is that getsockopt(SO_REUSEADDR) returns the wrong result after a setsockopt(SO_REUSEADDR) (the latter has the correct behavior; the value of the option just isn't reported back correctly after being set). In this case the relevant test is simply skipped on Cygwin. The patch is currently light on in-line documentation of the situation, but I can add that if it's otherwise approved. -- components: Tests files: 0001-Fix-test_asyncore-tests-on-Cygwin-by-working-around-.patch keywords: patch messages: 285326 nosy: erik.bray, zach.ware priority: normal severity: normal stage: patch review status: open title: Fix test_asyncore tests on Cygwin Added file: http://bugs.python.org/file46272/0001-Fix-test_asyncore-tests-on-Cygwin-by-working-around-.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Erik Bray added the comment: I'm still pretty happy with the previous patch, personally, since I don't need the tracemalloc module. But it seems like that should be fixed (or if nothing else that code in _tracemalloc.c should check Py_HAVE_NATIVE_TLS too). I like the idea of the new PyThread_tss_ API. At first I wasn't sure because I thought you implied that it would use tss_t and related APIs from C11 which was going to be a non-starter (as CPython has only just barely started using *some* features from C99, per the recent update to PEP 7). But I see in your patch that the naming is only inspired by C11 (and could be consistent with it if CPython ever moves toward C11 support). I imagine this will likely require a PEP though? I would happy to help draft one. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Erik Bray added the comment: To me, Masayuki's patch is an acceptable work-around for the time being. I don't *like* it because the fact remains that native TLS can work on these platforms and falling back on Python's slower implementation isn't necessary. That said, the previous patch attempts also add additional overhead that shouldn't be necessary. I agree the best thing to do would be to change this API, but that is a bigger issue I guess... -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28441] Change sys.executable to include executable suffix
Changes by Erik Bray <erik.m.b...@gmail.com>: -- stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28441] Change sys.executable to include executable suffix
Erik Bray added the comment: Thanks! Setting EXE_SUFFIX from the Makefile is much better. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28459] _pyio module broken on Cygwin / setmode not usable
Erik Bray added the comment: Hi Masayuki, thanks for the response (I thought I replied to this earlier but maybe I only imagined it--I've been on vacation). I agree with just about everything you write here. I'm aware of the FreeBSD setmode(), but I figured os.setmode() could do different things on different platforms as applicable. But that would also be very confusing. Your patch using ctypes looks fine to me--I considered doing the same, but what I'm not sure is if it's kosher to use ctypes here, given that it's techically an optional module. Since _pyio is, as I understand it, mainly used for testing it's probably fine? But I think we'll need some core maintainers' comments here... Implementing a cygwin module would be really nice, actually, even if it isn't included in the stdlib. There are a few other cygwin-specific APIs that it is useful to have wrappers around: https://cygwin.com/cygwin-api/cygwin-functions.html But that would be outside the scope of fixing this issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28459] _pyio module broken on Cygwin / setmode not usable
New submission from Erik Bray: Since the patch to #24881 was merged the _pyio module has been non-importable on Cygwin, due to an attempt to import from the msvcrt module. However, the msvcrt module is not built on Cygwin (Cygwin does not use MSVCRT). Cygwin's libc does, however, have _setmode. The problem this is trying to solve is to call _setmode (https://msdn.microsoft.com/en-us/library/tw4k6df8.aspx) on file descriptors to ensure that they are O_BINARY instead of O_TEXT (a distinction that needs to made on Windows). Fortunately, on Cygwin, it is fairly rare that a file descriptor will have mode O_TEXT, but it it is possible. See https://cygwin.com/faq/faq.html#faq.programming.msvcrt-and-cygwin This could be tricky to solve though. Removing setmode() call entirely works for me as far as the test suite is concerned. But it leaves _pyio slightly incongruous with the C implementation in this one small aspect, and it *is* a bug. I would propose for Python 3.7 adding an os.setmode() function. On Windows this could be simply an alias for msvcrt.setmode() (or vice-versa). But because setmode() is available also in Cygwin (and technically some other platforms too, though none that are currently supported by Python) it would be a good candidate for inclusion in the os module I think (for those platforms that have it). -- components: IO messages: 278802 nosy: erik.bray priority: normal severity: normal status: open title: _pyio module broken on Cygwin / setmode not usable type: crash ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
Erik Bray added the comment: FWIW this patch broke the _pyio module on Cygwin, as the msvcrt module is not built on Cygwin. AFAICT this is only a problem for Python built with MSVCRT, which Cygwin does not use. When test case works as expected on Cygwin without this. -- nosy: +erik.bray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24881> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28441] sys.executable is ambiguous on Cygwin without .exe suffix
Erik Bray added the comment: I agree this has a slight change in behavior which I was at first hesitant about. But I think the previous behavior was wrong insofar as it was overly ambiguous. I agree it should apply on MSYS2 as well (I actually thought __CYGWIN__ was defined on MSYS2 but I could be wrong about that). I'm not sure what better solution there is. I thought of tinkering with subprocess specifically, but that was too fragile. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28441] sys.executable is ambiguous on Cygwin without .exe suffix
New submission from Erik Bray: This actually came up previously in #1543469 in the context of test_subprocess, but it's a more general issue that I thought was worth addressing somehow. The issue here is that as Cygwin tries to provide a "UNIX-like" experience, any system interfaces that take the path to an executable as an argument allow the .exe extension to be left off. This is particularly convenient for the shell experience, so that one can run, for example "python" or "ls" without typing "python.exe" or "ls.exe" (this is of course true of the Windows cmd shell as well). In the case of ambiguity however--such as when there is both a "python" and a "python.exe" in the same path, one must explicitly add the ".exe", otherwise the path without the exe is assumed. This is made even worse when you factor in case-insensitivity. Thus, this becomes a real annoyance when developing Python on Cygwin because you get both a "python.exe" and the "Python" directory in your source tree. This isn't so much of a problem, except that sys.executable leaves off the ".exe" (in UNIX-y fashion), so any test that calls Popen([sys.executable]) errors out because it thinks you're trying to execute a directory (Python/). I think the only reasonable fix is to take the patch suggested at #1543469, and ensure that the ".exe" suffix is appended to sys.executable on Cygwin. I think that sys.executable should be as unambiguous as possible, and that's the only way to make it reasonably unambiguous on Cygwin. I've attached a patch adapted from the one in #1543469 which solves the issue for me. -- files: cygwin-sys-executable.patch keywords: needs review, patch messages: 278651 nosy: erik.bray, masamoto, zach.ware priority: normal severity: normal status: open title: sys.executable is ambiguous on Cygwin without .exe suffix type: behavior versions: Python 3.7 Added file: http://bugs.python.org/file45091/cygwin-sys-executable.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13756] Python3.2.2 make fail on cygwin
Erik Bray added the comment: Okay, that would explain it then. I was building from an older branch (pre-3.7) that still has the bundled libffi. FWIW with the fix from #2445, --with-system-ffi works (as does some trivial use of _ctypes though I haven't run all the tests). So if the bundled libffi is gone then I guess that's a moot point. Thanks for getting a bunch of these fixes merged. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14438] _cursesmodule build fails on cygwin
Erik Bray added the comment: I see what you're saying--thanks for pointing out those other tickets. I'll give #28190 a try first. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14438] _cursesmodule build fails on cygwin
Erik Bray added the comment: I think it would still be worth including this patch in Python. It wouldn't be the only condition in py_curses.h for platform-specific oddities with ncurses. This patch is still needed for the _curses module to build on Cygwin. -- nosy: +erik.bray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
