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/i
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 ch
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/is
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/issu
mattip added the comment:
"complex" is also missing a fast path
--
___
Python tracker
<https://bugs.python.org/issue46131>
___
___
Python-bugs-l
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
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
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
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
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
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
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/issue42
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
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/issue43
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/issu
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
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
Change by mattip :
--
nosy: +davin, pitrou
___
Python tracker
<https://bugs.python.org/issue42752>
___
___
Python-bugs-list mailing list
Unsubscribe:
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://bu
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/issue42
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
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".
--
nos
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/issue42
mattip added the comment:
vstinner: ping. Are merge builds still failing or can I close this?
--
___
Python tracker
<https://bugs.python.org/issue42604>
___
___
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 t
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/issu
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
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/issue39
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 -&
mattip added the comment:
the PR is awaiting approval/merge
--
___
Python tracker
<https://bugs.python.org/issue39825>
___
___
Python-bugs-list mailin
mattip added the comment:
No, my bad, B6 passes now on CPython
--
___
Python tracker
<https://bugs.python.org/issue28884>
___
___
Python-bugs-list mailin
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/issue28
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/
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/i
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/issu
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_
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/issue32
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
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
&
mattip added the comment:
Is automatic download really the best solution?
--
___
Python tracker
<https://bugs.python.org/issue37967>
___
___
Python-bugs-list m
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
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
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/issue36
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
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://
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']` game
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 s
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 d
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
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 ri
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
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
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: ca
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
mattip added the comment:
Sorry, I meant a "strides" keyword. "shape" is already a valid keyword
--
___
Python tracker
<https://bug
mattip added the comment:
This could be done via a `shape` kwarg to `cast`
--
nosy: +mattip
___
Python tracker
<https://bugs.python.org/issue34778>
___
___
Pytho
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
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/issue24
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
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/issue24
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
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
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 orde
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
c
mattip added the comment:
any traction on this?
--
___
Python tracker
<http://bugs.python.org/issue22308>
___
___
Python-bugs-list mailing list
Unsubscribe:
mattip added the comment:
ping
--
___
Python tracker
<http://bugs.python.org/issue21610>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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(co
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/issue11
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
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/issue22
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
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>
___
___
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
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/issue20
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 handl
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/issue9
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.
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/issue10
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 (fo
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/issue21
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
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
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/is
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
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
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/on
mattip added the comment:
What is the next stage in moving this forward? I am new here...
--
___
Python tracker
<http://bugs.python.org/issue15040>
___
___
Pytho
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
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,
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
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'\
mattip added the comment:
I also submitted a form. Sorry about the patch name, still learning.
--
___
Python tracker
<http://bugs.python.org/issue14521>
___
___
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/issue14
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
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
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
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
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
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., f
99 matches
Mail list logo
