[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"

2020-06-28 Thread Nick Coghlan
Nick Coghlan added the comment: Removing issue assignment, as I'm no longer actively investigating this. -- assignee: ncoghlan -> ___ Python tracker <https://bugs.python.org/issu

[issue30672] PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X)

2020-06-28 Thread Nick Coghlan
Nick Coghlan added the comment: Removing issue assignment, as I'm not actively investigating this. -- assignee: ncoghlan -> ___ Python tracker <https://bugs.python.org/issu

[issue34206] Move and clarify Py_Main documentation

2020-06-28 Thread Nick Coghlan
Nick Coghlan added the comment: Added 3.8 back in to the target versions. However, if the automatic backport doesn't work for that branch, I'll probably skip it rather than fixing any conflicts. -- versions: +Python 3.8 ___ Python tracker <ht

[issue34206] Move and clarify Py_Main documentation

2020-06-28 Thread Nick Coghlan
Nick Coghlan added the comment: Adjusted target versions, as I never previously got around to merging this PR. -- versions: +Python 3.10, Python 3.9 -Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34

[issue31898] Add a `recommended-packages.txt` file

2020-06-28 Thread Nick Coghlan
Nick Coghlan added the comment: Removing the issue assignment, as I'm not actively working on this (although I still think it's a reasonable idea). -- assignee: ncoghlan -> ___ Python tracker <https://bugs.python.org/issu

[issue31899] Ensure backwards compatibility with recommended packages

2020-06-28 Thread Nick Coghlan
Nick Coghlan added the comment: Removing the issue assignment, as I'm not actively working on this (although I still think it's a reasonable idea). -- assignee: ncoghlan -> ___ Python tracker <https://bugs.python.org/issu

[issue17490] Improve ast.literal_eval test suite coverage

2020-06-28 Thread Nick Coghlan
Nick Coghlan added the comment: Belatedly removing the issue assignment here, as I'm not actively working on this. I've also marked this as an easy newcomer friendly task, as all that's involved is taking the `test_ast.py` changes from https://bugs.python.org/file29520

[issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds

2020-06-28 Thread Nick Coghlan
Nick Coghlan added the comment: Belatedly clearing the issue assignment here - while I do still sometimes ponder this problem, I haven't been actively working on it since the 2017 core sprint where Greg & I made our last serious attempt at trying to improve the situation. Mark'

[issue24048] remove_module() needs to save/restore exception state

2020-06-28 Thread Nick Coghlan
Nick Coghlan added the comment: Belatedly marking this as resolved. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)

2020-06-17 Thread Nick Coghlan
Nick Coghlan added the comment: I'm seeing this as well when attempting to run an optimised Python 3.8 build on an old Debian 9 system (with the curses and socket extension modules). For example: cpython/Modules/socketmodule.c: In function ‘PyInit__socket’: cpython/Modules/socketmodule.c

[issue33944] Deprecate and remove code execution in pth files

2020-05-12 Thread Nick Coghlan
Nick Coghlan added the comment: While it's still not entirely accurate, I've tweaked the title on the issue to refer to the arbitrary code execution behavior. Getting "Make pth file sys.path modifications easier to debug" in there as well would be rat

[issue33944] Deprecate and remove code execution in pth files

2020-05-12 Thread Nick Coghlan
Change by Nick Coghlan : -- title: Deprecate and remove pth files -> Deprecate and remove code execution in pth files ___ Python tracker <https://bugs.python.org/issu

[issue28180] Implementation of the PEP 538: coerce C locale to C.utf-8

2020-03-22 Thread Nick Coghlan
Nick Coghlan added the comment: The test cases for locale coercion *not* triggering still assume that bpo-19977, using surrogateescape on the standard streams in the POSIX locale, has been implemented (since that was implemented in Python 3.5). Hence the various test cases complaining

[issue39976] Add "**other_popen_kwargs" to subprocess API signatures in docs

2020-03-16 Thread Nick Coghlan
New submission from Nick Coghlan : Two of my colleagues missed the "The arguments shown above are merely the most common ones, ..." caveat on the subprocess.run documentation, and assumed that Python 3.5 only supported the "cwd" option in the low level Popen API, and no

