New submission from Nick Coghlan :
This is a simpler proposal born out of https://bugs.python.org/issue31815:
adding __length_hint__ implementations to some known-infinite iterators in
itertools that always raise TypeError.
This means that iterator consumers that use the operator.length_hint
Nick Coghlan added the comment:
Aye, I'm fine with deferring the programmatic deprecation for now - it's mainly
the docs I'd like to see changed at the same time as the regression is fixed.
--
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
While I agree the documentation issue means that this should be made to work
again for Python 3.7.1, I'd like for Python 3.7 to at least deprecate calling
Py_Initialize twice without an intervening Py_Finalize.
Otherwise the public multi-phase interpreter
Nick Coghlan added the comment:
New changeset 16eb3bcdb22be4d82dc597b92b7154fcb11c6479 by Nick Coghlan in
branch 'master':
bpo-33499: PYTHONPYCACHEPREFIX What's New entry (GH-7749)
https://github.com/python/cpython/commit/16eb3bcdb22be4d82dc597b92b7154fcb11c6479
Nick Coghlan added the comment:
Right, the HTML example was always a bit cutesy (hence the disclaimer in the
header), but it's hard to come up with a good illustrative example that isn't
already a native context manager in the standard library.
Perhaps it would make sense to change
Nick Coghlan added the comment:
xtreak: if you're familiar with GitHub workflows, then we now accept docs and
code updates as GitHub PRs: https://devguide.python.org/pullrequest/
The parts about running the tests aren't exactly relevant here, what's more
relevant is building
Change by Nick Coghlan :
--
pull_requests: +7357
___
Python tracker
<https://bugs.python.org/issue33499>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Merged as PYTHONPYCACHEPREFIX=path, -X pycache_prefix=path and
sys.pycache_prefix :)
I'll also update PEP 304 with a note saying a variant of the idea was
eventually accepted for Python 3.8.
--
resolution: -> fixed
stage: patch review -> re
Nick Coghlan added the comment:
New changeset b193fa996a746111252156f11fb14c12fd6267e6 by Nick Coghlan (Carl
Meyer) in branch 'master':
bpo-33499: Add PYTHONPYCACHEPREFIX env var for alt bytecode cache location.
(GH-6834)
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
Adding a link to the first post in a series of articles from Victor Stinner
regarding the evolution over time of the text encoding assumptions in Python
3's operating system interfaces:
https://vstinner.github.io/python30-listdir-undecodable-filenames.html
Nick Coghlan added the comment:
Correction: I just rejected my proposed wsgiref in issue 22264 as failing to
make a sufficient case for their practical utility, so that one is closed as
well :)
--
___
Python tracker
<https://bugs.python.
Nick Coghlan added the comment:
We don't have anyone clamouring for this, and the third party module
https://ftfy.readthedocs.io/en/latest/ has a lot more utilities for working
with messy binary inputs and incorrectly decoded text than we'd ever add to the
standard library, so I'm going
Nick Coghlan added the comment:
With PEPs 538 and 540 merged for Python 3.7 (so we'll almost always use UTF-8
instead of ASCII when the platform nominates the C or POSIX locale as the
currently active one), and Windows previously switching to assuming UTF-8
instead of mbcs for binary
Change by Nick Coghlan :
--
stage: backport needed -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue11874>
___
___
Pyth
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 1bcb8a636857e3383d65aaf196f93edb949f2e79 by Nick Coghlan in
branch 'master':
bpo-33409: Clarify PEP 538/540 relationship (GH-7534)
https://github.com/python/cpython/commit/1bcb8a636857e3383d65aaf196f93edb949f2e79
Nick Coghlan added the comment:
It also occurred to me to ask whether or not moving modules to the end of
sys.modules each time they're successfully imported would help solve the
problem (albeit at the expense of making import cache hits more expensive).
I don't think it does, though, since
Nick Coghlan added the comment:
I think the key concern here is that we *don't* consistently add modules to
sys.modules in the order their bodies are executed: we add them in a kind of
sawtooth order based on the imports from __main__, and the order of import
statements in the imported
Nick Coghlan added the comment:
Merged for 2.7 in
https://github.com/python/cpython/commit/458ed1b237150f5c59b6ab3e1a5241a672ac8cbd
Thank you for the PRs, Mayank!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Nick Coghlan added the comment:
Thanks for the PR, and your patience!
The change has now been merged for all active 3.x versions.
It turns out the 2.7 argparse code is still close enough to the 3.x code for
the automated backport to work, so the CI for that is currently running
Nick Coghlan added the comment:
The rationale for documenting it in the porting section is that even though
this isn't a guaranteed stable interface, the output *does* potentially affect
development tools like Ned's coverage.py, as well as other implementations
attempting to adhere closely
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +7172
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
New changeset 66f02aa32f1e4adb9f24cf186f8c495399d5ce9b by Nick Coghlan (wim
glenn) in branch 'master':
bpo-11874: fix assertion failure in argparse metavar handling (GH-1826)
https://github.com/python/cpython/commit/66f02aa32f1e4adb9f24cf186f8c495399d5ce9b
Nick Coghlan added the comment:
New changeset 66f02aa32f1e4adb9f24cf186f8c495399d5ce9b by Nick Coghlan (wim
glenn) in branch 'master':
bpo-11874: fix assertion failure in argparse metavar handling (GH-1826)
https://github.com/python/cpython/commit/66f02aa32f1e4adb9f24cf186f8c495399d5ce9b
Nick Coghlan added the comment:
New changeset 66f02aa32f1e4adb9f24cf186f8c495399d5ce9b by Nick Coghlan (wim
glenn) in branch 'master':
bpo-11874: fix assertion failure in argparse metavar handling (GH-1826)
https://github.com/python/cpython/commit/66f02aa32f1e4adb9f24cf186f8c495399d5ce9b
Nick Coghlan added the comment:
New changeset 66f02aa32f1e4adb9f24cf186f8c495399d5ce9b by Nick Coghlan (wim
glenn) in branch 'master':
bpo-11874: fix assertion failure in argparse metavar handling (GH-1826)
https://github.com/python/cpython/commit/66f02aa32f1e4adb9f24cf186f8c495399d5ce9b
New submission from Nick Coghlan :
Talking to Berker on http://psf.upfronthosting.co.za/roundup/meta/issue644 I
noticed that docs for random.Random are currently embedded in the module
preamble text for https://docs.python.org/3/library/random.html and hence
really easy to miss.
It would
Nick Coghlan added the comment:
While I wouldn't describe this as completely intentional (as it's an artifact
of the change-and-revert dance with 3.7 previously removing docstring nodes
from the AST entirely), I also wouldn't want to change it again at this late
stage of the release process
Nick Coghlan added the comment:
New changeset 9ef1b0690b90c526798b6b3125b0fa7ae98319a2 by Nick Coghlan (Mayank
Singhal) in branch 'master':
bpo-31215: Add version changed notes for OpenSSL 1.1.0 compatibility (GH-7346)
https://github.com/python/cpython/commit
Change by Nick Coghlan :
--
versions: +Python 3.8 -Python 3.7
___
Python tracker
<https://bugs.python.org/issue19982>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
Updated link to the ABI tracker report:
https://abi-laboratory.pro/tracker/timeline/python/
(The stable ABI report still has a separate entry on
http://upstream.rosalinux.ru/ but it links to the same report as I've linked
above)
I'm bumping this based
Change by Nick Coghlan :
--
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31014>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Nick Coghlan :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
type: compile error -> behavior
___
Python tracker
<https://bugs.python
Nick Coghlan added the comment:
In that case, closing this as resolved. Folks interested in the idea of a
"suite" compilation mode to compile a series of statements without
special-casing the first one as a potential docstring, as well as the idea of a
dedicated DocString AST nod
Nick Coghlan <ncogh...@gmail.com> added the comment:
I'm aiming for this week, so with the docstring-AST-induced delay I should even
meet the original rc1 goal :)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Nick Coghlan <ncogh...@gmail.com> added the comment:
Ned, just adding you to the nosy list here, as I don't think this is a release
blocker per se (since nothing's actually *broken*), but the current state of
the PEP 538/540 docs is such that it isn't going to be clear to most reader
Nick Coghlan <ncogh...@gmail.com> added the comment:
After looking at potential implementation approaches, I believe the following
would be the ASDL code generator changes needed to present the docstring as
part of the body in the Python API, while keeping it as a separate attribute in
Nick Coghlan <ncogh...@gmail.com> added the comment:
Just noting that I'm going to attempt an alternative, hopefully lower impact,
approach at implementing the reversion, which will be to modify
Parser/asdl_c.py to inject the following constructor postamble for ASDL nodes
that defin
Nick Coghlan <ncogh...@gmail.com> added the comment:
Huh, I thought I cleaned those out when I made the compilation unconditional. I
guess not :)
The actual fix looks good to me, but the autoconf regeneration looks
unexpectedly noisy, so I've asked Benjamin Peterson to take
Nick Coghlan <ncogh...@gmail.com> added the comment:
Not as a statement, but you can force it with importlib.import_module:
$ python3 -c "import pkg; pkg.submodule = 1; import importlib;
importlib.import_module('.submodule', 'pkg'); print(pkg.submodule)"
pkg
pkg.submodule
W
Nick Coghlan <ncogh...@gmail.com> added the comment:
Ouch, I'd completely missed the fact that this would affect the parsing of bare
strings to a simple AST (I was focused on functions and classes, as in Mark's
original example).
So even though I'm the author of https://bugs.pyth
Nick Coghlan <ncogh...@gmail.com> added the comment:
Yes, while weird, that's expected behaviour.
Rather than being due to absolute vs relative imports, the difference arises
from the fact that in "import pkg.module", the request is explicitly for a
submodule, so the submodu
Nick Coghlan <ncogh...@gmail.com> added the comment:
Adding a low level callback based mechanism to ask another interpreter to do
work seems like a good way to go to me.
As an example of why that might be needed, consider the case of sharing a
buffer exporting object with a
Nick Coghlan <ncogh...@gmail.com> added the comment:
Rather than tracking this per object, you could potentially track it per arena
at the memory allocator level instead. Then if you really need the info (e.g.
when running the debug allocator), you can check it in a reliab
Nick Coghlan <ncogh...@gmail.com> added the comment:
Also see
https://github.com/python/cpython/blob/55edd0c185ad2d895b5d73e47d67049bc156b654/Objects/exceptions.c#L2713
for the version we use in a few places to implicitly update the exception
message, while keeping the exceptio
Nick Coghlan <ncogh...@gmail.com> added the comment:
I think the reference to RuntimeWarning in the docs is a typo (if it was only
going to be a warning, it could have been that from the start), and that
reference to RuntimeError in the code comment is correct.
So there's also a do
Nick Coghlan <ncogh...@gmail.com> added the comment:
Yeah, the "transparent exception chaining" code falls into the category of code
that I'm both proud of (since it works really well in typical cases [1]) and
somewhat horrified by (since the *way* it works tramples over sev
Nick Coghlan <ncogh...@gmail.com> added the comment:
While it does match Christian's original suggestion, I'm not taking the "bytes"
in the issue title as literally requiring that the feature be implemented as
operator support on the bytes type (implementing it on memoryvi
Nick Coghlan <ncogh...@gmail.com> added the comment:
Hmm, I wonder if the UX problem with the current chaining might be solved in a
different way, by doing something similar to what we did for codec exceptions
(where we want to try to mention the codec name, but also don't want to
Nick Coghlan <ncogh...@gmail.com> added the comment:
I filed https://bugs.python.org/issue33576 to cover removing the exception
wrapping from __set_name__ errors.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Nick Coghlan <ncogh...@gmail.com>:
Type creation currently wraps all exceptions raised by __set_name__ calls with
a generic RuntimeError:
https://github.com/python/cpython/blob/master/Objects/typeobject.c#L7263
Unfortunately, this makes it difficult to use __set_
Nick Coghlan <ncogh...@gmail.com> added the comment:
I think it would make sense to remove the exception wrapping from the
__set_name__ calls - I don't think we're improving the ease of understanding
the tracebacks by converting everything to a generic RuntimeError, and we're
hurting
Nick Coghlan <ncogh...@gmail.com> added the comment:
I think Antoine's right that another venue (such as python-ideas) might be a
better venue for this discussion, but I'll still try to explain the potential
analogy I see to bytes.upper()/.lower()/etc: those operations let you treat
Nick Coghlan <ncogh...@gmail.com> added the comment:
I believe the main argument for -X options is the fact that cmd on Windows
doesn't offer a nice way of setting environment variables as part of the
command invocation (hence "-X utf8", for example).
As far as setting valu
Nick Coghlan <ncogh...@gmail.com> added the comment:
Thanks for the link Serhiy (I'd forgotten about the struct changes proposed in
PEP 3118), but the existing struct formatting codes are fine for my purposes.
The question is whether we might be able to avoid some
bytes->Python-objec
Nick Coghlan <ncogh...@gmail.com> added the comment:
This issue isn't at the stage where a PR would help - the core question is
still "Should we add better native support for multi-byte bitwise operations?",
not the specifics of what they API might look like or how we
Nick Coghlan <ncogh...@gmail.com> added the comment:
I'm back in the embedded software world now, and hence working with the
combination of:
- low level serial formats (including fixed length CAN packets)
- C firmware developers that are quite capable of writing supporting
C-in-Pytho
Nick Coghlan <ncogh...@gmail.com> added the comment:
Issue 19251 is still under consideration, so marking this as a duplicate,
rather than as rejected.
--
nosy: +ncoghlan
resolution: rejected -> duplicate
superseder: -> bitwise ops for bytes of
Nick Coghlan <ncogh...@gmail.com> added the comment:
Ah, sorry, I misinterpreted Petr's comment, and then didn't look at the details
of your PR before commenting.
Having fixed that mistake, I agree that making the naive approach "just work"
Nick Coghlan <ncogh...@gmail.com> added the comment:
Regarding environment variables, note that they get used in two *very*
different ways:
1. The "persistent shell setting" case that Raymond describes. While setting
PYTHONBYTECODEPATH to always point to a RAM disk could
Nick Coghlan <ncogh...@gmail.com> added the comment:
As David notes, the issue in the example is the fact that you're setting
"__main__.a", so "a.py" never gets imported as a module - it gets a hit on the
parent module attribute, and hence stops there.
--
Nick Coghlan <ncogh...@gmail.com> added the comment:
The behaviour I'd expect to see:
"module:qual.name" -> "imports module, accesses module.qual.name"
"module.qual.name" -> "no implicit import, accesses module.qual.name"
"package.sub
Nick Coghlan <ncogh...@gmail.com> added the comment:
I've assigned the PR and issue to myself, as the proposed addition in the PR
isn't quite right, but it isn't immediately obvious why not.
The gist of the problem is that the current docs are actually correct and
complete: m
Nick Coghlan <ncogh...@gmail.com> added the comment:
If these warnings are being emitted when using setuptools, that's a bug in
setuptools (as it should be ensuring these are handled without warnings), and
can be reported over on https://github.com/pypa/setuptools/
If these warnings are
Nick Coghlan <ncogh...@gmail.com> added the comment:
PSF link for Diana Clark's thread on python-ideas about this:
https://mail.python.org/pipermail/python-ideas/2017-September/047224.html (this
is the same thread Brett linked, just to the PSF archives rather than Google
New submission from Nick Coghlan <ncogh...@gmail.com>:
The current example for contextlib.contextmanager doesn't use try/finally,
which sets folks up for writing resource management context managers that don't
clean up after exceptions properly.
There's an example with try/finall
Nick Coghlan <ncogh...@gmail.com> added the comment:
Marking as closed/later to indicate that we're not going to pursue this in the
near term, but it's not out of the question that we might accept a future
proposal along these lines.
--
resolution: -> later
stage: pat
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset df00f048250b9a07195b0e3b1c5c0161fdcc9db8 by Nick Coghlan (Serhiy
Storchaka) in branch 'master':
bpo-26701: Tweak the documentation for special methods in int(). (GH-6741)
https://github.com/python/cpython/
New submission from Nick Coghlan <ncogh...@gmail.com>:
Due to a python-ideas discussion about reducing boilerplate for
__file__-relative path calculations, I was running "./python -X importtime -S
-c 'import pathlib'" and noticed three potential candidates where it may be
wort
Nick Coghlan <ncogh...@gmail.com> added the comment:
Note that Neil did start with a python-ideas discussion, and was directed over
here, since the idea seemed simple enough, and worth pursuing.
As Serhiy notes though, there are many more subtleties to be addressed here
than I first t
Nick Coghlan <ncogh...@gmail.com> added the comment:
"package.module:attribute" is also the syntax used in packaging tools to
unambiguously separate the name of the module to be imported from the attribute
chain to be looked up within that module:
https://packaging.python.or
New submission from Nick Coghlan <ncogh...@gmail.com>:
While Victor and I reconciled the respective designs & implementations of PEP
538/540 (with 538 relying on 540 to handle the "No suitable target locale"
case, and 540 relying on 538 to handle extension modul
Nick Coghlan <ncogh...@gmail.com> added the comment:
The current discrepancy is odd when you compare it to the equivalent generator
expression:
{k:v for k, v in iterable}
dict(((k, v) for k, v in iterable))
It would never have occurred to me to expect the evaluation order to
Nick Coghlan <ncogh...@gmail.com> added the comment:
Hartmut, thanks for the issue report, and Pablo, thanks for the PR to resolve
it!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Pyth
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 0977091dca59709864b14cfc129388f1f0de7bf7 by Nick Coghlan (Pablo
Galindo) in branch 'master':
bpo-33128 Fix duplicated call to importlib._install_external_importers
(GH-6273)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
As a concrete proposal for 3.8, how about:
1. Add the following utility functions to importlib.util (names adjusted to
match PEP 451 rather than my initial suggestions above):
def get_location(module):
try:
Nick Coghlan <ncogh...@gmail.com> added the comment:
If I recall Eugene Toder's previous AST-level compilation patches correctly,
they handle this problem by putting the AST optimisation step *after* the
output of the Py_CF_ONLY_AST step.
This meant that if you're running the source->
Change by Nick Coghlan <ncogh...@gmail.com>:
--
assignee: -> paul.moore
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https:/
Nick Coghlan <ncogh...@gmail.com> added the comment:
-1 from me for __package__, as setting that's the preferred way for directly
executed scripts to fix their explicit relative imports (rather than trying to
retroactively fix their spec).
(https://docs.python.org/3/library/importli
Nick Coghlan <ncogh...@gmail.com> added the comment:
Xavier's changes should fix the reported compile error, while keeping the
increased isolation of the interpreter core from the optional extension modules.
If the latter change causes a detectable performance regression, then I
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 063db62aab4041ac47798e7e48b27b2f2bef21c5 by Nick Coghlan
(xdegaye) in branch 'master':
bpo-32232: by default, Setup modules are no longer built with -DPy_BUILD_CORE
(GH-6489)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
I also resolved my own puzzlement from the PR comments regarding why
_weakrefs.c was fine with being built as a regular extension module: it's
because the C level access API for __weakrefs__ is published through the
regular
Nick Coghlan <ncogh...@gmail.com> added the comment:
Ah, oops - I commented before fully catching up on everything else, and now I
see that Xavier already made exactly that point just above.
I'll go review the PR now :)
--
___
Python tracke
Nick Coghlan <ncogh...@gmail.com> added the comment:
Even when statically linked, extension modules should *NOT* be getting built
with `-DPy_BUILD_CORE`. That preprocessor definition is for CPython core core
only, and we moved the headers to help make that 100% crystal
Change by Nick Coghlan <ncogh...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 1a5c4bdb6ecc6a8b19ff33bde323ab188ed60977 by Nick Coghlan in
branch 'master':
bpo-33185: Improve wording and markup (GH-6477)
https://github.com/python/cpython/commit/1a5c4bdb6ecc6a8b19ff33bde323ab188e
Change by Nick Coghlan <ncogh...@gmail.com>:
--
pull_requests: +6177
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33185>
___
_
Nick Coghlan <ncogh...@gmail.com> added the comment:
Merge to master and set the "needs backport to 3.7" label for the initial PR -
the backport bot will then take care of creating the 3.7 PR. For the backport,
all you then need to do is leave an Approve review, and the bot wil
Nick Coghlan <ncogh...@gmail.com> added the comment:
Terry, if you'd like to continue that discussion, please open a new enhancement
request for 3.8+ against the inspect module asking for the affected
introspection functions to recursively search for relevant attributes, the sam
Nick Coghlan <ncogh...@gmail.com> added the comment:
The inspect functions throwing an exception when handed a method wrapping a
non-function callable instead of returning False is a definite bug.
The behaviour of MethodType when handed a non-function callable is cryptic, but
not ac
Nick Coghlan <ncogh...@gmail.com> added the comment:
Classifying this as a minor performance enhancement, since methods are much
simpler objects than full Python level closures.
Thanks!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&
Nick Coghlan <ncogh...@gmail.com> added the comment:
New changeset 23ab5ee667a9b29014f6f7f01797c611f63ff743 by Nick Coghlan
(jdemeyer) in branch 'master':
bpo-33265: use an actual method instead of a method-like function in ExitStack
(GH-6456)
https://github.com/python/cpython/
Nick Coghlan <ncogh...@gmail.com> added the comment:
Yury, could you double check the async exit stack change in the PR? I think
it's fine since the bound method just passes back the underlying coroutine and
the tests all still pass, but a second opinion would be good :)
-
Nick Coghlan <ncogh...@gmail.com> added the comment:
+1 from me for further ResourceWarning docs improvements - my focus when
working on PEP 565 was the actual change in how DeprecationWarning was being
handled, and the other warnings doc improvements were just a necessary
prereq
Nick Coghlan <ncogh...@gmail.com> added the comment:
The main idea that comes to mind is to cache a reference to
`_frozen_importlib._module_locks` in the interpreter state, and do a key lookup
in there (since any in-progress import should have a lock allocated to it).
That would be a se
Change by Nick Coghlan <ncogh...@gmail.com>:
--
nosy: +ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue26979>
___
__
Change by Nick Coghlan <ncogh...@gmail.com>:
--
nosy: +ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue1230540>
___
_
Change by Nick Coghlan <ncogh...@gmail.com>:
--
stage: patch review -> commit review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nick Coghlan <ncogh...@gmail.com>:
--
keywords: +patch
pull_requests: +6122
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Nick Coghlan <ncogh...@gmail.com>:
--
nosy: +encukou, ncoghlan
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue15727>
___
501 - 600 of 6264 matches
Mail list logo
