Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: +5973
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33053>
___
_
Nick Coghlan <ncogh...@gmail.com> added the comment:
While I've merged an initial fix for this (so it should be working again in
3.7.0b3), I'm not going to close the issue until folks have had a chance to
review and comment on the linked list based approach I've taken.
--
ve
Nick Coghlan <ncogh...@gmail.com> added the comment:
It turned out some tests in CPython's own test suite were implicitly relying on
the old behaviour where the current working directory automatically ended up on
sys.path (see the changes to test_bdb and test_doctest in the upda
Nick Coghlan <ncogh...@gmail.com> added the comment:
PR posted with the change to use an absolute path for the starting working
directory in the "-m" case.
That PR also includes a change to improve the fidelity of the test suite: back
when I first wrote test_cmd_line_scri
Change by Nick Coghlan <ncogh...@gmail.com>:
--
keywords: +patch
pull_requests: +5970
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/issue33053>
___
_
New submission from Nick Coghlan <ncogh...@gmail.com>:
While working on https://bugs.python.org/issue33042, I found it hard to keep
track of which kind of config struct a particular piece of code was referencing.
As a particularly relevant example, we currently have 3 different "
Nick Coghlan <ncogh...@gmail.com> added the comment:
I added the new test case, and found to my surprise that it didn't fail, even
in debug mode (where there aren't any default filters).
The point I had missed was that even though warnoptions can be NULL in
Core
Nick Coghlan <ncogh...@gmail.com> added the comment:
PR has been updated to be mostly complete (just pending docs changes now), but
I think I've found a potential issue with the interaction between the way I've
currently implemented it and the way _Py_Initiali
Nick Coghlan <ncogh...@gmail.com> added the comment:
Possibly - we implemented ensurepip the way we did just because it was the
easiest option, not because we closely considered all the available approaches.
That would be a separate process improvement issue,
New submission from Nick Coghlan <ncogh...@gmail.com>:
Paul brought up recently [1] that with pip 10.0.0 due for release next month
[2], we'd really prefer to ship that in Python 3.7.0 (such that 3.7 launches
with PEP 518/517 pyproject.toml support), rather than shipping with
Nick Coghlan <ncogh...@gmail.com> added the comment:
This is deliberate, and is covered in the documentation at
https://docs.python.org/3/using/cmdline.html#cmdoption-m where it says 'If this
option is given, the first element of sys.argv will be the full path to the
module file
Nick Coghlan <ncogh...@gmail.com> added the comment:
Aye, this is the issue for making the API public, so it will stay open until
PEP 432 is actually accepted.
We switched to the pre-implement-changes-as-an-internal-CPython-refactoring
approach after we/I realised there was no feasib
Nick Coghlan <ncogh...@gmail.com> added the comment:
Heh, apparently I forgot how IMPORT_FROM currently works some time between 2015
and 2017 :)
I agree this is out of date now, as the requested behaviour was already
implemented for 3.7
--
resolution: -> out of d
Nick Coghlan <ncogh...@gmail.com> added the comment:
Brett or Eric, any chance one of you could run with this for 3.7b3? I already
have a startup refactoring related regression that I'm aiming to have fixed
before then.
Thanks to Victor's refactoring work, there's at least a
Nick Coghlan <ncogh...@gmail.com> added the comment:
Thinking about PySys_AddWarnOptionUnicode a little further, I'm not sure we
actually need to change anything in the implementation there - I think we can
just make it clearer in the docs that *only* PySys_AddWarnOption is supported
Nick Coghlan <ncogh...@gmail.com> added the comment:
Over in https://bugs.python.org/issue33053#msg314192, I came up with
`--basepath ` as another possible spelling (`--no-basepath` would then be
an option for turning it off.
The main argument *against* that name is that we use "ba
Nick Coghlan <ncogh...@gmail.com> added the comment:
(Adding the other import system maintainers to the nosy list, along with Ned as
the release manager for 3.6 and 3.7)
Summarizing my current thoughts on this:
I think the fact that "-m" currently adds the empty directo
Nick Coghlan <ncogh...@gmail.com> added the comment:
The linked PR has the draft test case for this - it goes beyond the ones I used
to find the cause of the problem by actually checking that sys.warnoptions and
sys._xoptions have been populated as ex
Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: +5914
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Nick Coghlan <ncogh...@gmail.com> added the comment:
Donald made an interesting suggestion over on
https://github.com/pypa/packaging-problems/issues/127#issuecomment-374401331,
which was to have distutils stop overwriting the Author metadata with the
Maintainer metadata whe
Nick Coghlan <ncogh...@gmail.com> added the comment:
It occurs to me that there may be some additional unshared context here: the
way `python -m pip` searches for the module to execute is much closer to the
way Windows searches for a command like `pip` (i.e. current directory first)
Nick Coghlan <ncogh...@gmail.com> added the comment:
This question recently came up again over in
https://bugs.python.org/issue33053#msg314040.
With the assorted startup refactorings that were landed for 3.7, it likely
makes sense to take another run at this f
Nick Coghlan <ncogh...@gmail.com> added the comment:
https://bugs.python.org/issue13475 is the existing enhancement request to
expose sys.path[0] management independently of the other execution isolation
features.
--
___
Python tracke
Nick Coghlan <ncogh...@gmail.com> added the comment:
"python -m mypkg.myscript" does the right thing as far as local packages are
concerned, whereas "python -m mypkg/myscript.py" will set you up for
double-import bugs.
Note that you can almost always trigger
Nick Coghlan <ncogh...@gmail.com> added the comment:
I'm going to abuse the "third party" resolution type a bit and mark this as
closed (at least for now) on the basis of "use setuptools instead if you want
the improved behaviour".
I've also opened https://github.c
Nick Coghlan <ncogh...@gmail.com> added the comment:
Regarding 2.7: if folks want this fixed on RHEL/CentOS, then they need to talk
to Red Hat about it, not the upstream CPython devs. I used to work there, and
was told multiple times by Red Hat executives that none of their customers
ac
Nick Coghlan <ncogh...@gmail.com> added the comment:
I've also separated out https://bugs.python.org/issue33095 (a docs issue about
making isolated mode more discoverable) based on the jwilk's comment that it
wasn't clear how to disable the default "add the current directory
New submission from Nick Coghlan <ncogh...@gmail.com>:
In https://bugs.python.org/issue33053#msg313966, jwilk noted that it isn't
obvious from https://docs.python.org/3/using/cmdline.html#cmdoption-m how to
keep the current directory from being added to `sys.path` when using the -m
Nick Coghlan <ncogh...@gmail.com> added the comment:
Also, a small upstream community interaction tip: if you want people to
seriously consider your requests for changes in default behaviour (which
inevitably risk backwards compatibility breaks), don't start out by insulting
them.
Py
Nick Coghlan <ncogh...@gmail.com> added the comment:
This isn't considered a security issue, as running "python3" interactively
behaves in exactly the same way (i.e. tracking changes to the current working
directory for the duration of the session), and running "pyt
Nick Coghlan <ncogh...@gmail.com> added the comment:
This shouldn't affect the public ABI, so I don't think it's a blocker for the
ABI freeze, but it's a regression that effectively makes PySys_AddWarnOption
(and related APIs) unusable, so we should definitely fix it before shippi
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset c2b0b12d1a137ada1023ab7c10b8d9a0249d95f9 by Nick Coghlan (Marcel
Plch) in branch 'master':
bpo-32374: m_traverse may be called with m_state=NULL (GH-5140)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
Patched test_capi results for 2ebc5ce42a8a9e047e790aefbf9a94811569b2b6 (the
global state consolidation commit): both pre-initialization tests fail
Patched test_capi results for bab21faded31c70b142776b9a6075a4cda055d7f (the
immed
Nick Coghlan <ncogh...@gmail.com> added the comment:
We allowed semi-standardised additional fields for an extended period with 1.2
(for Provides-Extra and Description-Content-Type), but folks mostly found it
confusingly ambiguous, so Dustin created PEP 566 to define them offi
Nick Coghlan <ncogh...@gmail.com> added the comment:
While I haven't definitely narrowed it down yet, I suspect it isn't your
changes that are the problem: since the reported crash relates to attempting to
access a not-yet-created thread state, `warnoptions` and `_xoptions` likely
Nick Coghlan <ncogh...@gmail.com> added the comment:
Thanks for the report and pull request. Do you happen to know if setuptools is
also affected?
If yes, the problem will need to be reported & fixed there as well (otherwise
the maintainer metadata will still be missing for many
Nick Coghlan <ncogh...@gmail.com> added the comment:
After reworking the patch to backport the pre-initialization embedding tests to
3.7.0a1, they *both* failed, as that was before Victor fixed Py_DecodeLocale to
work prior to initialization again.
As a result, I tried
https://gith
Nick Coghlan <ncogh...@gmail.com> added the comment:
https://github.com/python/cpython/commit/b4d1e1f7c1af6ae33f0e371576c8bcafedb099db
(the first attempted fix for bpo-20891) is the last commit where the draft
test case patch applies cleanly.
That still segfaults, so I'll jump all t
Nick Coghlan <ncogh...@gmail.com> added the comment:
Adding a bit of context from my prior email discussion with Hartmut: CPython
actually reads sys.warnoptions at the end of Py_Initialize (its the last thing
we do before the function returns).
It also reads sys._xoptions during s
Nick Coghlan <ncogh...@gmail.com> added the comment:
With both Eric's and Serhiy's updates merged, and issue 33039 broken out for
the __index__ oddities, this is resolved now.
--
resolution: -> fixed
stage: patch review -> resolved
status: op
Change by Nick Coghlan <ncogh...@gmail.com>:
--
assignee: -> ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33042>
___
_
Nick Coghlan <ncogh...@gmail.com> added the comment:
I don't think we made any start-up changes that were specific to
PySys_AddWarnOption, so my suspicion is that the crash is going to be related
to a change in the constraints on either the unicode object creation or the
list append ope
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 1028ca4f04c14cf40a8f3e7951623a96ec0143c2 by Nick Coghlan (Miss
Islington (bot)) in branch '3.6':
bpo-26701: Add documentation for __trunc__ (GH-6050)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset f34e0d60e27acff3f9604ec63e9de36878c3743a by Nick Coghlan (Miss
Islington (bot)) in branch '3.7':
bpo-26701: Add documentation for __trunc__ (GH-6049)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
Marking this as a documentation enhancement request for now, but I think we
should also consider changing the type creation behaviour in 3.8 to implicitly
add __int__ and __trunc__ definitions when __index__ is defined, but they
Nick Coghlan <ncogh...@gmail.com> added the comment:
I think __trunc__ is special here, as it's called by a built-in type
constructor, whereas __floor__ and __ceil__ really are specific to their
respective math module functions. That said, I also wouldn't be opposed to
listing all 4 m
New submission from Nick Coghlan <ncogh...@gmail.com>:
(Note: I haven't categorised this yet, as I'm not sure how it *should* be
categorised)
Back when the __index__/nb_index slot was added, the focus was on allowing 3rd
party integer types to be used in places where potentially
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 308eab979d153f1ab934383dc08bc4546ced8b6c by Nick Coghlan (Eric
Appelt) in branch 'master':
bpo-26701: Add documentation for __trunc__ (GH-6022)
https://github.com/python/cpython/commit/308eab979d153f1ab934383dc08bc4546c
Nick Coghlan <ncogh...@gmail.com> added the comment:
The note on https://docs.python.org/3/library/re.html#re.compile provides a
useful precedent for possible wording here, as the struct cache and the regex
cache are quite similar.
--
___
New submission from Nick Coghlan <ncogh...@gmail.com>:
The struct.Struct docs claim that creating and re-using a Struct object will be
noticeably faster than calling the module level methods repeatedly with the
same format string, as it will avoid parsing the format string multiple
Nick Coghlan <ncogh...@gmail.com> added the comment:
Yeah, dropping _PyFrame_Init/Fini for 3.8+ would make sense.
It's PyByteArray_Init/Fini that probably aren't worth the hassle of removing,
since the lack of a leading underscore means they'd need to go through a
deprecation
Nick Coghlan <ncogh...@gmail.com> added the comment:
(Bringing my response from core-mentorship over to the main tracker)
These APIs are exposed to embedding applications via the pylifecycle header:
https://github.com/python/cpython/blob/master/Include/pylifecycle.h#L143
While we techn
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 3a087beddd9f0955eb9080a6fd1499ff89ca74bf by Nick Coghlan (Nitish
Chandra) in branch 'master':
bpo-32836: Remove obsolete code from symtable pass (GH-5680)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
I +1'ed Serhiy's patch for issue 32946, so we'll have to take that
micro-optimisation into account if we decide to rely on the Python level
`_handle_fromlist` to cover the "*" import case.
Given that optimisation, it's
Nick Coghlan <ncogh...@gmail.com> added the comment:
_xxsubinterpreters has been added, and we'll use PEP 554 as the interim
documentation while it's only exposed for testing purposes.
--
resolution: -> fixed
stage: patch review -> resolved
status: op
Nick Coghlan <ncogh...@gmail.com> added the comment:
With issue 17611 merged (which moves stack unwinding to the compiler), I expect
the exact details of this problem to have changed, but the general problem
still exists: Ctrl-C may lead to __exit__ (or __aexit__) not being called even
Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: -5640
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue12345>
___
_
Nick Coghlan <ncogh...@gmail.com> added the comment:
I believe the original rationale for the `__path__` check was to restrict that
branch to the case where we may need to import a not-yet-imported submodule in
order to get the attribute set appropriately.
However, giving a better
Nick Coghlan <ncogh...@gmail.com> added the comment:
I think supporting "s" makes sense, as we're going to need to treat the empty
format string as implying "s" for backwards compatibility reasons:
>>> f"{v4}"
'1.2.3.4'
Right now, attemptin
Nick Coghlan <ncogh...@gmail.com> added the comment:
We don't change the extension on optimised pyc files any more, we add an
optimisation marker to the name without changing the file extension:
https://www.python.org/dev/peps/pep-0488/
(This means `-O` and `-OO` don't tread on each oth
Nick Coghlan <ncogh...@gmail.com> added the comment:
+1 for the DeprecationWarning->SyntaxWarning->SyntaxError approach from me
(especially as 3.7 will make the existing deprecation warning visible in
interactive shells and __main__ module
Nick Coghlan <ncogh...@gmail.com> added the comment:
I'll also note that I made my comments above about writing a new PEP prior to
the migration to GitHub and the availability of a PR-based workflow for
reviewing PEP changes.
So consider the PR Cheryl linked and the post at
Nick Coghlan <ncogh...@gmail.com> added the comment:
Ah, right - in that case, I think the subclasses would be worthwhile, as they
shouldn't be too much hassle to maintain for a release, and will provide a more
graceful migration for folks doing their own AST processing and gene
Nick Coghlan <ncogh...@gmail.com> added the comment:
As pure aliases, those wouldn't necessarily be that useful, as aside from
NameConstant, the field names are different (Num.n, Str.s, Bytes.s).
I do wonder whether it might be worth keeping "NameConstant", though, and use
t
Nick Coghlan <ncogh...@gmail.com> added the comment:
For TESTFN_NONASCII vs TESTFN_UNICODE (inferred from reading the current code &
https://github.com/python/cpython/commit/8b219b2936d767bf6c6c17618db3a7b22fc2e865):
* TESTFN_NONASCII guarantees that it can be encoded a
Nick Coghlan <ncogh...@gmail.com> added the comment:
I've updated the issue title to reflect the revised proposal (i.e. using
__format__ rather than a new IP address specific method).
--
title: Add bits method to ipaddress -> Add __format__ method to
Nick Coghlan <ncogh...@gmail.com> added the comment:
+1 from me for making the change 3.7.0+ only - 3.6 isn't doing the right thing,
but given folks are relying on it doing the wrong thing, then let's leave it
alone given where it is in its lif
Nick Coghlan <ncogh...@gmail.com> added the comment:
The python-ideas discussion didn't turn up any major concerns we hadn't already
considered, so you're in "wait for PR review" mode now. If you wanted to do a
self-review in the meantime, then
https://devguide.pytho
Nick Coghlan <ncogh...@gmail.com> added the comment:
Allowing for None-first and None-last ordering is a fair use case, but I'm not
sure a __key__ protocol is the right answer to that - as your own example
shows, it gets tricky when dealing with nested containers.
It may make sense to
Nick Coghlan <ncogh...@gmail.com> added the comment:
Aye, definitely worth a thread on python-ideas. My rationale for suggesting
something based on the built-in numeric codes is that it makes it
straightforward for *users* to transfer knowledge from that mini-language.
As far as parsin
Nick Coghlan <ncogh...@gmail.com> added the comment:
We still need to the ".0" style temporary variables that are used for argument
names in the implicitly generated functions, but it's definitely plausible that
we're not actually using the "_[1]" style hidden
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset aec7532ed3ccbd29d3429a3f375e25f956c44003 by Nick Coghlan in
branch 'master':
bpo-30579: Docs for dynamic traceback creation (GH-5653)
https://github.com/python/cpython/commit/aec7532ed3ccbd29d3429a3f375e25f956
Nick Coghlan <ncogh...@gmail.com> added the comment:
It isn't InitVar that you want for that use case (that's just for passing extra
information to __post_init__).
Instead, you want:
extra_field = field(compare=False): int # Excluded from __hash__, __eq_, etc
You can also exclude a
Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: +5455
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue30579>
___
_
Nick Coghlan <ncogh...@gmail.com> added the comment:
For now, I'm going to close this as "out of date", with the guidance being
"Define a data class instead" (since that gets rid of the historical
boilerplate a different way: auto-generating suitable methods based
Nick Coghlan <ncogh...@gmail.com> added the comment:
I can reproduce this, but it looks to me like it's being triggered by UTF-8
mode rather than locale coercion (the "LC_ALL=C" setting will implicitly
disable locale coercion entirely):
```
$ LANG=C PYTHONCOERCECLOCALE=warn
Nick Coghlan <ncogh...@gmail.com> added the comment:
I think the aspect that makes this potentially worthy of a helper function is
the need to dynamically adjust the field width based on whether you're printing
an IPv4 address or an IPv6 one, whether you're printing it in
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset a0b998df314370f00502efe7ad84206f5bb782ff by Nick Coghlan (Miss
Islington (bot)) in branch '3.7':
bpo-11015: Update test.support documentation (GH-5619)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
I merged Cheryl's PR to the dev branch, and triggered the backport to 3.7. If
nobody beats me to it, I'll merge the latter tomorrow :)
--
assignee: docs@python -> ncoghlan
resolution: -> fixed
stage: patch review ->
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 988fb28431d3a3fc5dc6eb657c8a4baacc04d9ce by Nick Coghlan (Cheryl
Sabella) in branch 'master':
bpo-11015: Update test.support documentation (GH-5610)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
>From VA's description of the intended use case, this actually sounds a bit
>like a variant of https://bugs.python.org/issue29944: one reason that
>replacing C with a new dynamically constructed type won't work reliably is
Nick Coghlan <ncogh...@gmail.com> added the comment:
I'd also ask whether the use case can be satisfied by rebinding __class__
instead of __bases__. That's far better defined than replacing the contents of
the bases list and attempting to dynamically recalculate t
Nick Coghlan <ncogh...@gmail.com> added the comment:
I've added Guido to the thread, as my initial reaction is to propose
deprecating writable __bases__ rather than trying to support it properly.
However, if we do decide to fix it, then the potential path to resolution I
would suggest
Nick Coghlan <ncogh...@gmail.com> added the comment:
Thanks for the patch Cheryl, and for the reviews Terry!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset fea0a12f6bee4a36b2c9533003e33a12c58d2d91 by Nick Coghlan (Miss
Islington (bot)) in branch '3.7':
[3.7] bpo-8722: Document __getattr__ behavior with AttributeError in property
(GH-5543)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset a8c25d1c7f0d395861cc3e10dd01989150891c95 by Nick Coghlan (Miss
Islington (bot)) in branch '3.6':
[3.6] bpo-8722: Document __getattr__ behavior with AttributeError in property
(GH-5542)
https://github.com/python/cpython/
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:
I didn't think to check those - it looks like they have the same problem with
the same fix (i.e. the actual syntax is "digit+").
--
___
Python tracker <rep...@bugs
Nick Coghlan <ncogh...@gmail.com> added the comment:
If I recall the discussion correctly, it was:
1. That this was worth doing precisely because the naive approach is likely to
be broken in the presence of multiple threads;
2. It was only worth doing either as a true global d
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset d1f318105b8781b01f3507d5cb0fd841b977d5f2 by Nick Coghlan (Cheryl
Sabella) in branch 'master':
bpo-8722: Document __getattr__ behavior with AttributeError in property
(GH-4754)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 1a0239e12e161609fdf68f13cedbabca9bf353f1 by Nick Coghlan (Miss
Islington (bot)) in branch '3.7':
[3.7] bpo-32691: Use mod_spec.parent when running modules with pdb (GH-5510)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 38bfa8418f5d39bcc7478b8f7aef4a632c26172e by Nick Coghlan (Mario
Corchero) in branch 'master':
bpo-32691: Use mod_spec.parent when running modules with pdb (GH-5474)
https://github.com/python/cpython/
New submission from Nick Smith <ni...@fastmail.fm>:
The log_error method in refactor.RefactoringTool raises the exception:
def log_error(self, msg, *args, **kwds):
"""Called when an error occurs."""
raise
but every usage of it imp
Nick Coghlan <ncogh...@gmail.com> added the comment:
I forget we had mod_spec.parent available to us these days, so yes, we should
use that rather than recalculating the parent with str.rpartition.
As Mario noted, we only want to change the behaviour when the executed module
is a plain
Nick Coghlan <ncogh...@gmail.com> added the comment:
A useful heuristic is that if something is named with CapWords, then class-like
*usage* is explicitly supported (inheritance, isinstance checks, etc).
If it's named with snake_case or wordsruntogether, then calling it is OK, but
you m
Nick Coghlan <ncogh...@gmail.com> added the comment:
OK, this is back the way it was on the 3.6 branch now, while keeping the change
on the 3.7 branch.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
version
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 05f91a42cd9575ef338a67bd04855b44f6ac20c2 by Nick Coghlan in
branch '3.6':
[3.6] Revert "bpo-32690: Preserve order of locals() (GH-5379) (#5390)"
https://github.com/python/cpython/commit/05f91a42cd9575ef338a67bd
New submission from Nick Coghlan <ncogh...@gmail.com>:
I just noticed that https://docs.python.org/3/library/string.html#formatspec
links to the "integer" definition in the main Python grammar for the permitted
format of numeric fields.
This isn't accurate:
```
>&g
Nick Coghlan <ncogh...@gmail.com> added the comment:
Noting the git-fu required for non-master reverts:
- check out the branch of interest and ensure it's up to date
- `git checkout -b bpo-32690-revert-3.6-backport`
- `git revert 9105879bfd7133ecbac67f3e9c0bacf6e477de5a`
- edit commit m
701 - 800 of 8215 matches
Mail list logo