[issue39892] Enable DeprecationWarnings by default when not explicit in unittest.main()

2020-03-15 Thread Nick Coghlan
Nick Coghlan added the comment: Issue 10535 says they should already be on by default in unittest. I seem to recall checking that was still true when implementing the default warning filter changes in 3.7. -- ___ Python tracker <ht

[issue39824] Multi-phase extension module (PEP 489): don't call m_traverse, m_clear nor m_free before the module state is allocated

2020-03-15 Thread Nick Coghlan
Nick Coghlan added the comment: Petr's point that any subclass state should be managed in the subclass cleanup functions is a good one, so I withdraw my concern: * custom module subclasses should clean up like any other class instance * the module slots are then only needed if the module

[issue39725] unrelated `from None` exceptions hide prior exception information

2020-03-15 Thread Nick Coghlan
Nick Coghlan added the comment: Tweaked title to be "hide" rather "lose" (all the info is theoretically still there in various places, it's just hidden by the default traceback printing machinery, and hard to extract from the exception tree). Issue #18861 is

[issue34822] Simplify AST for slices

2020-03-07 Thread Nick Coghlan
Nick Coghlan added the comment: The one thing in the PR that makes me slightly wary is the point Vedran raised: in the old AST _Unparser code, the fact that index tuples containing slices should be printed without parentheses was encapsulated in the ExtSlice node type, but with Index

[issue39824] Multi-phase extension module (PEP 489): don't call m_traverse, m_clear nor m_free before the module state is allocated

2020-03-07 Thread Nick Coghlan
Nick Coghlan added the comment: One of the intended use cases for Py_mod_create is to return instances of ModuleType subclasses rather than straight ModuleType instances. And those are definitely legal to define: >>> import __main__ >>> class MyModule(type(__main__)

[issue39465] Design a subinterpreter friendly alternative to _Py_IDENTIFIER

2020-02-08 Thread Nick Coghlan
Nick Coghlan added the comment: As Petr notes, as long as all subinterpreters share the GIL, and share str instances, then the existing _Py_IDENTIFIER mechanism will work fine for both single phase and multi-phase initialisation. However, that constraint also goes the other way: as long

[issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code

2020-01-29 Thread Nick Coghlan
Nick Coghlan added the comment: In the subinterpreter context: perhaps it would make sense to move *all* Py_IDENTIFIER declarations to file scope? That would make it much clearer which of our extension modules actually have hidden state for caching purposes. If we did that though, we'd

[issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code

2020-01-29 Thread Nick Coghlan
Nick Coghlan added the comment: My apologies, my comment above was based on an outdated understanding of how the identifier structs get initialised (it's the usage that initialises them, not the declaration). That means this is a useful refactoring to help identify blockers to full

[issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code

2020-01-29 Thread Nick Coghlan
Nick Coghlan added the comment: We can't make this change, as it means the statics get initialised before the Python interpreter has been initialised, and won't be reinitialised if the interpreter is destroyed and recreated. -- nosy: +ncoghlan resolution: -> rejected stage: pa

[issue39153] Clarify refcounting semantics of PyDict_SetItem[String]

2020-01-29 Thread Nick Coghlan
Nick Coghlan added the comment: New changeset e1e80002e28e1055f399a20918c49d50d093709e by Joannah Nanjekye in branch 'master': bpo-39153: Clarify C API *SetItem refcounting semantics (GH-18220) https://github.com/python/cpython/commit/e1e80002e28e1055f399a20918c49d50d093709e

[issue39465] Design a subinterpreter friendly alternative to _Py_IDENTIFIER

2020-01-27 Thread Nick Coghlan
Change by Nick Coghlan : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue39465> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue39465] Design a subinterpreter friendly alternative to _Py_IDENTIFIER

2020-01-27 Thread Nick Coghlan
New submission from Nick Coghlan : Both https://github.com/python/cpython/pull/18066 (collections module) and https://github.com/python/cpython/pull/18032 (asyncio module) ran into the problem where porting them to multi-phase initialisation involves replacing their usage

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

2020-01-20 Thread Nick Coghlan
Nick Coghlan added the comment: New changeset 1e420f849d0c094098543d2c27d35eaec69b2784 by Nick Coghlan in branch 'master': bpo-35134: Migrate frameobject.h contents to cpython/frameobject.h (GH-18052) https://github.com/python/cpython/commit/1e420f849d0c094098543d2c27d35eaec69b2784

[issue35134] Add a new Include/cpython/ subdirectory for the "CPython API" with implementation details

2020-01-20 Thread Nick Coghlan
Change by Nick Coghlan : -- pull_requests: +17475 pull_request: https://github.com/python/cpython/pull/18052 ___ Python tracker <https://bugs.python.org/issue35

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

2020-01-18 Thread Nick Coghlan
Change by Nick Coghlan : -- pull_requests: +17447 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18052 ___ Python tracker <https://bugs.python.org/issu

[issue39048] Change the lookup order of __aenter__ and __aexit__ for async with

2020-01-14 Thread Nick Coghlan
Change by Nick Coghlan : -- resolution: -> fixed stage: -> resolved status: open -> closed type: behavior -> enhancement versions: -Python 3.8 ___ Python tracker <https://bugs.python

[issue39048] Change the lookup order of __aenter__ and __aexit__ for async with

2020-01-14 Thread Nick Coghlan
Nick Coghlan added the comment: New changeset 1d1b97ae643dd8b22d87785ed7bd2599c6c8dc8d by Nick Coghlan (Géry Ogam) in branch 'master': bpo-39048: Look up __aenter__ before __aexit__ in async with (GH-17609) https://github.com/python/cpython/commit/1d1b97ae643dd8b22d87785ed7bd2599c6c8dc8d

[issue39301] Specification of bitshift on integers should clearly state floor division used

2020-01-11 Thread Nick Coghlan
Nick Coghlan added the comment: Aye, adding "floor" to the existing footnote would be the minimal fix. I'm just wondering whether it's also worth stating that this means that positive integers saturate at zero, while negative integers satu

[issue26515] Update extending/embedding docs to new way to build modules in C

2020-01-11 Thread Nick Coghlan
Nick Coghlan added the comment: Changed target version as per Petr's comment (PEP 573 is close to being accepted for 3.9 - it just needs some editing to improve clarity in the PEP itself, rather than needing any changes to the technical proposal) -- versions: +Python 3.9 -Python 3.6

[issue39302] Language reference does not clearly describe modern operand coercion

2020-01-11 Thread Nick Coghlan
New submission from Nick Coghlan : While reviewing ISO-IECJTC1-SC22-WG23's latest draft of their Python security annex, I found a description of operand coercion that was based on the legacy coercion model described at https://docs.python.org/2.5/ref/coercion-rules.html That's still

[issue39301] Specification of bitshift on integers should clearly state floor division used

2020-01-10 Thread Nick Coghlan
New submission from Nick Coghlan : While reviewing ISO-IECJTC1-SC22-WG23's latest draft of their Python security annex, I noticed that https://docs.python.org/3.7/library/stdtypes.html#bitwise-operations-on-integer-types doesn't explicitly state that *floor* division is used for right shift

[issue37194] Move new vector private declarations to the internal C API

2020-01-07 Thread Nick Coghlan
Change by Nick Coghlan : -- pull_requests: -17306 ___ Python tracker <https://bugs.python.org/issue37194> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36476] Runtime finalization assumes all other threads have exited.

2019-12-30 Thread Nick Coghlan
Nick Coghlan added the comment: Thinking about that idea further, I don't think that change would help much, since the relevant operations should already be checking for thread termination when they attempt to reacquire the GIL. That means what we're missing is: 1. When daemon threads

[issue36476] Runtime finalization assumes all other threads have exited.

2019-12-30 Thread Nick Coghlan
Nick Coghlan added the comment: Perhaps we need a threading.throw() API, similar to the one we have for generators and coroutines? If we had that, then Py_FinalizeEx() could gain a few new features: * throw SystemExit into all daemon threads and then give them a chance to terminate before

[issue20443] __code__. co_filename should always be an absolute path

2019-12-30 Thread Nick Coghlan
Nick Coghlan added the comment: With the sys.argv[0] change reverted, I think this overall issue is fixed now - code objects will get absolute paths, while sys.argv[0] will continue to reflect how __main__ was identified. -- priority: -> normal resolution: -> fixed stage:

[issue39037] Fix the trial order of the __exit__ and __enter__ methods in the with statement documentation

2019-12-29 Thread Nick Coghlan
Nick Coghlan added the comment: New changeset 226e6e7d4326cf91ef37e13528eb1f62de1bb832 by Nick Coghlan (Géry Ogam) in branch 'master': bpo-39037: Fix lookup order of magic methods in with statement documentation (GH-17608) https://github.com/python/cpython/commit

[issue39161] Py_NewInterpreter docs need updating for multi-phase initialization

2019-12-29 Thread Nick Coghlan
New submission from Nick Coghlan : The Py_NewInterpreter docs only cover the behaviour of extension modules that use single-phase initialization: https://docs.python.org/3/c-api/init.html#c.Py_NewInterpreter Multi-phase initialization allows each subinterpreter to get its own copy

[issue39153] Clarify refcounting semantics of PyDict_SetItem[String]

2019-12-29 Thread Nick Coghlan
Nick Coghlan added the comment: Right, that's why I don't think the other "*SetItem*" operations should get a Sphinx note - just a sentence, as was already done for PySequence_SetItem. If it weren't for PyList_SetItem being different, none of the others would need the clarificat

[issue39153] Clarify refcounting semantics of PyDict_SetItem[String]

2019-12-29 Thread Nick Coghlan
Change by Nick Coghlan : -- assignee: -> docs@python components: +Documentation nosy: +docs@python stage: -> needs patch type: -> enhancement versions: +Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.or

[issue39153] Clarify refcounting semantics of PyDict_SetItem[String]

2019-12-29 Thread Nick Coghlan
New submission from Nick Coghlan : The documentation for PyList_SetItem is explicit that it steals a reference to the passed in value, and drops the reference for any existing entry: https://docs.python.org/3.3/c-api/list.html?highlight=m#PyList_SetItem The documentation for PyDict_SetItem

[issue39033] zipimport raises NameError: name '_boostrap_external' is not defined

2019-12-15 Thread Nick Coghlan
Nick Coghlan added the comment: New changeset 79f02fee1a542c440fd906fd54154c73fc0f8235 by Nick Coghlan (Xtreak) in branch 'master': bpo-39033: Fix NameError in zipimport during hash validation (GH-17588) https://github.com/python/cpython/commit/79f02fee1a542c440fd906fd54154c73fc0f8235

[issue38021] Modify AIX platform_tag so it provides PEP425 needs

2019-12-15 Thread Nick Coghlan
Nick Coghlan added the comment: Thanks for your patience Michael! I made some cosmetic changes to the error handling logic that you may want to include in the PyPA patches. (I'd intended to make it so that a malformed build date resulted in the "Unknown" "9898" build dat

[issue38021] Modify AIX platform_tag so it provides PEP425 needs

2019-12-15 Thread Nick Coghlan
Nick Coghlan added the comment: New changeset 39afa2d3147e4b05a1161cc90dbf09b95072c2bb by Nick Coghlan (Michael Felt) in branch 'master': bpo-38021: Modify AIX platform_tag so it covers PEP 425 needs (GH-17303) https://github.com/python/cpython/commit/39afa2d3147e4b05a1161cc90dbf09b95072c2bb

[issue37292] _xxsubinterpreters: Can't unpickle objects defined in __main__

2019-12-15 Thread Nick Coghlan
Nick Coghlan added the comment: There's a reason multiprocessing in spawn mode jumps through the hoops that it does: it's the only way to get __main__ pickling to work when you're not forking the entire process. You also don't want to naively re-run __main__ in the subprocess for the same

[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules

2019-12-15 Thread Nick Coghlan
Nick Coghlan added the comment: Leaving the relationship between pickle and __name__ alone wasn't an oversight, as folks already rely on that to gracefully transition from single-file modules to multi-file packages without breaking pickle compatibility in either direction. The trick

[issue39037] Fix the trial order of the __exit__ and __enter__ methods in the with statement documentation

2019-12-15 Thread Nick Coghlan
Nick Coghlan added the comment: It's a matter of historical timing: PEP 343 was written before try/except/finally was allowed, when try/finally and try/except were still distinct statements. However, PEP 341 was *also* accepted and implemented for Python 2.5, allowing for the modern try

[issue38021] Modify AIX platform_tag so it provides PEP425 needs

2019-12-08 Thread Nick Coghlan
Nick Coghlan added the comment: There's a compatibility problem with changing the AIX distutils platform prefix from aix to AIX: any existing code that does "distutils.get_platform().startswith('aix')" will break. (There isn't any code in the standard library that does that, it

[issue38021] Modify AIX platform_tag so it provides PEP425 needs

2019-12-08 Thread Nick Coghlan
Nick Coghlan added the comment: Removing 3.9 from the target versions, as similar to other platform tag improvements, emulation on older release versions will be the domain of cross-version libraries, rather than changing the standard library in a maintenance. -- versions: -Python

[issue38021] pep425 tag for AIX is inadequate

2019-11-23 Thread Nick Coghlan
Nick Coghlan added the comment: For folks that aren't aware, Michael and I have been discussing the AIX package tagging problem via email since his initial distutils-sig posts about it. It's genuinely murky as fixing the AIX problem doesn't *technically* require any PEP 425 changes

[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules

2019-11-12 Thread Nick Coghlan
Nick Coghlan added the comment: [Belatedly updating this issue with the current status as of March] Cameron's implementation generally looks good, but there are couple of compatibility/migration questions that we need to consider, as spelled out in the PEP update that added me as BDFL

[issue20443] __code__. co_filename should always be an absolute path

2019-10-23 Thread Nick Coghlan
Nick Coghlan added the comment: This change isn't in Python 3.8 though, it's only in Python 3.9 (the PR merge date is after the beta 1 branch date). Unless it was backported in a Python 3.8 PR that didn't link back to this issue or the original Python 3.9 PR

[issue38524] functools.cached_property is not supported for setattr

2019-10-20 Thread Nick Coghlan
Nick Coghlan added the comment: After writing my previous comment, I double-checked the code, and cached_propery is actually one of the cases where a simple "self.attrname = 'age3'" *will* do the right thing, as cached_property never checks the class information. That

[issue38524] functools.cached_property is not supported for setattr

2019-10-20 Thread Nick Coghlan
Nick Coghlan added the comment: Regarding the "attrname" property idea: unfortunately, that won't work, as `__set_name__` doesn't just provide the attribute name, it also provides a reference to the class itself. cached_property needs both pieces of information, not just the attr

[issue38524] functools.cached_property is not supported for setattr

2019-10-20 Thread Nick Coghlan
Nick Coghlan added the comment: Another interesting question this raises is whether type.__setattr__ should be checking for values that have `__set_name__` methods defined and calling those methods automatically. Unfortunately, I think the answer to that is "If we'd thought of that

[issue20443] __code__. co_filename should always be an absolute path

2019-10-20 Thread Nick Coghlan
Nick Coghlan added the comment: I think that's a valid point regarding sys.argv[0] - it's the import system and code introspection that wants(/needs) absolute paths, whereas sys.argv[0] gets used in situations (e.g. usage messages) where we should retain whatever the OS gave us, since

[issue38457] __package__ is None in __init__.py until an import is used

2019-10-20 Thread Nick Coghlan
Nick Coghlan added the comment: Yes, this is a design flaw in the Python 2 import system - it derives `__package__` from `__name__` the first time it needs the information and `__package__` isn't already set. The problem was fixed for the Python 3 series by way of PEP 451, which made

[issue32856] Optimize the `for y in [x]` idiom in comprehensions

2019-10-20 Thread Nick Coghlan
Nick Coghlan added the comment: The benefit offered by the parent local scoping was that it made assignment expressions usable as a straightforward way to implement comprehension-based accumulators where you actually do want access to the final value after the comprehension completes

[issue30672] PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X)

2019-10-20 Thread Nick Coghlan
Nick Coghlan added the comment: (Removed the patch keyword, as the linked PR was for an old change that didn't cover the remaining test issues) -- ___ Python tracker <https://bugs.python.org/issue30

[issue30672] PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X)

2019-10-20 Thread Nick Coghlan
Nick Coghlan added the comment: There are a couple of cases that the C locale coercion tests skip because I don't (or didn't) know what they *should* do: * https://github.com/python/cpython/blob/24dc2f8c56697f9ee51a4887cf0814b6600c1815/Lib/test/test_c_locale_coercion.py#L262 (skips

[issue22257] PEP 432 (PEP 587): Redesign the interpreter startup sequence

2019-10-05 Thread Nick Coghlan
Nick Coghlan added the comment: Agreed. I've also added PEP 587 to the issue title to make the connection to that PEP more obvious. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed title: PEP 432: Redesign the interpreter startup sequence -

[issue18578] Rename and document test.bytecode_helper as test.support.bytecode_helper

2019-10-05 Thread Nick Coghlan
Nick Coghlan added the comment: Just noting for the record that the reason a new warning wasn't needed here is because there is already a general "No compatibility guarantees" warning for the entire test package: https://docs.python.org/3/library/test.html Thanks for getting thi

[issue38326] Concerns with the last minute changes to the PEP 587 API

2019-09-30 Thread Nick Coghlan
Change by Nick Coghlan : -- keywords: +patch pull_requests: +16084 stage: commit review -> patch review pull_request: https://github.com/python/cpython/pull/16496 ___ Python tracker <https://bugs.python.org/issu

[issue38326] Concerns with the last minute changes to the PEP 587 API

2019-09-30 Thread Nick Coghlan
Nick Coghlan added the comment: (I'm currently working a PR for this that Victor can review) -- assignee: -> ncoghlan ___ Python tracker <https://bugs.python.org/issu

[issue38326] Concerns with the last minute changes to the PEP 587 API

2019-09-30 Thread Nick Coghlan
New submission from Nick Coghlan : (Nosy list is RM, PEP 587 BDFL-Delegate, PEP 587 author) Filing as a release blocker, given that I don't think we should ship rc1 until consensus has been reached on the last minute changes to the PEP 587 configuration API. Thread at https

[issue38304] PEP 587 implementation is not ABI forward compatible

2019-09-29 Thread Nick Coghlan
Nick Coghlan added the comment: The hidden _config_version field wasn't in the accepted PEP. Both it and struct_size should be removed, as we don't support updating an embedded Python runtime to a new X.Y.0 release without rebuilding the embedding application. -- nosy: +ncoghlan

[issue37937] Mention ``frame.f_trace`` in :func:`sys.settrace` docs.

2019-09-20 Thread Nick Coghlan
Nick Coghlan added the comment: Thanks for the PR, Ram, and the initial review, Serhiy. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.8 ___ Python tracker <https://bug

[issue37937] Mention ``frame.f_trace`` in :func:`sys.settrace` docs.

2019-09-20 Thread Nick Coghlan
Nick Coghlan added the comment: New changeset 9c2682efc69568e1b42a0c1759489d6f2e3b30ea by Nick Coghlan (Ram Rachum) in branch 'master': bpo-37937: Mention frame.f_trace in sys.settrace docs (GH-15439) https://github.com/python/cpython/commit/9c2682efc69568e1b42a0c1759489d6f2e3b30ea

[issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds

2019-09-14 Thread Nick Coghlan
Nick Coghlan added the comment: It's also not unique to with statements - it applies to all finally clauses. The longstanding workaround when deterministic cleanup is absolutely critical has been to run the "real" application in a subthread, and devote the main thread to

[issue33095] Cross-reference isolated mode from relevant locations

2019-09-13 Thread Nick Coghlan
Nick Coghlan added the comment: New changeset bdd6945d4dbd1fe6a7fcff95f7d6908db7d791a1 by Nick Coghlan (Xtreak) in branch 'master': bpo-33095: Add reference to isolated mode in -m and script option (GH-7764) https://github.com/python/cpython/commit/bdd6945d4dbd1fe6a7fcff95f7d6908db7d791a1

[issue37941] python -m and runpy.run_module set different __name__ by default

2019-09-11 Thread Nick Coghlan
Nick Coghlan added the comment: There is one, it just isn't public: runpy._run_module_as_main. It's a private API that the -m switch implementation calls, and was introduced after the original runpy.run_module was found not to offer everything the switch needed. It isn't possible to fully

[issue30076] Opcode names BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL are too long

2019-09-11 Thread Nick Coghlan
Nick Coghlan added the comment: So we'd be going with a naming convention where "VAR" corresponds to the star syntax, and whether it means packing or unpacking, or refers to arguments or parameters is context dependent? I could definitely support that, given that the ambigui

[issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds

2019-09-11 Thread Nick Coghlan
Nick Coghlan added the comment: There is also the draft test case at https://github.com/ncoghlan/cpython/pull/2 That needs updating to account for the eval loop changes since I last worked on it, though. (I think that conflict may also be keeping the bots from running, even after I updated

[issue30076] Opcode names BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL are too long

2019-09-03 Thread Nick Coghlan
Nick Coghlan added the comment: Reviewing this again now, I think my previous naming suggestion is problematic, as it encourages conflating two different concepts that use similar syntax: * collecting arbitrary positional parameters in a tuple (VAR_POSITIONAL) or arbitrary keyword

[issue37398] contextlib.ContextDecorator decorating async functions

2019-09-03 Thread Nick Coghlan
Nick Coghlan added the comment: The query in #37743 highlights that generator functions and other wrapped iterator factories actually face a similar problem: they need the function body to contain "yield from wrapped(*args, **kwargs)" if the CM is going to be closed after th

[issue37743] How should contextmanager/ContextDecorator work with generators?

2019-09-03 Thread Nick Coghlan
Nick Coghlan added the comment: This is a documentation bug, as the current behaviour is as intended, but the documented equivalence doesn't hold for generator functions: for a generator function, the CM will only be applied when the generator is instantiated, whereas the inline context

[issue37398] contextlib.ContextDecorator decorating async functions

2019-09-03 Thread Nick Coghlan
Nick Coghlan added the comment: It isn't the simple case where the auto-detection idea concerns me, it's decorator stacking cases like: @outer @magic_detection @inner_forces_async def sync_native_api(): ... (With the original asyncio.coroutine being one example

[issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level

2019-09-03 Thread Nick Coghlan
Nick Coghlan added the comment: We never actually coded a reproducer for this, but if we had, it would have been a crash bug. -- type: -> crash ___ Python tracker <https://bugs.python.org/issu

[issue31874] [feature] runpy.run_module should mimic script launch behavior for sys.path

2019-09-03 Thread Nick Coghlan
Nick Coghlan added the comment: Good point regarding the heuristic: it would need to take the requested module name into account to be correct. * check if the requested module was found relative to the current directory (can be worked out from __main__.__spec__ and the current working

[issue37941] python -m and runpy.run_module set different __name__ by default

2019-09-03 Thread Nick Coghlan
Nick Coghlan added the comment: Yes, this is deliberate. From the run_module documentation: "__name__ is set to run_name if this optional argument is not None, to mod_name + '.__main__' if the named module is a package and to the mod_name argument otherwise." This allows arbi

[issue37941] python -m and runpy.run_module set different __name__ by default

2019-09-03 Thread Nick Coghlan
Change by Nick Coghlan : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37941> ___ ___ Python-bugs-list

[issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level

2019-08-29 Thread Nick Coghlan
Nick Coghlan added the comment: New changeset 06145230c833c3db5dab8858e11bcd550a37c57f by Nick Coghlan in branch 'master': bpo-37947: Avoid double-decrement in symtable recursion counting (GH-15593) https://github.com/python/cpython/commit/06145230c833c3db5dab8858e11bcd550a37c57f

[issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level

2019-08-29 Thread Nick Coghlan
Nick Coghlan added the comment: Reviewing all the code that touches recursion_depth (both in the symtable and in the thread state), I'm not seeing any sanity checks that ensure our increments and decrements *balance*. So I'm going to add one to PySymTable_BuildObject

[issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level

2019-08-29 Thread Nick Coghlan
Nick Coghlan added the comment: Reviewing the PR post-merge, I'm pretty sure this has introduced a double-decrement bug due to the original code being hard to read (the error cases did the decrement inside the helper function, while the success case did it in the calling function). https

[issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level

2019-08-29 Thread Nick Coghlan
Change by Nick Coghlan : -- pull_requests: +15269 pull_request: https://github.com/python/cpython/pull/15593 ___ Python tracker <https://bugs.python.org/issue37

[issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots

2019-08-29 Thread Nick Coghlan
Nick Coghlan added the comment: Thank you Pablo! Even having seen your fix, it still took me a couple of rescans of the original PR to figure out exactly how I'd broken it in the first place (refactoring to call an existing function without noticing that the replaced code included an extra

[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-25 Thread Nick Coghlan
Nick Coghlan added the comment: Merged for 3.8b4 after Emily's review. Thanks to all involved in the PEP update and change discussion! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracke

[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-25 Thread Nick Coghlan
Nick Coghlan added the comment: New changeset 6ca030765db49525f16b8fabff4153238148b58d by Nick Coghlan in branch '3.8': [3.8] bpo-37757: Disallow PEP 572 cases that expose implementation details (GH-15491) https://github.com/python/cpython/commit/6ca030765db49525f16b8fabff4153238148b58d

[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-25 Thread Nick Coghlan
Change by Nick Coghlan : -- pull_requests: +15178 pull_request: https://github.com/python/cpython/pull/15491 ___ Python tracker <https://bugs.python.org/issue37

[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-25 Thread Nick Coghlan
Nick Coghlan added the comment: New changeset 5dbe0f59b7a4f39c7c606b48056bc29e406ebf78 by Nick Coghlan in branch 'master': bpo-37757: Disallow PEP 572 cases that expose implementation details (GH-15131) https://github.com/python/cpython/commit/5dbe0f59b7a4f39c7c606b48056bc29e406ebf78

[issue37830] continue and break in finally with return in try results with segfault

2019-08-14 Thread Nick Coghlan
Nick Coghlan added the comment: Even though it doesn't fully resolve this crash, I'd still like us to consider reverting the change to allow "continue" in try/finally blocks. It doesn't seem to have a compelling practical motivation behind it (beyond the fact that it's nice not

[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-13 Thread Nick Coghlan
Nick Coghlan added the comment: The outcome of the python-dev discussion was that we agreed to switch to raising a plain SyntaxError, as that's what we do everywhere else that this kind of problem comes up (e.g. conflicts between global and nonlocal declarations, or between those

[issue37398] contextlib.ContextDecorator decorating async functions

2019-08-09 Thread Nick Coghlan
Nick Coghlan added the comment: I wouldn't be OK with magic switching in the behaviour of ContextDecorator (that's not only semantically confusing, it's also going to make the contextlib function wrappers even slower than they already are). I'm also entirely unclear on what you would expect

[issue37636] Deprecate slicing and ordering operations on sys.version

2019-08-09 Thread Nick Coghlan
Nick Coghlan added the comment: Regarding the "Would releasing 4.0 instead avoid problems?" Anthony actually did that experiment, too: it broke third party projects even more impressively than the 3.10 build did. I think Serhiy's point is fairly compelling though - che

[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-05 Thread Nick Coghlan
Nick Coghlan added the comment: I believe our main motivation for separating it out was the fact that even though TargetScopeError is a compile-time error, the affected code is syntactically fine - there are just issues with unambiguously inferring the intended read/write location

[issue35224] PEP 572: Assignment Expressions

2019-08-05 Thread Nick Coghlan
Nick Coghlan added the comment: Proposed PEP update is here: https://github.com/python/peps/pull/1140 The update also aims to clarify *why* we're doing the extra work in CPython's compiler to make these cases fail (i.e. we don't want to implicitly impose the current CPython runtime

[issue37757] TargetScopeError not raised for comprehension scope conflict

2019-08-05 Thread Nick Coghlan
Nick Coghlan added the comment: Added a PEP update as well: https://github.com/python/peps/pull/1140 -- ___ Python tracker <https://bugs.python.org/issue37

  1   2   3   4   5   6   7   8   9   10   >