[issue46131] Add PyType_FastSubclass for float
New submission from mattip : The basic classes int, dict, list, tuple ... all have a fast path for Py_*Check(obj): #define PyLong_Check(op) \ PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_LONG_SUBCLASS) except for float. I propose to add a Py_TPFLAGS_FLOAT_SUBCLASS enum and use it to implement PyType_FastSubclass for float. -- components: C API messages: 408890 nosy: mattip priority: normal severity: normal status: open title: Add PyType_FastSubclass for float ___ Python tracker <https://bugs.python.org/issue46131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46131] Add PyType_FastSubclass for float
mattip added the comment: "complex" is also missing a fast path -- ___ Python tracker <https://bugs.python.org/issue46131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46131] Add PyType_FastSubclass for float
Change by mattip : -- keywords: +patch pull_requests: +28421 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30200 ___ Python tracker <https://bugs.python.org/issue46131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46131] Add PyType_FastSubclass for float
mattip added the comment: What do ya'all think of widen the flags field to int64_t so that there is more room for optimizations like this? -- ___ Python tracker <https://bugs.python.org/issue46131> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46794] Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)
mattip added the comment: On PyPy, the test `test_issue3151` in `test_xml_etree.py` is failing with libexpat 2.4.6. I think the problem is connected to instantiation of the `XMLParser()` with `parser = expat.ParserCreate(encoding, "}")` where `"}"` is not a valid URI character. In any case, due to libexpat issue 577, https://github.com/libexpat/libexpat/pull/577 they will be releasing a new version 2.4.7 soon. -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue46794> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46794] Please update bundled libexpat to 2.4.6 with security fixes (5 CVEs)
mattip added the comment: > [T]he test has been removed in CPython pull request > https://github.com/python/cpython/pull/31453/files Thanks, I missed that. Makes sense. -- ___ Python tracker <https://bugs.python.org/issue46794> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37967] release candidate is not gpg signed (and missing release workflow)?
New submission from mattip : Over at [multibuild](https://github.com/pypa/manylinux/pull/333#issuecomment-519802858), they ran into an issue trying to build c-extensions with the 3.8rc3 since it seems it is not gpg signed. I could not find a HOWTO_RELEASE document to check that the release workflow includes signing the package. One exists in Tools/msi/README.txt. -- components: Installation messages: 350660 nosy: mattip priority: normal severity: normal status: open title: release candidate is not gpg signed (and missing release workflow)? type: security versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37967] Beta GPG signature check failing
mattip added the comment: Is automatic download really the best solution? -- ___ Python tracker <https://bugs.python.org/issue37967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37967] Beta GPG signature check failing
mattip added the comment: I am not a gpg expert, but I think the proper solution is to add the release manager's key to the official Python GPG public key list. What would it take for that to happen? -- ___ Python tracker <https://bugs.python.org/issue37967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37967] Beta GPG signature check failing
mattip added the comment: > If you use pubkeys.txt from https://www.python.org/static/files/pubkeys.txt, > then GPG verification gives you no additional security I am confused. If the pubkeys.txt on python.org has no benefit, why does it exist? What is considered best practices for people wanting to verify the download from https://www.python.org/ftp ? -- ___ Python tracker <https://bugs.python.org/issue37967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42752] multiprocessing Queue leaks a file descriptor associated with the pipe writer (#33081 still a problem)
mattip added the comment: @crazycasta could you turn your patches into a PR? I am not sure how to get some eyes on this, but certainly the test is useful to prove the problem still exits -- ___ Python tracker <https://bugs.python.org/issue42752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43503] [subinterpreters] PyObject statics exposed in the limited API break isolation.
mattip added the comment: I am confused. How can widening the usable number of functions (i.e. using the whole C-API rather than the limited API) help c-extension modules be usable in subinterpreters? Aren't the same singletons, exception types, and other types exposed in the full C-API? -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue43503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44959] EXT_SUFFIX is missing '.sl' on HP-UX
mattip added the comment: I assume you tried and succeeded with your patch. Could you post what `_imp.extension_suffixes()` reports after the patch? I am a bit confused because you said the following, should the last line be `_m2crypto.sl` and not `_m2crypto.sl` ? my understanding is that python should search for the following file names when extension module _m2crypto is imported (in this order): _m2crypto.cpython-38.sl _m2crypto.so -- ___ Python tracker <https://bugs.python.org/issue44959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45011] tests fail when using pure-python instead of _asycio
New submission from mattip : PyPy has no asyncio c-extension module _asyncio. I see stdlib test failures when running the tests in test/test_asyncio/*.py. If I disable _asyncio in Lib/asyncio/events.py (at the end of the file) I see similar failures in CPython3.8 on Ubuntu 20.04 in test_buffered_proto.py test_buffered_proto_create_connection test_sslproto.py test_create_connection_memory_leak, test_handshake_timeout, test_start_tls_client_buf_proto_1, Also this test depends on _CFuture test_futures.py -- components: asyncio messages: 400322 nosy: asvetlov, mattip, yselivanov priority: normal severity: normal status: open title: tests fail when using pure-python instead of _asycio ___ Python tracker <https://bugs.python.org/issue45011> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
mattip added the comment: >> I wouldn't recommend [setting ob_type] after PyType_Ready is called. > Why not? What bad things will happen? It seems to be working so far. It breaks the unwritten contract that "once PyType_Ready is called, the C struct will not be modified". This is implemented in PyPy, since calling PyType_Ready creates the PyPy object in the interpreter based on the C structure. Any further changes will not be reflected in the PyPy interpreter object, so now the python-level and c-level objects do not agree what type(obj) is. We have discussed this in the PyPy team, and would like to propose relaxing the contract to state that "if the c-level contents of an object are modified, PyType_Modified must be called to re-synce the python level and c-level objects" -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue15870> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45417] Enum creation non-linear in the number of values
mattip added the comment: Over at PyPy arigo authored and we applied this fix to the as-yet unreleased pypy3.8. Note that it cannot be applied directly to CPython as sets are not ordered. Does the fix break anything? Tests in Lib/test/test_enum.py passed after applying it. -- keywords: +patch nosy: +mattip Added file: https://bugs.python.org/file50341/quadratic-fix-2.diff ___ Python tracker <https://bugs.python.org/issue45417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32780] ctypes: memoryview gives incorrect PEP3118 format strings for both packed and unpacked structs
mattip added the comment: Is there a ctypes or PEP-3118 core-dev who could review the issue and the PR solution? -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue32780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
mattip added the comment: It seems (B6) is still failing (both on PyPy3.7 and on CPython3.8.6) -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue28884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
mattip added the comment: No, my bad, B6 passes now on CPython -- ___ Python tracker <https://bugs.python.org/issue28884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39825] EXT_SUFFIX inconsistent between sysconfig and distutils.sysconfig (Windows)
mattip added the comment: the PR is awaiting approval/merge -- ___ Python tracker <https://bugs.python.org/issue39825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39825] EXT_SUFFIX inconsistent between sysconfig and distutils.sysconfig (Windows)
mattip added the comment: I submitted PR 23684 to try to skip tests to fix this. I don't understand why this wasn't caught before merge, and where AIX and FREEBSD are setting EXT_SUFFIX improperly. -- message_count: 9.0 -> 10.0 pull_requests: +22549 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/23684 ___ Python tracker <https://bugs.python.org/issue39825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39825] EXT_SUFFIX inconsistent between sysconfig and distutils.sysconfig (Windows)
mattip added the comment: I moved the new test to a separate test function and added `skipIf` for freebsd and AIX. -- ___ Python tracker <https://bugs.python.org/issue39825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42604] EXT_SUFFIX too short on FreeBSD and AIX
New submission from mattip :
Continuation of bpo 39825, this time for FreeBSD and AIX. As commented there,
the test added in the fix to 39825 fails on FreeBSD and AIX:
FAIL: test_EXT_SUFFIX_in_vars (test.test_sysconfig.TestSysConfig)
--
Traceback (most recent call last):
File
"/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_sysconfig.py",
line 368, in test_EXT_SUFFIX_in_vars
self.assertEqual(vars['EXT_SUFFIX'], _imp.extension_suffixes()[0])
AssertionError: '.so' != '.cpython-310d.so'
- .so
+ .cpython-310d.so
So somehow EXT_SUFFIX is being set to .so rather than .cpython-310d.so.
It seems the difference in EXT_SUFFIX comes from this stanza in configure:
case $ac_sys_system in
Linux*|GNU*|Darwin|VxWorks)
EXT_SUFFIX=.${SOABI}${SHLIB_SUFFIX};;
*)
EXT_SUFFIX=${SHLIB_SUFFIX};;
esac
where $ac_sys_system is `uname -s`. On FREEBSD, this is "FreeBSD", and I think
on AIX it is "AIX". My preference would be to always set EXT_SUFFIX to
${SOABI}${SHLIB_SUFFIX}, with no option for setting it to a different value.
Does that seem right?
--
components: Build
messages: 382767
nosy: mattip, vstinner
priority: normal
severity: normal
status: open
title: EXT_SUFFIX too short on FreeBSD and AIX
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42604>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42604] EXT_SUFFIX too short on FreeBSD and AIX
Change by mattip : -- keywords: +patch pull_requests: +22572 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23708 ___ Python tracker <https://bugs.python.org/issue42604> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big Sur
mattip added the comment: It seems the approach that "The code for sysconfig.get_config_var() has a pretty clear intent: it will try to cast its return value to an int." has been accepted as true even though other parts of the code assumed the returned value was a string, and the CPython code was updated appropriately. This is causing problems for downstream libraries like NumPy, see https://github.com/numpy/numpy/pull/17906. If CPython does not wish to reconsider this decision, it should at least be documented clearly via a type hint and/or in the documentation for sysconfig.get_config_var https://docs.python.org/3/library/sysconfig.html#sysconfig.get_config_var -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue42504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42604] EXT_SUFFIX too short on FreeBSD and AIX
mattip added the comment: vstinner: ping. Are merge builds still failing or can I close this? -- ___ Python tracker <https://bugs.python.org/issue42604> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42604] EXT_SUFFIX too short on FreeBSD and AIX
mattip added the comment: The linked PR 23708 is meant to fix the failures. Any chance you can take a look? -- ___ Python tracker <https://bugs.python.org/issue42604> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42151] Pure Python xml.etree.ElementTree is missing default attribute values
mattip added the comment: Is there an owner for the XML module that can make a decision? The PR has a test that shows this fix brings the python implementation into sync with the C implementation, which is, unintuitively, the "reference implementation". -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue42151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42752] multiprocessing Queue leaks a file descriptor associated with the pipe writer (#33081 still a problem)
mattip added the comment: Just to be clear, here is the code from the test (how do you format a code block here?) that demonstrates the writer is not closed when nothing is put into the queue ``` $ python3 Python 3.8.6 | packaged by conda-forge | (default, Oct 7 2020, 19:08:05) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import multiprocessing >>> q = multiprocessing.Queue() >>> q.close() >>> q.join_thread() >>> q._reader.closed True >>> q._writer.closed False >>> ``` And the changed behaviour to close the writer if the queue is used ``` >>> q = multiprocessing.Queue() >>> q.put(1) >>> q.get() 1 >>> q.close() >>> q.join_thread() >>> q._reader.closed True >>> q._writer.closed True ``` -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue42752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42752] multiprocessing Queue leaks a file descriptor associated with the pipe writer (#33081 still a problem)
mattip added the comment: In the expert index https://devguide.python.org/experts/ it lists @davin, @pitrou as referrents for multiprocessing. Adding then to the Nosy list -- ___ Python tracker <https://bugs.python.org/issue42752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42604] EXT_SUFFIX too short on FreeBSD and AIX
mattip added the comment:
I think this issue can only cause failed tests.
`sysconfig.get_config_var('EXT_SUFFIX')` is, as far as I can tell, not used
internally by any cpython build or import code.
--
___
Python tracker
<https://bugs.python.org/issue42604>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42752] multiprocessing Queue leaks a file descriptor associated with the pipe writer (#33081 still a problem)
Change by mattip : -- nosy: +davin, pitrou ___ Python tracker <https://bugs.python.org/issue42752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42151] Pure Python xml.etree.ElementTree is missing default attribute values
mattip added the comment: PyPy issue https://foss.heptapod.net/pypy/pypy/-/issues/3181 shows another problem with the pure-python ElementTree implementation, that again is not reflected in the C implementation. Is there a code owner for this stdlib module? -- ___ Python tracker <https://bugs.python.org/issue42151> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43307] Sync site.py and sysconfig.py with PyPy
New submission from mattip : PyPy added some enhancements to sysconfig.py to deal with multiple implementations. site.py copies parts of sysconfig.py to save time when importing. It would be nice to backport these enhamncements, maybe other implementations could reuse them. -- components: Installation messages: 387583 nosy: mattip priority: normal severity: normal status: open title: Sync site.py and sysconfig.py with PyPy versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue43307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43307] Sync site.py and sysconfig.py with PyPy
Change by mattip : -- keywords: +patch pull_requests: +23413 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24628 ___ Python tracker <https://bugs.python.org/issue43307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment
mattip added the comment: I wonder if the distro maintainers might be able to use this to reduce the patching they do for their schema? -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue43312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41324] Add a minimal decimal capsule API
mattip added the comment: Was expanding the C-API discussed on the mailing list or in any wider forum? It seems vstinner is working hard to reduce the public API exposure while this issue + PR makes it even larger. Please reconsider putting this in for 3.10. -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue41324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40747] sysconfig.get_config_var("py_version_nodot") should return 3_10
New submission from mattip :
Over in packaging, that code expects
`sysconfig.get_config_var("py_version_nodot")` to be consistent with
`tags._version_nodot`, which expects 3_10 for python 3.10. See
https://github.com/pypa/packaging/issues/308. The current value of
`sysconfig.get_config_var("py_version_nodot")` (which comes from
https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L89) is `310`
which is ambiguous.
--
components: Installation
messages: 369750
nosy: mattip
priority: normal
severity: normal
status: open
title: sysconfig.get_config_var("py_version_nodot") should return 3_10
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue40747>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40747] sysconfig.get_config_var("py_version_nodot") should return 3_10
Change by mattip : -- keywords: +patch pull_requests: +19601 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20333 ___ Python tracker <https://bugs.python.org/issue40747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39825] EXT_SUFFIX inconsistent between sysconfig and distutils.sysconfig (Windows)
Change by mattip : -- keywords: +patch nosy: +mattip nosy_count: 8.0 -> 9.0 pull_requests: +21174 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/22088 ___ Python tracker <https://bugs.python.org/issue39825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41100] Support macOS 11 and Apple Silicon Macs
mattip added the comment: Over at NumPy we are getting reports that some python built for macOSx 11 is not accepting wheels with the `macosx_10_9_x86_64` platform tag. Could it be related to this issue, another open issue, or some other provider's python? xref https://github.com/numpy/numpy/issues/17784 -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue41100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
New submission from mattip :
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.copysign(1., float('inf'))
1.0
>>> math.copysign(1., float('-inf'))
-1.0
>>> math.copysign(1., float('nan'))
-1.0
>>> math.copysign(1., float('-nan'))
1.0
>>>
--
components: None
messages: 157746
nosy: mattip
priority: normal
severity: normal
status: open
title: math.copysign(1., float('nan')) returns -1.
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue14521>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
mattip added the comment:
It appears that microsoft decided NAN will be represented by
'\x00\x00\x00\x00\x00\x00\xf8\xff', which has the sign bit set.
Compiling this c code with visual 9.0 gives the correct answers for the first
value, and a mess for the second:
#include
#include
#include
int main( void ) {
unsigned long nan[2]={0x, 0x7fff};
double g;
double z, zn;
int i;
for (i=0;i<2; i++)
{
g = *( double* )(nan+i);
printf( "g( %g ) is NaN, _isnan(g) %d\n", g, _isnan(g) );
z = _copysign(-3, g);
zn = _copysign(-3, -g);
printf("z=%g, zn=%g\n", z, zn);
}
return 0;
}
This corresponds with loewis 's observation.
--
___
Python tracker
<http://bugs.python.org/issue14521>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
mattip added the comment: Sorry for the garbage c code, the comment however is correct: Py_NAN is created with the sign bit set (on windows), and then _copysign on windows uses the sign bit to determine the output, which results in the wrong answer. -- ___ Python tracker <http://bugs.python.org/issue14521> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
mattip added the comment: I was going to add a test for this to Lib/test/test_math.py, but found this comment: # copysign(INF, NAN) may be INF or it may be NINF, since # we don't know whether the sign bit of NAN is set on any # given platform. I would try to claim this is fixable, by this patch: --- Include\pymath.h.orig Sun Apr 08 10:02:37 2012 +++ Include\pymath.hSun Apr 08 10:02:41 2012 @@ -150,7 +150,7 @@ * doesn't support NaNs. */ #if !defined(Py_NAN) && !defined(Py_NO_NAN) -#define Py_NAN (Py_HUGE_VAL * 0.) +#define Py_NAN abs(Py_HUGE_VAL * 0.) #endif /* Py_OVERFLOWED(X) Should I rework the tests to reflect this and submit a patch? -- ___ Python tracker <http://bugs.python.org/issue14521> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
mattip added the comment:
You are correct, the patch should use fabs
I would go with a standard, cross-platform definition of Py_NAN so that pickled
objects could be opened by other platforms. Would this patch be better? It's
more complicated as I needed to cast the repr of Py_NAN to a unsigned char[].
It passes the tests in test.test_math and handles the copysign in a more
intuitive way
>>> math.copysign(1., float('nan')) => 1. on win32, microsoft compiler
diff -r efeca6ff2751 Include/pymath.h
--- a/Include/pymath.h Thu Apr 05 22:51:00 2012 +0200
+++ b/Include/pymath.h Sun Apr 08 22:20:16 2012 +0300
@@ -152,8 +152,13 @@
* doesn't support NaNs.
*/
#if !defined(Py_NAN) && !defined(Py_NO_NAN)
+#if DBL_MANT_DIG == 53 /* ieee 754 doubles */
+extern double * _Py_NAN;
+#define Py_NAN (*_Py_NAN)
+#else
#define Py_NAN (Py_HUGE_VAL * 0.)
#endif
+#endif
/* Py_OVERFLOWED(X)
* Return 1 iff a libm function overflowed. Set errno to 0 before calling
diff -r efeca6ff2751 Modules/_math.c
--- a/Modules/_math.c Thu Apr 05 22:51:00 2012 +0200
+++ b/Modules/_math.c Sun Apr 08 22:20:16 2012 +0300
@@ -24,6 +24,10 @@
static const double two_pow_p28 = 268435456.0; /* 2**28 */
static const double zero = 0.0;
+#if DBL_MANT_DIG == 53 /* ieee 754 doubles */
+static const unsigned char _Py_NAN_as_char[8] = {0, 0, 0, 0, 0, 0, 0xf8, 0x7f};
+extern double * _Py_NAN = (double *)(_Py_NAN_as_char);
+#endif
/* acosh(x)
* Method :
* Based on
--
___
Python tracker
<http://bugs.python.org/issue14521>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
mattip added the comment: Your patch is much more reasonable than mine. Should I add a test that fails pre-patch and passes with the patch, or one that is skipped pre-patch and passes post-patch? I'm not sure what is accepted in the cpython development cycle -- ___ Python tracker <http://bugs.python.org/issue14521> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
mattip added the comment: I added tests to the mark.dickinson patch, test.test_math passes. -- Added file: http://bugs.python.org/file25165/math_patch2.txt ___ Python tracker <http://bugs.python.org/issue14521> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
mattip added the comment: I also submitted a form. Sorry about the patch name, still learning. -- ___ Python tracker <http://bugs.python.org/issue14521> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
mattip added the comment:
The pickle issue occurs in the numpy module, on windows
>> cPickle.dumps(numpy.array(float('nan')))
yeilds
"cnumpy.core.multiarray\n_reconstruct\np1\n(cnumpy\nndarray\np2\n(I0\ntS'b'\ntRp3\n(I1\n(tcnumpy\ndtype\np4\n(S'f8'\nI0\nI1\ntRp5\n(I3\nS'<'\nNNNI-1\nI-1\nI0\ntbI00\nS'\\x00\\x00\\x00\\x00\\x00\\x00\\xf8\\xff'\ntb."
While this is not a python core issue, it seems that python core could be one
possible solution point.
--
___
Python tracker
<http://bugs.python.org/issue14521>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14521] math.copysign(1., float('nan')) returns -1.
mattip added the comment:
The pickle output has the sign-bit set. Ignoring the sign-bit, it is unpickled
correctly. However math.copysign using this value will now return minus on
platforms where copysign(3., float('nan')) is known to work.
Perhaps the whole can of worms should not have been opened in the first place.
Another solution would be to raise a ValueError if copysign(x, float('nan')) is
called...
--
___
Python tracker
<http://bugs.python.org/issue14521>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35420] how to migrate a c-extension module to one that supports subinerpreters?
New submission from mattip : NumPy does not currently support subinterpreters, it has global state that is not cleaned up when releasing the module. I could not find a description of the steps I need to take to modernize the C-extension module to be able to used under a subinterpreter. It would be nice to describe this in the Python documentation, or does such documentation exist? -- assignee: docs@python components: Documentation messages: 331142 nosy: docs@python, eric.snow, mattip priority: normal severity: normal status: open title: how to migrate a c-extension module to one that supports subinerpreters? type: enhancement ___ Python tracker <https://bugs.python.org/issue35420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve
mattip added the comment:
> the original decision to exclude non 'C' views was deliberate
Seems this is reflected in the code:
```
a = np.array([[0, 1, 2], [3, 4, 5]])
mv = memoryview(a.T)
mv.f_contiguous
# True
mv.cast('i', (3, 2))
# TypeError: memoryview: casts are restricted to C-contiguous views
```
Is there any interest in revisiting that discussion? It seems the buffer
protocol could allow more flexibility wrt strides and contiguous flags. Do you
have a link to the discussion where this was rejected?
--
___
Python tracker
<https://bugs.python.org/issue34778>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35688] "pip install --user numpy" fails on Python from the Windos Store
New submission from mattip : After enabling Insider and installing Python3.7 from the Windows Store, I open a cmd window and do `pip install --user numpy` which runs to completion. But I cannot `import numpy`. The NumPy `mutiarray` c-extension module in the `numpy/core` directory depends on an `OpenBLAS` DLL that is installed into the `numpy/.libs` directory. But even after adding that directory to the `PATH` before running python (and checking with `depends.exe` that the `multiarray` c-extension module is now not missing any dependencies) I still cannot `import numpy`. See also NumPy issue https://github.com/numpy/numpy/issues/12667 -- components: Windows messages: 333262 nosy: brett.cannon, mattip, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: "pip install --user numpy" fails on Python from the Windos Store versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35688> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35688] "pip install --user numpy" fails on Python from the Windows Store
mattip added the comment: The difference in search order between apps from the app store and desktop applications may be relevant https://docs.microsoft.com/en-us/windows/desktop/Dlls/dynamic-link-library-search-order#alternate-search-order-for-windows-store-apps -- ___ Python tracker <https://bugs.python.org/issue35688> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35688] "pip install --user numpy" fails on Python from the Windows Store
mattip added the comment: It seems changing os.environ['PATH'] is a security risk and is not allowed for Windows Store apps. The suggestion in the NumPy issue is to: - use AddDllDirectory, (which is as accessable as os.environ['PATH'] but is not considered a security risk so far), but this requires using SetDefaultDllDirectories which breaks other things - put any dlls required for the c-extension pyd in the same directory which means scipy and numpy will be using duplicate and potentially different OpenBLAS dlls, and whoever imports first wins - load all the required dlls via LoadLibrary, meaning NumPy will have to export a windows-only API to SciPy so the latter can know where the DLL is. I am glad NumPy only has one DLL, and not a dozen like QT or wxPython. Is there a PEP that describes the overall design of windows directory layout or a design guide for package authors with best practices for additional dll dependencies? -- ___ Python tracker <https://bugs.python.org/issue35688> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35688] "pip install --user numpy" fails on Python from the Windows Store
mattip added the comment: Closing. It seems the days of modifying os.environ['PATH'] on windows are over, and packages need to adopt to calling AddDllDirectory. As long as python is built with ctypes, this is easy enough to adopt, even though there are some caveats. See the issue from anaconda https://github.com/ContinuumIO/anaconda-issues/issues/10628 -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35688> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35688] "pip install --user numpy" fails on Python from the Windows Store
mattip added the comment: @eryksun thanks for the details. I didn't realize assemblyBinding was supported by the generic runtime framework, the documentation https://docs.microsoft.com/en-us/dotnet/framework/deployment/how-the-runtime-locates-assemblies seems to suggest it is a dotnet feature. How can we confirm it is supported for older windows versions (XP) as well as app store installed apps? -- ___ Python tracker <https://bugs.python.org/issue35688> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35688] "pip install --user numpy" fails on Python from the Windows Store
mattip added the comment: I think the original problem we had with the AddDllDirectory approach was that once set, it seems to mitigate searching the os.environ['PATH'] for dll loading. Is that accurate? Would RemoveDllDirectory restore the ability to find DLLs along the system PATH? > This wouldn't solve the problem of DLL name and version conflicts, however Right, so far we are discussing the easier problem of adding search paths, not their order. This does become an issue for users who modify their system path in order to overcome the first problem, and end up pulling in the wrong version of a support DLL. -- ___ Python tracker <https://bugs.python.org/issue35688> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36085] Enable better DLL resolution
mattip added the comment: Clear documentation would go a long way toward onboarding package providers. Of course this does not solve the problem for packages with no active ongoing support for windows, and will annoy developers whose code base is full of `os.environ['PATH']` games. Perhaps the solution should come with a deprecation warning when setting `os.environ['PATH']`. It would be very helpful if failure to import a pyd (or for that matter to open a DLL with ctypes) due to missing support dlls could be easily debugged. Right now we get a message from windows that seems to suggest the file was not found. - Python could check if the file exists on disk and print a more helpful message - A debug hook to print the dll search path at the time of the failed LoadLibraryEx call, or perhaps adding it as an attribute of the Exception (this might be nice to have on Linux as well, even though there the Exception already includes the name of the missing *.so). Even better would be official python/Microsoft support for a CLI version of depends.exe like ldd on linux, but that seems much harder and is out of scope for this issue. -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue36085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36085] Enable better DLL resolution
mattip added the comment: > legitimately modify PATH for process launches Correct me if I'm wrong, don't process launches use the `env` kwarg for Popen, not the raw os.environ['PATH']? -- ___ Python tracker <https://bugs.python.org/issue36085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36085] Enable better DLL resolution
mattip added the comment: Correct me if I'm wrong, but once SetDefaultDllDirectories() is used, there is no going back: PATH no longer can change the search path no matter what flags are used with LoadLibrary* calls (see the recent Anaconda issue when they did this and broke NumPy). Assuming that is true, then > add sys._adddlldirectory() and sys._removedlldirectory() as CPython-specific > functions for extending the search path (for use by packages currently > modifying PATH at runtime) Why is this CPython-specific and "private"? It seems like * it should be a public interface, used by all implementations consistently, as a policy decision for the win32 platform and documented as such * located in os, much like os.environ (not critical) There should be some kind of debugging tool for when LoadLibraryEx fails, to indicate what might have gone wrong, perhaps os.getdlldirectory() would be helpful -- ___ Python tracker <https://bugs.python.org/issue36085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36085] Enable better DLL resolution
mattip added the comment: I have left a note for arigato, but why is CFFI different than ctypes or c-extension modules? All will need adjustment. -- ___ Python tracker <https://bugs.python.org/issue36085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36085] Enable better DLL resolution
mattip added the comment: @eryksun - is there a sample resource: blog post, code snippet, msdn documentation, that demonstrates how that all works? I personally find the MSDN documentation of "what happens when I call LoadLibraryEx" not very user friendly. They seem to be written to document the system calls and not to explain the user experience. A diagram with some examples of setting and debugging this would go a long way to helping users enter the right mindset to debug failures to load DLLs because the support dlls they depend on are not found -- ___ Python tracker <https://bugs.python.org/issue36085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34172] multiprocessing.Pool and ThreadPool leak resources after being deleted
mattip added the comment: It would be sufficient to modify the documentation to reflect the code. There are other objects like `file` that recommend[0] calling a method to release resources without depending on implementation-specific details like garbage collection. [0] https://docs.python.org/3/tutorial/inputoutput.html#reading-and-writing-files -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue34172> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve
mattip added the comment: This could be done via a `shape` kwarg to `cast` -- nosy: +mattip ___ Python tracker <https://bugs.python.org/issue34778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve
mattip added the comment: Sorry, I meant a "strides" keyword. "shape" is already a valid keyword -- ___ Python tracker <https://bugs.python.org/issue34778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15040] stdlib compatability with pypy: mailbox.py
New submission from mattip : These are changes necessary to mailbox.py and its tests so that tests pass (windows platform) on pypy 1.9.0. Files must be explicitly closed on pypy. I would like to submit these as a "compatability" issue type, but that category does not exist, so I used "behavior". This is the first in a series of a number of such patches, I think there will be about 20. -- components: Library (Lib) files: mailbox.patch keywords: patch messages: 162564 nosy: mattip priority: normal severity: normal status: open title: stdlib compatability with pypy: mailbox.py type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file25869/mailbox.patch ___ Python tracker <http://bugs.python.org/issue15040> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15040] stdlib compatability with pypy: mailbox.py
mattip added the comment: Revised patch: changes to mailbox.py were not needed for pypy. Someone did a good job with mailbox.py in stdlib 2.7.3 Now the patch only changes tests. The tests in 3.3 are very different, it seems to me there is little that can be reused there. -- Added file: http://bugs.python.org/file25937/mailbox.patch ___ Python tracker <http://bugs.python.org/issue15040> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15040] stdlib compatability with pypy: mailbox.py
mattip added the comment: What is the next stage in moving this forward? I am new here... -- ___ Python tracker <http://bugs.python.org/issue15040> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15996] pow() for complex numbers is rough around the edges
New submission from mattip:
complex(1., 0.) ** complex(float('inf'), 0.) raises a ZeroDivisionError. In
general, complex_power() needs to handle more corner cases. Barring a clear
standard for pow() in C99, the documentation for pow 3 in glibc
http://www.kernel.org/doc/man-pages/online/pages/man3/pow.3.html
seems solid for a start, however it only describes behaviour for float/double
values.
Where would be an appropriate place to add tests? I propose adding a test-case
file similar to cmath_testcases.txt (attached) and a test runner similar to
test_cmath.py
--
components: Interpreter Core
files: rcomplex_testcases2.txt
messages: 170856
nosy: mark.dickinson, mattip
priority: normal
severity: normal
status: open
title: pow() for complex numbers is rough around the edges
type: behavior
Added file: http://bugs.python.org/file27238/rcomplex_testcases2.txt
___
Python tracker
<http://bugs.python.org/issue15996>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20887] stdlib compatibility with pypy, test_zipfile.py
mattip added the comment: The test_zipfile in Python 3 is very different from this one, so I would prefer that it be two seperate issues. After your review of the patch, are there remaining issues that need to be cleared up? -- ___ Python tracker <http://bugs.python.org/issue20887> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20887] stdlib compatibility with pypy, test_zipfile.py
mattip added the comment: As far as I know, cpython3 dropped the assumption that garbage collection closes files, so python3's version of this test should already handle the issue, no? -- ___ Python tracker <http://bugs.python.org/issue20887> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21128] testing stdlib and compatibility with pypy
New submission from mattip: In continuation of issue 20887, this patch closes and removes all temp files created while running regression tests for stdlib 2.7.6 on win32 and pypy. Note that a gc.collect was required to release the closed files in test_argparse, as well as making them all rw. -- components: Tests files: patch messages: 215343 nosy: mattip priority: normal severity: normal status: open title: testing stdlib and compatibility with pypy type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file34698/patch ___ Python tracker <http://bugs.python.org/issue21128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21128] testing stdlib and compatibility with pypy
mattip added the comment: the gc.collect is not needed, sorry. I updated the patch, which affects test_argparse.py (make files rw before rmtree) test_file.py (add file.close() ) test_file2k.py (add file.close() ) test_httpservers.py (add file.close() ) -- Added file: http://bugs.python.org/file34716/patch ___ Python tracker <http://bugs.python.org/issue21128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21128] testing stdlib and compatibility with pypy
mattip added the comment: Correct, the other patches were against pypy, sorry. I now patched and tested against banch 2.7 on the python tree. -- Added file: http://bugs.python.org/file34720/patch ___ Python tracker <http://bugs.python.org/issue21128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10744] ctypes arrays have incorrect buffer information (PEP-3118)
mattip added the comment: Here are updated patches for 2.7 and HEAD. I've updated the patches for both python 2 and python 3 and addressed some of the issues here: 1. Added _ctypes_alloc_format_string_with_shape() to ctypes.h 2. Changed the buffer size calculation to 32 *ndim + 3 (for the question asked before, the 32 size is just because this was the size used before the patch) 3. Changed the sprintf to use the macro: sprintf(buf, "%"PY_FORMAT_SIZE_T"d,", shape[k]); I really hope this patch makes it to 2.7.7 and python 3 versions, as currently the situation is broken and code that once worked with older numpy versions does not work today (and we have legacy code that stopped working). -- nosy: +mattip versions: +Python 2.7 Added file: http://bugs.python.org/file35217/hg-python2.7-ctypes-fix-pep3118-format-strings-for-arrays-updated.patch ___ Python tracker <http://bugs.python.org/issue10744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10744] ctypes arrays have incorrect buffer information (PEP-3118)
mattip added the comment: Here is the patch for HEAD -- Added file: http://bugs.python.org/file35218/hg-default-ctypes-fix-pep3118-format-strings-for-arrays-update.patch ___ Python tracker <http://bugs.python.org/issue10744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10744] ctypes arrays have incorrect buffer information (PEP-3118)
mattip added the comment: Updated patch for default for empty shape, thanks eryksun -- Added file: http://bugs.python.org/file35224/hg-default-ctypes-fix-pep3118-format-strings-for-arrays-update.patch ___ Python tracker <http://bugs.python.org/issue10744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9266] ctypes "ValueError: NULL pointer access" on Win7 x64
mattip added the comment: This was fixed with changeset 8fa73a0885c9 in Jan 2011, probably should be closed -- nosy: +mattip ___ Python tracker <http://bugs.python.org/issue9266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
mattip added the comment: Here is a fix for arguments and return values, based on the support in cffi, for python2.7 I added a test in test_win32, removed the too-early attempt to fix in callproc.c, and merged in most of the changes in lib_msvc from cffi's code base. These changes handle the following (in addition to callproc change): - fix rtype handling by converting a return-by-value struct to a pointer-sized int - fix stack byte-size calculation by checking for large pass-by-value structs, incrementing bytes by sizeof(void*) in this case - fix avalue copying by checking for large pass-by-value structs and copying the pointer not the value - fix bogus check for stack buffer < 40 bytes A similar patch for 3.4 will be posted soon. Other related issues: http://bugs.python.org/issue11835 -- keywords: +patch nosy: +mattip Added file: http://bugs.python.org/file35248/issue_20160_python2_7.patch ___ Python tracker <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
mattip added the comment: and here is the promised patch for tip -- Added file: http://bugs.python.org/file35249/issue_20160_tip.patch ___ Python tracker <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21610] load_module not closing opened files
New submission from mattip: imputil and modulefinder are opening files but not actively closing them. This causes problems for pypy and is not clean. -- components: Library (Lib) files: close_fp_2.7.patch keywords: patch messages: 219367 nosy: mattip priority: normal severity: normal status: open title: load_module not closing opened files type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file35405/close_fp_2.7.patch ___ Python tracker <http://bugs.python.org/issue21610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21610] load_module not closing opened files
mattip added the comment: the issue has already been fixed on HEAD but not backported to 2.7 -- ___ Python tracker <http://bugs.python.org/issue21610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22308] add {implementation} to sysconfig.py
New submission from mattip:
An issue was reported on PyPy where a user had a
~/.local/lib/python2.7/site-packages directory that contained cpython specific
libraries. We trakced it down to posix_user in sysconfig.py being set to an
implementation-specific cpython path, but used by pypy.
This patch against HEAD adds {implementation} and {implementation_lower}
fields to _CONFIG_VARS, making sysconfig.py compatable with other python
implementations. Perhaps valuable to jython as well, which would require
modifying _get_implementation() accordingly
--
components: Library (Lib)
files: sysconfig_head.patch
keywords: patch
messages: 226143
nosy: mattip
priority: normal
severity: normal
status: open
title: add {implementation} to sysconfig.py
type: behavior
Added file: http://bugs.python.org/file36507/sysconfig_head.patch
___
Python tracker
<http://bugs.python.org/issue22308>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22308] add {implementation} to sysconfig.py
mattip added the comment: adding a diff patch to 2.7 -- Added file: http://bugs.python.org/file36508/sysconfig_2_7.patch ___ Python tracker <http://bugs.python.org/issue22308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20887] stdlib compatibility with pypy, test_zipfile.py
New submission from mattip: Files must be explicitly closed on pypy, and switch to use test_support.rmtree which tries harder on Windows. only test_zipfile.py is patched. -- components: Tests files: zipfile_patch messages: 213086 nosy: mattip priority: normal severity: normal status: open title: stdlib compatibility with pypy, test_zipfile.py type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file34343/zipfile_patch ___ Python tracker <http://bugs.python.org/issue20887> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
mattip added the comment: it seems the problem is that the bundled libffi version in Modules/_ctypes/libffi needs updating. The fix for aarch64 is a simple one-liner (tested on 2.7 in a aarch64 vm), for both HEAD and 2.7 (attached), but perhaps a better fix would be to update the bundled libffi? -- Added file: http://bugs.python.org/file37716/libffi.patch ___ Python tracker <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11835] python (x64) ctypes incorrectly pass structures parameter
mattip added the comment: This is a duplicate of issue 20160, and has been fixed. Can someone mark it as a duplicate and close it? -- nosy: +mattip ___ Python tracker <http://bugs.python.org/issue11835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23414] seek(count, whence) accepts bogus whence on windows, python2.7
New submission from mattip:
f=open('abc.txt', 'w+')
f.seek(0, 42)
does not raise an exception on windows, python2.7
--
components: Windows
messages: 235568
nosy: mattip, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: seek(count, whence) accepts bogus whence on windows, python2.7
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue23414>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24952] stack_size([size]) is actually stack_size(size=0)
New submission from mattip: when using thread.stack_size or threading.stack_size, if no argument is provided the stack size is reset to default. Trivial patch for 3.5 provided -- assignee: docs@python components: Documentation files: stack_size.patch keywords: patch messages: 249280 nosy: docs@python, mattip priority: normal severity: normal status: open title: stack_size([size]) is actually stack_size(size=0) type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file40281/stack_size.patch ___ Python tracker <http://bugs.python.org/issue24952> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24952] stack_size([size]) is actually stack_size(size=0)
mattip added the comment: Add a patch for 2.7 -- versions: +Python 2.7 -Python 3.5 Added file: http://bugs.python.org/file40282/stack_size2.7.patch ___ Python tracker <http://bugs.python.org/issue24952> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24952] stack_size([size]) is actually stack_size(size=0)
mattip added the comment: Add the default value 0 to the documentation, please review this patch and not the previous one -- versions: -Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40304/stack_size.patch ___ Python tracker <http://bugs.python.org/issue24952> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24952] stack_size([size]) is actually stack_size(size=0)
mattip added the comment: Add default value of 0 to documentation for 2.7 -- versions: +Python 3.5 -Python 2.7 Added file: http://bugs.python.org/file40305/stack_size2.7.patch ___ Python tracker <http://bugs.python.org/issue24952> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21610] load_module not closing opened files
mattip added the comment: ping -- ___ Python tracker <http://bugs.python.org/issue21610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22308] add {implementation} to sysconfig.py
mattip added the comment: any traction on this? -- ___ Python tracker <http://bugs.python.org/issue22308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23634] os.fdopen reopening a read-only fd on windows
New submission from mattip: If I have a read-only fd, and I try to open it as 'w' with os.fdopen(fd, 'w'), the operation raises on linux but succeeds on windows. Python relies on the underlying clib's fdopen to return an error, which glibc does, but MSVC happily closes the original fd and returns with no error. Would a patch to fix this be welcomed? A test demonstrating the issue is attached. The fix would be to check that the mode requested matches the mode of the argument fd. Related issues #22259 and #21191 did not consider this case -- components: Windows files: test_openfd.py messages: 237818 nosy: mattip, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: os.fdopen reopening a read-only fd on windows Added file: http://bugs.python.org/file38430/test_openfd.py ___ Python tracker <http://bugs.python.org/issue23634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
mattip added the comment: "Bob" is relating to a dead issue, the email was from 2012 and this issue was fixed in Nov 2014. His fix is wrong and unnecessary, which he would have discovered had he run the tests that were added with that patch. This issue was only left open in order to allow someone to resync libffi with the upstream version In the mean time this is the second time someone has mistakenly related to this issue, so could someone with super powers please close the issue. If needed (a failing test would be nice) then we could open a new issue for "sync libffi with upstream" -- ___ Python tracker <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs)
mattip added the comment: This is the workflow for developing a patch for python https://docs.python.org/devguide This is the workflow for adding a patch to an issue https://docs.python.org/devguide/patch.html If there is an issue with python, please demonstrate it in a way that we can follow, and when you submit a patch please upload it in a way that we can see what version of the original file you are changing. libffi is a library used in python to allow foreign function interfaces in python. It lives here https://github.com/atgreen/libffi The code from libffi was imported into python at version 3.1, (Modules/_ctypes/libffi) but since the official compiler used for windows is msvc, a forked version of libffi, called libffi_msvc lives in parallel to the official libffi in the python source tree. Clang should be using the libffi code or a libffi provided with clang, not the libffi_msvc version since it is specific for msvc. If the libffi inside python is faulty, someone should create an issue to import a newer version from the "upstream" source at https://github.com/atgreen/libffi In addition, you reference an email from 2012, but now relate to an issue with python 2.7.9 which was released much after that date. What is the problem you see, how does it manifest itself? You should create a separate issue for that behaviour This issue here was specifically for using libffi with the microsoft compiler to support ctypes, and was fixed for the 2.7.9 release. A test was added in the general ctypes test directory to make sure small and large structures are correctly handled in ctypes. While the test is in a file named win32, the test is run on all platforms, thus exposing a problem with aarch64 on redhat systems in Jan 2015. Their issue was that the libffi in python, and the one used on their platform, had an issue with aarch64. But the upstream libffi does support aarch64, so again, this issue is not the place to report that failure. In summary, f there is a problem using clang with libffi, perhaps open a new issue that clearly shows how clang+libffi+python fail to do something, it may be enough to simply not use the msvc version of libffi -- ___ Python tracker <http://bugs.python.org/issue20160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
