[issue36001] LIBFFI_INCLUDEDIR is not detected when set into a profile nor in ./configure LIBFFI_INCLUDEDIR="path/to/libffi/include"

New submission from neil pop : Hello, I tried making python 3.7.2 on linux mint without libffi set into my LIBFFI_INCLUDEDIR (usr/local/include) but set into my bashsrc which is basically a profile with export LIBFFI_INCLUDEDIR="-Ipath/to/libff/include" however when i try making py

[issue35813] shared memory construct to avoid need for serialization between processes

Neil Schemenauer added the comment: Some thoughts on this API. I think we need the "create with exclusive behavior" option, even though we don't know how to implement it on Windows right now. To me, there are two cases when calling SharedMemory: 1) You want to create a ne

[issue36012] Investigate slow writes to class variables

Neil Schemenauer added the comment: Some profiling using 'perf'. This is for cpython 63fa1cfece4912110ce3a0ff11fb3ade3ff5e756. children self [...] + 97.27% 0.00% run_mod (inlined) + 88.53% 6.33% PyObject_SetAttr + 79.34% 6.80% type_setattro + 43.92

[issue36012] Investigate slow writes to class variables

Neil Schemenauer added the comment: BTW, 'perf report [...]' has a really neat annotated assembly view. Scroll to the function you are interested in and press 'a'. Press 't' to toggle the time units (left side numbers). I'm attaching a screenshot

[issue36044] PROFILE_TASK for PGO build is not a good workload

New submission from Neil Schemenauer : I was doing some 'perf' profiling runs of Python. I decided to try running PROFILE_TASK to see what the profile looks like. I was surprised that gc_collect dominated runtime: Children Self Symbol + 93.93

[issue35810] Object Initialization does not incref Heap-allocated Types

Neil Schemenauer added the comment: Hello Eddie, Thank you for putting what looks to be significant effort into this PR. It would be great if we can get this fixed. There is a real issue about breaking 3rd party extensions. So, we want to proceed with care. I wonder, if we are going to

[issue35810] Object Initialization does not incref Heap-allocated Types

Neil Schemenauer added the comment: Sorry, morning coffee didn't kick in yet I guess. ;-) My actual wish is to make all types heap allocated and eliminate the statically allocated ones. So, Py_TPFLAGS_HEAPTYPE would be set on all types in that world. That is a gigantic task, affe

[issue30192] hashlib module breaks with 64-bit kernel and 32-bit user space

New submission from Neil Schemenauer: The test in setup.py to check for SSE2 support is incorrect. Checking that arch == x86_64 is not sufficient. If the kernel is 64-bit but Python is compiled with a 32-bit compiler, the _blake2 module will fail to build. The attached patch fixes this

[issue30192] hashlib module breaks with 64-bit kernel and 32-bit user space

Changes by Neil Schemenauer : -- pull_requests: +1440 ___ Python tracker <http://bugs.python.org/issue30192> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27377] Add smarter socket.fromfd()

Changes by Neil Schemenauer : -- pull_requests: +1441 ___ Python tracker <http://bugs.python.org/issue27377> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27377] Add smarter socket.fromfd()

Changes by Neil Schemenauer : -- pull_requests: +1460 ___ Python tracker <http://bugs.python.org/issue27377> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27377] Add socket.fdtype()

Neil Schemenauer added the comment: Changing title, I think #28134 (socket.socket(fileno=fd) does not work as documented) is a cleaner solution. However, exposing the ability to query a socket file descriptor seems useful so I'm still proposing to add socket.fdtype(). The github PR 134

[issue30192] hashlib module breaks with 64-bit kernel and 32-bit user space

Neil Schemenauer added the comment: It should be backported in my opinion. -- ___ Python tracker <http://bugs.python.org/issue30192> ___ ___ Python-bugs-list m

[issue17852] Built-in module _io can loose data from buffered files at exit

Neil Schemenauer added the comment: Well, I just spent a couple of hours debugging a problem caused by this issue. You could argue that I should be calling close() on all of my file-like objects but I agree with Armin that the current "most of the time it works" behaviour is quite

[issue17852] Built-in module _io can loose data from buffered files at exit

Neil Schemenauer added the comment: "Did you get any ResourceWarning?" I already knew that explicitly closing the file would fix the issue. However, think of the millions of lines of Python 2 that hopefully will be converted to Python 3. There will be many ResourceWarning errors.

