Nick Coghlan added the comment:
(I'm currently working a PR for this that Victor can review)
--
assignee: -> ncoghlan
___
Python tracker
<https://bugs.python.org/issu
New submission from Nick Coghlan :
(Nosy list is RM, PEP 587 BDFL-Delegate, PEP 587 author)
Filing as a release blocker, given that I don't think we should ship rc1 until
consensus has been reached on the last minute changes to the PEP 587
configuration API.
Thread at
https
Nick Coghlan added the comment:
The hidden _config_version field wasn't in the accepted PEP.
Both it and struct_size should be removed, as we don't support updating an
embedded Python runtime to a new X.Y.0 release without rebuilding the embedding
application.
--
nosy: +ncoghlan
Nick Coghlan added the comment:
Thanks for the PR, Ram, and the initial review, Serhiy.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8
___
Python tracker
<https://bug
Nick Coghlan added the comment:
New changeset 9c2682efc69568e1b42a0c1759489d6f2e3b30ea by Nick Coghlan (Ram
Rachum) in branch 'master':
bpo-37937: Mention frame.f_trace in sys.settrace docs (GH-15439)
https://github.com/python/cpython/commit/9c2682efc69568e1b42a0c1759489d6f2e3b30ea
Nick Coghlan added the comment:
It's also not unique to with statements - it applies to all finally clauses.
The longstanding workaround when deterministic cleanup is absolutely critical
has been to run the "real" application in a subthread, and devote the main
thread to
Nick Coghlan added the comment:
New changeset bdd6945d4dbd1fe6a7fcff95f7d6908db7d791a1 by Nick Coghlan (Xtreak)
in branch 'master':
bpo-33095: Add reference to isolated mode in -m and script option (GH-7764)
https://github.com/python/cpython/commit/bdd6945d4dbd1fe6a7fcff95f7d6908db7d791a1
Nick Coghlan added the comment:
There is one, it just isn't public: runpy._run_module_as_main.
It's a private API that the -m switch implementation calls, and was introduced
after the original runpy.run_module was found not to offer everything the
switch needed.
It isn't possible to fully
Nick Coghlan added the comment:
So we'd be going with a naming convention where "VAR" corresponds to the star
syntax, and whether it means packing or unpacking, or refers to arguments or
parameters is context dependent?
I could definitely support that, given that the ambigui
Nick Coghlan added the comment:
There is also the draft test case at https://github.com/ncoghlan/cpython/pull/2
That needs updating to account for the eval loop changes since I last worked on
it, though. (I think that conflict may also be keeping the bots from running,
even after I updated
Nick Henderson added the comment:
We have recently bumped into a similar problem. Using FreeBSD, subprocess calls
were taking more than 10 times the usual time to execute after migrating to
python3.6. After some digging, the default for 'close_fds' was changed to
'True'. On linux
Change by Nick Timkovich :
--
components: +Library (Lib)
title: JSON sorting type error -> Can't use sort_keys in json.dumps with
mismatched types
versions: +Python 3.9 -Python 3.7
___
Python tracker
<https://bugs.python.org/issu
Nick Timkovich added the comment:
It's not clear what you suggest, but it is likely better to alert the user that
their keys have mismatched types than to suppress it by default.
Perhaps alongside the `sort_keys` argument, you would like a parameter that
gets passed into `sorted()` when
Nick Coghlan added the comment:
Reviewing this again now, I think my previous naming suggestion is problematic,
as it encourages conflating two different concepts that use similar syntax:
* collecting arbitrary positional parameters in a tuple (VAR_POSITIONAL) or
arbitrary keyword
Nick Coghlan added the comment:
The query in #37743 highlights that generator functions and other wrapped
iterator factories actually face a similar problem: they need the function body
to contain "yield from wrapped(*args, **kwargs)" if the CM is going to be
closed after th
Nick Coghlan added the comment:
This is a documentation bug, as the current behaviour is as intended, but the
documented equivalence doesn't hold for generator functions: for a generator
function, the CM will only be applied when the generator is instantiated,
whereas the inline context
Nick Coghlan added the comment:
It isn't the simple case where the auto-detection idea concerns me, it's
decorator stacking cases like:
@outer
@magic_detection
@inner_forces_async
def sync_native_api():
...
(With the original asyncio.coroutine being one example
Nick Coghlan added the comment:
We never actually coded a reproducer for this, but if we had, it would have
been a crash bug.
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
Good point regarding the heuristic: it would need to take the requested module
name into account to be correct.
* check if the requested module was found relative to the current directory
(can be worked out from __main__.__spec__ and the current working
Nick Coghlan added the comment:
Yes, this is deliberate. From the run_module documentation: "__name__ is set to
run_name if this optional argument is not None, to mod_name + '.__main__' if
the named module is a package and to the mod_name argument otherwise."
This allows arbi
Change by Nick Coghlan :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue37941>
___
___
Python-bugs-list
Nick Timkovich added the comment:
To clarify, there is an "ARC" command in Logo that draws a circle/circle
segment *centered on* the turtle. Reference:
http://fmslogo.sourceforge.net/manual/command-arc.html Examples:
https://personal.utdallas.edu/~veerasam/logo/ That command
Nick Coghlan added the comment:
New changeset 06145230c833c3db5dab8858e11bcd550a37c57f by Nick Coghlan in
branch 'master':
bpo-37947: Avoid double-decrement in symtable recursion counting (GH-15593)
https://github.com/python/cpython/commit/06145230c833c3db5dab8858e11bcd550a37c57f
Nick Coghlan added the comment:
Reviewing all the code that touches recursion_depth (both in the symtable and
in the thread state), I'm not seeing any sanity checks that ensure our
increments and decrements *balance*.
So I'm going to add one to PySymTable_BuildObject
Nick Coghlan added the comment:
Reviewing the PR post-merge, I'm pretty sure this has introduced a
double-decrement bug due to the original code being hard to read (the error
cases did the decrement inside the helper function, while the success case did
it in the calling function).
https
Change by Nick Coghlan :
--
pull_requests: +15269
pull_request: https://github.com/python/cpython/pull/15593
___
Python tracker
<https://bugs.python.org/issue37
Nick Coghlan added the comment:
Thank you Pablo!
Even having seen your fix, it still took me a couple of rescans of the original
PR to figure out exactly how I'd broken it in the first place (refactoring to
call an existing function without noticing that the replaced code included an
extra
Nick Timkovich added the comment:
Looking at the history, the line in the docs used to say
> ... (for example, an empty query (the draft states that these are equivalent).
which was changed to "the RFC" in April 2006
https://github.com/python/cpython/commit/ad5
Nick Timkovich added the comment:
Resolving #1 as you suggest is next to impossible. Python can not deduce if you
meant to call the function or just refer to its name. Admittedly, the latter is
strange in non-interactive contexts, but it is valid.
#2, as far as I can tell Logo had an ARC
Nick Timkovich added the comment:
Regarding #1: In Python, you may refer to a variable's name (e.g. `rt`, which
is a function), which often has no effect in a script. In the REPL (where you
see >>>) it is useful to inspect the object:
>>> turtle.rt
In order to call
Nick Coghlan added the comment:
Merged for 3.8b4 after Emily's review.
Thanks to all involved in the PEP update and change discussion!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracke
Nick Coghlan added the comment:
New changeset 6ca030765db49525f16b8fabff4153238148b58d by Nick Coghlan in
branch '3.8':
[3.8] bpo-37757: Disallow PEP 572 cases that expose implementation details
(GH-15491)
https://github.com/python/cpython/commit/6ca030765db49525f16b8fabff4153238148b58d
Change by Nick Coghlan :
--
pull_requests: +15178
pull_request: https://github.com/python/cpython/pull/15491
___
Python tracker
<https://bugs.python.org/issue37
Nick Coghlan added the comment:
New changeset 5dbe0f59b7a4f39c7c606b48056bc29e406ebf78 by Nick Coghlan in
branch 'master':
bpo-37757: Disallow PEP 572 cases that expose implementation details (GH-15131)
https://github.com/python/cpython/commit/5dbe0f59b7a4f39c7c606b48056bc29e406ebf78
Yes the community edition works fine.
It seems to require a 64 bit version of Windows 7 or higher (I'm not sure
as I haven't used Windows in years).
On Tue, 20 Aug 2019, 03:27 , wrote:
> Nick Sarbicki於 2019年8月19日星期一 UTC+8下午5時33分27秒寫道：
> > PyCharm takes you to the source code within t
PyCharm takes you to the source code within the editor for any
variables/functions/classes/modules if you ctrl+click on what you want to
see. It allows you to browse the relevant bits of code quickly, as well as
let you change them in your local environment if need be.
That way you don't have to
Nick Coghlan added the comment:
Even though it doesn't fully resolve this crash, I'd still like us to consider
reverting the change to allow "continue" in try/finally blocks.
It doesn't seem to have a compelling practical motivation behind it (beyond the
fact that it's nice not
Nick Coghlan added the comment:
The outcome of the python-dev discussion was that we agreed to switch to
raising a plain SyntaxError, as that's what we do everywhere else that this
kind of problem comes up (e.g. conflicts between global and nonlocal
declarations, or between those
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 what you would expect
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 - che
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
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 CPython runtime
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:
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:
#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 scope
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:
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 the PEP
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.
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:
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/issue35
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 entirely
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/8a758f5b99c5fc3fd32edeac049d7d4a4b7cc163
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:
Agreed, raising the exception properly would be the way to go.
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue35
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 statem
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.
--
__
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> compile error
___
Python tracker
<https://bugs.python
New submission from Nick Coghlan :
Reviewing some code today, I came across a ConfigParser.set() call that only
specified the section and key, with the value argument missing.
If you look at the ConfigParser.set() docs, this seems like incorrect code, as
those docs indicate that the value
Nick Coghlan added the comment:
In reviewing https://github.com/cython/cython/pull/3009, Jeroen pointed out
that my symbol checking idea wouldn't actually work, since the preprocessor can
only see preprocessor definitions, not compiler symbols. If we're going to rely
on a preprocessor
Nick Coghlan added the comment:
There's also the question of complying with our own deprecation policy, as the
approval to ditch tp_print API compatibility in PEP 590 relied on the fact that
it has been deprecated since Python 3.0.
However, it turns out the associated programmatic
Nick Coghlan added the comment:
I'm happy with the change in https://github.com/python/cpython/pull/13959, but
we need sign-off from Łukasz as release manager on bumping the
Py_VERSION_SERIAL a bit early so Cython can reliably detect that this change
has been reverted without having to check
Nick Coghlan added the comment:
It isn't the actively maintained projects that publish wheel files that I'm
worried about fixing - it's the sdist only projects that would otherwise only
need recompilation to work on the new Python version.
With this fixed, and the PyCode_New -> PyCode_
Nick Coghlan added the comment:
New changeset 08970cb03c61f62f4f69e7769d0075fa66bb86aa by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-36210: update optional extension handling for AIX (GH-12202)
https://github.com/python/cpython/commit/08970cb03c61f62f4f69e7769d0075fa66bb86aa
Nick Coghlan added the comment:
Perhaps `os._abspath_for_import`? If importlib finds it, then it can handle
making early paths absolute itself, otherwise it will defer doing that until it
has the full external import system bootstrapped. (importlib does try to make
all paths absolute
Nick Papior added the comment:
FYI:
The problem arises since Intel adds a library path to:
../clck/2019.2.1/lib/intel64/
which has libutil.so!
This means that the Intel compiler *may* not find OpenPTY since that may
optionally be placed in libutil.so...
Simply removing the path from
New submission from Nick Papior :
When trying to compile Python without OpenPTY and without stropts.h the
compilation fails at Modules/posixmodule.c.
Apparently there is a failed logic in the def's.
It goes something like this:
#ifdef HAVE_OPENPTY
...
#elif defined(HAVE__GETPTY)
...
#else
Nick Coghlan added the comment:
(Note: this isn't SC feedback yet, it's individual contributor feedback from me)
As others noted, the reason we treat "Incompatible with Cython generated source
code" distinctly from other C API source compatibility issues is because
Cython-usin
Nick Coghlan added the comment:
New changeset 3a1d50e7e573efb577714146bed5c03b9c95f466 by Nick Coghlan (Michael
Felt) in branch 'master':
bpo-28009: Fix uuid SkipUnless logic to be based on platform programs capable
of introspection (GH-12777)
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
The key problem isn't Cython itself, the problem is that Cython generated
libraries can't be rebuilt for 3.8 without regenerating their C files.
I'd be fine with PyCode_NewWithPosArgs (Victor's right that a descriptive
naming convention handles future changes
New submission from Nick Coghlan :
The Porting section of the What's New guide is for changes where the old
behaviour was at best arguably correct, but it's still possible someone was
relying on it behaving exactly the way it used to.
It isn't for us to say "We broke all extensions tha
Nick Coghlan added the comment:
New changeset 99b5c940d3471e0ed6579771d94e7342d7c733e0 by Nick Coghlan (Dimitri
John Ledkov) in branch '2.7':
[2.7] bpo-34836: fix test_default_ecdh_curve, needs no tlsv1.3. (GH-9626)
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
Addressing the other part of Chris's initial post: there's also no
`--upgrade-pip` option on `venv` itself.
Instead, there's only an `--upgrade` option that is intended for *Python*
version upgrades, and restructures the internal layout of the venv to switch
Nick Coghlan added the comment:
(Added packaging, Linux distro, and Windows and macOS installer folks to the cc
list)
Chris and I were discussing this behaviour, and it turns out even I had
forgotten how we had specified this feature in PEP 453: `ensurepip --upgrade`
ensures that an older
Nick Coghlan added the comment:
New changeset e788057a9188ff37e232729815dfda2529079420 by Nick Coghlan in
branch 'master':
bpo-36797: Reduce levels of indirection in outdated distutils docs (#13462)
https://github.com/python/cpython/commit/e788057a9188ff37e232729815dfda2529079420
New submission from Nick Coghlan :
(Splitting out a separate performance issue from
https://bugs.python.org/issue36751#msg342683)
There can be two quite different reasons for inspecting a function signature:
* inspecting arbitrary functions to learn as much about them as possible in
order
Nick Coghlan added the comment:
I split https://bugs.python.org/issue37010 out as a separate performance issue
in case anyone is inclined to explore the idea of reversing the relationship
between inspect.signature and inspect.getfullargspec, such that the latter
becomes a fast building
Nick Coghlan added the comment:
This has been merged for 3.8 and 3.7, but not for 2.7, since the docs have
diverged far enough that the automatic backport didn't work:
https://github.com/python/cpython/pull/13087#issuecomment-494402704
Given the proximity to the general end of life
Nick Coghlan added the comment:
While I do have a second PR open with some additional smaller cleanups, the
first PR removed the outdated information that seemed most problematic.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Change by Nick Coghlan :
--
pull_requests: +13372
___
Python tracker
<https://bugs.python.org/issue36797>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Thanks Pablo.
Noting for the record: positional-only arguments aren't new *semantically",
since extension modules have always allowed them, and you've long been able to
emulate them in Python code by accepting "*args".
Prior to the introduct
Nick Coghlan added the comment:
New changeset dae1229729920e3aa2be015453b7f702dff9b375 by Nick Coghlan in
branch 'master':
bpo-36797: Prune more legacy distutils documentation (GH-13092)
https://github.com/python/cpython/commit/dae1229729920e3aa2be015453b7f702dff9b375
Nick Coghlan added the comment:
Also note #32190 regarding changing the way these APIs are documented, without
introducing any programmatic deprecation warnings.
--
___
Python tracker
<https://bugs.python.org/issue36
Change by Nick Coghlan :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue27172>
___
___
Python-bugs-list mailing list
Unsubscrib
Nick Coghlan added the comment:
And no, the undeprecation wasn't because of Python 2 (Py2 doesn't have
getfullargspec() - it's a Py3 only API).
The undeprecation was because there are a lot of 3rd party projects for whom
the getfullargspec() representation is good enough, and switching
Change by Nick Coghlan :
--
priority: normal -> release blocker
___
Python tracker
<https://bugs.python.org/issue36751>
___
___
Python-bugs-list mai
Nick Coghlan added the comment:
This PR needs to be reverted - we previously deprecated this API, but then
undeprecated it again in #27172, as the consequence of deprecating it was
projects copying & pasting the getfullargspec() implementation into their own
code, not switc
Nick Coghlan added the comment:
New changeset 1b4abcf302ff2c8f4d4881294510d48ba5186b53 by Nick Coghlan (Kojo
Idrissa) in branch 'master':
bpo-33071: remove outdated PyPI docs (GH-13087)
https://github.com/python/cpython/commit/1b4abcf302ff2c8f4d4881294510d48ba5186b53
--
nosy
Nick Coghlan added the comment:
New changeset 94a64e9cd411a87514b68082c1c437eb3b49dfb9 by Nick Coghlan (Zackery
Spytz) in branch 'master':
bpo-24048: Save the live exception during import.c's remove_module() (GH-13005)
https://github.com/python/cpython/commit
Nick Coghlan added the comment:
Another potential issue here is if a thread belonging to another interpreter
attempts to access the interpreter being cleaned up.
--
___
Python tracker
<https://bugs.python.org/issue36
Nick Coghlan added the comment:
Pablo pointed out a problem with this change at the PyCon sprints: the thread
cleanup code doesn't currently distinguish between "Python created daemon
thread" and "thread created by the embedding application".
That's already
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +13006
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
New submission from Nick Coghlan :
Prompted by #33071, I'm going to do a pass through the legacy distutils
documentation deleting outdated information that is better maintained elsewhere.
--
assignee: ncoghlan
messages: 341407
nosy: jaraco, ncoghlan
priority: normal
severity: normal
Change by Nick Coghlan :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python
Nick Coghlan added the comment:
New changeset 4d0233ec656bc7e7814e5f6f484e79a50a0daf91 by Nick Coghlan (Miss
Islington (bot)) in branch '3.7':
bpo-30840: Document relative imports (GH-12831) (GH-12938)
https://github.com/python/cpython/commit/4d0233ec656bc7e7814e5f6f484e79a50a0daf91
Nick Coghlan added the comment:
New changeset 70bf713617e15fad390ed953e48b3c65d9bc90ec by Nick Coghlan (Joannah
Nanjekye) in branch 'master':
bpo-30840: Document relative imports (#12831)
https://github.com/python/cpython/commit/70bf713617e15fad390ed953e48b3c65d9bc90ec
New submission from Nick Coghlan :
The test output from test_sys_settrace makes it look like a couple of the async
tracing tests aren't cleaning up after themselves properly:
```
[ncoghlan@localhost cpython]$ ./python -m test test_sys_settrace
Run tests sequentially
0:00:00 load avg: 1.27 [1
Change by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue35998>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Davies added the comment:
> Would you prepare a patch for number 3?
I will give it a try and see what I come up with.
> I am afraid we can add another hard-to-debug multi-threaded problem by
> complicating the data structure.
Yeah this was my concern too, the adding and remo
Change by Nick Coghlan :
--
title: Dropping __main__ from sys.modules clears the REPL namespace -> REPL
doesn't ensure builtins are available when implicitly recreating __main__
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
The relevant functions:
* PyRun_InteractiveLoopFlags:
https://github.com/python/cpython/blob/e8113f51a8bdf33188ee30a1c038a298329e7bfa/Python/pythonrun.c#L89
* PyRun_InteractiveOneObjectEx:
https://github.com/python/cpython/blob
201 - 300 of 8215 matches
Mail list logo
