[issue17446] doctest test finder doesnt find line numbers of properties

Michael Cuthbert added the comment: Here's a rather obscure bug that I was able to catch before we put this into action: doctests inside the __doc__ for namedtuples (and perhaps all namedtuples?) are instances of property, have .fget, but do not have .fget.__code__. Thus one more che

[issue26739] Errno 10035 a non-blocking socket operation could not be completed immediately

New submission from MICHAEL JACOBSON: So far I've got past the "bug in program" stage of debugging, but this came up: IDLE internal error in runcode() Traceback (most recent call last): File "C:\Python27\lib\idlelib\rpc.py", line 235, in asyncqueue self.putmessage(

[issue26739] Errno 10035 a non-blocking socket operation could not be completed immediately

Changes by MICHAEL JACOBSON <922...@isd624.org>: -- nosy: -MICHAEL JACOBSON, paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <http://bugs.python.org/i

[issue26739] idle: Errno 10035 a non-blocking socket operation could not be completed immediately

MICHAEL JACOBSON added the comment: 0. I have Python 2.7.5 1. I don't know what you mean. 2. It fails right when I run it. IDLE stands for Python's Integrated DeveLopment Environment I am running IDLE / Python on a Windows Vista, Serv

[issue26739] idle: Errno 10035 a non-blocking socket operation could not be completed immediately

MICHAEL JACOBSON added the comment: Is the command prompt itself admin? I don't have access to the admin command prompt. -- ___ Python tracker <http://bugs.python.org/is

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: These are very different issues. However, this patch may resolve both! ldconfig (-p if I recall) lists where (shared) libraries have been installed (imho, this is a GNU tool approach) - whereas AIX would use dump -H to find library paths embedded in a program

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: I have not looked specifically, at least not that I remember, for differences in util/ctypes in python2 and python3. Will do so tomorrow. I did just look briefly at the library, rather archive, built by default as libpython2.7.a - it is static members only, i.e

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: On 4/28/2016 11:56 PM, Michael Felt wrote: > Michael Felt added the comment: > > I have not looked specifically, at least not that I remember, for differences > in util/ctypes in python2 and python3. Will do so tomorrow. > > I did just look brie

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: Question - before I submit a patch. A. Is there a PEP I should read re: ctypes/util and/or ctypes/cdll? B. I show two different behaviors of responding - My question is, what does the community think should be the response? My preference is to bring the request

[issue26904] Difflib quick_ratio() could use Counter()

New submission from Michael Cuthbert: The implementation used in difflib.SequenceMatcher().quick_ratio() counts how often each member of the sequence (character, list entry, etc.) appears in order to calculate its lower bound. Counting how often an entry appears in an iterable has been sped

[issue26904] Difflib quick_ratio() could use Counter()

Michael Cuthbert added the comment: @wolma -- you're right, that the inplace __iand__ version of Counter is substantially faster -- it is still slower than the current code (since it is still basically a superset of it). However, testing shows that it is close enough to the current co

[issue26904] Difflib quick_ratio() could use Counter()

Michael Cuthbert added the comment: Here are the results I obtained along with the test code I used to get the results. The test code also has a "hybrid" code which I did not propose, but maybe I should have, which uses the old code for very short (but not degenerate) tests and th

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: reworked patch. To assist port to Python3 that changes in __init__.py and util.py are minimal. There is a new file: aixutil.py I have only tested on Python-2.7, so there may be issues for Python3. My goal is to have a single file for both versions. The main

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: implements ctypes.aixutil.find_library() In a separate file as both __init__.py as util.py needs it's logic. -- Added file: http://bugs.python.org/file42713/aixutil.py ___ Python tracker <http://bugs.py

[issue23228] Crashes when tarfile contains a symlink and unpack directory contain it too

Michael Vogt added the comment: Anything I can do to help moving this issue forward? -- ___ Python tracker <http://bugs.python.org/issue23228> ___ ___ Python-bug

[issue26967] argparse: allow_abbrev=False stops -vv from working

New submission from Michael Kruse: #! /usr/bin/env python3 import argparse parser = argparse.ArgumentParser(allow_abbrev=True) parser.add_argument('-v', '--verbose', action='count') print(parser.parse_args(['-vv'])) parser = argparse.ArgumentParser(all

