Nick Coghlan 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, though
New submission from Nick Coghlan :
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 9.0.x and
then upgrading to 1
Nick Coghlan 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 (while the module file is
Nick Coghlan 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 feasible way to develop and
Nick Coghlan 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 date
stage: -> resolved
status
Nick Coghlan 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 clear interception
Nick Coghlan 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
prior to Py_Initializ
Nick Coghlan 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 "base" to mean
Nick Coghlan 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 directory as sys.path[0]
instead of
Nick Coghlan 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 expected
Change by Nick Coghlan :
--
pull_requests: +5914
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33042>
___
___
Python-bugs-list mai
Nick Coghlan 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 when both are specified and instead emit a
Nick Coghlan 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)
than it is to the way *nix
Nick Coghlan 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 for 3.8
Nick Coghlan 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 tracker
<https://bugs.python.
Nick Coghlan 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 arbitrary non-obvious code execut
Nick Coghlan 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.com/pypa/pa
Nick Coghlan 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
actually used Python, so the
Nick Coghlan 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 to
New submission from Nick Coghlan :
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
switch. The answer is to
Nick Coghlan 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.
Python's de
Nick Coghlan 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 "python3 script.py"
Nick Coghlan 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 shipping 3.7.
For
Nick Coghlan 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/commit/c2b0b12d1a137ada1023ab7c10b8d9
Nick Coghlan 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
immediately preceding commit): both
Nick Coghlan 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 officially as
Metadata 1.3.
Given that
Nick Coghlan 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
need to become C lev
Nick Coghlan 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 publishers), if no, then
u
Nick Coghlan 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://github.com/python/cpython/commit
Nick Coghlan 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 the way back to 3.7.0a1, r
Nick Coghlan 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 startup, since that's one w
Nick Coghlan 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: open -> closed
___
Change by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<https://bugs.python.org/issue33042>
___
___
Python-bugs-list mailing list
Unsubscrib
Nick Coghlan 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 operation.
The att
Nick Coghlan 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/commit/1028ca4f04c14cf40a8f3e7951623a
Nick Coghlan 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/commit/f34e0d60e27acff3f9604ec63e9de3
Nick Coghlan 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
aren't.
That way, no beha
Nick Coghlan 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 methods togethe
New submission from Nick Coghlan :
(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 lossy conversion
wi
Nick Coghlan 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/308eab979d153f1ab934383dc08bc4546ced8b6c
-
Nick Coghlan 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.
--
___
Python tracker
<ht
New submission from Nick Coghlan :
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 times:
https://docs.python.org
Nick Coghlan 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 cycle.
--
re
Nick Coghlan 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 technically *could* deprecate
Nick Coghlan 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/commit/3a087beddd9f0955eb9080a6fd1499
Nick Coghlan 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 probably
Nick Coghlan 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
Nick Coghlan 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
after __enter__ (or
Change by Nick Coghlan :
--
pull_requests: -5640
___
Python tracker
<https://bugs.python.org/issue12345>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan 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 error message for __all__ in
Nick Coghlan 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, attempting to for
Nick Coghlan 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 othe
Nick Coghlan 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__ modules by default).
--
___
Nick Coghlan 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
https://mail.python.org/pipe
Nick Coghlan 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 gener
Nick Coghlan 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
that for Ellipsis
Nick Coghlan 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 and decoded with the
default filesy
Nick Coghlan 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 i
Nick Coghlan 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 lifecycle.
--
Nick Coghlan 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.python.org/committing
Nick Coghlan 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 raise the questi
Nick Coghlan 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 parsing goes, I was thinking of
Nick Coghlan 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 variables anyw
Nick Coghlan 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/aec7532ed3ccbd29d3429a3f375e25
Nick Coghlan 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 field from __h
Change by Nick Coghlan :
--
pull_requests: +5455
___
Python tracker
<https://bugs.python.org/issue30579>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan 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 on the
field declarat
Nick Coghlan 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 ./python -We -
Nick Coghlan 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 binary or
hexadecimal, whet
Nick Coghlan 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/commit/a0b998df314370f00502efe7ad8420
Nick Coghlan 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 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/commit/988fb28431d3a3fc5dc6eb657c8a4b
Nick Coghlan 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
>because som
Nick Coghlan 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 recalcula
Nick Coghlan 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 is:
1. Factor out a
Nick Coghlan added the comment:
Thanks for the patch Cheryl, and for the reviews Terry!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.o
Nick Coghlan 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/cpyt
Nick Coghlan 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/cpyt
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Nick Coghlan 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
<https://bugs.pyt
Nick Coghlan 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 disable that accounted for
multi
Nick Coghlan 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/cpyt
Nick Coghlan 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/cpyt
Nick Coghlan 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/commit/38bfa8418f5d39bcc7478b8f7aef4a
New submission from Nick Smith :
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 implies that it does not, e.g:
Nick Coghlan 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 module or submodule
Nick Coghlan 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 may run into q
Nick Coghlan 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
versions: -Python 3.6
_
Nick Coghlan 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/05f91a42cd9575ef338a
New submission from Nick Coghlan :
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:
```
>>> format(10e4, ",
Nick Coghlan 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 message as approp
Change by Nick Coghlan :
--
pull_requests: +5272
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue32690>
___
___
Python-bugs-lis
Nick Coghlan added the comment:
I've also added Matthias and Barry to the cc list, in case this does turn out
to be a Debian or Ubuntu specific quirk.
Restating the problem, the issue is that test_locale_flag in test_re may fail
for at least the en_IN locale, and we're not sure y
Nick Coghlan added the comment:
Ah, and in my REPL example, the NameError was pending when the internal result
storage was getting set back to None.
I'm not sure I even knew the "Don't complain when an exception is pending"
check existed, so it would have taken me a lo
Nick Coghlan added the comment:
Looking at the ceval code, I think Yury's theory is plausible, and we may also
be leaving the interpreter's internal stack in a dubious state. Things then get
cleaned up if you wrap the async with in a try/except or try/finally:
==
>
Nick Coghlan added the comment:
A warning I'm sometimes seeing currently on successful test runs is as follows:
--
/home/ncoghlan/devel/cpython/Lib/multiprocessing/semaphore_tracker.py:55:
UserWarning: semaphore_tracker: process died unexpectedly, relaunching. Some
semaphores might
Nick Coghlan added the comment:
Hmm, this actually works for me on Fedora 27 even if I go back to
1b3d88eb33085e90af729c4c2f78b5ba1b942b1e, the commit just before the initially
merged (and subsequently reverted) test change above.
Unassigning, since I can't readily reproduce it m
Nick Coghlan added the comment:
Hmm, even though we reverted the original test_re based change, and the initial
attempted fix for bpo-20087 was also reverted, I'm still not currently seeing
the failure for:
LANG=en_IN.utf8 ./python -m test -v test_re
I do have the locale installe
Nick Coghlan added the comment:
Thanks for the patches, Sanyam & Nitish, and for the original bug report Mayank.
Thanks also to Cheryl for nudging us to get it resolved :)
--
resolution: -> fixed
stage: patch review -> resolved
status: open
Nick Coghlan added the comment:
New changeset b3b4b81d0147534151941105eba4af984acdc763 by Nick Coghlan (Miss
Islington (bot)) in branch '3.6':
bpo-32685: Improve suggestion for print statement (GH-5380)
https://github.com/python/cpython/commit/b3b4b81d0147534151941105eba4af
701 - 800 of 6508 matches
Mail list logo