Nick Coghlan added the comment:
The updated PR fully resolves the synchronous CM case by switching to using
threading.Lock as the test CM (as per Nathaniel's original suggestion). Without
that, the pending exception was being processed as soon as __exit__() started
running, so the test f
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue31344>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Nick Coghlan :
--
pull_requests: +3415
___
Python tracker
<http://bugs.python.org/issue31344>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
My posted PR implements the "independent flags" option, where f_trace_lines and
f_trace_opcodes allow per-line and per-opcode events to be requested
independently.
The default is to emit per-line events (as has historically been the case).
--
Nick Coghlan added the comment:
It isn't writing the test case that's the problem - the same technique we're
using for the synchronous CM works for the asynchronous CM as well.
The problem is that unlike the synchronous CM, the DEFER_PENDING_UNTIL opcode
isn't sufficient
Nick Coghlan added the comment:
Regarding the accidental exposure of _Py_CheckRecursionLimit, the main active
usage of the stable ABI that we're aware of is Riverbank's C/C++ binding
generator for PyQt:
http://pyqt.sourceforge.net/Docs/sip4/directives.html#directive-%Module
Nick Coghlan added the comment:
I think you're agreeing with me - we can make synchronous context managers
meaningfully more signal safe (at least for CMs implemented in C, or
precompiled with Cython), but for asynchronous context managers, the only
meaningful defense available is to re
Nick Coghlan added the comment:
Attempting to clarify what Greg & I think the right answer will be for the
async context management case:
https://docs.python.org/3/library/asyncio-eventloop.html#unix-signals
In practice, that would look something like:
```
>>> loop = asyncio.g
New submission from Nick Coghlan:
Issue 29988 covers the fact that with the default SIGINT handler installed, a
poorly timed Ctrl-C can lead to context managers failing to even start running
their __(a)exit__ methods, let alone complete them.
For the asynchronous case, the problem is even
Nick Coghlan added the comment:
I've retitled this issue to specifically cover the synchronous signal-safe
context management case and filed issue 31387 to cover making it easy to switch
asyncio over to cooperative SIGINT handling (rather than the default
pre-emptive han
New submission from Nick Coghlan:
As discussed in issue 29988, it's currently difficult to write completely
robust cleanup code in Python, as the default SIGINT handler may lead to
KeyboardInterrupt being raised as soon as *any* Python code starts executing in
the main thread, even when
Nick Coghlan added the comment:
Yes, it could also be done as a temporary global block on all signal and
pending call processing, not just on SIGINT specifically.
Either way, I'll also note that this can be a no-op in any thread other than
the main thread, as those already delegate s
Nick Coghlan added the comment:
I've also filed issue 31388 to cover providing APIs to defer signals and
pending calls when running in the main thread.
--
___
Python tracker
<https://bugs.python.org/is
Nick Coghlan added the comment:
+1 from me for the general idea. As far as where to put it goes, I think the
`gc` module would be the most appropriate home.
--
assignee: ncoghlan ->
components: +Library (Lib)
stage: -> needs patch
___
Nick Coghlan added the comment:
As Serhiy notes, this isn't a bug in the import name resolution, it's a
consequence of the wildcard import in bugtest's __init__.py replacing its own
"bug.foo" submodule attribute with a reference to "bug.foo.foo".
If the st
Nick Coghlan added the comment:
Yes, this will be in the same category as the standard stream redirection
context managers - multi-threaded applications either won't be able to use it,
or else will need to manage access to it somehow.
--
___
P
Nick Coghlan added the comment:
New changeset 5a8516701f5140c8c989c40e261a4f4e20e8af86 by Nick Coghlan in
branch 'master':
bpo-31344: Per-frame control of trace events (GH-3417)
https://github.com/python/cpython/commit/5a8516701f5140c8c989c40e261a4f
Changes by Nick Coghlan :
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
Issue 31388 is also potentially relevant here, as registering a signal handler
for SIGINT isn't sufficient to cover all potential cases were Py_AddPendingCall
gets called. In particular, the tests for issue 29988 use Py_AddPendingCall to
emulate Ctrl-C, r
Nick Coghlan added the comment:
A new issue (depending on this one and potentially on issue 31388) would be
helpful, especially if you were able to use the testing trace hook from this PR
to reproduce the problem.
The reason I've taken the async with change out of this issue is because
Nick Coghlan added the comment:
Nathaniel, actually, I think issue 31387 is the right one to comment on, as
still being able to interrupt long-running loops in synchronous code is a
quality of implementation concern for that RFE.
--
___
Python
Nick Coghlan added the comment:
As per Nathaniel's comments on issue 29988 and 31388, doing this robustly
relies on:
1. the event loop being able to reliably guard itself and __aexit__ method
implementations against interrupts (issue 31388)
2. "async with" statements ensur
Nick Coghlan added the comment:
In addition to adding a test case to ensure exceptions were handled correctly,
I also added test cases for return, break, and continue, and all four new tests
initially failed.
Adding a special case for WITH_CLEANUP_START resolved those, but the tests need
an
Nick Coghlan added the comment:
Yeah, I was already thinking the lookaside table might be a better idea
(similar to co_lnotab replacing the old SET_LINENO opcodes), especially since
that would also provide a quick way of introspecting code objects to see if
they included any try/finally
Nick Coghlan added the comment:
I updated the PR at https://github.com/ncoghlan/cpython/pull/2/files with
another attempt at reinstating the asynchronous CM test case that also tweaks
the eval loop to ensure that the first few opcodes in a function are always
executed before pending calls are
Nick Coghlan added the comment:
This is being proposed for the gc module, not contextlib, so I'm not sure how
the previous comment applies.
This is just a convenience API for folks already doing this kind of
manipulation themselves.
--
___
P
Nick Coghlan added the comment:
Posted as PEP 558:
* https://github.com/python/peps/blob/master/pep-0558.rst
* https://www.python.org/dev/peps/pep-0558/
--
___
Python tracker
<https://bugs.python.org/issue17
Nick Coghlan added the comment:
After drafting PEP 558, briefly chatting about it to Guido, and sleeping on the
topic, I'm wondering if there might be answer that's simpler than any of the
alternatives consider so far: what if PyFrame_FastToLocals added the *cell
objects* to f_loca
Nick Coghlan added the comment:
After chatting to Facebook's Carl Shapiro here at the core dev sprint, I'm
going to start exploring a hopefully more robust white-listing based approach
where we check for pending calls in the following cases:
* the instruction pointer either hasn&#x
Nick Coghlan added the comment:
The same way the dis module does: by looking at the names listed in the various
code object attributes.
If it's listed in co_cellvars, then it's a local variable in the current frame
that's in a cell because it's part of the closure for a
Nick Coghlan added the comment:
I've pushed a variant that relies entirely on checking for instruction pointer
changes, and it seems quite promising. However, a test_io failure introduced by
this variant shows a new way for this version to *create* problems: because of
the shift in th
Nick Coghlan added the comment:
I think a bundled copy as idlelib._pyclbr in the 3.6 branch would be within the
intent of PEP 434.
--
___
Python tracker
<https://bugs.python.org/issue1612
Nick Coghlan added the comment:
Introducing sys.__modules__ doesn't solve the problem, since you'd be able to
recreate the problems Oren reports just by messing with that as well as with
sys.modules.
And we try reasonable hard to protect users from completely breaking the
interpret
Nick Coghlan added the comment:
While I agree changing the default would be risky from a compatibility
perspective, I do think it would be helpful to offer a straightforward way to
filter out transitive imports and other non-public implementation details from
the result of `dir(module)`, and
Nick Coghlan added the comment:
As far the implementation goes, since the `__dir__` overload support in the
`dir()` builtin ignores instance dictionaries, this could be implemented in
module.__dir__ (or object.__dir__) rather than directly in the builtin.
Alternatively, it could use a
Changes by Nick Coghlan :
--
keywords: +patch
pull_requests: +3635
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Changes by Nick Coghlan :
--
keywords: +patch
pull_requests: +3634
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue30744>
___
___
Py
Nick Coghlan added the comment:
https://github.com/python/cpython/pull/3640/files includes a more
automated-tested-friendly version of Armin's deterministic reproducer (the
generator loop uses range() to generator a separate loop counter, and then the
test checks that the incremented cl
Changes by Nick Coghlan :
--
dependencies: +Clarify the required behaviour of locals()
___
Python tracker
<https://bugs.python.org/issue30744>
___
___
Python-bug
Nick Coghlan added the comment:
Status update: I've posted an initial PR to issue 30744 that relies on the
trace hook semantic change proposed in the PEP to resolve the trace hook/cell
reference incompatibility reported there.
That provides confidence that it really is only the semanti
Nick Coghlan added the comment:
Yes, that's one of the goals of the feature: to allow module authors to decide
if they want tab completion for all attributes, or just the public API.
--
___
Python tracker
<https://bugs.python.org/is
New submission from Nick Coghlan:
As described in
https://blog.lerner.co.il/favorite-terrible-python-error-message/, object_new
and object_init currently have "object" hardcoded in the error messages they
raise for excess parameters:
>>> class C: pass
...
>>>
Changes by Nick Coghlan :
--
components: +Interpreter Core
stage: -> needs patch
type: -> enhancement
versions: +Python 3.7
___
Python tracker
<https://bugs.python.org/i
Changes by Nick Coghlan :
--
keywords: +easy (C)
___
Python tracker
<https://bugs.python.org/issue31506>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Fortunately, the logic is already well encapsulated: there's a "if (excess_args
&& (case A || case B)) {... report error ...}" check at the start of each of
object_new and object_init, where "case A" = "the other function i
Nick Coghlan added the comment:
For this issue, I'm not proposing to make any change other than to solve the
specific problem reported in the blog post: when the method itself isn't
overridden, then the error message should report the name of the most derived
class, not "o
Nick Coghlan added the comment:
Specifically this message, where the unwritten rationale is to offer
behavioural consistency across the builtin types that know their own name and
include it in their current repr() output:
https://mail.python.org/pipermail/python-ideas/2011-October/012464.html
Nick Coghlan added the comment:
Those would both report "C() takes no parameters" without further enhancements
(which would be out of scope for this issue).
The proposed improvement here isn't "Let's make the error message exactly
correct in all cases" (that'
Nick Coghlan added the comment:
For write-backs: no, since the interpreter will still write those values back
into the destination cell
For locals display: no, since nothing changes for the handling of fast locals
For closure display: yes as, by default, debuggers will now print the closure
Nick Coghlan added the comment:
That said, bringing over my overall comment from the PR review:
I think the number of additional changes needed in the test suite and the
standard library highlights the compatibility restoration busy-work risks of
actually making this change:
- while
Nick Coghlan added the comment:
New changeset a6c0c0695614177c8b6e1840465375eefcfee586 by Nick Coghlan (Serhiy
Storchaka) in branch 'master':
bpo-31506: Improve the error message logic for object.__new__ and
object.__init__. (GH-3650)
https://github.com/python/cpyt
Changes by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
Reopening, as I was a little hasty with the merge button: the merged PR *also*
changed the `__init__` error message to drop the method name, but I don't think
that's what we want.
I'm also wondering if we should change the up-call case to *alw
Nick Coghlan added the comment:
One place where this came up recently is in working out precisely how a
Python-level subinterpreter API will interact with the threading API:
https://mail.python.org/pipermail/python-dev/2017-September/149566.html
That said, I do agree with Tim that the status
New submission from Nick Coghlan:
object_new and object_init currently use their own argument checking logic, and
hence haven't benefited from the error reporting enhancements in
PyArg_ParseTupleAndKeywords
Compare:
>>> str(1, 2, 3, 4, 5, x=1)
Traceback (most recent call
Nick Coghlan added the comment:
Adding a dependency on issue 31506, as this shouldn't be tackled until those
simpler amendments are resolved.
--
dependencies: +Improve the error message logic for object_new & object_init
___
Python tracke
Nick Coghlan added the comment:
I filed issue 31527 as a follow-up issue to see whether or not it might be
possible to amend the way these custom errors are generated to benefit from the
work that has gone into improving the error responses from
PyArg_ParseTupleAndKeywords
Nick Coghlan added the comment:
Aye, the "C.__new__" example omitting the first arg was just an error in that
example.
And that's a good point about the current "object.__init__()" error message
actually being incorrect, since the *methods* each take exactly one
Nick Coghlan added the comment:
We had the quirks of import related threading deadlocks documented for a long
time, not as a promise, but as a debugging aid (and a recommendation for "don't
do that").
I'd see this as being similar: we'd document that if you're
Nick Coghlan added the comment:
3.4 and 3.5 are in security fix only mode now, so the change won't be
backported there. However, it will be applicable to 2.7, so I've updated the
impacted version list accordingly.
Igor's suggested approach in the PR looks reasonable to me as a
Nick Coghlan added the comment:
New changeset 9adda0cdf89432386b7a0a6199b580d287a1 by Nick Coghlan (Igor
Filatov) in branch 'master':
bpo-31351: Set return code in ensurepip when pip fails (GH-3626)
https://github.com/python/cpython/commit/9adda0cdf89432386b7a0a6199
Nick Coghlan added the comment:
I think the rules for C includes are that `"path/header.h"` looks next to the
current file first, whereas `` looks only in include directories.
However, given your technique of mostly hiding the new directory name from API
consumers, what do yo
Nick Coghlan added the comment:
I didn't know what was possible when I wrote PEP 432 either - instead, I wrote
down an initial concept for what I *wanted*, and then started exploring the
code to find out the barriers to achieving that.
We know enough now to know that original design co
Change by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<https://bugs.python.org/issue17490>
___
___
Python-bugs-list mailing list
Unsubscrib
Nick Coghlan added the comment:
Ah, interesting. https://bugs.python.org/issue30672 covered the fact that this
test was already weird on FreeBSD, but the current status is that it was
expecting BSD variants to act somewhat like Mac OS X, not like Linux.
I'm wondering if we may need to
Nick Coghlan added the comment:
If I've understood https://bugs.python.org/issue35290 and its resolution in
https://github.com/python/cpython/commit/f6e323ce322cf54b1a9e9252b13f93ebc28b5c24
correctly, that's a concrete example of why I consider the early coercion
approach that
Nick Coghlan added the comment:
I still think the current Python 3.7 behaviour makes the CPython runtime a
badly behaved C library, since we may end up changing the active libc locale
even when it isn't the main application, and a change hasn't been explicitly
requested by the emb
Nick Coghlan added the comment:
Aye, the relevant change here would be the fact that -b and -bb now modify
sys.warnoptions, rather than the warnings module being aware of those command
line options specifically: https://docs.python.org/3/whatsnew/3.7.html#warnings
As a result, unittest.main
Nick Coghlan added the comment:
The two errors mean different things: ModuleNotFoundError means literally that
the module could not be found at all (i.e. no import hook offered to try to
load it)
A plain ImportError then means that the module was located, but attempting to
actually load it
Nick Coghlan added the comment:
Note that the above distinction is also the rationale for introducing the new
subtype: so that it's easy to tell the difference between "that module was not
found at all" (ModuleNotFoundError) and "the module was found, but attempting
Nick Coghlan added the comment:
New changeset 5661459f5f508ea4bd24c13cbc861543f283147e by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-11192: Skip unsupported cases in test_socket on AIX (GH-8954)
https://github.com/python/cpython/commit/5661459f5f508ea4bd24c13cbc8615
Nick Coghlan added the comment:
New changeset 22462da70c1ae015a60a7b821547bc6d2b5bc265 by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-27643 - skip test_ctypes test case with XLC compiler. (GH-5164)
https://github.com/python/cpython/commit/22462da70c1ae015a60a7b821547bc
Nick Coghlan added the comment:
New changeset 2062a20641febad5eb9c18d74e1cfb4d7a6e53ed by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-34711: Return HTTPStatus.NOT_FOUND if path.endswith('/') and not a
directory (GH-9687)
https://github.com/p
Nick Coghlan added the comment:
New changeset 259c159fc1faab0dd631d20374842dc0d6a9f145 by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-34897: avoid distutils test error when CXX is not set (GH-9706)
https://github.com/python/cpython/commit/259c159fc1faab0dd631d20374842d
Nick Coghlan added the comment:
New changeset e2926b72488596f59e43c27f3b7cedf0c5b9e88e by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-34373: fix test_mktime and test_pthread_getcpuclickid tests on AIX (GH-8726)
https://github.com/python/cpyt
Nick Coghlan added the comment:
New changeset ed57e13df60ce28ba89bd49c9c5a15b1d9bf79c7 by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-11191: skip unsupported test_distutils case for AIX with xlc (GH-8709)
https://github.com/python/cpyt
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: -Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.or
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
Reviewing the diff at https://github.com/python/cpython/compare/v3.7.1...v3.7.2
the only item I've spotted that seems like it could even plausibly be related
is the tweak at
https://github.com/python/cpython/compare/v3.7.1...v3.7.2
Nick Coghlan added the comment:
Ah, you're right - I missed that the ForceASCII stuff was on the non-Windows
side of an ifdef so it's literally impossible for that change to affect
Windows, not just highly unlikely.
It would be interesting to compare the output of `python -vv` b
Nick Coghlan added the comment:
New changeset b539cef31c060c7eecc331d25a23b80ded0baf08 by Nick Coghlan (Sanyam
Khurana) in branch 'master':
bpo-35614: Fix pydoc help() on metaclasses (#11357)
https://github.com/python/cpython/commit/b539cef31c060c7eecc331d25a23b8
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
To make a potentially viable concrete proposal here, I think a reasonable first
step would be to change the ".pth" file processing code in site.py to emit
PendingDeprecationWarning for the 'if line.startswith(("import ",
"import\
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +11147
stage: test needed -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Nick Coghlan :
--
keywords: +patch, patch, patch
pull_requests: +11147, 11148, 11149
stage: test needed -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Nick Coghlan :
--
keywords: +patch, patch
pull_requests: +11147, 11148
stage: test needed -> patch review
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
dw: we routinely impose new requirements on folks modifying runtime internals
in new feature releases, so the only aspect we missed for this changing is to
explicitly call it out in the Porting section of the Python 3.6 What's New
document as a pote
Nick Coghlan added the comment:
@Rémi Aye, filling out derived slots is one of the things PyType_Ready does.
This would need a discussion on python-dev before going ahead and doing it
though, as the closest equivalent we have to this right now is the "negative"
derivation, where
Nick Coghlan added the comment:
Deriving __int__ from __float__ wouldn't be the right answer, as that can
easily lead to unwanted OverflowError exceptions and other issues.
However, Jeroen's suggested order of checking __index__ then __float__ then
__int__ in _PyTime_FromObject m
Nick Coghlan added the comment:
I'm suggesting PendingDeprecationWarning because we can't *actually* deprecate
anything until we provide a more transparent alternative that offers comparable
functionality, and I haven't seen a credible proposal for a replacement yet.
So
Nick Coghlan added the comment:
Namespace packages in general didn't rely on pth files - only the
setuptools/pkg_resources implementation of them did.
I'll also reiterate that I am *completely* opposed to deprecating the "append
entries to sys.path" usage model, as
Nick Coghlan added the comment:
`site.addsitedir` is called for every site-packages directory (whether global,
within a venv, or at the user level), so my proposal above covers appending
multiple segments.
Linux distros approach to handling this is terrible because they dump all their
Nick Coghlan added the comment:
Note that any PEP I contributed to writing would need to be restricted to
eliminating arbitrary code execution, as I don't think there's anything wrong
with the path extension feature.
--
___
Python track
Nick Coghlan added the comment:
Putting some of my comments here rather than on the PR, as they're design
questions related to "Is the current behaviour actually wrong?" and "Even if
the current behaviour is deemed technically incorrect, is it worth the risk of
changin
Nick Coghlan added the comment:
Aye, we can :)
--
assignee: -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tra
Nick Coghlan added the comment:
Yep, that's a bug in `py`'s module interface emulation - see the last paragraph
in https://docs.python.org/3/reference/import.html#module-spec
--
resolution: -> not a bug
stage: -> resolved
status
1801 - 1900 of 6301 matches
Mail list logo
