Nick Coghlan added the comment:
Closing this without any changes contradicts the answer we gave Ronald on
#35791 that it's expected behaviour for importlib.find_spec() to throw an
exception for already loaded modules without a __spec__ attribute.
So if this stays closed, then we s
New submission from Nick Coghlan :
(Alternate proposal inspired by the discussions in #35806 and #35791)
Currently, a sys.modules entry with no __spec__ attribute will prevent
importlib.util.find_spec() from locating the module, requiring the following
workaround:
def
Nick Coghlan added the comment:
OK, I've filed #35839 to propose falling back to a regular search when the
__spec__ attribute is missing, while treating "obj.__spec__ is None" as a true
negative cache entry.
--
___
Python
Nick Coghlan added the comment:
I'd also suggest that we emit ImportWarning when taking the fallback path,
since we really would prefer that sys.modules entries either have a valid
__spec__, or else explicitly set `__spec__ = None`.
--
___
P
Nick Coghlan added the comment:
#35839 is follow-up enhancement request, proposing that we tweak the
sys.modules handling in find_spec to ignore cache entries that don't have a
__spec__ attribute set.
--
___
Python tracker
&
Nick Coghlan added the comment:
A more recent discussion of this on python-dev:
https://mail.python.org/pipermail/python-dev/2019-January/156095.html
The situation there appears to be a case of "Hand off an OS level thread from
the creating interpreter to a different subinterpreter. A
Nick Coghlan added the comment:
Added Dave Malcolm to the nosy list, as the more recent tracebacks are actually
throwing an exception in the gdb hooks, rather than just failing the expected
output comparison in the test suite.
--
nosy: +dmalcolm
Nick Coghlan added the comment:
+1 for Antoine's comment - while our approach with memoryview has generally
been "If you're doing serious work with n-dimensional data, you still need
NumPy (or an equivalent)", we've also been open to borrowing more NumPy
beh
Change by Nick Coghlan :
--
pull_requests: -11261
___
Python tracker
<https://bugs.python.org/issue27015>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Nick Coghlan :
--
pull_requests: -11260
___
Python tracker
<https://bugs.python.org/issue27015>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Reviewing Rémi's page made me realise that a big part of the root cause here is
pickle support in exceptions predating the introduction of `__getnewargs__` and
`__getnewargs_ex__`.
--
nosy: +ncoghlan
___
P
Nick Coghlan added the comment:
https://github.com/ncoghlan/python-userref/blob/master/ODF/Chapter01_EssentialConcepts.odt
is the Chapter 1 userref link now that the PSF SVN server has shut down.
Depending on what you mean by "Pursuing this...":
1. I'd definitely still
Nick Coghlan added the comment:
(Added Victor, Eric, and Steve to the nosy list here, as I'd actually forgotten
about this until issue #35706 reminded me)
Core of the problem: the embedding APIs don't currently offer a
Windows-compatible way of setting up "use this base Pytho
Nick Coghlan added the comment:
Yeah, I mainly cc'ed Victor and Eric since making this easier ties into one of
the original design goals for PEP 432 (even though I haven't managed to
persuade either of them to become co-authors of th
Nick Coghlan added the comment:
As discussed in
http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html#executing-the-main-module-twice
and https://www.python.org/dev/peps/pep-0395/#why-are-my-imports-broken the
cryptic error message here is due to the relative
Nick Coghlan added the comment:
Cheryl has started the conversion process for the old user reference manuscript
[1], so I think it makes sense to mark this as "postponed" for now, until we
see how far we can get with this more usage-centric level of explanation as a
separate pr
Nick Coghlan added the comment:
Steve, you're describing the goals of PEP 432 - design the desired API, then
write the code to implement it. So while Victor's goal was specifically to get
PEP 540 implemented, mine was just to make it so working on the startup
sequence was less awf
Nick Coghlan added the comment:
Note also that Eric and I haven't failed to agree with Victor on an API, as
Victor hasn't actually written a concrete proposal *for* a public API (neither
as a PR updating PEP 432, nor as a separate PEP).
The current implementation does NOT follow
Nick Coghlan added the comment:
Having types created through the stable ABI potentially be deallocated when
their instances are deallocated is indeed a major problem, and fixing that
seems worth the risk of some types that were designed to handle that become
immortal.
--
nosy
Nick Coghlan added the comment:
Folks use "python -m myproject.mymodule" to run code that they're working on
all the time - it's currently the only way to get sys.path right for cases like
that (otherwise you're exposed to the double import trap, where you can get t
Nick Coghlan added the comment:
I agree the current text is ambiguous given how often folks refer to the
newline escape sequence as a "newline", but it isn't wrong - it's just talking
about escaping literal newlines in your source code like:
>>> "This is a
Nick Coghlan added the comment:
Since I haven't really written them down anywhere else, noting some items I'm
aware of from the Python 3.7 internals work that haven't made their way back
into the PEP 432 public API proposal yet:
* If we only had to care about the pure embed
Change by Nick Coghlan :
--
pull_requests: +11941
___
Python tracker
<https://bugs.python.org/issue35704>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
Paolo: it still won't be completely clear, since there's still the subtle issue
that __new__ is a static method rather than a class method, so the correct
calls up to the base class are respectively:
super(Singleton, cls).__new__(cls) # Static m
Nick Coghlan added the comment:
New changeset 5105483acb3aca318304bed056dcfd7e188fe4b5 by Nick Coghlan (Sanyam
Khurana) in branch 'master':
bpo-31506: Clarify error messages for object.__new__ and object.__init__
(GH-11641)
https://github.com/python/cpyt
Nick Coghlan added the comment:
The revised behaviour now makes the error messages consistent with each other:
>>> class TooManyArgs():
... def __new__(cls):
... super().__new__(cls, 1)
...
>>> TooManyArgs()
Traceback (most recent call last):
File &quo
New submission from Nick Coghlan:
The docs on bitwise operations at
https://docs.python.org/3/library/stdtypes.html#bitwise-operations-on-integer-types
include the caveated sentence:
Negative numbers are treated as their 2’s complement value (this assumes
that there are enough bits so
Nick Coghlan added the comment:
Added 2.7 to the list of affected versions.
Clearly my 2's-complement arithmetic is incredibly rusty, as for some reason I
was thinking "~(-sys.maxint-1)" could overflow, but no, the answer to that is
just "sys.maxint" :)
---
Nick Coghlan added the comment:
An updated reference implementation has been pushed to the
pep538-coerce-c-locale branch in my GitHub fork:
https://github.com/python/cpython/compare/master...ncoghlan:pep538-coerce-c-locale
(That doesn't include Xavier's Android fixes y
Nick Coghlan added the comment:
I'm with Serhiy on this one: if the "re" module isn't using
locale.getpreferredencoding(), then there's something odd going on.
It just sounds like the disconnect on Windows is the opposite of the one we hit
on Linux without Benjamin&#x
Nick Coghlan added the comment:
I think Eryk's diagnosis is correct: this is a straight up bug in the original
patch, where it's missing the check to only use the new logic when in isolated
mode (as it's compensating for the fact that there is no extra sys.path[0]
entry insert
Nick Coghlan added the comment:
Thanks for the explanation - given that, I agree that simply reverting the
attempted test-based fix and instead relying on the issue 20087 updates is the
way to go.
--
___
Python tracker
<http://bugs.python.
Nick Coghlan added the comment:
I just realised I need to add some test cases to
test_importlib/source/test_file_loader.py before merging it, but since Larry
hasn't objected to the proposed approach, I'm going to go ahead and implement
Nick Coghlan added the comment:
Merged (with test cases) in
https://github.com/python/cpython/commit/93602e3af70d3b9f98ae2da654b16b3382b68d50
The test cases even cover ensuring the backwards compatibility also applies to
frozen bytecode :)
--
resolution: -> fixed
stage: patch rev
Nick Coghlan added the comment:
I just merged
https://github.com/python/cpython/commit/93602e3af70d3b9f98ae2da654b16b3382b68d50
as the fix for issue #29537, so 3.5.4+ should handle legacy bytecode files
without any complaints (and redistributors can backport it to 3.5.3 as needed).
For *this
Nick Coghlan added the comment:
Ah, interesting, I didn't know there was a difference between the platforms in
when the placeholder got resolved to a full path.
However, after browsing the code and running some local tests, it seems that
injecting sys.path[0] isn't handled by Py_Ge
Nick Coghlan added the comment:
So a potentially more robust fix here would be to always call
`PySys_SetArgVEx(argc, argv, 0)` rather than the plain `PySys_SetArgV` when we
know we're going to be relying on RunMainFromImporter.
That way RunMainFromImporter could just *always* insert a
Changes by Nick Coghlan :
--
pull_requests: +459
___
Python tracker
<http://bugs.python.org/issue29537>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
As Eryk notes, this has revealed a separate bug in that we don't make the path
absolute when adding to sys.path. However, that's *not* directly related to the
regression, so I'm resisting the temptation to change it here.
Instead, the new test
Changes by Nick Coghlan :
--
pull_requests: +467
___
Python tracker
<http://bugs.python.org/issue29723>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Work in progress PR at https://github.com/python/cpython/pull/571
I also came up with a reasonably straightforward way of defining the desired
"sys.path" initialisation behaviour, which is that the following should all get
the *same* sys.pa
Nick Coghlan added the comment:
Slightly correction, as I didn't have the isolated mode equivalents quite
correct:
python3 -s script_dir/__main__.py
python3 -s script_dir
python3 -I script_dir
Isolated mode still runs the system site.py, which turns out to be signficant
Changes by Nick Coghlan :
--
pull_requests: +472
___
Python tracker
<http://bugs.python.org/issue29319>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
pull_requests: +471
___
Python tracker
<http://bugs.python.org/issue29723>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
OK, https://github.com/python/cpython/pull/575 is the new PR that covers
everything needed to fix the root cause of the problem (which was the entirely
unnecessary add-and-overwrite dance that zipfile and directory executation was
doing for sys.path[0
Changes by Nick Coghlan :
--
versions: +Python 3.7
___
Python tracker
<http://bugs.python.org/issue29723>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Issue 29723 is a follow up issue to this one, where these changes revealed some
latent defects in how sys.path[0] was being initialised in general for
directory and zipfile execution (those defects mean the change committed here
adds an extra directory to
Nick Coghlan added the comment:
I think there's an open issue somewhere pointing out that _iter_file_finder
doesn't handle PEP 420 namespace packages correctly, precisely because it's
still looking for an __init__.py file.
So I'd suggest not worry about changing the __ini
Nick Coghlan added the comment:
For anyone interested in the question of backports, I moved that discussion
over to the contextlib2 tracker:
https://github.com/jazzband/contextlib2/issues/12
--
___
Python tracker
<http://bugs.python.org/issue29
Nick Coghlan added the comment:
If you append ".patch" to a GitHub PR URL, it will give you a patch file that
can be applied to any branch with "git apply".
In this case, the rendered patch is at
https://patch-diff.githubusercontent.com/raw/python/cp
Nick Coghlan added the comment:
Paul Moore reporting on trying out the new PR in
http://bugs.python.org/issue29319#msg289357 and confirmed that it still solves
the originally reported problem in issue 29319.
--
___
Python tracker
<h
Nick Coghlan added the comment:
This RFE is unfortunately based on some incorrect assumptions about the way
Linux kernels use CSPRNGs and entropy pools. Using /dev/random isn't magically
more secure than /dev/urandom, it just makes your applications less reliable
for no good reason.
Nick Coghlan added the comment:
To provide some additional context to that answer: the problem isn't with folks
wanting direct access to their hardware entropy devices as such.
There are plenty of options for that (such as exposing it as a file descriptor
distinct from both /dev/rando
Changes by Nick Coghlan :
--
pull_requests: +515
___
Python tracker
<http://bugs.python.org/issue29656>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
pull_requests: +514
___
Python tracker
<http://bugs.python.org/issue29656>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nick Coghlan:
While backporting issue 29656 to get "make patchcheck" to play nice with git PR
branches, I discovered an incompatibility between the way "git worktree" works
and the assumptions in "patchcheck.py".
Specifically, in a worktree, &
Nick Coghlan added the comment:
http://bugs.python.org/issue29798 is a follow-up issue to make the patchcheck
script compatible with `git worktree`.
--
___
Python tracker
<http://bugs.python.org/issue29
Changes by Nick Coghlan :
--
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/issue29656>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
pull_requests: +516
___
Python tracker
<http://bugs.python.org/issue29656>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
pull_requests: +517
___
Python tracker
<http://bugs.python.org/issue29798>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Nick Coghlan :
--
pull_requests: +521
___
Python tracker
<http://bugs.python.org/issue29798>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
pull_requests: +522
___
Python tracker
<http://bugs.python.org/issue29798>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
pull_requests: +523
___
Python tracker
<http://bugs.python.org/issue29798>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29798>
___
Changes by Nick Coghlan :
--
pull_requests: +525
___
Python tracker
<http://bugs.python.org/issue29319>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
pull_requests: +524
___
Python tracker
<http://bugs.python.org/issue29723>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
I've merged PR 575 to master, and 636 is pending a successful Travis run for
3.6.
Both branches still need NEWS entries- I'll do those as independent PRs rather
than cherry-picking (since cherry picking NEWS changes is currently still
doom
Changes by Nick Coghlan :
--
pull_requests: +527
___
Python tracker
<http://bugs.python.org/issue29723>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Noting for the record: Steve reviewed & approved the original PR before I
merged that and did the backport to 3.6.
With the new test case ensuring sys.path configuration consistency and Paul's
report of success when checking the original problem f
Nick Coghlan added the comment:
With the fix for issue 29723 merged, this should be properly resolved now (and
the fix available with 3.6.1).
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python track
Nick Coghlan added the comment:
Turns out I missed another isdir() check in get_base_branch(), so this still
isn't working properly in git worktree directories.
--
resolution: fixed ->
stage: resolved -> needs patch
status: clo
Changes by Nick Coghlan :
--
pull_requests: +540
___
Python tracker
<http://bugs.python.org/issue28180>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
OK, the PEP 538 reference implementation has reached the point where I was
willing to create a PR for it: https://github.com/python/cpython/pull/659
That PR/branch also includes the necessary changes to always force the C.UTF-8
locale on Android rather than
Nick Coghlan added the comment:
I just ran into this discrepancy working on the test cases for PEP 538 - +1 for
Gareth's suggested approach of just aligning the `--help` output with the man
page.
--
nosy: +ncoghlan
___
Python tracker
New submission from Nick Coghlan:
For PEP 538, setting PYTHONIOENCODING turned out to have undesirable side
effects on Python 2 instances in subprocesses, since Python 2 has no
'surrogateescape' error handler.
So I switched to using the "Py_SetStandardStreamEncoding"
Changes by Nick Coghlan :
--
versions: +Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue29818>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
Right, there's a longstanding RFE to allow builtin packages and submodules:
https://bugs.python.org/issue1644818
At the moment, modules like pyexpat are more like the os module than they are
packages: they eagerly set other modules as attributes at import
New submission from Nick Coghlan:
Issue 14208 was ultimately resolved through an import system specific solution,
with PEP 451 making the module name passed to `python -m` available as
`__main__.__spec__.name`.
However, there are other situations where it may be useful to offer an
Nick Coghlan added the comment:
A few updates here:
* For the specific case of `python -m`, the original argument has been
available as `__main__.__spec__.name` since Python 3.4
* Also since Python 3.4, the `multiprocessing` module has correctly handled the
-m switch. For more details, see
Nick Coghlan added the comment:
Indeed, the traceback abbreviation doesn't try to detect recursive loops, only
exactly duplicated lines.
The problem is that the more state management we do in the traceback printing,
the higher the chance there is of getting an error while attempt to di
Nick Coghlan added the comment:
For CPython, I was thinking of having it be "whatever gets passed to Py_Main",
and that accepts wchar_t in Py3 [1], so on *Nix systems, the command line has
already been decoded with [2] by the time it runs.
[1] https://docs.python.org/3/c-api/ver
Nick Coghlan added the comment:
@Steven This is an implementation detail in the same sense that sys._getframe()
is: it's not something that's actually going to make sense in all contexts. For
example, if Py_Main() is never called (for CPython), it would still be None,
Nick Coghlan added the comment:
If the embedding application doesn't call PySys_SetArgv or PySys_SetArgvEx,
then there is no `argv` attribute defined in the sys module (I wasn't actually
sure what happened in that case, so I went and checked the code).
For the reference CLI, the rel
Nick Coghlan added the comment:
OK, I've changed the proposed attribute name to be `sys.executable_argv`, with
the rationale being that it's "argv as originally seen by sys.executable,
rather than by Python's __main__ module"
As part of documenting this, both it and
Nick Coghlan added the comment:
I like this idea in principle, and suspect it may be helpful in the
implementation of the new thread-specific-storage API proposed in PEP 539 (also
see http://bugs.python.org/issue25658 ).
How would you feel about calling it _Py_ONCE_VAR? The use case here is
Nick Coghlan added the comment:
Passing var_decl was based on not knowing the answer to two questions:
* do we ever declare non-statics this way? (OTOH, if we do, this could be an
opportunity to hide them behind read-only accessor functions)
* do we ever declare more specific types than
Nick Coghlan added the comment:
The main potential benefit I see to keeping the special variable declaration is
that it may help avoid a certain category of error: calling _Py_ONCE_VAR_INIT
on a stack local pointer reference (which would leave the global array with a
reference to nonsense
Nick Coghlan added the comment:
For module level variables, I'd expect this API to need to be used in tandem
with switching the module over to PEP 489 multi-phase initialization.
By calling the new API in their _Py_mod_exec slot implementation, extension
modules should be able to h
Nick Coghlan added the comment:
New changeset c60948464fb0ec116ea227f6bce8a4bb8fb75257 by Nick Coghlan in
branch '3.6':
[3.6] bpo-29723: Consistently configure sys.path[0] (#636)
https://github.com/python/cpython/commit/c60948464fb0ec116ea227f6bce8a4
Nick Coghlan added the comment:
New changeset c60948464fb0ec116ea227f6bce8a4bb8fb75257 by Nick Coghlan in
branch '3.6':
[3.6] bpo-29723: Consistently configure sys.path[0] (#636)
https://github.com/python/cpython/commit/c60948464fb0ec116ea227f6bce8a4
Nick Coghlan added the comment:
New changeset 27abb0e533a6f7ad195bd56b064c32164296a56e by Nick Coghlan in
branch 'master':
bpo-29723: Add missing NEWS entry (#638)
https://github.com/python/cpython/commit/27abb0e533a6f7ad195bd56b064c32
Nick Coghlan added the comment:
New changeset d2977a3ae2cc6802921b1e3b6e9d13fcfbda872d by Nick Coghlan in
branch 'master':
bpo-29723: Consistently configure sys.path[0] (#575)
https://github.com/python/cpython/commit/d2977a3ae2cc6802921b1e3b6e9d13
Nick Coghlan added the comment:
New changeset d2977a3ae2cc6802921b1e3b6e9d13fcfbda872d by Nick Coghlan in
branch 'master':
bpo-29723: Consistently configure sys.path[0] (#575)
https://github.com/python/cpython/commit/d2977a3ae2cc6802921b1e3b6e9d13
Nick Coghlan added the comment:
New changeset a6aac8c87036c3180916b893d66b1e257b5e2ec2 by Nick Coghlan in
branch '3.5':
bpo-29798: Handle git worktree in `make patchcheck` (#629) (#634)
https://github.com/python/cpython/commit/a6aac8c87036c3180916b893d66b1e
Nick Coghlan added the comment:
New changeset ee10fb9c5b0ae8706bcf7ab70d8d65604f2517a7 by Nick Coghlan in
branch '2.7':
bpo-29798: Handle git worktree in `make patchcheck` (#629) (#635)
https://github.com/python/cpython/commit/ee10fb9c5b0ae8706bcf7ab70d8d65
Nick Coghlan added the comment:
New changeset 61a82a5fbf1a674b91764652ab70f5dbb9ba50f2 by Nick Coghlan in
branch '3.6':
bpo-29798: Handle git worktree in `make patchcheck` (#629) (#633)
https://github.com/python/cpython/commit/61a82a5fbf1a674b91764652ab70f5
Nick Coghlan added the comment:
New changeset c8869af89e9b62fbfd066c01da1f502b0fd2ed3f by Nick Coghlan in
branch '2.7':
[2.7] bpo-29656: Handle PR branches in 'make patchcheck' (#302) (#628)
https://github.com/python/cpython/commit/c8869af89e9b62fbfd06
1901 - 2000 of 6301 matches
Mail list logo