[issue17852] Built-in module _io can loose data from buffered files at exit

Changes by Neil Schemenauer : -- pull_requests: +1987 ___ Python tracker <http://bugs.python.org/issue17852> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29324] test_aead_aes_gcm fails on Kernel 4.9

Neil Schemenauer added the comment: This patch works for me as well. Debian testing, kernel: Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170425 (Debian 6.3.0-16) ) #1 SMP Debian 4.9.25-1 (2017-05-02) In the 3.6.1 Python release, test_socket fails with

[issue29324] test_aead_aes_gcm fails on Kernel 4.9

Neil Schemenauer added the comment: This bug can be closed. The fix is in the master branch (commit 9764c151c51480a) and has also been backported to the "3.6" branch (git commit 4ac01f0ff3e). The fork for 3.6.1rc1 happened before the backport which is why 3.6.1 doesn'

[issue30192] hashlib module breaks with 64-bit kernel and 32-bit user space

Neil Schemenauer added the comment: Create PR 2042 for backport to 3.6 branch. -- ___ Python tracker <http://bugs.python.org/issue30192> ___ ___ Python-bugs-list m

[issue28907] test_pydoc fails if build is in sub-directory

Changes by Neil Schemenauer : -- pull_requests: +2104 ___ Python tracker <http://bugs.python.org/issue28907> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30192] hashlib module breaks with 64-bit kernel and 32-bit user space

Changes by Neil Schemenauer : -- pull_requests: +2105 ___ Python tracker <http://bugs.python.org/issue30192> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36710] Pass _PyRuntimeState as an argument rather than using the _PyRuntime global variable

Neil Schemenauer added the comment: I think there are two questions to answer. First, do we want to support multiple runtimes per process? Second, if we do, what is the best way to do that? Some people would argue that multiple runtimes are not needed or are too hard to do. Maybe they

[issue17852] Built-in module _io can lose data from buffered files at exit

Neil Schemenauer added the comment: Using atexit is not the solution because the data can be lost even while the program is running, not just at interpreter shutdown. The problem occurs if the buffered file object and the underlying file object are both part of a reference cycle. Then

[issue32626] Subscript unpacking raises SyntaxError

Neil Girdhar added the comment: This came up already on python-ideas: https://groups.google.com/forum/#!topic/python-ideas/YOpT9fDQyFk I think this was an oversight, and I'm with Ben that it's unexpected. That said, this is usually the kind of thing that Guido likes to comme

[issue33124] Lazy execution of module bytecode

New submission from Neil Schemenauer : This is an experimental patch that implements lazy execution of top-level definitions in modules (functions, classes, imports, global constants). See Tools/lazy_compile/README.txt for details. -- components: Interpreter Core messages: 314294

[issue33124] Lazy execution of module bytecode

Change by Neil Schemenauer : -- keywords: +patch pull_requests: +5941 ___ Python tracker <https://bugs.python.org/issue33124> ___ ___ Python-bugs-list mailin

[issue33419] Add functools.partialclass

New submission from Neil Girdhar : functools.partial is almost good enough for specifying some of the parameters of an object's initializer, but the partial object doesn't respond properly to issubclass. Adding functools.partialclass is similar to the addition of partialmet

[issue33419] Add functools.partialclass

Change by Neil Girdhar : -- components: +Library (Lib) type: -> enhancement ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bugs-lis

[issue33419] Add functools.partialclass

Change by Neil Girdhar : Added file: https://bugs.python.org/file47568/partialclass2.diff ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bug

[issue33419] Add functools.partialclass

Neil Girdhar added the comment: I edited some of the documentation as well to use the technical terms "partial function application", "partial method application", and "partial class application". This emphasizes the parallel structure and reduces confusion

[issue33419] Add functools.partialclass

Neil Girdhar added the comment: Added functools experts. Links to relevant stackoverflow questions: https://stackoverflow.com/questions/38911146/python-equivalent-of-functools-partial-for-a-class-constructor https://stackoverflow.com/questions/50143864/is-there-a-nice-way-to-partially-bind

[issue33419] Add functools.partialclass

Change by Neil Girdhar : Added file: https://bugs.python.org/file47569/partialclass3.diff ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bug