[issue26967] argparse: allow_abbrev=False stops -vv from working

Michael Kruse added the comment: I think the allow_abbrev option should be orthogonal on how short options are parsed. I am using parse_known_args() to forward the unrecognized args to another program, therefore allow_abbrev=False is essential. There is a special handling for short options in

[issue11063] uuid.py module import has heavy side effects

Michael Felt added the comment: I cannot comment on uuid directly, but for me, this is yet another example of how assumptions can break things. imho - if you know the exact version of s shared library that you want, calling cdll directly should be find. Maybe find_library is historic

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: New patch of the Lib/ctypes directory - BUT - this time as a delta based on 3.5.0. ++ changes from last patch ++ * OSError gets raised (as expected) by test/test_loading.py * test in util.py modified (libm is replaced by libc when "aix"), and added an

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: New version of aixutil.py ++ Changes ++ * more comments * re-worked the 'searches' for matches after adding changing the way the output from _get_dumpH was read (now to an array using readlines). Also, p.stdout.close() and p.wait() are done within the

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: Spent more time today, testing - on 3.5.1, 3.4.4 and 2.7.11. The patches would not apply on both Python2 and Python3, but the new file Lib/ctypes/aixutil.py is identical on all three versions. History of patching (starting from version 3.5.1(.1) is my patched

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Changes by Michael Felt : Added file: http://bugs.python.org/file42802/Python2.Lib.ctypes.160510.patch ___ Python tracker <http://bugs.python.org/issue26439> ___ ___ Pytho

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Changes by Michael Felt : Added file: http://bugs.python.org/file42803/Python2.Modules._ctypes.160510.patch ___ Python tracker <http://bugs.python.org/issue26

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Changes by Michael Felt : Added file: http://bugs.python.org/file42804/Python3.Lib.ctypes.160510.patch ___ Python tracker <http://bugs.python.org/issue26439> ___ ___ Pytho

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Changes by Michael Felt : Added file: http://bugs.python.org/file42805/Python3.Modules._ctypes.160510.patch ___ Python tracker <http://bugs.python.org/issue26

[issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux

Michael Felt added the comment: In https://bugs.python.org/issue26439 I have been working on this for AIX - as the default behavior was to depend on two things: a) ldconfig -p (which generally does not exist on AIX, and I doubt it will know about the non-gnu libraries b) that the objects are

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: a) https://bugs.python.org/review/26439/#msg12, but getting HTML 500 error) The call to find_library here is for "ease of use" with existing code who use, e.g., cdll("libcrypto.so"). This format fails unless someone has previously done, e.

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: re: AIX: CDLL("libcrypto.a(libcrypto.so.1.0.0)", DEFAULT_MODE | RTLD_MEMBER) Officially it would be dlopen("libcrypto.a(libcrypto.so.1.0.0)", RTLD_NOW | RTLD_MEMBER) Further, that would only load the 32-bit version, as there is a legacy na

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: used diff -rNu Python-3.5.1 Python-3.5.1.1 to generate -- Added file: http://bugs.python.org/file42811/Python3.issue26439.160511.patch ___ Python tracker <http://bugs.python.org/issue26

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: used diff -rNu Python-2.7.11 Python-2.7.11.4 to generate Note: content same as those from yesterday - except Lib/ctype/test/test_loading.py is no longer changed. No longer needed. -- Added file: http://bugs.python.org/file42812/Python2.issue26439.160511

[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

Michael Foord added the comment: I agree with David, I don't like the name but it is at least accurate (if you already understand what it does). assertItemsEqual was better but misleading. In the absence of a *dramatically* better name leave it

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: A bug was found, and has been corrected - but I am unclear on how to best submit the differences. Editing the current "review" code is not a good idea, as there are many differences. Please recommend correct course of action. p.s. I will have also r

[issue23469] Delete Misc/*.wpr files

Michael Foord added the comment: What is the advantage to deleting the Wing IDE project files, other than making it harder to use Wing to work on Python? -- ___ Python tracker <http://bugs.python.org/issue23

[issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python

Michael Clerx added the comment: Is there anyway to fix this without using setuptools? I'm using distutils to compile on the fly which has worked brilliantly for the last few years, not sure I want to destabilize everything by switching to setuptools. -- nosy: +Michael

[issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python

Michael Clerx added the comment: Thanks! However, importing setuptools causes a string of errors about PYTHONPATH and .pth files (even on a linux system) In addition, a monkeypatched version of find_vcvarsall allowed things to run, but it seems finding plain C libraries with Visual C++ for

[issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python

Michael Clerx added the comment: @Mark I don't quite understand what you're saying. Distutils supports it, provided you add a line to distutils.cfg. I've been using the PythonXY versions of Python with MinGW (everything before 2.7.9.0) to happily compile for nearly 4 years

[issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python

Michael Clerx added the comment: Thanks! If I do copy this patch, do I need to add anything to my license text other than a reference in the file itself? -- ___ Python tracker <http://bugs.python.org/issue23

[issue23187] Segmentation fault, possibly asyncio related

Michael Goldish added the comment: I'm not sure where to post this as the issue is closed: I've encountered the same problem. I don't have a stack trace to share at the moment but I know it's almost (or entirely) identical. My context: - Windows - Happens with Python

[issue23643] Segmentation Fault with Large Simple Function

Changes by Michael Klein : -- type: -> crash ___ Python tracker <http://bugs.python.org/issue23643> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue23643] Segmentation Fault with Large Simple Function

Michael Klein added the comment: I found a simpler one, like Amaury's eval("+1" * 748580): def f(x): y = x+x+x+x+x return y print f(0) (Except there are 74875 x+'s. This is exactly enough for a segfault, one less runs fine.) I've tried something like:

[issue23643] Segmentation Fault with Large Simple Function

New submission from Michael Klein: I have gotten "Segmentation Fault: 11" with the newest version of Python 2.7 and nothing but standard functions. The program is of the following form (attached to this email): def loopcountaux(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13,

[issue23643] Segmentation Fault with Large Simple Function

Changes by Michael Klein : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue23643> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue23187] Segmentation fault, possibly asyncio related

Michael Goldish added the comment: > Why do you consider that it's the same issue? Because it's a very similar stack trace, the crash itself is in subtype_dealloc(), it happens once every few days, asyncio is involved, and the issue is relatively new - I couldn't find anoth

[issue12641] Remove -mno-cygwin from distutils

Michael Clerx added the comment: I'm seeing this bug in 2.7.9. The reason seems to be that the version detection doesn't work... This snippet: out = os.popen(gcc_exe + ' -dumpversion', 'r') out_string = out.read() returns an empty out_string, causing gcc_v

[issue23187] Segmentation fault, possibly asyncio related

Michael Goldish added the comment: I don't see a reason to assume the machine was running out of memory. After each crash the process was kept alive by one of those Windows crash dialogs - "the process terminated unexpectedly" or similar. I could see exactly how much memory

[issue23187] Segmentation fault, possibly asyncio related

Michael Goldish added the comment: I caught another crash just now, this time in update_refs(). A stack trace is attached below. I still think this is the same issue. static void update_refs(PyGC_Head *containers) { PyGC_Head *gc = containers->gc.gc_next; 67382D60 mov

[issue23187] Segmentation fault, possibly asyncio related

Michael Goldish added the comment: > That's nearly 4 GB. I somehow doubt your app is actually trying to allocate > that much memory There's no reason for the app to allocate that much memory in a single call. It's using almost 4 GB of memory in total today, but that

[issue23187] Segmentation fault, possibly asyncio related

Michael Goldish added the comment: > It looks like you are running your app on Windows. Are you using the proactor > event loop? Yes. > In Python 3.4.3, I fixed a *lot* of crashes and race conditions in the > proactor event loop. There are maybe more race conditions. I'

[issue23187] Segmentation fault, possibly asyncio related

Michael Goldish added the comment: OK, I caught the crash with a debug build of Python 3.4.3. I have a core dump and even the process itself still alive in memory. I can provide any information you need. I can also explain how to debug a core dump with Visual Studio, if necessary. This time

[issue23187] Segmentation fault, possibly asyncio related

Michael Goldish added the comment: > Sorry, you're wrong: the proactor event loop heavily uses the _overlapped > module which is implemented in C. A crash in the garbage collector is more > likely a bug in asyncio/your application, than a bug in Python itself. I'm aware of

[issue15836] unittest assertRaises should verify excClass is actually a BaseException class

Michael Foord added the comment: I like the first variant suggested by Ezio as more concise. I'll try and look at the substance of the patch today. -- ___ Python tracker <http://bugs.python.org/is

[issue15836] unittest assertRaises should verify excClass is actually a BaseException class

Michael Foord added the comment: The change to unittest is fine. I'd prefer the tests tweaking as Ezio suggested. -- ___ Python tracker <http://bugs.python.org/is

[issue20718] OpenBSD/AIX: tests passing a file descriptor with sendmsg/recvmsg failures

Changes by Michael Schurter : -- nosy: -schmichael ___ Python tracker <http://bugs.python.org/issue20718> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue19907] gettext - Non ascii chars in header

Michael McFadden added the comment: I'm having no luck reproducing this issue. Regarding pygettext.py generating .po files: I've used the messages.po file provided by the OP, and also using a generated .po file from pygettext.py with the offending header PO-Revision-Date: As a side

[issue20669] OpenBSD: socket.recvmsg tests fail with OSError: [Errno 40] Message too long

Changes by Michael Schurter : -- nosy: -schmichael ___ Python tracker <http://bugs.python.org/issue20669> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Michael McFadden added the comment: I have a patch for moving script_helper as R. David suggested. Here it is. -- nosy: +flipmcf Added file: http://bugs.python.org/file39003/iss9517_move_script_helpers_py.patch ___ Python tracker <h

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Michael McFadden added the comment: bobcatfish: Sorry, I didn't refresh and see your comment before submitting my patch. It only moves script_helpers, but doesn't address the original OP. Hopefully I made your life easier,

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Michael McFadden added the comment: re: test.test_tools.py - should this also move into test.support ? -- ___ Python tracker <http://bugs.python.org/issue9

[issue18128] pygettext: non-standard timestamp format in POT-Creation-Date

Michael McFadden added the comment: I'm going to be adding some tests around pygettext tool and then tackling this. -- nosy: +flipmcf ___ Python tracker <http://bugs.python.org/is

[issue18128] pygettext: non-standard timestamp format in POT-Creation-Date

Michael McFadden added the comment: Patch File iss18128.patch adds test_i18n to start testing the entire Tools/i18n package, and has a very simple fix. -- keywords: +patch Added file: http://bugs.python.org/file39024/iss18128.patch ___ Python

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Michael McFadden added the comment: Yes, I did miss that. (Root cause: `git diff` instead of `git diff --staging`) Sorry. I'm learning, and decided to take the git path - might not have been the best choice. I'll submit a new pat

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Michael McFadden added the comment: > I'm thinking also, maybe instead of putting script_helper into the > test.support namespace, we could move the individual methods and > helpers from script_helper into test.support, e.g.: > > test.support.run_p

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Michael McFadden added the comment: Uploading new patch that includes the creation of Lib/test/support/script_helper.py -- Added file: http://bugs.python.org/file39038/iss9517_move_script_helpers_py.patch ___ Python tracker <http://bugs.python.

[issue19907] gettext - Non ascii chars in header

Michael McFadden added the comment: issue18128 is not related methinks. This ticket: POT-Creation-Date issue18128: PO-Revision-Date -- ___ Python tracker <http://bugs.python.org/issue19

[issue19907] gettext - Non ascii chars in header

Michael McFadden added the comment: This might be fixed by issue17156, which would explain why I can't recreate it. https://github.com/python/cpython/commit/f4273cfd16fa502f0eb8a0a8fd1c537ec63e47db -- ___ Python tracker <http://bugs.py

[issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.

Michael McFadden added the comment: Also fixes 19907? -- nosy: +flipmcf ___ Python tracker <http://bugs.python.org/issue17156> ___ ___ Python-bugs-list mailin

[issue18128] pygettext: non-standard timestamp format in POT-Creation-Date

Michael McFadden added the comment: Post-review - new patch -- Added file: http://bugs.python.org/file39050/issue18128.patch ___ Python tracker <http://bugs.python.org/issue18

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Michael McFadden added the comment: namespaces are a honkin' great idea I don't have enough information to say that 'script_helper' is the right name for the namespace, tho. -- ___ Python tracker <http://bu

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Michael McFadden added the comment: @Christie - Nope. This patch can stand on it's own, simply moving the package to where it belongs. In fact, I'd recommend applying the patch first. -- ___ Python tracker <http://bugs.python.

[issue24113] shlex constructor unreachable code

New submission from Michael Smith: In its __init__ method, shlex.shlex sets self.debug = 0. An `if self.debug:` statement follows shortly thereafter and without allowing the user to change self.debug. The code inside the if statement is unreachable. Users should either be permitted to set

[issue24113] shlex constructor unreachable code

Michael Smith added the comment: Hat tip abarnert on StackOverflow for digging in. http://stackoverflow.com/questions/29996208/putting-shlex-in-debug-mode This code was introduced in https://hg.python.org/cpython/rev/81a121d21340 -- ___ Python

[issue24141] Python 3 ships an outdated valgrind suppresison file.

New submission from Michael Ensslin: The suppression file that is shipped in Misc/valgrind-python.supp of the CPython 3(.x) source tarball only works with CPython 2. This was tested on Debian Sid, with Python 3.4.3 and Python 2.7.9, both presumably not compiled with "--valgrind&quo

[issue24141] Python 3 ships an outdated valgrind suppressison file.

Changes by Michael Ensslin : -- title: Python 3 ships an outdated valgrind suppresison file. -> Python 3 ships an outdated valgrind suppressison file. ___ Python tracker <http://bugs.python.org/issu

[issue24141] Python 3 ships an outdated valgrind suppressison file.

Michael Ensslin added the comment: Note: Additionally replacing PyObject_Free -> _PyObject_Free and PyObject_Realloc -> _PyObject_Realloc appears to fix the issue. -- ___ Python tracker <http://bugs.python.org/i

[issue27376] Add mock_import method to mock module

Changes by Michael Foord : -- assignee: -> michael.foord ___ Python tracker <http://bugs.python.org/issue27376> ___ ___ Python-bugs-list mailing list Un

[issue27376] Add mock_import method to mock module

Michael Foord added the comment: Is this for mocking out runtime dependencies that aren't available at test time? It seems like a good way of masking bugs! I'd be happier with a (or at least an option) to specify the imports that should be mocked. The use case should be mentioned i

[issue27376] Add mock_import method to mock module

Michael Foord added the comment: It's not a use case I've specifically had but I can see its use. I'm uncertain of whether that means it belongs in the module or not. Let me see if I can get some more eyes on this bug. -- ___ Python

[issue27376] Add mock_import method to mock module

Michael Foord added the comment: Before you spend any more time on this, my current thinking is that this is a bit too specialised to belong in the standard library. I'll wait and see if a preponderance of core devs and other users disagree with me before I close this t

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: On 04/09/2016 06:11, Martin Panter wrote: > I do not know whether to fix the annotation (has 64 preceded by any number of > underscores), or whether to fix the regular expression (_?64). The later - _?64. Working on this today. Thank you for the corr

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: Not always as elegant as I would wish (do not like the idea of "while 1:" and later a break... But, all in all, much improved by redoing the processing of the subprocess output and getting rid of more noise. Hope this meets your approval! p.s. This

[issue27905] Add documentation for typing.Type

Michael Lee added the comment: Ok, here's version 2, taking into account Ivan's feedback! -- Added file: http://bugs.python.org/file44401/document-type-v2.patch ___ Python tracker <http://bugs.python.o

[issue21826] Performance issue (+fix) AIX ctypes.util with no /sbin/ldconfig present

Michael Felt added the comment: re: issue 26439 and issue 27435 would like to show: without patch, find_library() is consistently slow, and in default situations, returns nothing. root@x064:[/data/prj/aixtools/python/python-2.7.10]./python -m timeit -n 100 'import ctypes

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

New submission from Michael Felt: Short version: the five routines get_node() calls to get the MAC address either fail by definition, or is wrong. The one routine that works - is wrong because it returns the same value regardless of the system it runs on - wrong character is used to identify

[issue28049] Add documentation for typing.Awaitable and friends

New submission from Michael Lee: This patch adds documentation for Awaitable, AsyncIterable, and AsyncIterator to the typing module, mostly linking to the corresponding class in collections.abc. It also briefly clarifies the documentation on generators to explain that you may use either

[issue28073] Update documentation about None vs type(None) in typing

New submission from Michael Lee: For some reason, the section of the typing docs about Optional stated that Optional[T] was equivalent to Union[T, type(None)]. While this is true, it's somewhat inconsistent and potentially confusing since everywhere else in the docs, we just use None.

[issue5396] os.read not handling O_DIRECT flag

Michael Mol added the comment: I need to remember not to try to write quick programs in Python that need O_DIRECT. My use case: I'm attempting to write a program that forces the disk to seek to a particular place, as part of burning in the disk. My algorithm goes: 1. Seek to the begi

[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist

New submission from Michael Felt: in Lib/ctypes/test/test_loading.py there is the following test def test_find(self): for name in ("c", "m"): lib = find_library(name) if lib: cdll.LoadLibrary(lib) CDLL(l

[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist

Changes by Michael Felt : -- components: +ctypes ___ Python tracker <http://bugs.python.org/issue28276> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28277] ./Modules/_io/_iomodule.c build failure on AIX (beta1) while (a2) was fine.

New submission from Michael Felt: Python-3.6.0.a2 (a2 == 162) root@x064:[/data/prj/python/python-3.6.0.162]xlc -DNDEBUG -O -I/opt/include -qmaxmem=-1 -qarch=pwr4 -O3 -I/opt/buildaix/includes -O -I. -IInclude -I./Include -I/opt/include -I/opt/buildaix/inclu de -DPy_BUILD_CORE -I

[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist

Michael Felt added the comment: The assert to be added is much more simple: i.e., self.assertTrue(lib) And then you get something like: root@x064:[/data/prj/python/python-3.6.0.177/Lib/ctypes/test]../../../python -m unittest test_loading.py libc_name is libc.a(shr.o) sslib is None F.sss

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

Michael Felt added the comment: Sigh - missed the feature cutoff that would have made this easier to get into python... Anyway - have learned a few new things about python def: syntax and removed some bits that I thought were suitable for variable "initialization" - but tend to

[issue28290] BETA report: Python-3.6 build messages to stderr: AIX and "not GCC"

Changes by Michael Felt : -- versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue28290> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28290] BETA report: Python-3.6 build messages to stderr: AIX and "not GCC"

New submission from Michael Felt: GCC and IBM xlC compilers pay attention to different things - so some of the messages are "accepted" if not harmless. e.g. this type: "./Modules/xxsubtype.c", line 293.19: 1506-196 (W) Initialization between types "void*" and &q

[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist

Michael Felt added the comment: Actually, what may be needed are more "@skip" blocks - as ctypes has always been platform dependent. OR - have a counter or boolean that starts as zero or false and increase each time find_library() returns a value - and the test fails if the counter

[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist

Michael Felt added the comment: Is this suitable? def test_find(self): # to track that at least one call to find_library() found something found = false for name in ("c", "m"): lib = find_library(name) if lib:

[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist

Michael Felt added the comment: ok - false needs to be False and true needs to be True seemed so simple. Sigh. -- ___ Python tracker <http://bugs.python.org/issue28

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

Michael Felt added the comment: The "core" changes in this patch are very simple - in parallel with the way find_library() is managed in util.py a) __init__.py: add an additional mode bit for call to dlopen() (in __init__.py) diff -u src/Python-2.7.12/Lib/ctypes/__init__.

[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)

Changes by Michael Felt : Added file: http://bugs.python.org/file44869/_aix.py ___ Python tracker <http://bugs.python.org/issue27435> ___ ___ Python-bugs-list mailin

[issue28311] AIX shared library extension modules installation broken - Python2.7

New submission from Michael Felt: issue#25825 is closed - and had python2.7 removed - so, want to mention there is something broken - a long time it would seem on AIX - for building packages after python and ensurepip are installed. Currently trying to pip install mercurial; later a regular

[issue28311] AIX shared library extension modules installation broken - Python2.7

Changes by Michael Felt : -- type: -> compile error ___ Python tracker <http://bugs.python.org/issue28311> ___ ___ Python-bugs-list mailing list Unsubscrib

<    24   25   26   27   28   29   30   31   >