[issue32551] 3.5.4 has a regression that was fixed in 3.6.1rc1
Nick Coghlan <ncogh...@gmail.com> added the comment: Unfortunately, it looks like bpo-29319 was backported to the 3.5 branch, but not the follow-up fix from bpo-29723: https://github.com/python/cpython/commits/3.5/Modules/main.c (The metadata on bpo-29319 indicated that the original change was targeted at 3.6+ only, and I didn't notice the message that mentioned the 3.5 branch, so I never even looked at 3.5 when working on bpo-29723 - I just assumed it wasn't affected) Adding unexpected directories to sys.path can definitely be a security problem, so I think the fix should be backported for 3.5.5, but I'm also wondering whether it might be a significant enough regression to warrant an extra "Oops, sorry, we broke it" binary release. (We don't have any good usage numbers on how often folks use directory execution vs other forms of execution, so we don't know how widespread any impact is likely to be) -- nosy: +steve.dower ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32551> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32004] Allow specifying code packing order in audioop adpcm functions
Nick Coghlan <ncogh...@gmail.com> added the comment: Adjusting target versions, as even though the status quo leads to mishandling some input data, the fix is a feature request to make the behaviour configurable, which restricts the change to 3.7+. -- nosy: +ncoghlan versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9325] Add an option to pdb/trace/profile to run library module as a script
Nick Coghlan <ncogh...@gmail.com> added the comment: While I do think it makes sense to enhance `dis` in this regard, I'm also thinking it might be better to have that automatically fall back to a `python -m inspect module:qualname` style lookup in the event that `os.path.exists(infile)` is false. So considering it out of scope for *this* issue makes sense. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue9325> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31975] Add a default filter for DeprecationWarning in __main__
Nick Coghlan <ncogh...@gmail.com> added the comment: New changeset 9b99747386b690007027c3be2a5d7cfe3d3634f5 by Nick Coghlan in branch 'master': bpo-31975 (PEP 565): Show DeprecationWarning in __main__ (GH-4458) https://github.com/python/cpython/commit/9b99747386b690007027c3be2a5d7cfe3d3634f5 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31975] Add a default filter for DeprecationWarning in __main__
Change by Nick Coghlan <ncogh...@gmail.com>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32498] urllib.parse.unquote raises incorrect errormessage when string parameter is bytes
Nick Coghlan <ncogh...@gmail.com> added the comment: As David noted, we updated all the URL parsing functions to be polymorphic back in 3.2: https://docs.python.org/3/library/urllib.parse.html#parsing-ascii-encoded-bytes We left the quoting functions alone, because they already had their own way of dealing with the bytes-vs-str distinction (quote_from_bytes, unquote_to_bytes, etc) that meant the polymorphic approach we adopted for the parsing functions didn't make sense. That said, I think it would be reasonable to enhance unquote() to accept a bytes object, processing it as follows: unquote_to_bytes(string).decode(encoding, errors) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9325] Add an option to pdb/trace/profile to run library module as a script
Nick Coghlan <ncogh...@gmail.com> added the comment: Thanks. I've added the dependencies, and also granted you triage permissions on the tracker, so you should be able to edit dependencies yourself in the future. -- dependencies: +Add an option to profile to run library module as a script, Add an option to trace to run module as a script ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue9325> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31975] Add a default filter for DeprecationWarning in __main__
Nick Coghlan <ncogh...@gmail.com> added the comment: I think https://github.com/python/cpython/pull/4458 is ready to go now, but I expect it would benefit from a review before I merge it. If anyone has the time to take a look, it would be much appreciated :) However, I'd also like to get it in for 3.7.0a4 this week, so I'll merge it tomorrow regardless - if we decide we need to tweak it before the first beta, we can do that. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9325] Add an option to pdb/trace/profile to run library module as a script
Nick Coghlan <ncogh...@gmail.com> added the comment:
+1 for creating separate issues and linking them from this one - while the risk
of breaking anything seems low, if we do cause a regression, multiple issues
and PRs provide better traceability than one giant issue for everything.
(I'm also not aware of anyone else actively working on this since Sanyam's
cProfile PR, so go ahead and create issues and PRs for any which you're
interested in working on)
As far as `dis` specifically goes, while the function name in `dis` is
"_test()" and it doesn't provide a meaningful help message, it's a genuinely
useful CLI operation: it disassembles whatever file you provide, or `stdin` if
you don't provide one:
$ echo "print('Hello')" | python3 -m dis
1 0 LOAD_NAME0 (print)
2 LOAD_CONST 0 ('Hello')
4 CALL_FUNCTION1
6 POP_TOP
8 LOAD_CONST 1 (None)
10 RETURN_VALUE
So a `-m` option does make sense in `dis`, but it should probably be
accompanied by some other changes as well (like a better name for the private
function, and `--help` support).
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue9325>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30579] Allow traceback objects to be instantiated/mutated/annotated
Nick Coghlan <ncogh...@gmail.com> added the comment: Thanks for the patch! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30579> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30579] Allow traceback objects to be instantiated/mutated/annotated
Nick Coghlan <ncogh...@gmail.com> added the comment: New changeset e46a8af450210ee5c7f0459ad6beddbc626ae60f by Nick Coghlan (Nathaniel J. Smith) in branch 'master': bpo-30579: Allow TracebackType creation and tb_next mutation from Python (GH-4793) https://github.com/python/cpython/commit/e46a8af450210ee5c7f0459ad6beddbc626ae60f -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30579> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32206] Run modules with pdb
Nick Coghlan <ncogh...@gmail.com> added the comment: Re-opening for the CLI help updates. -- resolution: fixed -> stage: resolved -> needs patch status: closed -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32206] Run modules with pdb
Nick Coghlan <ncogh...@gmail.com> added the comment: Thanks for the patch! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32206] Run modules with pdb
Nick Coghlan <ncogh...@gmail.com> added the comment: New changeset 9f1e5f1b7f074e026843a5d70834233a95a6bf9d by Nick Coghlan (Mario Corchero) in branch 'master': bpo-32206: Pdb can now run modules (GH-4752) https://github.com/python/cpython/commit/9f1e5f1b7f074e026843a5d70834233a95a6bf9d -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32206] Run modules with pdb
Nick Coghlan <ncogh...@gmail.com> added the comment: Linking back to the overall RFE for improved executable module support for standard library modules that run other scripts: https://bugs.python.org/issue9325 -- nosy: +ncoghlan ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9325] Add an option to pdb/trace/profile to run library module as a script
Nick Coghlan <ncogh...@gmail.com> added the comment: Issue 32206 covers doing this for `pdb`. It relies on directly accessing private APIs in the `runpy` module, but we can live with that, since `pdb` is part of the standard library. -- dependencies: +Run modules with pdb, cProfile command-line should accept "-m module_name" as an alternative to script path ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue9325> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32479] inconsistent ImportError message executing same import statement
Nick Coghlan <ncogh...@gmail.com> added the comment: Since the problem is specific to Python 2.7 and has been resolved in the importlib based import implementation, I'm inclined to close this as "Won't Fix". The only reason I haven't is that if someone really wanted to dig into the Python 2.7 import implementation and figure out how to improve the situation, I'd actually be willing to review the patch. Alternatively, it might be worthwhile for OpenStack to investigate migrating over to importlib2 for their Python 2.7 support (or at least supporting it as a debugging option). -- priority: normal -> low ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32145] Wrong ExitStack Callback recipe
Nick Coghlan <ncogh...@gmail.com> added the comment: As per the comment at https://bugs.python.org/issue32445#msg309356, there's a bug in my suggested changes to `ExitStack.pop_all()`: the right method to call is ExitStack.push(), *not* ExitStack.callback() (the latter adds a wrapper function to make the signatures match, but our stored callbacks all already have the right signature). I'm not too fussy about the details of the docstring, but we need to be careful about the guarantees we make to ExitStack subclasses: if the docstring implies that "target.push()" will always be called, then we need to limit the stack stealing behaviour to actual ExitStack instances (which may be a good idea anyway). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32445] Skip creating redundant wrapper functions in ExitStack.callback
Nick Coghlan <ncogh...@gmail.com> added the comment: Ah, you're right, I wasn't thinking clearly when I filed this - the correct public API method to transfer existing exit stack entries to a new stack would be "ExitStack.push()". I'll make a note of that on the original issue. -- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32459] Capsule API usage docs are incompatible with module reloading (etc)
New submission from Nick Coghlan <ncogh...@gmail.com>: After commenting [1] on the fact that the current datetime module C API [2] is problematic due to its reliance on C level global variables, I discovered that this is actually the outcome of our recommended approach to using capsules to export a C API as function pointers: https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module So we first need to fix the documentation to propose a reloading friendly way of using capsules in other extension modules, and then we can then propose updating the public datetime C API accordingly (probably by defining new macros that accept the capsule reference as their first argument). [1] https://bugs.python.org/issue10381#msg309214 [2] https://docs.python.org/3/c-api/datetime.html [3] https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module -- messages: 309266 nosy: brett.cannon, eric.snow, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Capsule API usage docs are incompatible with module reloading (etc) type: behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10381] Add timezone support to datetime C API
Nick Coghlan <ncogh...@gmail.com> added the comment: https://bugs.python.org/issue32459 covers defining a module-reloading-friendly way of using capsules. For this issue, I now think it makes sense to just ignore that problem, and add whatever you need to the existing API. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10381> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10381] Add timezone support to datetime C API
Nick Coghlan <ncogh...@gmail.com> added the comment: On 31 December 2017 at 01:34, Paul Ganssle <rep...@bugs.python.org> wrote: > That said, I think it would be really good if we could get a fast path for > timezone creation and access to the UTC singleton into the Python 3.7 > release. I think it's kind of a big disparity between the Python and C APIs > that's existed for too long already. It turns out the API already *is* exported as a capsule: https://github.com/python/cpython/blob/master/Include/datetime.h#L149 Our general guidance for capsule usage is just outdated, and the datetime API follows that dated advice: https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module I'll file a separate issue for that docs problem later (the tracker is reporting 502 Proxy Error for me right now) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10381> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31975] Add a default filter for DeprecationWarning in __main__
Change by Nick Coghlan <ncogh...@gmail.com>: -- keywords: +patch pull_requests: +4929 stage: needs patch -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31975] Add a default filter for DeprecationWarning in __main__
Change by Nick Coghlan <ncogh...@gmail.com>: -- assignee: -> ncoghlan ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10381] Add timezone support to datetime C API
Nick Coghlan <ncogh...@gmail.com> added the comment: Would it be possible to deprecate (or at least stop enhancing) the current datetime C API and add a new capsule based one instead? We're trying to get extension module authors to *stop* relying on C level globals, since it causes problems with: - memory usage analysis - interpreter reinitialisation - module reloading - subinterpreters Unfortunately, the current design of the datetime C API *requires* the use of C level global state. -- nosy: +ncoghlan ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10381> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.
Nick Coghlan <ncogh...@gmail.com> added the comment: Another point in favour of the JSR approach is that it should make it easier for tools like coverage.py to continue mapping opcode coverage to line coverage. I also like Serhiy's proposed strategy of separating the initial introduction of the compiler based exception handling from the subsequent simplification of the exception handling opcodes. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32145] Wrong ExitStack Callback recipe
Nick Coghlan <ncogh...@gmail.com> added the comment: I'm not clear on what you mean about allowing arbitrary names for the instance creation function - at that point we're back to subclasses not being able to use the default `pop_all()` implementation at all, and needing to duplicate the state transfer logic in the subclass (which we don't provide a public API to do, since the `_exit_callbacks` queue is deliberately private). However, I'm thinking we could potentially change `pop_all` *itself* to accept a target object: def pop_all(self, *, target=None): """Preserve the context stack by transferring it to a new instance If a *target* stack is given, it must be either an `ExitStack` instance, or else provide a callback registration method akin to `ExitStack.callback`. """ if target is None: target = type(self)() exit_callbacks = self._exit_callbacks self._exit_callbacks = deque() if isinstance(target, ExitStack): target._exit_callbacks = exit_callbacks else: for cb in exit_callbacks: target.callback(cb) return target The recipe fix would then be to make `Callback.cancel()` look like: def cancel(self): # We deliberately *don't* clean up the cancelled callback self.pop_all(target=ExitStack()) (Tangent: https://bugs.python.org/issue32445 suggests adding a small optimisation to `ExitStack.callback` to skip adding the wrapper when `args` and `kwds` are both empty) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32445] Skip creating redundant wrapper functions in ExitStack.callback
New submission from Nick Coghlan <ncogh...@gmail.com>: While discussing https://bugs.python.org/issue32145, I noticed that ExitStack.callback *always* adds a wrapper function, even when the `args` and `kwds` parameters are both empty. For plain callbacks that aren't receiving any extra arguments, it would be better to skip adding the redundant wrapper function. -- messages: 309171 nosy: barry, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Skip creating redundant wrapper functions in ExitStack.callback type: performance versions: Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32030] PEP 432: Rewrite Py_Main()
Nick Coghlan <ncogh...@gmail.com> added the comment: _PyCoreConfig.ignore_environment was part of the initial PEP 432 implementation that I wrote. It's that due to the design goal that once the refactoring is complete, an embedding application should be able to control *all* the settings through the config structs, without *ever* touching the global variables directly. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32374] Document that m_traverse for multi-phase initialized modules can be called with m_state=NULL
Nick Coghlan <ncogh...@gmail.com> added the comment: Yep, the requirement for supporting multiple interpreters is just that you either avoid relying on C global state entirely, or else correctly synchronise access to it. Multi-phase initialisation just provides a few nudges in the direction of doing that more consistently. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode
Nick Coghlan <ncogh...@gmail.com> added the comment: (However, the behaviour Steve is describing suggests that sys.path[0] initialisation may have problems on Windows that the test suite isn't picking up - "-I" should *not* add the script directory to the path, and directory execution should always add an absolute path, not a relative one) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32324] [Security] "python3 directory" inserts "directory" at sys.path[0] even in isolated mode
Nick Coghlan <ncogh...@gmail.com> added the comment: When executing a sys.path entry, you're executing that *entire* entry (whether it's a directory or zipfile). This isn't a bug, and it isn't in conflict with the assurances offered by isolated mode (it would only be a problem if running "~/code/mydirectory" added "~/code" to sys.path). -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24991] Define instance mutability explicitly on type objects?
Nick Coghlan <ncogh...@gmail.com> added the comment: Declaring "I intend for instances of this class to be immutable" isn't a fuzzy concept - it's in the same vein as other type hints, like "I intend for this to be a string". The part that's fuzzy is how well Python actually enforces that declaration, and hence the degree to which you can actually rely on it at runtime. In most cases, detecting and reporting *violations* of that intent would be in the realm of typecheckers rather than the language interpeter, but there'd be cases where the interpreter itself could make useful inferences from such a declaration (for example, by prohibiting conventional mutation operations, the way "frozen=True" does for data classes). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24991> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32145] Wrong ExitStack Callback recipe
Nick Coghlan <ncogh...@gmail.com> added the comment: Regarding super().__init__(): I added ExitStack to contextlib2 first, so I was thinking in the Py2/3 compatible subset when I wrote the original docs. We can freely change that for the standard library recipes. Regarding the "how to create a copy" question, while I don't especially like the notion of adding a dedicated semi-public copy method, I think you're right that it may be the best option: 1. Full pickle/copy module support doesn't make sense, since exit stacks are inherently stateful - you can't save them to use later, since you'd need to repeat the setup steps as well, but we don't keep track of what the setup steps actually *were*. 2. `stack.pop_all()` was designed such that if you clone the stack, you ensure that the original stack *won't* call the cleanup callbacks any more. If we were to add a fully public `stack.copy()` method (or `copy.copy(stack)` support via `stack.__copy__()`), then we'd lose that deliberate nudge, and put folks more at risk of "double-free" style bugs, where they run the cleanup functions multiple times. 3. A for-subclasses-only "self._clone()" API could work as follows: def _clone(self, new_instance=None): if new_instance is None: new_instance = type(self)() # Clone state here return new_instance Then subclasses could override *just* the instance creation part by doing: def _clone(self): return super()._clone(self._make_instance()) While also being free to add their own additional state copying code if needed. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"
Nick Coghlan <ncogh...@gmail.com> added the comment: New changeset 9c19b020249c451891affd81751947321a1e6957 by Nick Coghlan in branch 'master': bpo-32002: Refactor C locale coercion tests (GH-4369) https://github.com/python/cpython/commit/9c19b020249c451891affd81751947321a1e6957 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27505] Missing documentation for setting module __class__ attribute
Nick Coghlan <ncogh...@gmail.com> added the comment: This is still a valid docs issue, although PEP 562's module __getattr__ and __dir__ will provide a simpler alternative for most of the cases that previously required setting the __class__ attribute: https://www.python.org/dev/peps/pep-0562/ So I've added https://bugs.python.org/issue32225 as a dependency for this issue, as it will likely make sense to figure out a good docs structure for those changes first, and then see if there's any work left to do specifically for this issue: https://bugs.python.org/issue32225#msg307935 Issue #24991 is a fairly different topic - I've added an extra comment there that should help clarify the actual question/proposal. -- dependencies: +Implement PEP 562: module __getattr__ and __dir__ ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32225] Implement PEP 562: module __getattr__ and __dir__
New submission from Nick Coghlan <ncogh...@gmail.com>: For documentation of this feature, I'd suggest adding a new subsection after https://docs.python.org/3/reference/datamodel.html#customizing-attribute-access (but at the same level), called "Customizing module attribute access". That can then cover defining __getattr__ and __dir__ as module level functions, and also mention setting __class__ (which would be enough to close issue 27505 as well). The new section should explicitly mention that these only affect lookups and modifications made using the attribute access syntax - directly accessing the module globals (whether by code within the module, or via a reference to the module's globals dict) is unaffected. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32225] Implement PEP 562: module __getattr__ and __dir__
Change by Nick Coghlan <ncogh...@gmail.com>: -- nosy: +ncoghlan ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24991] Define instance mutability explicitly on type objects?
Nick Coghlan <ncogh...@gmail.com> added the comment: I updated some of the issue metadata and added a question mark to the issue title to help make it clearer that this would require a PEP level conceptual enhancement to the language, rather than being about documenting an existing concept. PEP 557's data classes take a step in that direction with their "frozen=True" parameter: https://www.python.org/dev/peps/pep-0557/#frozen-instances -- components: +Interpreter Core title: Define instance mutability explicitly on type objects -> Define instance mutability explicitly on type objects? type: -> enhancement versions: +Python 3.8 -Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24991> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31506] Improve the error message logic for object_new & object_init
Nick Coghlan <ncogh...@gmail.com> added the comment: Thanks for the feedback and updates folks! If we decide to make any further changes, I think they will be best handled as a new issue :) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31506] Improve the error message logic for object_new & object_init
Nick Coghlan <ncogh...@gmail.com> added the comment: New changeset 780acc89bccf332d334a27887684cc942eb6 by Nick Coghlan (Sanyam Khurana) in branch 'master': bpo-31506: Improve the error message logic for class instantiation (GH-4740) https://github.com/python/cpython/commit/780acc89bccf332d334a27887684cc942eb6 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options
Nick Coghlan <ncogh...@gmail.com> added the comment: The approach I've taken in my PR is similar to the one that Arfrever proposed (albeit different in the details due to other changes in the startup code since that patch was written). For the embedding case, I've simply noted in the What's New section of the porting guide that embedding applications need to configure a `error::BytesWarning` filter explicitly if they want to treat BytesWarning as errors (in addition to setting the flag to request that the warnings be emitted in the first place). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options
Change by Nick Coghlan <ncogh...@gmail.com>: -- pull_requests: +4647 stage: needs patch -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32002] test_c_locale_coercion fails when the default LC_CTYPE != "C"
Nick Coghlan <ncogh...@gmail.com> added the comment: For the POSIX case, we're going to fix the implementation to always handle that the same way as it does the "C" locale: https://bugs.python.org/issue30672#msg307784 So the main question to address with the refactoring here will be capturing the expected behaviour for the 'locale setting is an empty string' case. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32002> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30672] PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X)
Nick Coghlan <ncogh...@gmail.com> added the comment: As discussed in https://bugs.python.org/issue32238 and https://mail.python.org/pipermail/python-dev/2017-December/151105.html, I now think the right answer for the POSIX case is to ensure the legacy locale detection logic always treats that the same way as it does the C locale. LANG=UTF-8 I'm still not sure about - as I understand it, that's a partial locale that only defines LC_CTYPE, which may be why the libc implementation ignores it if you try to set it as a general category default. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30672> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32238] Handle "POSIX" in the legacy locale detection
Nick Coghlan <ncogh...@gmail.com> added the comment: Oops, I forgot I already had an open issue for this discrepancy - I just hadn't decided how to resolve it yet. Marking as a duplicate of https://bugs.python.org/issue30672 -- superseder: -> PEP 538: Unexpected locale behaviour on *BSD (including Mac OS X) ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32238] Handle "POSIX" in the legacy locale detection
Nick Coghlan <ncogh...@gmail.com> added the comment: Added a dependency on https://bugs.python.org/issue32002, as we should finish the test case refactoring proposed there before adjusting the `POSIX` locale handling on macOS and other *BSD systems. -- dependencies: +test_c_locale_coercion fails when the default LC_CTYPE != "C" ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32238] Handle "POSIX" in the legacy locale detection
New submission from Nick Coghlan <ncogh...@gmail.com>: Right now, the legacy locale detection introduced in PEP 538 doesn't trigger for "LANG=POSIX" and "LC_CTYPE=POSIX" on macOS and other *BSD systems. This is because we're looking specifically for "C" as the response from "setlocale(LC_CTYPE, NULL)", which works on Linux (where glibc reports "C" if you configured "POSIX"), but not on *BSD systems (where POSIX and C behave the same way, but are still reported as distinct locales). As per Jakub Wilk's comments at https://mail.python.org/pipermail/python-dev/2017-December/151105.html, this isn't right: we should allow either string to be returned from setlocale, and consider both of them as indicating a legacy locale to be coerced to an explicitly UTF-8 based one if possible. -- components: FreeBSD, Interpreter Core, Unicode, macOS messages: 307781 nosy: ezio.melotti, koobs, ncoghlan, ned.deily, ronaldoussoren, vstinner priority: normal severity: normal stage: test needed status: open title: Handle "POSIX" in the legacy locale detection type: behavior versions: Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32234] Add context management to mailbox.Mailbox
Nick Coghlan <ncogh...@gmail.com> added the comment: I don't know the mailbox API particularly well, but the fact the object offers all three of lock(), unlock() and close() as methods does imply a fair bit of inherent ambiguity. One option would be to offer a module level "mailbox.locked()" API to handle the lock/unlock case, and then have native context management on the mailbox itself that was akin to "contextlib.closing". (Note regarding contextlib.locked(): the reason we don't currently have that is because there's no consistent protocol for locking method names. acquire()/release() and lock()/unlock() would be the most popular pairings, so we could technically offer both "contextlib.acquired()" and "contextlib.locked()", but the duplication still seems a bit dubious to me) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32234> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32229] Simplify hiding developer warnings in user facing applications
Nick Coghlan <ncogh...@gmail.com> added the comment: Note: for consistency with the underlying action names, the API should probably be called "warnings.ignore_warnings". I'd still keep the proposed parameter name as "show" though (and we may want to consider introducing that as a more semantically meaningful alias for "default"). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32229] Simplify hiding developer warnings in user facing applications
Nick Coghlan <ncogh...@gmail.com> added the comment: Warnings aren't off by default in general - we just add implicit "ignore" filters for a few specific types. So the primary functionality is to opt in to hiding *all* warnings, but to do it in a way that can be overridden by PYTHONWARNINGS, the interpreter's "-W" switch and the new "-X dev" mode. For that, the usage looks like: import warnings warnings.hide_warnings() Essentially, it flips the default behaviour over to "ignore everything", but reverts to the regular default if there are any config settings supplied. The odd structure of my opening message arises from the fact that *given* such a modified default, it's then surprisingly tricky to say "hide warnings, except for those from modules I'm responsible for". That latter complication then becomes the rationale for the design of the proposed "show" parameter to carve out exceptions to the overall "hide everything" filter. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32230] -X dev doesn't set sys.warnoptions
Nick Coghlan <ncogh...@gmail.com> added the comment: If we wanted to go that way, then I'd go back to my original code order for - putting the '-X dev' setting first in sys.warnoptions, so both PYTHONWARNINGS and -W options override it. Then https://bugs.python.org/issue32231 would determine the relative precedence of the BytesWarning filter. (I still think the interaction between "-Wd" and "-bb" is weird, but we can argue about that on the other issue). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32231] -bb option should override -W options
Nick Coghlan <ncogh...@gmail.com> added the comment: One potential complication here is that embedding applications would inherit the requirement to do both: Py_BytesWarningFlag = 2; and PySys_AddWarnOption(L"error::BytesWarning"); to request errors. That's probably OK though, since we're getting into pretty esoteric configuration behaviour at that point. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32230] -X dev doesn't set sys.warnoptions
Nick Coghlan <ncogh...@gmail.com> added the comment: Right, I hit some of those corner cases myself before I realised that pymain_add_warnings_options was the right place to inject "default" into sys.warnoptions after your refactoring improvements. It provides a nice pivot point where the command line machinery can decide relative priority and turn things into a neatly ordered list. That gives the following priority order in my PR: - first we add the filters from PYTHONWARNINGS - then we optionally add an extra "default" entry based on core_config->dev_mode (which may be from either PYTHONDEVMODE or from "-X dev") - then we add the filters from "-W" command line options The "last added, first applied" behaviour of "warnings.simplefilter" then means that later entries in that list take precedence over earlier entries. If we go on to also implement https://bugs.python.org/issue32231, then we'd add a 4th step to inject a "default::BytesWarning" or "error::BytesWarning" filter at the end based on cmdline->bytes_warning. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32231] -bb option should override -W options
Nick Coghlan <ncogh...@gmail.com> added the comment: I'm hesitant to put the *true* default filters in sys.warnoptions, as folks use "bool(sys.warnoptions)" as a check for "Were any warning options set via the environment or the command line?", and we don't want to invalidate that use case. However, I'm definitely a fan of having the warnings module *only* look at sys.warnoptions, and requiring *all* command line options to route their filter settings through that channel. https://bugs.python.org/issue32230 adjusts "-X dev" to work that way, and I'm suggesting we do the same here for "-b". That way, we can fully define the relative ordering of PYTHONWARNINGS, "-X dev", "-W", and "-b" inside pymain_add_warnings_options (and only the true default filters will be appended by the warnings module itself). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32230] -X dev doesn't set sys.warnoptions
Nick Coghlan <ncogh...@gmail.com> added the comment: In relation to the utility of sys.warnoptions: it also lets other modules (like the unittest module) inspect the warnings that have been specified on the command line. If it wasn't for that use case, I wouldn't be concerned about the fact that `-X dev` doesn't currently set it. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32231] -bb option should override -W options
Nick Coghlan <ncogh...@gmail.com> added the comment: (From the discussion at https://bugs.python.org/issue32230#msg307721) Another benefit we'd gain from this approach is that we could easily omit the filter entirely in the case where neither -b nor -bb is set: in those situations, BytesWarning won't be emitted at all, so we don't really need to define a filter for it. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32230] -X dev doesn't set sys.warnoptions
Nick Coghlan <ncogh...@gmail.com> added the comment: No, we don't need to worry about BytesWarning if neither -b nor -bb are set, as the interpreter doesn't even emit the warning in that case. The only thing the warnings machinery gets used for is to print the messages and/or raise the exceptions (so it would arguably be clearer to omit the filter entirely in the case where the flag isn't set at all). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32230] -X dev doesn't set sys.warnoptions
Nick Coghlan <ncogh...@gmail.com> added the comment: I filed https://bugs.python.org/issue32231 to cover having -bb always override other warnings settings when it comes to handling BytesWarning. Writing that issue made me realise another quirk with `-X dev` though: as a command line option, it should really take precedence over PYTHONWARNINGS, while remain subordinate to other explicit -W options. I've adjusted the PR to implement that change, but haven't added a test case that ensures the behaviour persists. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32231] -bb option should override -W options
New submission from Nick Coghlan <ncogh...@gmail.com>: When implementing the "-X dev" mode, Victor was asked to make it behave differently from "-Wd", such that "python -bb -X dev" would still raise errors for bytes comparisons. I don't think making "-X dev" and "-Wd" inconsistent with each other is the right way to address that request. Instead, I think we should find a way to make "-bb" *always* take precedence over any supplied "-W" options. One way to do that would be to adopt an approach similar to what I've proposed for "-X dev" in https://bugs.python.org/issue32230: instead of making the warnings module aware of the "-bb" setting, we'd instead adjust the initialisation code to inject "error::BytesWarning" into sys.warnoptions *after* all of the entries from environment variables and the command line. -- messages: 307717 nosy: ncoghlan, vstinner priority: normal severity: normal stage: needs patch status: open title: -bb option should override -W options type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32230] -X dev doesn't set sys.warnoptions
Nick Coghlan <ncogh...@gmail.com> added the comment: It isn't good to have "-X dev" do magical things that can't already be replicated with other options. If we want "-bb" to take precedence over the passed in "-W" settings (which I agree would be a reasonable change), we should make that change universally, not restrict it to "-X dev". -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32230] -X dev doesn't set sys.warnoptions
Change by Nick Coghlan <ncogh...@gmail.com>: -- keywords: +patch pull_requests: +4637 stage: test needed -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32230] -X dev doesn't set sys.warnoptions
Nick Coghlan <ncogh...@gmail.com> added the comment: Note that this change will make "-X dev" effectively treat "-bb" and "-b" as equivalent, the same way "-Wd" already does. I figure that's OK, since it means the runtime behaviour will match the documentation (which says that "-X dev" implies "-Wd". -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32230] -X dev doesn't set sys.warnoptions
New submission from Nick Coghlan <ncogh...@gmail.com>: The `-X dev` option is currently integrated directly with the warnings module, rather than working indirectly through `sys.warnoptions`. This means that any third party code that currently checks sys.warnoptions will need to be updated to check sys.flags.dev_mode as well. Rather than doing that, I propose that we instead change the way dev mode works to *literally* be equivalent to `-Wdefault`, and remove the direct integration with the warnings machinery. (PR for that coming shortly) -- assignee: ncoghlan messages: 307709 nosy: ncoghlan, vstinner priority: normal severity: normal stage: test needed status: open title: -X dev doesn't set sys.warnoptions type: behavior versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6531] atexit_callfuncs() crashing within Py_Finalize() when using multiple interpreters.
Nick Coghlan <ncogh...@gmail.com> added the comment: See also https://bugs.python.org/issue31901, which reached a similar conclusion to this discussion (i.e. atexit functions should be run when the subinterpreter goes away). -- nosy: +ncoghlan ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue6531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32229] Simplify hiding developer warnings in user facing applications
New submission from Nick Coghlan <ncogh...@gmail.com>:
One of the observations coming out of the PEP 565 discussions is that it's
surprisingly tricky to opt-in to getting all warnings from a particular package
and its subpackages, while opting out of warnings in general.
The simplest approximation is to do the following:
if not sys.warnoptions:
warnings.simplefilter("ignore")
warnings.filterwarnings("default", module="app_pkg.*")
That shows warnings for any module or package starting with `app_pkg`. A
stricter filter that avoided warnings from top-level packages that merely
shared the prefix would look like:
if not sys.warnoptions:
warnings.simplefilter("ignore")
warnings.filterwarnings("default", module="^app_pkg(\..*)?$")
It could be helpful to encapsulate that logic in a more declarative utility
API, such that applications could do the following:
import warnings.
warnings.hide_warnings()
Or:
import warnings.
warnings.hide_warnings(override_warnoptions=True)
Or:
import warnings.
warnings.hide_warnings(show=["app_pkg"])
Proposed API:
def hide_warnings(*, show=(), override_warnoptions=False):
if override_warnoptions or not sys.warnoptions:
simplefilter("ignore")
for pkg_name in show:
pkg_filter = _make_regex_for_pkg(pkg_name)
filterwarnings("default", module=pkg_filter)
--
messages: 307701
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Simplify hiding developer warnings in user facing applications
type: enhancement
versions: Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32229>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31506] Improve the error message logic for object_new & object_init
Nick Coghlan <ncogh...@gmail.com> added the comment: Aye, I think Sanyam's proposed messages look good, and the "C().__init__() takes no arguments" wording is easier to follow than my suggested "C.__init__() takes exactly one argument" wording (as interpreting the latter currently requires noticing that it's referring to the *unbound* method taking one argument: the instance). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20891] PyGILState_Ensure on non-Python thread causes fatal error
Nick Coghlan <ncogh...@gmail.com> added the comment: +1 for making this change 3.6+ only. Victor, could you run your patch through the performance benchmarks? While I suspect Antoine is right that our current GIL management heuristics will mean we don't need the lazy initialisation optimisation any more, it's still preferable to have the specific numbers before merging it. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)
Nick Coghlan <ncogh...@gmail.com> added the comment: Prohibiting strings and bytes on the grounds of "Yes they're iterable, but are more likely intended as atomic here, so treat them as ambiguous and refuse to guess" would be fine. (Although I'll also note the classifier case will already fail on upload, since they won't be valid classifiers) The only part I'm not OK with is upgrading a historically unenforced type restriction that only sometimes causes problems into an eagerly enforced one that breaks currently working code. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue19610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell
Nick Coghlan <ncogh...@gmail.com> added the comment: Thanks for the issue report! The fix will be released in 3.6.4 and 3.7.0a3 (both of which are expected to be later this month). -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell
Nick Coghlan <ncogh...@gmail.com> added the comment: New changeset c8f32aae0aa173e122cf4c0592caec620d0d1de9 by Nick Coghlan in branch '3.6': [3.6] bpo-32176: Set CO_NOFREE in the code object constructor (GH-4684) https://github.com/python/cpython/commit/c8f32aae0aa173e122cf4c0592caec620d0d1de9 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)
Nick Coghlan <ncogh...@gmail.com> added the comment: I'd prefer to see this change go in the other direction: instead of enforcing eager type checks, we should be unconditionally wrapping the given values in a "list(arg)" call, such that more typical iterable duck-typing behaviour applies. That will transparently fix any code that isn't already passing a list, will ensure that internal code can safely assume that the instance *attributes* are always lists (no matter what the caller passes in), and means that even when the caller is passing in a list, the instance will have its own copy (rather than retaining a reference to the caller's copy). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue19610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29710] Incorrect representation caveat on bitwise operation docs
Nick Coghlan <ncogh...@gmail.com> added the comment:
I like Mark's phrasing as well. For precision, I'd still like to give an exact
algorithmic formulation of what "large enough" means in this context, though.
Something like:
Each bitwise operation has the same result as though carried out in two's
complement using a bit-width that's large enough to represent the inputs.
("Large enough" for this purpose is ``1 + max(x.bit_length(), y
.bit_length()``, with the extra bit being needed to handle sign extension
appropriately)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue29710>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32192] Provide importlib.util.lazy_import helper function
Nick Coghlan <ncogh...@gmail.com> added the comment: Maintaining the actual implementation as a third party module seems like a good idea to me, so I'm marking this as a documentation issue instead. The idea would be to add this as an example of a very basic lazy importer under https://docs.python.org/3/library/importlib.html#examples -- assignee: -> docs@python components: +Documentation nosy: +docs@python ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell
Change by Nick Coghlan <ncogh...@gmail.com>: -- pull_requests: +4597 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell
Nick Coghlan <ncogh...@gmail.com> added the comment: New changeset 078f1814f1a4413a2a0fdb8cf4490ee0fc98ef34 by Nick Coghlan in branch 'master': bpo-32176: Set CO_NOFREE in the code object constructor (GH-4675) https://github.com/python/cpython/commit/078f1814f1a4413a2a0fdb8cf4490ee0fc98ef34 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.
Nick Coghlan <ncogh...@gmail.com> added the comment: While there are some good comments in line in the PR, I think it would be helpful if these changes were accompanied by some additions to https://devguide.python.org/compiler/ that explain how the various pieces of the solution work together to manage the execution stack. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.
Nick Coghlan <ncogh...@gmail.com> added the comment: I like this change, and think we should go ahead with it, but just wanted to note that I suspect it may make the "Badly timed signals may lead to __exit__ being skipped even after __enter__ succeeded" problem slightly easier to hit: https://bugs.python.org/issue29988 That's not a new problem though, and this change should make it easier to apply the conventional solutions (i.e. only checking for signals when execution jumps backwards within a function, as well as in function pre-or-post-ambles) -- nosy: +ncoghlan ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell
Change by Nick Coghlan <ncogh...@gmail.com>: -- keywords: +patch pull_requests: +4583 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32176] Zero argument super is broken in 3.6 for methods with a hacked __class__ cell
Nick Coghlan <ncogh...@gmail.com> added the comment:
Given that, I'd say the way to cleanest way to fix this would be to remove
these lines from "compute_code_flags" in compile.c:
if (!PyDict_GET_SIZE(c->u->u_freevars) &&
!PyDict_GET_SIZE(c->u->u_cellvars)) {
flags |= CO_NOFREE;
}
and replace them with a check like the following in PyCode_New just after we
ensure the Unicode string for the filename is ready:
if (!PyTuple_GET_SIZE(freevars) &&
!PyTuple_GET_SIZE(cellvars)) {
flags |= CO_NOFREE;
}
That way CO_NOFREE will be set only when appropriate regardless of how the code
object is created, rather than relying on the caller to set it correctly.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32176>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32192] Provide importlib.util.lazy_import helper function
Change by Nick Coghlan <ncogh...@gmail.com>: -- nosy: +brett.cannon, eric.snow stage: -> needs patch type: -> enhancement versions: +Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32192] Provide importlib.util.lazy_import helper function
New submission from Nick Coghlan <ncogh...@gmail.com>:
While importlib provides all the *pieces* to implement lazy imports, we don't
actually provide a clear way of chaining them together into a lazy import
operation. Without any error checking, that looks like:
import sys
import importlib.util
def lazy_import(name):
spec = importlib.util.find_spec(name)
loader = importlib.util.LazyLoader(spec.loader)
spec.loader = loader
module = importlib.util.module_from_spec(spec)
sys.modules[name] = module
loader.exec_module(module)
return module
>>> lazy_typing = lazy_import("typing")
>>> lazy_typing.TYPE_CHECKING
False
I'm thinking it may make sense to just provide a robust implementation of that,
and accept that it may lead to some bug reports that are closed with "You need
to fix the module you're loading to be compatible with lazy imports"
--
messages: 307370
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Provide importlib.util.lazy_import helper function
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32192>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32145] Wrong ExitStack Callback recipe
Nick Coghlan <ncogh...@gmail.com> added the comment: Hmm, I think that may actually qualify as a bug in the `pop_all()` implementation: https://docs.python.org/3/library/contextlib.html#contextlib.ExitStack.pop_all states that it returns an ExitStack instance, not an instance of the current type. For 3.6 (and hence the online docs), we can fix the recipe to allow for `callback=None` (with the expectation that the callback will be added afterwards). Barry, I'd be interested in your thoughts on what to do for 3.7+ - we can either leave the current behaviour alone, and amend the documentation, or else change the code to call ExitStack directly, rather than type(self). I'm leaning towards only changing the docs as being lower risk - folks may be relying on the current behaviour, so changing it may break their code, whereas changing the docs doesn't risk breaking anything. -- nosy: +barry versions: +Python 3.7 -Python 3.4 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27172] Undeprecate inspect.getfullargspec()
Nick Coghlan <ncogh...@gmail.com> added the comment: Independently of what we eventually decide to do for 4.0, there are some changes we could make at the documentation level to more clearly indicate "Even though this isn't deprecated, you still shouldn't use it for new code": https://bugs.python.org/issue32190 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27172> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32190] Separate out legacy introspection APIs in the inspect docs
New submission from Nick Coghlan <ncogh...@gmail.com>: (Follow up to https://bugs.python.org/issue27172) The deprecation notice on inspect.getfullargspec has been removed, since we want folks porting from Python 2 to rely on it as part of the porting process, rather than feeling they need to upgrade to using inspect.signature() immediately. At the same time, we really don't want folks relying on it for *new* code, since it has some inherent limitations (like failing to distinguish positional-only args from positional-and-keyword ones), and some odd historical quirks (like reporting the bound arg as part of the signature for already bound methods). The subprocess modules clearly separates out the "Older high-level API" https://docs.python.org/3/library/subprocess.html#older-high-level-api to help make it clear that new code should use "subprocess.run" instead. We could potentially add a similar final section to the inspect documentation for "Legacy introspection APIs". That would also be useful if https://bugs.python.org/issue31230 is eventually implemented - the current generator and coroutine specific APIs could be moved down to the legacy section for backwards compatibility maintenance, with the type independent API being preferred for new code. -- assignee: docs@python components: Documentation messages: 307362 nosy: brett.cannon, docs@python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Separate out legacy introspection APIs in the inspect docs type: enhancement versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Nick Coghlan <ncogh...@gmail.com> added the comment: With Serhiy's patch merged, I'm marking this as resolved. Thanks all! https://bugs.python.org/issue32189 is the follow-up issue to turn the warning into an unconditional SyntaxError in 3.8. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32189] SyntaxError for yield expressions inside comprehensions & genexps
New submission from Nick Coghlan <ncogh...@gmail.com>: This is the Python 3.8 follow-up to turn the DeprecationWarning from https://bugs.python.org/issue10544 into an unconditional SyntaxError. -- messages: 307360 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: SyntaxError for yield expressions inside comprehensions & genexps type: behavior versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32189> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Nick Coghlan <ncogh...@gmail.com> added the comment: New changeset 73a7e9b10b2ec9636e3c6396cf7b3695f8ed1856 by Nick Coghlan (Serhiy Storchaka) in branch 'master': bpo-10544: Deprecate "yield" in comprehensions and generator expressions. (GH-4579) https://github.com/python/cpython/commit/73a7e9b10b2ec9636e3c6396cf7b3695f8ed1856 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27172] Undeprecate inspect.getfullargspec()
Nick Coghlan <ncogh...@gmail.com> added the comment: I'll also note that one possible alternative would be to accept Ryan's original proposal, which was to make "skip_bound_arg=False" part of the public API for `inspect.Signature.from_callable`. Keeping `getfullargspec` around (but discouraged for new code), seems nicer to me than doing that, though, since the *only* use case we're aware of for that behaviour toggle is to be able to emulate inspect.getfullargspec() atop inspect.Signature(). TOOWTDI simply doesn't strike me as a good enough reason to break working code in this case - there *is* an obvious way for new code (inspect.signature), and there are plenty of other standard library APIs that we keep around primarily for backwards compatibility reasons, even though we don't necessarily recommend using them any more. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27172> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27172] Undeprecate inspect.getfullargspec()
Nick Coghlan <ncogh...@gmail.com> added the comment: If there was a documented deprecation that said "Use instead", I'd be OK with that. The part I wasn't OK with is multiple projects each copying & pasting their own variant of the getfullargspec code and accessing private inspect module APIs in order to get the old behaviour back. So in order to move this to PyPI instead, we'd need to offer a completely public API that was equivalent to `_signature_from_callable(func, follow_wrapper_chains=False, skip_bound_arg=False, sigcls=Signature)` `inspect.Signature.from_callable(func, follow_wrapped=False)` comes very close, but misses a subtlety where "getfullargspec" will mention "self" for bound methods, even though it's implicitly supplied, and doesn't need to be supplied by the caller. That aspect could potentially just be deprecated outright though, with the PyPI replacement following inspect.signature's behaviour and reporting the actual call signature of the bound method. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27172> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32136] Move embedding tests to their own test module
Change by Nick Coghlan <ncogh...@gmail.com>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32136] Move embedding tests to their own test module
Nick Coghlan <ncogh...@gmail.com> added the comment: New changeset 39f0bb5ad0715dbfc0a2d5dd6d0ddea9e4c65ae2 by Nick Coghlan in branch 'master': bpo-32136: Separate embedding tests from C API tests (GH-4567) https://github.com/python/cpython/commit/39f0bb5ad0715dbfc0a2d5dd6d0ddea9e4c65ae2 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Nick Coghlan <ncogh...@gmail.com> added the comment: As far as I'm aware, there's nothing that specifically promises these constructs will do anything in Py3 at all - the existing behaviour is just an accident of implementation arising from the way nested scopes and yield expressions interact in general. Tinkering with "await" in comprehensions and generator expressions would be different, since PEP 530 actually does make promises about how we expect that to work. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Nick Coghlan <ncogh...@gmail.com> added the comment: Guido, should we write this change up as a PEP, or are you happy to just cover it as a section in the What's New document for 3.7? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Nick Coghlan <ncogh...@gmail.com> added the comment: Cool, if you're OK with that behaviour, it actually makes this a lot easier, since it means: 1. Serhiy's patch is already sufficient for the final hard compatibility break 2. It can be readily adapted to emit either DeprecationWarning or SyntaxWarning for 3.7 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32136] Move embedding tests to their own test module
Nick Coghlan <ncogh...@gmail.com> added the comment: I guess the shorted name would also better match the naming scheme used for the C API test module: Modules/_testcapi.c -> Lib/test/test_capi.py Progams/_testembed.c -> Lib/test/test_embed.py -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32136] Move embedding tests to their own test module
Change by Nick Coghlan <ncogh...@gmail.com>: -- keywords: +patch pull_requests: +4495 stage: needs patch -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32096] Py_DecodeLocale() fails if used before the runtime is initialized.
Nick Coghlan <ncogh...@gmail.com> added the comment: Successful test run on the Debian machine that failed above: * http://buildbot.python.org/all/#/builders/27/builds/242 And for the macOS Tiger machine: * http://buildbot.python.org/all/#/builders/30/builds/227 So I think we can call the regression fixed, which is where we wanted to get to before the next alpha release. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32136] Move embedding tests to their own test module
Nick Coghlan <ncogh...@gmail.com> added the comment: As noted in https://bugs.python.org/issue32096#msg306989, it would also be good to ensure that the full traceback from a failed `_testembed` call is always visible when running in verbose mode. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32096] Py_DecodeLocale() fails if used before the runtime is initialized.
Nick Coghlan <ncogh...@gmail.com> added the comment: Looking more closely at the code, I've realised Victor's right - there's no way for Py_DecodeLocale() to accidentally trigger an attempt to import the "encodings" module. Instead, the error is likely coming from the init_sys_streams step towards the end of the initialization process. The way the embedded test cases are currently being run unfortunately truncated that traceback. Rather than trying to improve the test case error reporting under the scope of this issue, I've instead filed https://bugs.python.org/issue32136 to cover factoring the runtime embedding tests out to their own test file. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
