Nick Coghlan added the comment:
ImportError sounds right to me.
We already raise that just above this for the "no dots at all" case, so also
raising it for the "not enough dots" case makes more sense than leaving them
different.
--
__
Nick Coghlan added the comment:
Reviewing the thread, we never actually commented on thautwarm's proposal in
https://bugs.python.org/issue12782#msg327875 that aims to strip out any INDENT,
NEWLINE, and DEDENT tokens that appear between the opening "with" keyword and
the s
Nick Coghlan added the comment:
Agreed, raising the exception properly would be the way to go.
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue35
New submission from Nick Coghlan :
At the core dev sprints in 2017 (IIRC), Ezio and I were talking about some of
the potential issues with 3.10, and one of them was folks attempting to
manipulate sys.version with string operations rather than using the already
decomposed sys.version info
Nick Coghlan added the comment:
New changeset 8a758f5b99c5fc3fd32edeac049d7d4a4b7cc163 by Nick Coghlan (Marco
Paolini) in branch 'master':
bpo-37587: Make json.loads faster for long strings (GH-14752)
https://github.com/python/cpython/commit/8a758f5b99c5fc3fd32edeac049d7d
Nick Coghlan added the comment:
I went ahead and merged the minimal PR and flagged it for backporting to 3.8 -
it's an obviously beneficial change, that clearly does less work on each pass
through the loop.
Even if you are doing non-strict parsing of a string that consists entire
Nick Coghlan added the comment:
Did the documentation PR get pushed/merged? Emily mentioned having one in
progress above, but it doesn't appear in the linked PRs.
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/is
New submission from Nick Coghlan :
While implementing PEP 572, Emily noted that the check for conflicts between
assignment operators and comprehension iteration variables had not yet been
implemented: https://bugs.python.org/issue35224#msg334331
Damien George came across this discrepancy
Nick Coghlan added the comment:
https://bugs.python.org/issue37757 separates out the TargetScopeError handling
for conflicts between assignment expressions and comprehension iteration
variables.
--
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
Also, a major procedural note: it is NOT OK to merge a PEP implementation that
completely ignores parts of the PEP. The merged tests are actively forcing
NON-compliance with the accepted PEP, since they're requiring implementations
to accept code that th
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +14871
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/15131
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
#37757 now has an associated PR adding the missing TargetScopeError cases:
https://github.com/python/cpython/pull/15131
There's one case where it goes beyond what the PEP specifies: because the
outermost iterable expression gets evaluated in a different
Nick Coghlan added the comment:
Thanks Guido. The former test cases that the new PR removes are the following:
res = [i := i for i in range(5)]
res = [i := 0 for i, j in [(1, 2), (3, 4)]]
res = [(i := 0, j := 1) for i, j in [(1, 2), (3, 4)]]
res = [(i := i, j := j) for i, j in [(1, 2), (3, 4
Nick Coghlan added the comment:
Added a PEP update as well: https://github.com/python/peps/pull/1140
--
___
Python tracker
<https://bugs.python.org/issue37
Nick Coghlan added the comment:
Proposed PEP update is here: https://github.com/python/peps/pull/1140
The update also aims to clarify *why* we're doing the extra work in CPython's
compiler to make these cases fail (i.e. we don't want to implicitly impose the
current
Nick Coghlan added the comment:
I believe our main motivation for separating it out was the fact that even
though TargetScopeError is a compile-time error, the affected code is
syntactically fine - there are just issues with unambiguously inferring the
intended read/write location for the
Nick Coghlan added the comment:
Regarding the "Would releasing 4.0 instead avoid problems?" Anthony actually
did that experiment, too: it broke third party projects even more impressively
than the 3.10 build did.
I think Serhiy's point is fairly compelling though - check
Nick Coghlan added the comment:
I wouldn't be OK with magic switching in the behaviour of ContextDecorator
(that's not only semantically confusing, it's also going to make the contextlib
function wrappers even slower than they already are).
I'm also entirely unclear on w
Nick Coghlan added the comment:
We don't use the alpha and beta phases for maintenance releases, so I think the
checks are functionally equivalent.
For example, the 3.6 branch currently reports itself as "3.6.1 final", will
temporarily report itself as "3.6.2 release&q
Nick Coghlan added the comment:
New changeset 81f67b6f48820beed6e138077fd785020bbfd5d6 by Nick Coghlan
(Stéphane Wirtel) in branch 'master':
bpo-30636: Fix the indentation for the help (#2131)
https://github.com/python/cpython/commit/81f67b6f48820beed6e138077fd785
Nick Coghlan added the comment:
Thanks once again! :)
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
Indeed, Emily is correct: this is expected behaviour for system Python versions
that don't patch their ensurepip modules, as the default pip (et al) used in
virtual environments created with the venv module generally only gets upgraded
when upgrading to
Nick Coghlan added the comment:
My latest proposal on python-dev:
- no warning by default on successful coercion
- set "PYTHONCOERCECLOCALE=warn" to enable the warning when it's considered a
configuration error in the runt
Nick Coghlan added the comment:
Some relevant mailing list threads on the usability problems posed by issuing
the warning by default:
python-dev (impact on developer experience):
https://mail.python.org/pipermail/python-dev/2017-June/148323.html
Fedora's python-devel (build enviro
Changes by Nick Coghlan :
--
pull_requests: +2208
___
Python tracker
<http://bugs.python.org/issue29514>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
pull_requests: +2209
___
Python tracker
<http://bugs.python.org/issue29514>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
New changeset d071a20f136547a490783fcfa969c6528025a6d2 by Nick Coghlan in
branch '3.5':
[3.5] bpo-29514: Check magic number for bugfix releases (#2158)
https://github.com/python/cpython/commit/d071a20f136547a490783fcfa969c6
Nick Coghlan added the comment:
New changeset 92e9e35292d4e2044c25970389f3cdb30cfc903a by Nick Coghlan in
branch '3.6':
[3.6] bpo-29514: Check magic number for bugfix releases (#2157)
https://github.com/python/cpython/commit/92e9e35292d4e2044c25970389f3cd
Changes by Nick Coghlan :
--
pull_requests: +2211
___
Python tracker
<http://bugs.python.org/issue29514>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
New changeset a51f12f154baef9e10698f43bd19b36d01af62f4 by Nick Coghlan in
branch '2.7':
[2.7] bpo-29514: Check magic number for bugfix releases
https://github.com/python/cpython/commit/a51f12f154baef9e10698f43bd19b3
Nick Coghlan added the comment:
This has now been backported to all active maintenance branches.
For 2.7, I backported the test as a standalone one in
Lib/test/test_import_magic.py, since there's only a partial importlib
implementation in 2.7, and hence no test_importlib directory.
T
Nick Coghlan added the comment:
New changeset 023564bf7d95f8e6a4b790491811e75ce497a071 by Nick Coghlan (Victor
Stinner) in branch 'master':
bpo-30635: Fix refleak in test_c_locale_coercion (#2126)
https://github.com/python/cpython/commit/023564bf7d95f8e6a4b790491811e7
Nick Coghlan added the comment:
It's intended behaviour, but you're right that we don't explicitly document
anywhere that SyntaxError can be reported from three different places:
- the initial parsing based on the language Grammar
- the conversion of the parse tree int
Nick Coghlan added the comment:
Technically a false alarm due to an unintended caching side effect in the test
case.
Victor fixed it by moving the list creation to the module setup fixture, so it
only runs once, even when hunting refleaks.
--
resolution: -> fixed
stage: -> re
Nick Coghlan added the comment:
New changeset 4563099d28e832aed22b85ce7e2a92236df03847 by Nick Coghlan in
branch 'master':
bpo-28180: assume UTF-8 for Mac OS X PEP 538 tests (GH-2130)
https://github.com/python/cpython/commit/4563099d28e832aed22b85ce7e2a92
Nick Coghlan added the comment:
I've added dependencies for PEP 538 induced testing problems that have been
broken out into their own issues.
I've also merged my attempt at fixing the tests on Mac OS X.
Something that's included in that patch is an implicit skip of the "LA
Nick Coghlan added the comment:
PEP 489 was accepted and implemented, so Python 3.5+ supports non-ASCII
extension module names as described in
https://www.python.org/dev/peps/pep-0489/#export-hook-name
--
resolution: -> fixed
stage: test needed -> resolved
status: open -&g
Nick Coghlan added the comment:
The upstream supported install path for bootstrapping the venv is from a wheel
file. The CPython source tree contains the necessary wheels, and, by default,
upgrading the system pip doesn't touch them.
The only distro I can speak authoritatively for wh
New submission from Nick Coghlan:
shutil.make_archive currently just uses the default tar format, which is
GNU_FORMAT.
This format doesn't ensure that all character paths are encoded as UTF-8, and
hence may end up embedding platform specific encoding assumptions into the
generated ta
Nick Coghlan added the comment:
The main benefit I'd see to the last option is that it would also cover passing
a "filter" option for tarfile.TarFile.add(). Dropping down to the lower level
API for that isn't *hard*, it's just a bit fiddly (note: currently untested
Nick Coghlan added the comment:
Emily's answer sort of covered the "It's not as simple as it might seem"
aspect, whereby the bit that's genuinely tricky is to provide access to the
system pip(/setuptools/wheel) without providing accessing to the system site
packages i
Nick Coghlan added the comment:
As Victor notes above, for systems where no suitable coercion target locale is
available, even the "unsupported locale" warning is an issue, since it's only
full Unicode text handling that's unsupported in such locales - you can still
proces
Nick Coghlan added the comment:
Serhiy: I believe that magic number was current when the test was written, and
it hasn't been getting updated since the test is currently being skipped.
Given how we designed the skip logic, I think that counts as "working as
intended" - we do
Nick Coghlan added the comment:
Curtis: by design, ``ensurepip`` isn't permitted to assume internet access
(since we want both it and venv to work without warnings or errors on systems
with no internet access). This was covered in the original PEP:
https://www.python.org/dev/peps/pep
Nick Coghlan added the comment:
Ah, I finally understand Victor's comment on my initial attempt at fixing the
tests on Mac OS X - the standard streams *don't* use the filesystem encoding,
so they default to ASCII in the C locale, even o
Changes by Nick Coghlan :
--
pull_requests: +2252
___
Python tracker
<http://bugs.python.org/issue28180>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
New changeset 7926516ff95ed9c8345ed4c4c4910f44ffbd5949 by Nick Coghlan in
branch 'master':
bpo-28180: Standard stream & FS encoding differ on Mac OS X (GH-2208)
https://github.com/python/cpython/commit/7926516ff95ed9c8345ed4c4c4
New submission from Nick Coghlan:
To get the new PEP 538 tests passing on Mac OS X (see [1,2]), I ended up having
to skip the following test scenarios:
LANG=UTF-8 (behaves like LANG=C, *not* LC_CTYPE=UTF-8)
LANG=POSIX (behaves like a distinct locale is set, not LANG=C)
LC_CTYPE
Nick Coghlan added the comment:
The latest commit should get the Mac OS X buildbot back to green, but I had to
disable some test cases to do it - see issue 30672 for details.
Issue 30565 is the one that covers silencing the locale coercion and locale
compatibility warnings by default
Nick Coghlan added the comment:
Updated issue title to reflect the fact we're now considering just silencing
*all* the warnings by default.
--
title: PEP 538: default to skipping warning for implicit locale coercion? ->
PEP 538: silence locale coercion and compatibility war
Nick Coghlan added the comment:
Note that the coercion logic includes a runtime check to see if
'setlocale(LC_CTYPE, "")' succeeds. That's how we skip over the
non-existent C.UTF-8 and C.utf8 to get to "LC_CTYPE=UTF-8" on Mac OS X and
FreeBSD.
That *appear
Nick Coghlan added the comment:
Thanks for the work on resolving this, all!
--
resolution: -> fixed
stage: backport needed -> resolved
status: pending -> closed
___
Python tracker
<http://bugs.python.or
Changes by Nick Coghlan :
--
nosy: +inada.naoki
___
Python tracker
<http://bugs.python.org/issue30565>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
pull_requests: +2310
___
Python tracker
<http://bugs.python.org/issue30565>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
For the case where POSIX is a distinct locale from the default C locale (rather
than a simple alias), I'm leaning towards taking PEP 538 literally, and
adjusting the affected test cases to assume that locale coercion *won't* happen
for that case on Ma
Nick Coghlan added the comment:
By having the warnings always compiled in, but off by default,
"PYTHONCOERCECLOCALE=warn" becomes a debugging tool for integration failures
that we (or end users) suspect might be due to the locale coercion behaviour.
It's essentially an eve
Nick Coghlan added the comment:
It seems the "POSIX is not just an alias for the C locale" behaviour is
inherited from *BSD, rather than being specific to Mac OS X:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%20CURRENT%20Debug%20custom/builds/12/steps/test/
Nick Coghlan added the comment:
OK, based on the latest round of custom buildbot results (e.g.
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%20CURRENT%20Debug%20custom/builds/12/steps/test/logs/stdio
), it looks like the main remaining problems are those covered by issue 30672
Nick Coghlan added the comment:
Flagging issue 30647 as a dependency, since the problem with breaking
nl_langinfo will need to be fixed before these tests can be re-enabled.
--
dependencies: +CODESET error on AMD64 FreeBSD 10.x Shared 3.x caused by the PEP
538
Nick Coghlan added the comment:
New changeset eb81795d7d3a8c898fa89a376d63fc3bbfb9a081 by Nick Coghlan in
branch 'master':
bpo-30565: Add PYTHONCOERCECLOCALE=warn runtime flag (GH-2260)
https://github.com/python/cpython/commit/eb81795d7d3a8c898fa89a376d63fc
Nick Coghlan added the comment:
OK, PEP 538 is effectively disabled on FreeBSD and Mac OS X now, and the locale
coercion and compatibility warnings are off by default everywhere.
PYTHONCOERCECLOCALE=warn is explicitly documented as a debugging tool for use
when folks already suspect that
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue30672>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue30647>
___
___
Python-bugs-list mailing list
Unsubscrib
Nick Coghlan added the comment:
The specific issue is that early exits from an "async with" statement are
actually defined the same way they for synchronous with statements: exiting
early via return, break, or continue, is the same as reaching the end of the
try block.
However,
Nick Coghlan added the comment:
A note regarding the applicable versions: for the original custom warning, we
decided it made sense to change it in a maintenance release, since the generic
syntax error really was incredibly cryptic, and we wanted to get the update
into the hands of users as
Nick Coghlan added the comment:
We'll likely still move it eventually, but I don't think that's a good reason
to keep this issue open - it's more a part of making incremental progress
towards being able to make PEP 432 a public API.
--
resolution: -> fixed
sta
Nick Coghlan added the comment:
Oops, having written the above comment, I belatedly remembered why I originally
suggested this be handled as a maintenance issue rather than as a regular
enhancement: I'd like to backport it to the Python 3.6 stack in Fedora, and I
think it's better
Nick Coghlan added the comment:
Also adding Ned to the nosy list, since it's ultimately his call as the 3.6
release manager.
Ned: the context here is that we just landed an improvement to the custom error
message for Py2-style print syntax that also says how to fix the problem,
rather
Nick Coghlan added the comment:
The specific error in question here is the one where Python 3 reads the old
Python 2 stream redirection syntax as a combination of the right shift operator
and tuple creation:
```
>>> print >> sys.stderr, "message"
Traceback (most
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue30744>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
--
pull_requests: +2421
___
Python tracker
<http://bugs.python.org/issue30647>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
The writeback-only-if-changed approach sounds like a plausible improvement to
me. I'd be hesitant to include such a change in 3.5.4 though, since we don't
get a second go at that if something breaks unexpectedly.
However, I don't think returning
Nick Coghlan added the comment:
Current status of the PR:
- testing suggests that "nl_langinfo(CODESET)" fails with LC_CTYPE=UTF-8 on Mac
OS X as well, but that doesn't matter for Python start-up, since we hardcode
UTF-8 as the locale encoding and never call nl_langinfo
- o
Nick Coghlan added the comment:
To make the behaviour more consistent in 3.7, I'd be more inclined to go in the
other direction: make locals() return a truly independent snapshot when used in
a function, rather than sharing a single snapshot between all locals() calls.
Shared snapshots
Changes by Nick Coghlan :
--
versions: +Python 3.7 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue17960>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
Sorry, I wasn't clear: I don't see any problem for the cases that don't
optimize local variable access, and don't think any of those should change.
Instead, I think we should tighten up the formal specification of locals() to
better matc
Nick Coghlan added the comment:
We have quite a few of them:
https://github.com/python/cpython/tree/master/Lib/test/crashers
Python 2.7 is ancient, so our tolerance for intrusive interpreter level fixes
to address rare problems that are easy to avoid at the development level is
pretty low
Nick Coghlan added the comment:
Since "soonish" turned out to be "4 years and counting", copying in the
specifics of the proposal in from the old python-dev thread:
1. While nominally undefined, in practice lots of Python programs depend on the
locals() builtin behaving ex
Nick Coghlan added the comment:
I updated the old "we should clarify the semantics" issue with a more concrete
update proposal: https://bugs.python.org/issue17960#msg296880
Essentially nothing would change for module and class scopes, but the proposal
for function scopes is that l
Nick Coghlan added the comment:
Guido: perhaps I should run this update through the PEP process?
Even though the actual proposed change is only to a pretty obscure edge case
(having multiple concurrent live references to the result of locals() for a
function namespace), the extra visibility
Nick Coghlan added the comment:
I like it because it categorically eliminates the "tracing or not?" global
state dependence when it comes to manipulation of the return value of locals()
- manipulating that will either always affect the original execution namespace
immediatel
Nick Coghlan added the comment:
One testing possibility worth considering: perhaps it would be make sense to
have "start_try" and "start_finally" trace events, such that a trace function
could be installed that injected signals at the worst possible time in the
opcode ev
Nick Coghlan added the comment:
Sorry, I misread Nathaniel's suggestion - the exhaustive search of all possible
offsets already avoids the need to hardcode any code generation dependent
details in the tests. So the trace function approach would just avoid the need
for that s
Nick Coghlan added the comment:
Also clarifying a point that came up later in the thread [1]: one of the
motivating examples that came up in the thread was the idea of using this to
catch AttributeError exceptions in property and __getattr__ implementations and
convert them to RuntimeError
Nick Coghlan added the comment:
The problem I see with proxy objects for functions/coroutines/generators is
that it *doesn't* match how locals() currently behaves in the absence of a
tracing function - that gives you a "single shared snapshot" behaviour, where
writes to the r
Nick Coghlan added the comment:
New changeset 18974c35ad9d25ffea041dc0363dc01889f4a595 by Nick Coghlan in
branch 'master':
bpo-30647: Check nl_langinfo(CODESET) in locale coercion (GH-2374)
https://github.com/python/cpython/commit/18974c35ad9d25ffea041dc0363dc0
Nick Coghlan added the comment:
I was able to fix the test_readline failure by restoring the locale based on
the environment settings with `setlocale(LC_CTYPE, "")` rather than the return
value from a preceding call to `setlocale(LC_CTYPE, NULL)`.
That means we can leave the runtim
Nick Coghlan added the comment:
I'm honestly not sure how our Python level locale handling really works (I've
mainly worked on the lower level C locale manipulation), so adding folks to the
nosy list based on #20076 and #29571.
I agree we shouldn't be aliasing C.UTF-8 to en_
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue17960>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue30597>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Nick Coghlan :
--
pull_requests: +2598
___
Python tracker
<http://bugs.python.org/issue30597>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
As per the discussion in issue #17960, I'm going to put together a short PEP
about this topic for Python 3.7 that will better specify the expected behaviour
of locals() and frame.f_locals.
That will be a combination of making the status quo official, prop
Nick Coghlan added the comment:
Err, s/officially part of the status quo/officially part of the language
specification/ :)
--
___
Python tracker
<http://bugs.python.org/issue30
Nick Coghlan added the comment:
I'm attempting to figure out whether or not we have a buildbot in the Buildbot
fleet that will cover this test case.
Based on the pre-merge CI run, it seems Ubuntu 14.04 is too old to include the
required kernel headers.
However, it looks like RHEL/CentO
Nick Coghlan added the comment:
New changeset bfdc6fdc0e76204caf2261f9cfa9d232fc23906a by Nick Coghlan in
branch '3.6':
[3.6] bpo-30597: Show expected input in custom 'print' error message. (GH-2531)
https://github.com/python/cpython/commit/bfdc6fdc0e76204caf22
Nick Coghlan added the comment:
And merged. Thanks all!
--
stage: backport needed -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Nick Coghlan added the comment:
This should be a fairly straightforward test-only fix: updating the start of
https://github.com/python/cpython/blob/master/Lib/test/test_c_locale_coercion.py
to set C_LOCALE_STREAM_ENCODING to 'iso8859-1' when
"sys.platform.
Nick Coghlan added the comment:
I also belatedly checked your list at
https://unicodebook.readthedocs.io/operating_systems.html#locale-encoding, and
confirmed that AIX is the only anomalous case you'd previously identified
(aside from the odd nominally-ASCII-but-not-really behavio
Nick Coghlan added the comment:
Documenting explicitly what I believe the expected order of module lock
acquisition would be in this case:
Thread A acquires package.subpackage lock
Thread B blocks on package.subpackage lock
Thread A acquires package lock
Thread A releases
Nick Coghlan added the comment:
Removing the "easy" tag, as I realised this isn't as clearcut a change as I
first thought.
Specifically, I'm wondering if in addition to changing the expectations for
this particular test, we should *also* be disabling locale coercion on AIX
1601 - 1700 of 6301 matches
Mail list logo