[issue33419] Add functools.partialclass

Neil Girdhar added the comment: I figured it would have to be 3.8, but it looks like Doc/whatsnew/3.8.rst has not been created? Do I create that? -- ___ Python tracker <https://bugs.python.org/issue33

[issue33419] Add functools.partialclass

Neil Girdhar added the comment: Done: https://github.com/python/cpython/pull/6699 -- ___ Python tracker <https://bugs.python.org/issue33419> ___ ___ Python-bug

[issue33419] Add functools.partialclass

Neil Girdhar added the comment: I'm not sure that this should be in the stdlib. The three-line function can be enough for your simple case, and it is too simple for including it in the stdlib. But for general stdlib quality solution it lacks many details. 1. It doesn't work with cl

[issue33419] Add functools.partialclass

Neil Girdhar added the comment: It seems like Python doesn't do very well with dynamically-generated classes. For that reason, I'm losing interest on this feature. Is there any interest in merging the documentation changes here: https://bugs.python.org/review/33419/diff/20050/D

[issue31558] gc.freeze() - an API to mark objects as uncollectable

Neil Schemenauer added the comment: I think the basic idea makes a lot of sense, i.e. have a generation that is never collected. An alternative way to implement it would be to have an extra generation, e.g. rather than just 0, 1, 2 also have generation 3. The collection would by default

[issue28643] Broken makefile depends for profile-opt target

Change by Neil Schemenauer : -- keywords: +patch pull_requests: +4191 ___ Python tracker <https://bugs.python.org/issue28643> ___ ___ Python-bugs-list mailin

[issue28643] Broken makefile depends for profile-opt target

Neil Schemenauer added the comment: New changeset 4e38d71a2b7b606fb1b0078c2d7014fc24044dac by Neil Schemenauer in branch 'master': bpo-28643: Record profile-opt build progress with stamp files (#4223) https://github.com/python/cpython/commit/4e38d71a2b7b606fb1b0078c2d7014

[issue28643] Broken makefile depends for profile-opt target

Neil Schemenauer added the comment: The previous behavior nearly drove me to drink. At least on my machine (and I have a relatively fast one), the profile-opt build takes a long time. After running "make" and checking things over, running "make install" will cause the

[issue17852] Built-in module _io can lose data from buffered files at exit

Neil Schemenauer added the comment: Yes, my bad. I thought that accepting the pull would close the bug. -- resolution: -> fixed stage: backport needed -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue31028] test_pydoc fails when run directly

Change by Neil Schemenauer : -- pull_requests: +4258 ___ Python tracker <https://bugs.python.org/issue31028> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28907] test_pydoc fails if build is in sub-directory

Neil Schemenauer added the comment: Pretty sure the fix for bug 31028 also fixed this. Closing. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> test_pydoc fails when run directly __

[issue27169] __debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks

Change by Neil Schemenauer : -- nosy: +nascheme ___ Python tracker <https://bugs.python.org/issue27169> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue24340] co_stacksize estimate can be highly off

Change by Neil Schemenauer : -- nosy: +nascheme ___ Python tracker <https://bugs.python.org/issue24340> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Change by Neil Schemenauer : ___ Python tracker <https://bugs.python.org/issue17611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/o

[issue24340] co_stacksize estimate can be highly off

Neil Schemenauer added the comment: The WIP pull request PR# 2827 seems to help. The following code prints 86 on python3.6 and 25 with PR 2827 applied. def g(): try: pass except ImportError as e: pass try: pass except ImportError as e: pass try: pass except ImportError

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: The attached pyperformance report compares cpython:master to nascheme:unwind_stack. If I've done the tests correctly, the unwind_stack version is slightly faster. -- Added file: https://bugs.python.org/file47253/perf_unwind_stac

[issue31963] AMD64 Debian PGO 3.x buildbot: compilation failed with an internal compiler error in create_edge

Neil Schemenauer added the comment: Hi Victor, My first guess is that the build bot is not cleaning the fprofile information after updating the source tree. A few options: - remove the profile-run-stamp file after checking out new code - call "make profile-removal" after check

[issue31963] AMD64 Debian PGO 3.x buildbot: compilation failed with an internal compiler error in create_edge

