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/
I have a question on my homework. My homework is to write a program in which
the computer simulates the rolling of a die 50 times and then prints
(i). the most frequent side of the die (ii). the average die value of all
rolls. I wrote the program so it says the most frequent number out of all the
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
On Wednesday, December 6, 2017 at 9:32:27 PM UTC-5, nick martinez wrote:
> On Wednesday, December 6, 2017 at 9:03:27 PM UTC-5, ssghot...@gmail.com wrote:
> > On Thursday, December 7, 2017 at 12:39:38 PM UTC+11, nick martinez wrote:
> > > On Wednesday, December 6, 2017 at 8:13:3
On Wednesday, December 6, 2017 at 9:03:27 PM UTC-5, ssghot...@gmail.com wrote:
> On Thursday, December 7, 2017 at 12:39:38 PM UTC+11, nick martinez wrote:
> > On Wednesday, December 6, 2017 at 8:13:36 PM UTC-5, ssghot...@gmail.com
> > wrote:
> > > The following works:
On Wednesday, December 6, 2017 at 8:13:36 PM UTC-5, ssghot...@gmail.com wrote:
> The following works:
>
> import math
>
> print("This program will calculate the surface area and volume of a
> 3-dimensional cone: ")
> print()
> print()
> r = input("What is the radius in feet? (no negatives): ")
I'm stuck. I need my program to round the end solution to 2 decimal places but
cant figure it out. Can someone help? I've been trying between printf and
round() but cant seem to get either to work. Python 3.5 is what I'm using.
import math
print("This program will calculate the surface area and
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_
New submission from Nick Coghlan <ncogh...@gmail.com>:
We currently run the runtime embedding tests as a subsection of "test_capi".
I'm thinking it may make more sense to clearly separate them out as their own
CPython-only test file, "test_runtime_embedding".
I'm a
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 4274609e1856facd80b7ee588b0791fe8963b9e0 by Nick Coghlan in
branch 'master':
bpo-32096: Ensure new embedding test can find the encodings module (GH-4566)
https://github.com/python/cpython/
Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: +4494
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32096>
___
_
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 53efbf3977a44e382397e7994a2524b4f8c9d053 by Nick Coghlan in
branch 'master':
bpo-11063: Handle uuid.h being in default include path (GH-4565)
https://github.com/python/cpython/commit/53efbf3977a44e382397e7994a2524b4f8
Nick Coghlan <ncogh...@gmail.com> added the comment:
The header file check in setup.py incorrectly reported "not found" if `uuid.h`
was in one of the standard include directories, so I've submitted a tweak to
fix that: https://github.com/python/cpython/pull/4565
--
Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: +4493
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue11063>
___
_
Nick Coghlan <ncogh...@gmail.com> added the comment:
Serhiy's PR now implements the "Prohibit yield & yield from in generator
expressions and comprehensions" approach discussed on python-dev (currently as
a hard SyntaxError, but it could be amended to be a warning inste
Nick Coghlan <ncogh...@gmail.com> added the comment:
Ah, you're right - I forgot about this little hack in the other embedding
tests:
https://github.com/vstinner/cpython/blob/3fda852ba4d4040657a1b616a1ef60ad437b7845/Programs/_testembed.c#L11
I'll add "./" to the program name
Nick Coghlan <ncogh...@gmail.com> added the comment:
+1 from me for using "default" instead of "always" for ResourceWarning.
Folks can always combine "-X tracemalloc" with "-W always::ResourceWarning" if
want to ensure they see absol
Nick Coghlan <ncogh...@gmail.com> added the comment:
I realised that even without modifying the compiler first, I could illustrate
the proposed `yield from` based resolution for the comprehension case by way of
explicit yield from clauses:
```
def get_gen_result(gen, inputs):
Nick Coghlan <ncogh...@gmail.com> added the comment:
Given the direction of the python-dev thread, should we split this question
into two issues?
Issue 1: a yield expression inside a comprehension changes the type of the
expression result (returning a generator-iterator i
Nick Coghlan <ncogh...@gmail.com> added the comment:
Huh, those crashes are interesting - I'd guess that it means we have a
platform-dependent dependency from Py_DecodeLocale on to Py_SetPythonHome in
order to locate the encodings module. If I'm right, that dependency would then
Nick Coghlan <ncogh...@gmail.com> added the comment:
Key point to note regarding PEP 432: at least personally, I'm not actually
aiming to deprecate the legacy embedding API.
Instead, I'm just aiming to eventually stop *adding* to it, with new config
structs replacing the current ad h
Nick Coghlan <ncogh...@gmail.com> added the comment:
Sure, you can technically do that, but you'll have to rewrite most of the
symtable pass in the compiler, since you won't be able to re-use the current
recursive descent algorithms (which are designed to handle function scopes).
Th
Nick Coghlan <ncogh...@gmail.com> added the comment:
Another slight variant to that test case to make sure the inner comprehension
actually generates a closure reference in the current implementation:
>>> [[x+y for x in range(2) for y in range(1, i)] for i in range(2, 5)]
Nick Coghlan <ncogh...@gmail.com> added the comment:
Also see https://bugs.python.org/issue1660500 for the original Python 3.0
change to hide the iteration variable.
While the test suite already covers some interesting scoping edge cases as
result of that initial patch, I think one
Nick Coghlan <ncogh...@gmail.com> added the comment:
"Just fix the issue" is easier said than done for the same reason that
comprehensions were implemented the way they are now: lambda expressions still
have to work.
That is, we need to maintain the invariant that:
[x f
Change by Nick Coghlan <ncogh...@gmail.com>:
--
nosy: +ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue10544>
___
__
Nick Coghlan <ncogh...@gmail.com> added the comment:
Even the public implementation of PEP 432 is going to bound by the requirement
to keep existing embedding logic working, and that's encapsulated in the new
test Eric added in his PR:
wchar_t *program = Py_DecodeLocale("
Nick Coghlan <ncogh...@gmail.com> added the comment:
Thanks to Jesse Bakker for the PR implementing this for 3.7!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7
___
Pyth
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 0784a2e5b174d2dbf7b144d480559e650c5cf64c by Nick Coghlan
(Jesse-Bakker) in branch 'master':
bpo-10049: Add a "no-op" (null) context manager to contextlib (GH-4464)
https://github.com/pytho
Nick Coghlan <ncogh...@gmail.com> added the comment:
Follow up: this also came up on https://bugs.python.org/issue32030#msg306763,
and I think Victor and I are on the same page now :)
Since MainInterpreterConfig is currently still a private struct, we can store
the existing C level
Nick Coghlan <ncogh...@gmail.com> added the comment:
Nice, thanks for that. Good call on keeping the current data types for now, so
we can focus on consolidating the configuration settings first, and then look
at upgrading from C level types to Python level types
Nick Coghlan <ncogh...@gmail.com> added the comment:
Also, the basic rules of thumb I use for deciding whether or not a setting
belongs in CoreConfig:
* does `PyUnicode_New` need this? (If yes, then include it)
* does the importlib bootstrapping need this? (If yes, then include it)
Ever
Nick Coghlan <ncogh...@gmail.com> added the comment:
Victor, I think you're fundamentally misunderstanding the goals of PEP 432.
The entire point is to let people have a *mostly working Python runtime* during
CPython startup. Moving everything that Py_Initialize needs to instea
Nick Coghlan <ncogh...@gmail.com> added the comment:
Victor, *please* don't add the external import settings to CoreConfig. That
struct should only contain the absolute bare minimum of settings needed to get
an interpreter that *can't* access the filesystem, such that builtin m
Nick Coghlan <ncogh...@gmail.com> added the comment:
If we do decide to do this, I'm inclined to eventually make the change at the
Grammar level rather than the AST level.
Current:
comparison: expr (comp_op expr)*
c
Nick Coghlan <ncogh...@gmail.com> added the comment:
Speaking of surprises with static initialization of the runtime allocations:
both PRs are failing in CI, suggesting that the changes that Py_Initialize
makes to the allocator settings aren't being reverted in Py_Finalize, so
t
Nick Coghlan <ncogh...@gmail.com> added the comment:
Victor, please stop trying to conflate the two questions of "How should we fix
the current Py_DecodeLocale regression before 3.7.0a3?" and "What do we want to
do long term?".
They're far from being the sa
Nick Coghlan <ncogh...@gmail.com> added the comment:
Touching the filesystem implicitly can have all sorts of unintentional side
effects (especially in read-only environments), so we strongly prefer not to do
that.
The most general solution here would be to turn the warnings re
New submission from Nick Coghlan <ncogh...@gmail.com>:
I'm hesitant to suggest adding yet-another-option to any subprocess API, but
I'm thinking it may be worth it in this case.
The idea is to make it possible to replace:
result = subprocess.run(cmd, stdout=PIPE, stder
Nick Coghlan <ncogh...@gmail.com> added the comment:
Another argument against PYTHONXOPTIONS is that each implementation is free to
decide which -X options it wants to support, and we don't really define what
they're supposed to do with options they don't recognise.
By contrast, t
901 - 1000 of 8215 matches
Mail list logo
