New submission from Nick Coghlan :
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 also thinkin
Nick Coghlan 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/commit/4274609e1856facd80b7ee588b0791
Change by Nick Coghlan :
--
pull_requests: +4494
___
Python tracker
<https://bugs.python.org/issue32096>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan 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/53efbf3977a44e382397e7994a2524
Nick Coghlan 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 :
--
pull_requests: +4493
___
Python tracker
<https://bugs.python.org/issue11063>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan 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 instead without too
much d
Nick Coghlan 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 in the new test
Nick Coghlan 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 absolutely every resource warnin
Nick Coghlan 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):
try:
yield_value = next
Nick Coghlan 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 instead of the expected
container type
Nick Coghlan 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
mean that embedding ap
Nick Coghlan 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 hoc mix of pre-ini
Nick Coghlan 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).
That ran afoul
Nick Coghlan 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)]
[[1, 2], [1, 2, 2, 3],
Nick Coghlan 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 we're currently missing i
Nick Coghlan 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 for x in iterable]
{
Change by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue10544>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan 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("spam", NULL);
Py
Nick Coghlan 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
___
Python tracker
<https://bug
Nick Coghlan 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/python/cpython/commit/0784a2e5b174d2dbf7b1
Nick Coghlan 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 config state directly in there
Nick Coghlan 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 later
Nick Coghlan 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)
Everything else goes in
Nick Coghlan 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 instead have to
happen b
Nick Coghlan 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 modules
and frozen modules
Nick Coghlan 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)*
comp_op: '<'|'>'|'=='|'>='|
Nick Coghlan 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
there's a mismatch b
Nick Coghlan 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 same question, and answering th
Nick Coghlan 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 registry into an
LRU cache - short
New submission from Nick Coghlan :
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, stderr=PIPE)
with:
Nick Coghlan 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, there's an e
Nick Coghlan added the comment:
Issue 32096 covers reverting the change to PyDecode_Locale specifically for 3.7.
We can use this issue to ask the broader question "Do we want to *deprecate*
our previously implied support for calling PyDecode_Locale() before
Py_Initialize()?"
If
Nick Coghlan added the comment:
While they're definitely closely related, I don't think this and issue 32086
are actually duplicates: this issue is "fix the current Py_DecodeLocale
regression in 3.7 by reverting back to the 3.6 behaviour", while issue 32086 is
&quo
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +4395
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31875>
___
___
Py
Nick Coghlan added the comment:
Just a note on why I find "a in b < c" unintuitive, even for sets: my brain
initially wanted to read it as equivalent to "a in b & c".
--
___
Python tracker
<http
Nick Coghlan added the comment:
Aye, there are definitely cases where the answer isn't nonsense.
Even for sets though, "a in b < c" isn't an intuitive spelling of "a in b and b
< c" the way that "a < b < c" is an intuitive spelling of an ord
Nick Coghlan added the comment:
https://bugs.python.org/issue14247 is another older issue related to this point
(again related to a user finding the current behaviour genuinely unintuitive)
--
___
Python tracker
<https://bugs.python.org/issue32
Nick Coghlan added the comment:
Also see https://bugs.python.org/issue32055 regarding the prospect of bringing
the implementation into line with the intuitive semantics, and preventing
implicit comparison chaining for containment tests.
--
nosy: +ncoghlan
New submission from Nick Coghlan :
(I thought there was an open low priority issue for this, but I can't find it,
so filing a new one)
Currently, "in" and "not in" are classified as comparison operations in the
language grammar, even though they're not actually
Nick Coghlan added the comment:
With issue 32023 (base class lists) and 32034 (fixing the documentation for
decorator factory function calls) covering the other refinements, this
particular issue is done now.
The most recent PR is the one for issue 32023.
--
resolution: -> fi
Nick Coghlan added the comment:
Given the symptoms (stripping 4 spaces + "pr" from the start of the line,
leaving "int " behind), it looks like we're not stripping the leading
whitespace when determining the text to include in the suggested print() call.
To reprod
Nick Coghlan added the comment:
I think it's reasonable to keep this open if the problems can be reproduced
with the current 3.7 dev branch - while we've refactored a lot of things, we
haven't specifically gone memory leak hunting for the embedded case, and I'm
pretty
Nick Coghlan added the comment:
While it doesn't necessarily need to be in this patch, something else I
recently realised (by breaking it *cough* [1]) is that the interaction between
our command line options and our environment variables isn't really clearly
defined anywhe
Nick Coghlan added the comment:
If limited to the original scope, this isn't a new special case, it's fixing a
bug in the implementation of the existing special case (where it's ignoring the
trailing comma when it shouldn't be).
If it hadn't been for the scope cre
Nick Coghlan added the comment:
OK, I've filed https://bugs.python.org/issue32024 to cover the decorator syntax
discrepancy.
So I'd still prefer to restrict the patch for *this* issue to just the
genuinely ambiguous case, and leave the
unambiguous-but-inconsistent-with-the-lan
New submission from Nick Coghlan :
Function calls in decorators are implemented as regular function calls, and
hence permit the use of generator expressions as their sole argument without a
second pair of parentheses.
However,
https://docs.python.org/3/reference/compound_stmts.html#function
Nick Coghlan added the comment:
I created https://bugs.python.org/issue32023 to explicitly cover the base class
list case, and after checking the language spec, I agree that case should be a
syntax error.
However, `@deco(x for x in [])` should *not* be a syntax error, as:
* it's a call
New submission from Nick Coghlan :
The compiler currently allows parentheses to be omitted if a generator
expression is the sole entry in a base class list:
>>> class C(x for x in []): pass
...
Traceback (most recent call last):
File "", line 1, in
Nick Coghlan added the comment:
I don't think anybody consistently does proper resource management in the REPL,
so the trade-offs involved there are quite different from those for deprecation
warnings.
Assuming PEP 565 gets accepted, we'll end up with once-per-session warnings f
Nick Coghlan added the comment:
As a user, what would I actually gain from being warned more than once per
session that a particular API I'm using is deprecated?
If I want that behaviour, I can already opt in to it by doing
"warnings.simplefilter('always')".
As thin
Nick Coghlan added the comment:
In a function call, `f(x for x in iterable)` is roughly equivalent to
`f(iter(iterable))`, not `f(*iterable)` (the genexp based equivalent of the
latter would be ``f(*(x for x in iterable))`).
Thus the base class list is no different from any other argument
Nick Coghlan added the comment:
The default command line UX of Python developer tools is also more
unambiguously python-dev's responsibility, though. That's where my own initial
line of argument for full reversion (i.e. that we should be letting app
developers manage their own stde
Nick Coghlan added the comment:
Reviewing the original thread yet again, you're right the original decision
wasn't specifically about developer tools (and I guess at some level I knew
that, or I wouldn't have been motivated to suggest the change to
FutureWarning's docume
Nick Coghlan added the comment:
I also learned we need more concrete examples of useful PYTHONWARNINGS and -W
settings in the docs - I believe PEP 565 currently contains more of those than
all of our existing warnings related documentation put together :)
I'll look into that &quo
Nick Coghlan added the comment:
I relearned a fair bit myself in writing it - I'd completely forgotten the
original rationale was about developer tools emitting unhelpful noise (rather
than general Python applications), and that's far more persuasive than the
rationale I'
Nick Coghlan added the comment:
My impression is that you've been arguing that my changes don't go far enough
(i.e. you'd prefer full reversion to the pre-2.7 behaviour), not that the
status quo is superior.
My PEP covers both why I think the status quo is problematic, and w
Nick Coghlan added the comment:
The initial draft of the PEP is up: https://www.python.org/dev/peps/pep-0565/
--
___
Python tracker
<https://bugs.python.org/issue31
Nick Coghlan added the comment:
Antoine, I'm a user too, and this single small change will be enough to
solve *my* problems, while still addressing Guido's developer tool
usability concerns that prompted him to change the default in the first
place (see the stdlib-sig thread for mo
Nick Coghlan added the comment:
As far as documentation goes, there are the amendments I'm considering:
===
exception DeprecationWarning
Base class for warnings about deprecated features. Visible by default for
APIs called from `__main__` modules and when usin
Nick Coghlan added the comment:
Regarding "Why not revert DeprecationWarning to behaving the same as
FutureWarning?", the rationale is basically the one Brett gave on python-dev
(which was a restatement of the one that led to the change in python-dev): it's
genuinely annoy
Nick Coghlan added the comment:
Note: I'm not entirely sold on my own argument though, as I believe at least
Alpine Linux already interprets the empty locale as C.UTF-8, so it may make
more sense to use your dynamic check with both the empty string and "POSIX",
and only testin
Nick Coghlan added the comment:
The essential problem in both this issue and issue 30672 is that the tests are
currently incorporating some Linux-specific assumptions about ways to request
the "C" locale.
In https://github.com/python/cpython/pull/4369, I've taken the approach
Change by Nick Coghlan :
--
pull_requests: +4322
___
Python tracker
<https://bugs.python.org/issue32002>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Given the existing "gc.enable", "gc.disable" and "gc.isenabled" APIs, I'd
suggest calling this one "gc.ensure_disabled": it ensures the GC is disabled in
the with statement body, but only turns it back on at the
Nick Coghlan added the comment:
OK, I've had a couple of days to become not-annoyed about this, and given the
discovery that pytest doesn't currently enable DeprecationWarning by default
(even though the default DeprecationWarning behaviour changed more than 7 years
ago), I'm
Nick Coghlan added the comment:
OK, I'd been meaning to get back to refactoring those tests anyway, so
assigning this to myself.
I'm thinking that the right way to go will be to give the test case a more
explicit model of "expected platform behaviour" (initialised in s
Nick Coghlan added the comment:
Issue 30672 is potentially related here - some of the test cases are already
disabled on Mac OS X and other *BSD systems since the tests assume that C &
POSIX are aliases of each other.
I've also added Xavier to the nosy list, since the current imple
Nick Coghlan added the comment:
Antoine, it's not a wishy-washy compromise, it's a compromise based on the fact
that code that has been factored out to a support module is far more likely to
have a test suite than code that's directly in __main__.
Thus the logic for the
Nick Coghlan added the comment:
Reverting to "Needs patch", as the currently attached patch is for the "No
behaviour" variant that always returns None from __enter__().
(hniksic, would you still be willing to sign the Python CLA? If so, then your
patch could be used
Nick Coghlan added the comment:
Reopening this based on several years of additional experience with context
managers since I wrote https://bugs.python.org/issue10049#msg119514 when
originally closing it.
The version I'm now interested in adding is the one from
https://bugs.pytho
Nick Coghlan added the comment:
I'm currently still too annoyed to write a PEP about this - it would probably
come out in tone like the state of the unicode literals PEP before I edited it.
I just don't understand how this logic is hard: *our* primary responsibility
for deprecatio
Nick Coghlan added the comment:
Sure, it's harsh, but it's still what it looks like from the outside - there's
no PEP explaining the reasoning for putting the interests of app developers
that don't want to take responsibility for their user experience ahead of thos
Nick Coghlan added the comment:
Ah, I see - yeah, that makes a lot of sense.
I've retitled the issue to make it clearer that the problem is where the
responsibility for calling atexit functions lives - currently it's in
Py_Finalize, but really it should be inside the interpreter ob
Nick Coghlan added the comment:
(And yes, I could push this as a downstream patch to Fedora's Python packages
instead - if enough folks insist that springing breaking changes on people
without warning them that those changes coming is fine, that's wh
Nick Coghlan added the comment:
Yes - stuff just flat out breaks when Linux distros upgrade Python.
The response is "Yeah, python-dev decided years ago that they don't care about
that".
--
___
Python tracker
<https://bugs.pyt
New submission from Nick Coghlan :
As per the post at
https://mail.python.org/pipermail/python-dev/2017-November/150366.html, this is
an RFE to cover adding a new warning filter to the default set:
once::DeprecationWarning:__main__
This means that all deprecation warnings triggered
Nick Coghlan added the comment:
Also, based on reviewing this, I suspect the same approach would also work for
the pure Python profile module.
--
___
Python tracker
<https://bugs.python.org/issue21
Nick Coghlan added the comment:
I added an inline comment on the PR - I think what's there now would work fine,
but I also suggested a slightly shorter and clearer (at least to me)
alternative.
--
___
Python tracker
<https://bugs.py
Change by Nick Coghlan :
--
versions: +Python 3.7 -Python 3.5
___
Python tracker
<https://bugs.python.org/issue19982>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
See issue 21862 and issue 9325 as potential use cases for this feature.
While it looks like issue 21862 (-m switch support in cProfile) can be
implemented just fine without it, this feature will be needed for the modules
that execute the given scripts directly
Nick Coghlan added the comment:
Issue 21862 is a related issue specifically for the cProfile module.
In that case, cProfile's command line invocation *doesn't* use the main module,
so the patch is able to just create a synthetic call to runpy.run_module as a
string and compile t
Nick Coghlan added the comment:
Interesting - I'd never looked at how cProfile works before, and the fact it
already doesn't support the "-i" (interactive) switch makes it much simpler to
handle than the pdb case.
So from a runpy perspective, this approach gets a +1 fro
Nick Coghlan added the comment:
Right, and that's why I think we're better off focusing on the arithmetic
explanations wherever they apply. The problem is that for "x | y" and "x & y"
there's no avoiding discussing the 2's complement representati
Nick Coghlan added the comment:
Starting to make some progress on an implementation, and it occurs to me that
if this approach does work out, it should make Python level trace functions
*much* faster.
Right now, the call to the Python function in call_trampoline is bracketed by
Nick Coghlan added the comment:
New changeset 1b46131ae423f43d45947bb48844cf82f6fd82b8 by Nick Coghlan in
branch 'master':
bpo-22257: Mention startup refactoring in What's New (GH-4286)
https://github.com/python/cpython/commit/1b46131ae423f43d45947bb48
Nick Coghlan added the comment:
New changeset 1b46131ae423f43d45947bb48844cf82f6fd82b8 by Nick Coghlan in
branch 'master':
bpo-22257: Mention startup refactoring in What's New (GH-4286)
https://github.com/python/cpython/commit/1b46131ae423f43d45947bb48
Change by Nick Coghlan :
--
pull_requests: +4248
___
Python tracker
<https://bugs.python.org/issue22257>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Nick Coghlan :
--
pull_requests: +4249
___
Python tracker
<https://bugs.python.org/issue31845>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Bug report (since resolved) that highlighted our general lack of test coverage
for the interactions between environment variable based configuration and
command line based configuration: https://bugs.python.org/issue31845
This work revealed the absence, since
Nick Coghlan added the comment:
Cross-linking to the work-in-progress RFE that introduced the error:
https://bugs.python.org/issue22257
--
___
Python tracker
<https://bugs.python.org/issue31
Nick Coghlan added the comment:
In https://mail.python.org/pipermail/python-ideas/2017-October/047599.html,
Guido suggested managing this as an occasionally updated Informational PEP
(somewhat akin to PEP 394), and I think that will actually work fairly well:
* it clearly gives the
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan added the comment:
New changeset e8b19656396381407ad91473af5da8b0d4346e88 by Nick Coghlan
(stratakis) in branch 'master':
bpo-23699: Use a macro to reduce boilerplate code in rich comparison functions
(GH-793)
https://github.com/python/cpyt
Nick Coghlan added the comment:
Thinking about it further, this list is actually going to be version
independent, suggest it may actually belong somewhere outside the main
documentation.
The Developer's Guide may be a reasonable stopgap measure until there's a
better option avai
Nick Coghlan added the comment:
As part of this, a new subsection would be added to
https://docs.python.org/devguide/stdlibchanges.html to document the process for
adding new packages to the recommended packages list: propose them for standard
library inclusion, and while "No" is
Nick Coghlan added the comment:
I guess we allow an unhandled SystemExit in a child thread to propagate to (and
hence terminate) the main thread, so allowing a Py_Finalize call in a
subinterpreter to terminate the main interpreter would be comparable to that.
My main rationale for *requiring
Nick Coghlan added the comment:
For the main interpreter, Py_Finalize should be destroying all other
subinterpreters as one of the first things it does, so if we're *not* currently
doing that, it would make sense to fix it as part of Eric's subinterp
Nick Coghlan added the comment:
Hmm, I don't think calling Py_Finalize in any interpreter other than the main
one is actually defined at all, so I'm inclined to just make it an error,
rather than trying to figure out how it should work. It would then be up to the
embedding appl
Nick Coghlan added the comment:
https://bugs.python.org/issue31899 is a follow-up issue to discuss whether or
not it would make sense to expand these recommendations to cover explicit
compatibility testing against these libraries for CPython updates
901 - 1000 of 6301 matches
Mail list logo