Neil Schemenauer added the comment: Oh I see. I'm at a loss then as to why the build is failing. A possible clue is the errors like: profiling:/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Objects/setobject.gcda:Merge mismatch for functi

[issue31963] AMD64 Debian PGO 3.x buildbot: compilation failed with an internal compiler error in create_edge

Neil Schemenauer added the comment: The current "master" branch seems to be building successfully on "AMD64 Debian PGO 3.x". Can we close this issue? -- ___ Python tracker <https://bug

[issue27987] obmalloc's 8-byte alignment causes undefined behavior

Neil Schemenauer added the comment: FYI, this would seem to be an incentive to get my "bitmaps for small GC objects" idea implemented. I.e. https://mail.python.org/pipermail/python-dev/2017-September/149307.html If implemented, the extra size of the PyGC_Head would only apply

[issue31778] ast.literal_eval supports non-literals in Python 3

Neil Schemenauer added the comment: Just a comment on what I guess is the intended use of literal_eval(), i.e. taking a potentially untrusted string and turning it into a Python object. Exposing the whole of the Python parser to potential attackers would make me very worried. Parsing code

[issue31963] AMD64 Debian PGO 3.x buildbot: compilation failed with an internal compiler error in create_edge

Neil Schemenauer added the comment: I'm willing to put some time into trying to fix this, in the case that it is caused by my Makefile changes. However, it would be very helpful if I could login to the build-bot and try running with the Makefile change backed out. Is that possible? H

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

Neil Schemenauer added the comment: I don't see a good reason to add this check. I would guess there could be lots of 3rd party packages that are no uninstallable on Python 3.7. E.g. python3 -m pip install exifread ... TypeError: 'classifiers' should be a 'list', n

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

Neil Schemenauer added the comment: I tried building the top packages from python3wos.appspot.com. Only simplejson-3.13.2.tar.gz fails to build due to this change. However, given that it is the top downloaded module, I think think making a change to Python that makes it uninstallable by

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

Neil Schemenauer added the comment: > Classifiers were always documented as lists (msg214915) and passing a > non-list type was raised a cryptic exception message as already reported in > my first message That doesn't matter. You can't break a bunch of packages in a 3

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Change by Neil Schemenauer : -- pull_requests: +4594 ___ Python tracker <https://bugs.python.org/issue17611> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

Neil Schemenauer added the comment: > Thank you, but I don't need a lecture from you. Feel free to propose our > solution in the form of pull request instead of acting like a project manager > and telling people what to do. I'm sorry you are offended. My pull request w

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

Change by Neil Schemenauer : -- pull_requests: +4598 stage: resolved -> patch review ___ Python tracker <https://bugs.python.org/issue19610> ___ ___ Python-

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

Neil Schemenauer added the comment: I like Nick's idea of calling list() to fix the argument. I've created a PR that implements it. I also generate a RuntimeWarning since if we document them as needing to be lists, we should at least warn for invalid types. The RuntimeWarning wi

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: After studying the patch and doing some reading, I prefer the finally-block duplication approach as well. Java does it that way as well and it works for them. It would be be interesting to compile a large body of packages and see what the increase in

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

Neil Schemenauer added the comment: Don't be sorry. We are all passionate about making Python better. distutils will be better once we gets this sorted out. Berker deserves credit for seeing an issue and developing on a fix for it. The collaboration between all the core develope

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

