[issue11805] package_data only allows one glob per-package
Erik Bray added the comment: > When run from an uninstalled checkout, for example when developing, the > file will be found in the checkout. When run after being installed on > a Debian system, the file will be found in /usr/local/share > /spam/templates/log.txt. Each Python installation can decide (through > sysconfig.cfg) where to install things. Got it! I think when I first submitted this issue my primary concern was where the resource files live in different development/deployment contexts. Looking at sysconfig.cfg makes it all pretty clear, though it was hard to find this information a while ago. So what exactly is the verdict then? Keep package_data for now, but encourage resources, and dump data_files all together? Or...? -- ___ Python tracker <http://bugs.python.org/issue11805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13712] pysetup create should not convert package_data to extra_files
Erik Bray added the comment: FWIW, I'm for the first option for specifying package_data: [files] package_data = spam = first second third I'm pretty sure this is how I ended up implementing it in d2to1, since I needed this functionality. Theoretically spaces could be supported with an escape sequence, but I don't think that's worth complicating things for if package_data is deprecated anyways. I'm all for making it difficult for anyone trying to include filenames with spaces in their source code. -- ___ Python tracker <http://bugs.python.org/issue13712> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12240] Allow multiple setup_hooks
New submission from Erik Bray : I have a use case where I have a small library of setup_hook functions for various purposes that are used by multiple projects. Some projects may want to use more than one of these setup_hooks. I can certainly create a wrapper hook for each function that calls all the necessary hooks. But that gets a little tedious and seems unnecessary. In this use case it would be fine if I could just list a set of setup_hooks to be executed in sequence. It is, of course, up the developer to be sure that none of these setup_hooks have conflicting actions. As a temporary workaround I wrote a setup_hook called chain_setup_hooks. I then looks for an option called "setup_hooks" which behaves as I've described. This works fine, though I don't see why setup_hook shouldn't allow multiple values to begin with. -- assignee: tarek components: Distutils2 messages: 137479 nosy: alexis, eric.araujo, erik.bray, tarek priority: normal severity: normal status: open title: Allow multiple setup_hooks type: feature request ___ Python tracker <http://bugs.python.org/issue12240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12240] Allow multiple setup_hooks
Erik Bray added the comment: Great! I'll add a patch shortly. -- ___ Python tracker <http://bugs.python.org/issue12240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12240] Allow multiple setup_hooks
Erik Bray added the comment: Adds support for multiple setup_hooks and updates the docs. For now I left the option name as "setup_hook", though it might make sense to rename it to "setup_hooks" for consistency's sake. -- keywords: +patch Added file: http://bugs.python.org/file22264/python_issue12240.patch ___ Python tracker <http://bugs.python.org/issue12240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11595] Miscellaneous bugs in cfg_to_args() utility function
Erik Bray added the comment: Done. Also added support for multi-valued description-file values. -- Added file: http://bugs.python.org/file22276/issue11595-2.patch ___ Python tracker <http://bugs.python.org/issue11595> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11595] Miscellaneous bugs in cfg_to_args() utility function
Erik Bray added the comment: Thanks Eric for your review. Obviously the last patch was rushed, and I didn't even run the tests. It also got my changes for issue12240 mixed into it. So I've gone ahead and attached an updated patch which incorporates your review comments. -- Added file: http://bugs.python.org/file22298/issue11595-3.patch ___ Python tracker <http://bugs.python.org/issue11595> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12240] Allow multiple setup_hooks
Erik Bray added the comment: Here's an update with tests. It should be applied after my patch for issue11595. -- Added file: http://bugs.python.org/file22299/python_issue12240-2.patch ___ Python tracker <http://bugs.python.org/issue12240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12375] Add packages_root to sys.path for hooks
New submission from Erik Bray : I just saw issue11637 [Add cwd to sys.path for hooks] and was reminded that this would also be useful (and in fact necessary if hook code is in a package that's under some root other than cwd). On a related matter, the current use of Distribution.package_dir is confusing. Sometimes it's assumed to be a string, though in other parts of the code it's assumed to be a dict to support multiple package dirs--something which I thought was going away. -- assignee: tarek components: Distutils2 messages: 138737 nosy: alexis, eric.araujo, erik.bray, tarek priority: normal severity: normal status: open title: Add packages_root to sys.path for hooks versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue12375> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12377] Clean up packages_root option
New submission from Erik Bray : This issue was first mentioned in issue12375. The Distribution.package_dir attribute (which also appears in a few commands) is not used in a consistent manner. Some code expects it to be a string, while other code expects it to be a dict. I believe the correct behavior now is for it to be a string, since only one root directory for Python packages is allowed in packaging. Eric Araujo also points out that packages_root and the associated package_dir attribute are misnamed: They also point to the root for any Python modules. I'm not sure what a better name would be though--I'm tempted to suggest "source_dir", but that seems a little broad since it doesn't necessarily include C extension source. -- assignee: tarek components: Distutils2 messages: 138747 nosy: alexis, eric.araujo, erik.bray, tarek priority: normal severity: normal status: open title: Clean up packages_root option versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue12377> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12375] Add packages_root to sys.path for hooks
Erik Bray added the comment: Added issue12377 for packages_root/package_dir cleanup. -- ___ Python tracker <http://bugs.python.org/issue12375> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12240] Allow multiple setup_hooks
Erik Bray added the comment: Good to know! The majority of my development is still on 2.x so it's easy to forget things like that. -- ___ Python tracker <http://bugs.python.org/issue12240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11595] Miscellaneous bugs in cfg_to_args() utility function
New submission from Erik Bray : Attached is a patch that fixes a few miscellaneous bugs in cfg_to_args() that were holding me up. Namely: * A bad variable name (file -> path) * A few more fields needed to be in MULTI_FIELDS * Added support for packages_root -> package_dir conversion This also adds a unit test for cfg_to_args(). -- assignee: tarek components: Distutils2 files: cfg_to_args.patch keywords: patch messages: 131336 nosy: Erik.Bray, alexis, eric.araujo, tarek priority: normal severity: normal status: open title: Miscellaneous bugs in cfg_to_args() utility function Added file: http://bugs.python.org/file21278/cfg_to_args.patch ___ Python tracker <http://bugs.python.org/issue11595> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11595] Miscellaneous bugs in cfg_to_args() utility function
Erik Bray added the comment: I've got an additional patch to this function that also adds support for the package_data option, for extension modules (at least as they are currently specified in setup.cfg), and adds support for running setup_hook. The only problem is that it's starting to copy more and more from distutils2.config.Config. The difference being that it's still simpler, and doesn't depend on much else from distutils2. The reason being that I'm using this in my own packages so that I can distutils2-like setup.cfgs, but still install with normal distutils and/or Distribute without depending on distutils2 in its entirety. I'm wondering if there might be a better way to proceed, or if this sort of compatibility support is even useful to anyone else. -- ___ Python tracker <http://bugs.python.org/issue11595> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11805] package_data only allows one glob per-package
New submission from Erik Bray : In distutils the package_data option can be supplied a list of glob patterns for each package. distutils2 currently only supports one glob per package. This could easily be fixed by simply allowing more than one `package_name = pattern` value in the package_data option. For example: package_data = mypackage = templates/*.html mypackage = static/css/*.css mypackage.subpackage = templates/*.html ... -- assignee: tarek components: Distutils2 hgrepos: 16 messages: 133346 nosy: alexis, eric.araujo, erik.bray, tarek priority: normal severity: normal status: open title: package_data only allows one glob per-package type: behavior ___ Python tracker <http://bugs.python.org/issue11805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11805] package_data only allows one glob per-package
Erik Bray added the comment: As far as I've been able to tell there is no proposed syntax in the docs specifically for package_data. The docs for the resources option seems to suggest separating globs with spaces, which would be fine by me (wouldn't allow paths that contain spaces, but that's a bad idea anyways). I think that allowing one glob string on each line is more readable, but I'm not too attached either way. Another possibility would be to allow line breaks in the value, for example: package data = mypackage = templates/*.html static/css/*.css But that's getting a little more complex syntax-wise. Agreed on getting rid of data_files--it's dangerous. But package_data I find very useful sometimes, and I don't think it's always wrong. At the very least, it's not clear to me how the above use case is intended to be replaced. -- ___ Python tracker <http://bugs.python.org/issue11805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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
[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
[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
[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
[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
[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
[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
[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
[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
[issue11805] package_data only allows one glob per-package
Erik Bray added the comment: This patch works for me, and I'm happy with the syntax. Thanks! -- ___ Python tracker <http://bugs.python.org/issue11805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14549] Recursive inclusion of packages
Erik Bray added the comment: +1 for the wildcard syntax. -- ___ Python tracker <http://bugs.python.org/issue14549> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14549] Recursive inclusion of packages
Erik Bray added the comment: Potential downside: Say I have foo, foo.bar, and foo.tests. I want to install foo and foo.bar, but not foo.tests. Then I have to manually list all the packages I do want: packages = foo foo.bar That's fine, but one nice thing about find_packages is that it had an optional exclude argument. So maybe in addition to the wildcard syntax it couldn't hurt to add an exclude-packages option? I don't think that would be too complicated. Something similar for extension module sources would also be desirable. -- ___ Python tracker <http://bugs.python.org/issue14549> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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
[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
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
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
[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
[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
[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
[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 <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: 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 <http://bugs.python.org/issue29988> ___ ___ 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 : -- pull_requests: +2546 ___ Python tracker <http://bugs.python.org/issue24766> ___ ___ 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 <http://bugs.python.org/issue29718> ___ ___ 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 <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 : -- pull_requests: +1656 ___ Python tracker <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 <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: Sure, thanks for pointing that out. -- ___ Python tracker <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 : -- pull_requests: +1760 ___ Python tracker <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: 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 <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 checking! -- ___ Python tracker <http://bugs.python.org/issue30353> ___ ___ 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
[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
[issue30537] Using PyNumber_AsSsize_t in itertools.islice
Erik Bray 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 <https://bugs.python.org/issue30537> ___ ___ 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: On Feb 8, 2018 12:55, "Jeroen Demeyer" wrote: New submission from Jeroen Demeyer : 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 <https://bugs.python.org/issue32797> ___ ___ 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: 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 <https://bugs.python.org/issue30353> ___ ___ 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 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 <https://bugs.python.org/issue20082> ___ ___ 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: +1, that seems obvious to me like better behavior. -- ___ 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
[issue31877] Build fails on Cython since issue28180
New submission from Erik Bray : 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 <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
Change by Erik Bray : -- keywords: +patch pull_requests: +4097 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31877> ___ ___ 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 : -- pull_requests: +4099 stage: commit review -> patch review ___ Python tracker <https://bugs.python.org/issue2445> ___ ___ 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 : 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 <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
Change by Erik Bray : -- keywords: +patch pull_requests: +4100 stage: -> patch review ___ 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
[issue31828] Support Py_tss_NEEDS_INIT outside of static initialisation
Change by Erik Bray : -- nosy: +erik.bray ___ Python tracker <https://bugs.python.org/issue31828> ___ ___ 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 : -- pull_requests: +4102 ___ Python tracker <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 : -- pull_requests: +4113 ___ Python tracker <https://bugs.python.org/issue16135> ___ ___ 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 : 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 <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
Change by Erik Bray : -- keywords: +patch pull_requests: +4115 stage: -> patch review ___ 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
[issue31883] Cygwin: heap corruption bug in wcsxfrm
New submission from Erik Bray : 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 <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
Change by Erik Bray : -- keywords: +patch pull_requests: +4116 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31883> ___ ___ 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 : 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 <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
Change by Erik Bray : -- keywords: +patch pull_requests: +4119 stage: -> patch review ___ 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
[issue4032] distutils doesn't search ".dll.a" as library on cygwin
Change by Erik Bray : -- pull_requests: +4120 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue4032> ___ ___ 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 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 <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 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 <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 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 <https://bugs.python.org/issue31883> ___ ___ 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 : -- pull_requests: +4305 ___ Python tracker <https://bugs.python.org/issue28441> ___ ___ 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 : 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 <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 : -- keywords: +patch pull_requests: +4316 stage: -> patch review ___ Python tracker <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 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 <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 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 <https://bugs.python.org/issue32002> ___ ___ 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 : 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 <https://bugs.python.org/issue32082> ___ ___ 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 : 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 <https://bugs.python.org/issue32243> ___ ___ 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 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 <https://bugs.python.org/issue32287> ___ ___ 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: 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 <https://bugs.python.org/issue28459> ___ ___ 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 : -- keywords: +patch pull_requests: +4855 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32243> ___ ___ 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 : -- pull_requests: +4856 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue23428> ___ ___ 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 : 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 <https://bugs.python.org/issue32438> ___ ___ 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
[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
[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
[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
[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
[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
[issue34211] Cygwin build broken due to use of &PyType_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(&PyType_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 &PyType_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
[issue34211] Cygwin build broken due to use of &PyType_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
[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
[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
[issue34211] Cygwin build broken due to use of &PyType_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(&PyType_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
[issue34211] Cygwin build broken due to use of &PyType_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
[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
[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: > 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&id=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
[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
[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
