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
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
ve
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(
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/9b99747386b690007027c3be2a5d7cfe3d
Change by Nick Coghlan <ncogh...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
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 the
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
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
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'
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://bu
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/
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://bu
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>
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/9f1e5f1b7f074e026843a5d70834233a95
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 t
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, cP
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
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
fu
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 th
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 ca
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 existi
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
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.pyt
Change by Nick Coghlan <ncogh...@gmail.com>:
--
assignee: -> ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31975>
___
_
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 pr
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
introd
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 dup
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
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 se
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
dir
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
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 r
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 wel
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 "ho
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/9c19b020249c451891affd81751947321a
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/pe
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&
Change by Nick Coghlan <ncogh...@gmail.com>:
--
nosy: +ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32225>
___
__
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
c
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: op
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/
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
Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: +4647
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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 w
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
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
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.
--
depend
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&qu
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 "mai
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
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 b
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 det
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
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 pi
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
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 th
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
situ
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
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
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 "
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
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.pyt
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 ma
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 u
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: +nc
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 si
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
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 initiali
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 c
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
versio
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/c8f32aae0aa173e122cf4c0592caec620d
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 b
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 a
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
Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: +4597
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32176>
___
_
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/078f1814f1a4413a2a0fdb8cf4490ee0fc
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 to
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 easie
Change by Nick Coghlan <ncogh...@gmail.com>:
--
keywords: +patch
pull_requests: +4583
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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-&g
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.
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
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 c
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 co
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 the
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
sta
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
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/pytho
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 `getful
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 pr
Change by Nick Coghlan <ncogh...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
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/39f0bb5ad0715dbfc0a2d5dd6d0ddea9e4
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 in
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.or
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 DeprecationW
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/t
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.pyt
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 ca
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 verbos
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_
801 - 900 of 6264 matches
Mail list logo