Neil Schemenauer added the comment: New changeset 8837dd092fe5ad5184889104e8036811ed839f98 by Neil Schemenauer in branch 'master': bpo-19610: Warn if distutils is provided something other than a list to some fields (#4685) https://github.com/python/cpyt

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: There is some more explanation in the PR and sample code. We unwind, if we hit a finally fblock, we emit code of the body of it. If inside the block, there is another return statement, we unwind again. That causes an infinite loop in the compiler. The

[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)

Change by Neil Schemenauer : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: def func(): try: try: raise RuntimeError except: return 1 finally: return 3 func() Sorry, I've been collecting a whole slew of code snippets that cause issues with the "unwind_stack&q

[issue32237] test_xml_etree leaked [1, 1, 1] references, sum=3

Change by Neil Schemenauer : -- keywords: +patch pull_requests: +4652 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32237> ___ ___ Py

[issue29970] Severe open file leakage running asyncio SSL server

Neil Aspinall added the comment: I think there's been some confusion about what PR 480 was meant to fix - it helps in cases where connections are closed during handshake, but if a server connection is waiting for a handshake but never receives any data at all then it stays in that

[issue29970] Severe open file leakage running asyncio SSL server

Change by Neil Aspinall : -- keywords: +patch pull_requests: +4717 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue29970> ___ ___ Py

[issue17852] Built-in module _io can lose data from buffered files at exit

Change by Neil Schemenauer : -- pull_requests: +4735 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue17852> ___ ___ Python-

[issue17852] Built-in module _io can lose data from buffered files at exit

Neil Schemenauer added the comment: I created a new PR which uses the atexit module instead of using _Py_PyAtExit. I think registering in io.py is okay. I see that atexit is now implemented in C. Rather than registering in io.py, we could create a C API to register callbacks (i.e

[issue32310] Remove _Py_PyAtExit from Python.h

New submission from Neil Schemenauer : _Py_PyAtExit only supports on callback function. Its sole use it to be used by atexit. IMHO, it should be removed from Python.h to prevent misuse. -- components: Interpreter Core messages: 308242 nosy: nascheme priority: low severity: normal

[issue32310] Remove _Py_PyAtExit from Python.h

Change by Neil Schemenauer : -- keywords: +patch pull_requests: +4738 ___ Python tracker <https://bugs.python.org/issue32310> ___ ___ Python-bugs-list mailin

[issue32312] Create Py_AtExitRegister C API

New submission from Neil Schemenauer : It would be handy to have a C API that registered an atexit function, similar to what calling atexit.register does. This API could be used by C extension modules to register atexit functions. I think the implementation would be fairly simple. We need a

[issue32312] Create Py_AtExitRegister C API

Neil Schemenauer added the comment: Private is fine. We want to get the design correct before making it part of the official API. My thought is that providing a handy atexit hook would be a good thing in that it could be an alternative to 3rd party code using __del__ to do cleanup. One

[issue17852] Built-in module _io can lose data from buffered files at exit

Neil Schemenauer added the comment: Attached is a script that triggers the non-flushing behaviour for me. I don't think it is reliable since it depends on the order that FileIO AND BufferedWriter are finalized when the gc finds them in a reference cycle. BTW, it is arguable that the

[issue17852] Built-in module _io can lose data from buffered files at exit

Neil Schemenauer added the comment: In the process of trying to write a test for this, I now realize that PR 4847 is not really a fix. If the underlying file gets closed during an earlier gc.collect() and not during shutdown, the extra flushing step is not going to help. So, using atexit

[issue17852] Built-in module _io can lose data from buffered files at exit

Neil Schemenauer added the comment: Using reversed chronological order would work in 99% of the cases probably but then you would have that rare case where it didn't work. So, I'm not too keen on that approach. I think this is a classic problem with finalization and GC, probably

[issue17852] Built-in module _io can lose data from buffered files at exit

Neil Schemenauer added the comment: Welp, another day another attempt. As mentioned in the PR 4847, atexit is not the answer. If the raw/buffered file pair are part of a reference cycle and the GC cleans it before atexit runs, then the buffered data can get lost. I attempted to implement

[issue17852] Built-in module _io can lose data from buffered files at exit

Neil Schemenauer added the comment: Yeah, I think you are correct. Currently files not part of reference cycles get properly flushed and closed by the reference counter. Implementing my "buffer_register_flush" patch would cause files to be closed only by the cyclic garbage col

[issue30492] 'make clinic' does not work for out of tree builds / clinic.py is not in the devguide

Neil Schemenauer added the comment: Thanks for fixing this. I always do my builds in subfolders as well. It is handy to have multiple builds (debug, opt, profiled) that all use a single source tree. I don't like to hijack this issue but could we get some of the build bots to do

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: Hello Raymond, I don't have anything ready to go. PR 4682 has some major outstanding issues. Specifically, exits from finally bodies did not cleanup the fblock stack correctly. I still think this patch is a good idea and that it can work. My goal

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: Ho ho ho! I spent some time to try to resolve the remaining issues with PR 4682. I think everything now works. Returns from a final body of a try/finally was the remaining issue. I've solved it by introducing the POP_NO_EXCEPT opcode. I ad

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: I wonder if I should drop PR 4682. I spent some more time working on it today. I switched to the same scheme as Serhiy for the no-exception case, i.e. push a single NULL value, rather than six NULLs. In ceval, we need to handle the non-exception case

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: I apologize if my extra PR is causing confusion. My original intention was to merely forward port Antoine changes so they could compile with the 'master' version of Python. Over time I have made some fixes to it. I have kept it open because I&

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: On 2017-12-29, Mark Shannon wrote: > One point I didn't cover is jumping to a new line in the debugger. > Implementing that reliably for finally blocks with code > duplication is tricky and would mean adding a number of marker > bytecodes

[issue31963] AMD64 Debian PGO 3.x buildbot: compilation failed with an internal compiler error in create_edge

Neil Schemenauer added the comment: That's mysterious. I reviewed the 'stdout' log from the buildbot. The removal of profile data is run early in the build: find . -name '*.gc??' -exec rm -f {} ';' Later, the bytearrayobject is compiled with profile g

[issue33609] Document that dicts preserve insertion order

Neil Schemenauer added the comment: The wording sounds strange to me. Currently it is: > Note that updating key doesn't affects the order ... I would say: > Note that updating a key does not affect the order ... -- nosy: +nascheme ___

[issue33609] Document that dicts preserve insertion order

Change by Neil Schemenauer : -- pull_requests: +7110 ___ Python tracker <https://bugs.python.org/issue33609> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33609] Document that dicts preserve insertion order

Neil Schemenauer added the comment: New changeset d3ed67d14ed401dfe2b5d07b6941adc3ecacb268 by Neil Schemenauer in branch 'master': bpo-33609: small wording fixes to dict ordering docs https://github.com/python/cpython/commit/d3ed67d14ed401dfe2b5d07b6941ad

[issue24575] timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH

Neil Schemenauer added the comment: I ran into an error like this and perhaps I have a clue was why some people run into it. Dynamic modules built from Modules/Setup will need to have -DPy_BUILD_CORE defined within the Setup file in the case they need to use the _Py_BEGIN_SUPPRESS_IPH

[issue34089] Remove required (non-optional) modules from Modules/Setup.dist

New submission from Neil Schemenauer : This is related to Issue32430. The behavior of Modules/Setup.dist and Modules/Setup is quirky and problematic. Issue32430 links to some of the related issues. The problem discussed in Issue24575 is also related (Py_BUILD_CORE not being defined when

[issue34089] Remove required (non-optional) modules from Modules/Setup.dist

Change by Neil Schemenauer : -- keywords: +patch pull_requests: +7770 ___ Python tracker <https://bugs.python.org/issue34089> ___ ___ Python-bugs-list mailin

[issue32430] Simplify Modules/Setup{,.dist,.local}

Neil Schemenauer added the comment: PR 8229 doesn't work if the build dir is separate from the src dir (mentioned in the PR comments). The attached patch (makesetup_fallback_dist.txt) changes makesetup to fallback to using $srcdir/Modules/Setup.dist if Modules/Setup doesn't

[issue32430] Simplify Modules/Setup{,.dist,.local}

Change by Neil Schemenauer : Added file: https://bugs.python.org/file47685/makesetup_fallback_dist.txt ___ Python tracker <https://bugs.python.org/issue32430> ___ ___

[issue32430] Simplify Modules/Setup{,.dist,.local}

Change by Neil Schemenauer : -- pull_requests: +7793 ___ Python tracker <https://bugs.python.org/issue32430> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32430] Simplify Modules/Setup{,.dist,.local}

Change by Neil Schemenauer : Removed file: https://bugs.python.org/file47685/makesetup_fallback_dist.txt ___ Python tracker <https://bugs.python.org/issue32430> ___ ___

[issue32430] Simplify Modules/Setup{,.dist,.local}

Neil Schemenauer added the comment: I removed the "makesetup_fallback_dist.txt". PR-8260 is a more polished implementation of the same idea. -- ___ Python tracker <https://bugs.python.o

[issue34106] Add --with-module-config= to 'configure' script

New submission from Neil Schemenauer : This patch is based on top of GH-8229 but could be changed to work without it. -- components: Build messages: 321580 nosy: nascheme priority: normal severity: normal stage: patch review status: open title: Add --with-module-config= to 'conf

<    1   2   3   4   5   6   7   >