Nick Coghlan added the comment:
Note that as far as I'm aware, AIX doesn't actually provide any of our coercion
target locales yet, so the question in my previous comment is about how we want
3.7.x releases to behave on AIX if IBM *do* introduce a C.UTF-8 locale.
The main argumen
Changes by Nick Coghlan :
--
stage: -> needs patch
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue30836>
___
___
Python-bugs-list
Nick Coghlan added the comment:
That part of the PEP was never implemented - relative imports have never been
allowed to cross package boundaries in practice (which is also why "from .
import sys" doesn't work as an equivalent to "import sys" at the interactive
prompt
Nick Coghlan added the comment:
The core motivation driving the original refactoring was to better understand
and consolidate our runtime state in order to clarify what the GIL is actually
protecting (aside from the reference counts). That then turned out to have
surprising performance
Nick Coghlan added the comment:
I don't think we're that strict with SystemError - once folks are messing about
with deleting things from the sys module, they *are* writing their own system
level code, and may end up provoking SystemError if they corrupt the
interpreter state in t
Nick Coghlan added the comment:
To summarise what the attached source archive is doing, module1.py is
essentially:
import sys
del sys.modules(__package__)
from . import module2
So the only way to trigger this is by corrupting the import state, which seems
like an appropriate use
Nick Coghlan added the comment:
If there are intermittent concurrent problems associated with this behaviour, I
think that may be a sign that the current management of the per-module import
locks is inadequate, since it isn't adequately accounting for direct
manipulation of sys.modul
Nick Coghlan added the comment:
OK, so at least for 3.7, we'll replace the SystemError with a recursive import
of the missing parent package, just as we'd expect to see with an absolute
import.
I'm classing this as "Won't fix" for the native import system in 2.7
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue30836>
___
___
Python-bugs-list mailing list
Unsubscrib
Nick Coghlan added the comment:
Indeed, Serhiy's been stress-testing some bits of the import system, and
finding a few holes made possible by the shift away from a single global import
lock to per-module locks. (Issue 30876 is another example of that)
Nothing immediately comes to mind
Nick Coghlan added the comment:
No, there's no global lock on the import system these days.
Instead, imports are supposed to be atomic on a per-module basis, but issue
30814 showed that some of the accesses to the shared state management (which
*is* still supposed to be protected b
Nick Coghlan added the comment:
I'm about to head to bed so I'll get back to this discussion tomorrow, but in
the meantime: Victor, maybe it would make sense to reformulate your reproducer
as a monkeypatch for _find_and_load_unlocked() that injects the 10 ms sleep
from the test
Nick Coghlan added the comment:
Based on https://github.com/python/cpython/pull/2646/files#r126574323, I'm
actually thinking along different lines: I'm starting to think we should move
the current sys.modules to sys._modules, and make sys.modules a synchronised
wrapper that does the
Nick Coghlan added the comment:
The fix is unintrusive enough that I'm +1 for also fixing it in 3.6 and 3.5.
Trying to fix it in 2.7 would likely be more trouble than it's worth, but I
also wouldn't be opposed to fixing it there if you or anyone else w
Nick Coghlan added the comment:
I've added a second answer to the referenced Stack Overflow issue that attempts
to more clearly explain what is going on:
https://stackoverflow.com/questions/43393764/python-3-6-project-structure-leads-to-runtimewarning/45070583#45070583
(The problem the
Changes by Nick Coghlan :
--
nosy: +kushal.das
___
Python tracker
<http://bugs.python.org/issue30925>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
nosy: +kushal.das, ncoghlan
___
Python tracker
<http://bugs.python.org/issue30924>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Nice :)
With the legacy code cleanups merged, I'd say the next step would be to update
the PEP with the simplified API and the explanation for why the removed
functions are no longer needed (i.e. we're making native TSS support a hard
dependen
Changes by Nick Coghlan :
--
pull_requests: +2777
___
Python tracker
<http://bugs.python.org/issue30836>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
New changeset f0b6a261bb8cbede42296e0cc70956fb3b9a6cf7 by Nick Coghlan in
branch 'master':
bpo-30836: fix test_c_locale_coercion on AIX (GH-2713)
https://github.com/python/cpython/commit/f0b6a261bb8cbede42296e0cc70956
Nick Coghlan added the comment:
This particular test passed on the custom AIX buildbot prior to merging (other
tests still have issues on AIX, though, so that buildbot remains red overall).
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -&g
Nick Coghlan added the comment:
I agree with Raymond here - the standard library's startup benchmarks are *NOT*
normal code execution paths, since normal code execution is dominated by the
actual operation being performed, and hence startup micro-optimizations vanish
into the
Nick Coghlan added the comment:
Folks, you're talking about removing a *public*, *documented* API from the
standard library. The onus would thus be on you to prove *lack* of use, *and*
provide adequate justification for the compatibility break, not on anyone else
to prove that
Nick Coghlan added the comment:
So unless and until he gets overruled by Guido, Raymond's decision to reject
the proposed change stands.
--
resolution: -> rejected
stage: -> resolved
status: open -> closed
___
Python
Nick Coghlan added the comment:
There's a path for escalation when you disagree with the decision of a
module/API maintainer (in this case, Raymond): bringing the issue closure up on
python-dev for wider discussion.
It *isn't* repeatedly reopening the issue after they have already
Nick Coghlan added the comment:
Check the issue history - the issue has been rejected by Raymond, and then
reopened for further debate by other core developers multiple times.
That's not a reasonable approach to requesting reconsideration of a module/API
maintainers design decisio
Nick Coghlan added the comment:
Yes, I'm saying you need a really long justification to explain why you want to
break backwards compatibility solely for a speed increase.
For namedtuple instances, the leading underscore does *NOT* indicate a private
attribute - it's just ther
New submission from Nick Coghlan:
The package installation docs at
https://github.com/python/cpython/blob/master/Doc/installing/index.rst have a
section on "Common Installation Issues":
https://docs.python.org/3/installing/#common-installation-issues
A new entry should be add
Nick Coghlan added the comment:
Are you able to confirm the version of setuptools involved is the same in both
cases?
The reason I ask is that the interaction between pkg_resources-style namespace
packages and native ones is known to be temperamental
(https://packaging.python.org/guides
Nick Coghlan added the comment:
At the Python level, the rules are simple: the first directory on sys.path that
contains an __init__.py file is identified as a self-contained package. It is
then up to that __init__.py file to emulate namespace package behaviour (by
extending __path__) if
Nick Coghlan added the comment:
New changeset b3527bfefd7a0188d43a2d7515ac6addd97a8202 by Nick Coghlan
(Nicholas) in branch 'master':
bpo-30964: Mention ensurepip in package installation docs (GH-2786)
https://github.com/python/cpython/commit/b3527bfefd7a0188d43a2d7515ac6a
Changes by Nick Coghlan :
--
stage: needs patch -> backport needed
___
Python tracker
<http://bugs.python.org/issue30964>
___
___
Python-bugs-list mai
Nick Coghlan added the comment:
New changeset 82a77d38d6dc7df740e7b01b66aeff433730e9ca by Nick Coghlan
(Nicholas) in branch '2.7':
[2.7] bpo-30964: Mention ensurepip in package installation docs (GH-2795)
https://github.com/python/cpython/commit/82a77d38d6dc7df740e7b01b66aeff
Nick Coghlan added the comment:
New changeset df5837b5a916aac645087ae02c44e88ff77024ef by Nick Coghlan
(Nicholas) in branch '3.6':
[3.6] bpo-30964: Mention ensurepip in package installation docs (GH-2797)
https://github.com/python/cpython/commit/df5837b5a916aac645087ae02c44e8
Nick Coghlan added the comment:
Thanks for the contribution & backports!
--
stage: backport needed -> resolved
___
Python tracker
<http://bugs.python.org/
Nick Coghlan added the comment:
This is a result of a known quirk in the way sys.path entry execution works:
the search for "__main__.py" isn't constrained specifically to sys.path[0].
That's almost entirely a bad thing, but I'd been ignoring it because I hadn&#x
Nick Coghlan added the comment:
Checking how we do it elsewhere, `NB_SLOT(nb_rshift)` looks like the right
replacement.
That's a compiler-dependent struct field offset calculation, so a discrepancy
there could easily be the cause of a Windows-only fa
Nick Coghlan added the comment:
This looks like the right technical fix to me (see
https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-prefix), but I'd
like Donald to confirm that before we merge anything.
Making this change will also require an update to the ensurepip docs:
New submission from Nick Coghlan:
On current Fedora systems, test_ossaudiodev is implicitly skipped even when the
audio resource is enabled due to the absence of the `/test/dsp` device:
```
$ ./python -m test -v -uaudio test_ossaudiodev
[...]
0:00:00 load avg: 0.33 [1/1] test_ossaudiodev
Nick Coghlan added the comment:
Adding Matthias to the nosy list as Debian Python maintainer.
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue31
Nick Coghlan added the comment:
This is a known limitation of the import caching mechanism, and is the key
reason
https://docs.python.org/3/library/importlib.html#importlib.invalidate_caches is
offered as a supported public API.
Ideally, the code that is dynamically creating packages at
Nick Coghlan added the comment:
Van, could you take a look at Senthil & Mariatta's questions above regarding
our handling of the copyright year in CPython's module headers?
--
nosy: +ncoghlan, vanl
___
Python tracker
<http:
Nick Coghlan added the comment:
Checking older versions of the docs, it looks like we simply haven't reworded
those docs since Python 2.0 (when the "list" of the 1.5 docs became "sequence"
for 2.0).
So I think the most appropriate resolution here would be to re
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue30681>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue30988>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue30701>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Tagging Petr Viktorin and Matthias Klose, as this may impact distro builds of
3.5.4 that run the tests over the installed version rather than directly from
the VCS checkout.
It would be slightly helpful to not have to carry the "fix Python's self-tes
Nick Coghlan added the comment:
I've added Greg to the nosy list and filed an issue with subprocess32 about
this: https://github.com/google/python-subprocess32/issues/30
I did that mainly to make sure they don't inadvertently backport this
regression, but also to ask if subproce
Nick Coghlan added the comment:
I don't think the changes created the bug, but I do think the new tests to
provoke the other race conditions made it easier for the test suite to hit this
race as well.
--
___
Python tracker
<http://bugs.py
Nick Coghlan added the comment:
Issue filed with six about this: https://github.com/benjaminp/six/issues/207
It turns out to be somewhat timely on that side as well, as it turns out that
six has a not-yet-released change adding "six.moves.commands", which doesn't
currently a
Nick Coghlan added the comment:
While I agree the line is blurry, extending automatic disassembly to cover new
types is currently still considered a new feature in the dis module rather than
a bug in the addition of those new types to the language.
Whether or not that's the *right* polic
New submission from Nick Coghlan:
In reviewing the PR for issue 31183, I noticed that the criteria for deciding
which values to disassemble when disassembling a namespace (objects with a
__dict__ attribute) has gotten out of sync with the criteria used by the dis()
itself.
The problem is
Nick Coghlan added the comment:
Note that the current dis._get_code_object() helper doesn't *quite* cover this,
as it will implicitly compile raw strings, which isn't the desired behaviour
for this use case.
--
___
Python trac
Nick Coghlan added the comment:
Another refactoring point that came up in the same discussion: it might be nice
if the objects that expose code attributes all offered a read-only __code__
property, rather than requiring the dis module (and other consumers) to be
aware of all the different
New submission from Nick Coghlan:
https://bugs.python.org/issue26470 updated the ssl and hashlib modules in 2.7
and 3.5+ to be compatible with OpenSSL 1.1.0.
However, it's currently unclear what the *minimum* versions actually are for
platforms that want to drop support for OpenSSL 1.0.x
Nick Coghlan added the comment:
I'm marking this as Python 3.7 only, not because I don't think it's a bug, but
because getpath.c is a maintainability nightmare and I strongly prefer we avoid
going anywhere near it in maintenance releases :)
Targeting Python 3.7+ also means we
Nick Coghlan added the comment:
If you have access to modify PYTHONPATH at all, you can already shadow almost
all standard library modules:
$ PYTHONPATH=/MY_CHOSEN_DIRECTORY python3 -m site
sys.path = [
'/home/ncoghlan',
'/MY_CHOSEN_DIRECTORY',
'/usr/lib64
Nick Coghlan added the comment:
Itamar wrote up a post describing the GC variant of this problem in more
detail: https://codewithoutrules.com/2017/08/16/concurrency-python/
In particular, he highlighted a particularly nasty action-at-a-distance variant
of the deadlock where:
1. Someone
Nick Coghlan added the comment:
For ease of reference, I separated out the idea of a common __code__ attribute
to its own RFE: https://bugs.python.org/issue31230
--
___
Python tracker
<http://bugs.python.org/issue31
New submission from Nick Coghlan:
As covered in issue 31183, correctly disassembling functions,
generator-iterators, coroutines, and async generator-iterators currently
requires checking for 4 different attributes:
* __code__ (functions)
* gi_code (generator iterators)
* cr_code (coroutines
Nick Coghlan added the comment:
New changeset fe2b56ab9212c1cf19c48b848fa60f7f201c366f by Nick Coghlan
(syncosmic) in branch 'master':
bpo-31183: `dis` now handles coroutines & async generators (GH-3077)
https://github.com/python/cpython/commit/fe2b56ab9212c1cf19c48b848f
Nick Coghlan added the comment:
I think there's a strong case for a generic __frame__ attribute, since there
are plenty of useful things you can do given "object with a linked frame" as a
protocol (like extract the current locals namespace). We may even want to
include trace
Nick Coghlan added the comment:
Actually, __async_return__ would be applicable for the synchronous generator
case as well, since it would link to the generator containing the `yield from`
expression.
--
___
Python tracker
<http://bugs.python.
Nick Coghlan added the comment:
Slight amendment: `__delegated_to__` and `__returns_to__` might be better names
for the doubly-linked list of the async call chain.
"__async_call__" and "__async_return__" both have the problem that they look
like imperative commands (sinc
Nick Coghlan added the comment:
If we end up deciding some of this information might be useful to end users as
well, it would be reasonable to extend "python -m sysconfig" to report it,
perhaps with the extra imports gated behind a command line option.
--
nosy:
Nick Coghlan added the comment:
Checking the merged implementation locally, I belatedly noticed that we forgot
the trailing question mark on the question:
```
>>> import sys
>>> print >> sys.stderr
Traceback (most recent call last):
File "", line 1, in
Typ
New submission from Nick Coghlan:
https://bugs.python.org/issue30721 introduces a new custom error message, such
that in 3.7+ "print >> sys.stderr" will report:
```
>>> import sys
>>> print >> sys.stderr
Traceback (most recent call last):
File "
Nick Coghlan added the comment:
Note that I filed a separate issue to ask Ned about potentially backporting
this to 3.6: https://bugs.python.org/issue31232
--
___
Python tracker
<http://bugs.python.org/issue30
Nick Coghlan added the comment:
New changeset a7c449b8c08933deabcf329fb74ed1336f6db34f by Nick Coghlan (Sanyam
Khurana) in branch 'master':
bpo-30721: Add missing '?' to new error message (GH-3131)
https://github.com/python/cpython/commit/a7c449b8c08933deabcf
Nick Coghlan added the comment:
And done - thanks folks!
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
I agree https://bugs.python.org/issue31197 is orthogonal - refactoring the
current logic is useful regardless of what we do at the object attribute layer.
Regarding __delegated_to__/__returns_to__, the reason I like *not* having
"async" in the attri
Nick Coghlan added the comment:
The condition we (mostly Serhiy) came up with for the check is actually kinda
neat, since it's based on the value of the LHS and is hard to trigger
accidentally:
```
>>> printf = print
>>> print = 10
>>> print >> 1
5
>&
Changes by Nick Coghlan :
--
pull_requests: +3192
___
Python tracker
<http://bugs.python.org/issue30721>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
pull_requests: +3191
___
Python tracker
<http://bugs.python.org/issue31232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
+1 for treating Queue.put() specifically as the case to be handled, as that's
the mechanism that can be used to *avoid* running complex operations directly
in __del__ methods and weakref callbacks.
For testing purposes, the current deadlock can be rel
Nick Coghlan added the comment:
New changeset 1a05e87ec75436d818f05a5dabcecaea67334cbd by Nick Coghlan in
branch '3.6':
[3.6] bpo-31232: Backport custom print rshift message (GH-3155)
https://github.com/python/cpython/commit/1a05e87ec75436d818f05a5dabceca
Nick Coghlan added the comment:
New changeset 1a05e87ec75436d818f05a5dabcecaea67334cbd by Nick Coghlan in
branch '3.6':
[3.6] bpo-31232: Backport custom print rshift message (GH-3155)
https://github.com/python/cpython/commit/1a05e87ec75436d818f05a5dabceca
Nick Coghlan added the comment:
Thanks all!
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
Would it be feasible to change the behaviour of non-reentrant locks such that:
1. They *do* keep track of the owning thread
2. Trying to acquire them again when the current thread already has them locked
raises RuntimeError instead of deadlocking the way it does
Changes by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
Thanks for the patch!
Issue 31230 is a follow-up issue looking at whether or not we should define a
general "__code__" attribute as a general purpose introspection protocol for
disassembly support (amongst other generalisations of state introspectio
Nick Coghlan added the comment:
I started a local PR at https://github.com/ncoghlan/cpython/pull/1/files to
explore what this might look like in practice.
I think that what I've done so far shows that generic __frame__ and __running__
attributes would be sufficient to extend the in
Nick Coghlan added the comment:
While it *may* be possible to do something simpler for test purposes where
performance isn't a major concern, fully supporting type() level mocking
basically requires bringing the equivalent of wrapt object proxies into the
standard library:
Nick Coghlan added the comment:
Thanks for the suggestion, but I'm closing this RFE, as there are two strong
arguments against it: one related to implementation feasibility, and one
related to the nature of what super() *does*.
The feasibility argument is that the compiler doesn't
Nick Coghlan added the comment:
The reason we don't always drop the importlib frames in general is because we
need them when we're debugging importlib itself, as well as when folks are
calling into it directly. However, I think it would be reasonable to do it
unconditionally for
Nick Coghlan added the comment:
Note that we're highly unlikely to ever accept a PEP to provide this natively,
as it couples the process of runtime module loading too tightly to what should
be private organisational details of the software publication process (domain
names, repository
Changes by Nick Coghlan :
--
versions: +Python 2.7, Python 3.6
___
Python tracker
<http://bugs.python.org/issue31271>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
The proposed fix looks good to me, but it did make me wonder if we might have a
missing check in the other direction as well. However, it looks like that case
is already fine:
```
>>> hex_codec = codecs.lookup("hex")
>>> hex_co
New submission from Nick Coghlan:
This is a proposed traceback module enhancement deriving from the "python -m"
traceback verbosity discussion in issue 16217.
Specifically, I'm thinking a good way of cleaning up those tracebacks would be
to use `TracebackException.forma
Nick Coghlan added the comment:
Aye, separating the two discussions is a good idea. I've filed
https://bugs.python.org/issue31299 for the traceback RFE, and added it as a
dependency here.
--
dependencies: +Add "ignore_modules" option to TracebackE
Nick Coghlan added the comment:
Regarding directories and zipfiles, runpy._run_module_as_main also handles
those - the CLI effectively transforms directory and zipfile execution into a
"python -m __main__" call with a suitably adjusted sys.path[0] entry (i.e. the
given direct
Nick Coghlan added the comment:
Greg Smith & I are looking at this at the core dev sprint, and we think some
variant of the "atomic until" idea should work, but there's a prerequisite
change to the way "async with" works: the "GET_AWAITABLE" opcodes ne
New submission from Nick Coghlan:
In order to test issue 29988 reliably, we want the ability to run trace hooks
for every opcode in a frame, rather than for every line.
The simplest API we've been able to come up with for that is a
"f_trace_opcodes" attribute on the frame wh
Nick Coghlan added the comment:
https://github.com/ncoghlan/cpython/pull/2/files provides a test case that
reliably reproduces the problem for both synchronous and asynchronous context
managers.
It's inspired by Nathaniel's proposal above, but relies on a modified version
of sy
Changes by Nick Coghlan :
--
dependencies: +f_trace_opcodes frame attribute to switch to per-opcode tracing
___
Python tracker
<http://bugs.python.org/issue29
Nick Coghlan added the comment:
Right, if you look at the comments in the draft test case, we realised there
are three things we currently need to protect:
1. POP_BLOCK -> WITH_CLEANUP_START (synchronous CM)
2. POP_BLOCK -> GET_AWAITABLE (asynchronous CM)
3. GET_AWAITABLE -> Y
Nick Coghlan added the comment:
https://github.com/ncoghlan/cpython/pull/2/files now adds a DEFER_PENDING_UNTIL
opcode that relies on the jump offset calculation machinery to decide how long
pending call processing should be deferred.
Right now, the test case is also emulating the "
Nick Coghlan added the comment:
Steve's also requested the ability to *turn off* line debugging, and I'm
thinking it may make sense to allow all four configurations:
* both line and opcode events disabled
* only getting one or the other
* getting both kinds of event
Opcode ev
Changes by Nick Coghlan :
--
nosy: +steve.dower
___
Python tracker
<http://bugs.python.org/issue31344>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
I've updated the draft PR to actually raise the exception from a pending call
hook, rather than emulating it in a trace hook.
This was a bit trickier than I first expected, as it required moving the trace
hook itself into C, as otherwise the "return
1701 - 1800 of 6301 matches
Mail list logo
