ll your test cases would still pass without
modification.
This is approach is not much different than for other magic methods which
kick-in if defined or revert to a default behavior if not.
My core concern is to keep the dict API clean as a whistle.
Raymond
__
[Ian Bicking]
> They seem terribly pointless to me.
FWIW, here is the script that had I used while updating and improving the two
functions (can't remember whether it was for Py2.3 or Py2.4). It lists
comparative results for many different types of inputs. Since perfection was
not possible, t
quence. Or better yet, stop designing APIs that require you to differentiate
things that aren't really different ;-)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail
ve been
>> better the other way.
[Grep]
> Any thoughts about fixing this in 3.0?
IMO, it isn't broken. It was an intentional divergence from naming conventions.
The reasons for the divergence haven't changed. Code that uses next() is more
understandable, friendly, and readab
> Thoughts?
FWIW, this idea has come-up a couple of times before so it should probably get
fixed once and for all.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://m
pplies to many different object types.
In contrast, next() would apply only to iterables.
Foolish consistency is a somewhat weak reason to add a built-in.
Also, calls to it.next() need to be as fast as possible.
Adding a layer of indirection through __builtin__.next() is a wa
real code and whether it provided any benefits in terms of consistency or
future development flexibility. Most likely, the answer is no. That should be
a
good indicator that the proposed benefits are illusory.
Raymond
___
Python-Dev mailing list
Python-Dev
sions.
That was working fine in Py2.4. It appears to have gotten left out of the AST
compiler.
The patch as submitted needs to be revised to only modify the compiler. The
other changes were both unnecessary and incorrect -- those components should be
left
erator protocol is
not one of them. Looping constructs need to be as lightweight as possible.
Code like "next=obj.__next__" should be avoided as much as possible. It is
ugly, it incidental to the expression of an algorithm, and it should not be
encouraged.
Raymond
ur understanding of the naming
convention to only apply to methods whose normal invocation is exclusively
magic
and not called directly.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
n id(self)
That would seem to be more Pythonic than creating custom variants of other
containers.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
g to be difficult as long as it is legal to write:
True = 0
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Ian Bicking]
> The question then is what the API should look like for such an object --
> an ordered, multi-value dictionary.
May I suggest that multidict begin it's life as a cookbook recipe so that its
API can mature.
Raymond
___
first entry -- its chief virtue being that it may help people avoid writing
crummy decorators. If his goes in, hopefully it will not fall down a slippery
slope and trigger an avalance of immature decorators being added to the core.
my-two-cents,
Raymond
___
ence for
> "functools" due to the parallel with "itertools").
I like "functools" for a different reason -- the name is sufficiently broad so
that we don't have fret about whether a particular tool fits within the
module
> In PEP 356, there is even a suggestion to "add builtin @deprecated
> decorator?".
Restraint please. Go easy on the decorator additions.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
tried it yet, I think the implementation is likely to be
trivial.
FWIW, the new with-statement makes the above fragment even more readable:
with atomic_transaction():
# do a series of steps without interruption
Raymond
___
Python-Dev mail
impler incarnation.
Also, unlike the gil.aquire() version, there is no blocking of the currently
active thread. IOW, the above incarnation won't deadlock (because the main
thread never goes into a wait mode).
Raymond
- Original Message -
From: "Guido van Rossum"
checking" and the active thread would do a few steps
atomically and then restore the original value. The new with-statement makes
that a piece of cake.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
the other
threads (being careful to avoid access to monitored resources and to pair the
suspend/resume operations in a try/finally or with-statement to prevent
deadlocks)?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
CPython specific support is in
sys.setcheckinterval(). That suggests adapting that function or adding a new
one to temporarily stop switching, almost the same as
sys.setcheckinterval(sys.maxint) but continuing to perform other periodic
checks
for control-break and such.
Raymond
___
uld like to get some feedback. If it works out, I'll
post a recipe to ASPN and see how it goes.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
[Raymond]
>> While this is a somewhat rough approach, it is dramatically
>> simpler than the alternatives (i.e. wrapping locks around every access to a
>> resource or feeding all resource requests to a separate thread via a Queue).
[Alexander]
> Why is that actually mo
er work until outstanding
requests are complete.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
>> Raymond is on it, anyway:
>>
>> http://python.org/sf/1444398
>
> You found it, you fix it :-)
I've got this one.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
I will try to free up
some
time to get that into alpha 1. It touches critical parts of the interpreted
and
needs to be reviewed, tested, timed, and exercised thoroughly.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
[Barry Warsaw]
> Oh, also, we have a couple of additions to the PySet C API.
> I'll work on putting together an SF patch for them over the weekend.
What are you proposing to add to the PySet API?
Raymond
___
Python-Dev mailing list
[Raymond]
> FYI, I have several non-major C components to go in but not in time for alpha
> 1.
> They include some minor fix-ups in the sets module, the str.partition
> function,
> add gc to itertools.tee, a couple of functions in binascii, add
> itertools.izip_longest, Crutch
the patch will most likely not
be accepted.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Raymond]
>> What are you proposing to add to the PySet API?
[Barry]
> PySet_Clear(), PySet_Next(), PySet_Update(), and PySet_AsList().
PySet_Clear()
-
Use PyObject_CallMethod(s, "clear", NULL).
Or if you need to save a millisecond on an O(n) operation, use
PyNum
mExit.
To me, they obviously should be under Exception, and not treated like
KeyboardInterrupt or SystemExit, so that probably means that I'm missing
something about GeneratorExit.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http:
s verifying the number of arguments. I would suggest
that if you have the wrong number of arguments for s.update(t) or s.clear(),
then you have problems a C API can't solve ;-)
Cheers,
Raymond
P.S. One other thought: I don't want to crystalize the API in a way that
precludes
n
> between
> PyNumber_InPlaceAdd(s,t) vs PyObject_CallMethod(s, "update", "(O)", t).
Of course, that should have been s|=t and PyNumber_InPlaceOr().
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
rious errors with current SVN.
I can't say that I care enough about this hypothetical inter-version flimflam
to
warrant mucking-up the otherwise useful distinction between Exception and
BaseException.
special-cases-aren't-special-enough ...
Raymond
_
[Barry]
> Maybe it will help you to understand why I want a richer concrete API.
> I work on an app that is deeply integrated with Python. It's hard to
> say whether we embed or extend -- it's a lot of both. We use Python
> data structures such as lists, dicts, and sets in many places as our
> fu
[Alex]
> And I'm on the fence regarding the specific issue of PySet_Next.
>
> So, having carefully staked out a position smack in the middle, I
> cheerfully now expect to be fired upon from both sides!-)
Okay, here's the first cheap shot ;-) Which of the following pieces of code is
preferable?
e this need to be made constants and
> explained with a comment
FWIW, the actual code does have comments. I stripped them out of the posting
because they weren't relevant to the code comparison.
Raymond
___
Python-Dev mailing list
Python-Dev@p
d principal maintainer, I get some say in the
matter.
Raymond
Nothing is more conducive to peace of mind than not having any opinions at all.
-- Georg Christoph Lichtenberg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
e is no need
to muck-up the set api for this.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Why don't we expose _PySet_Next() for Barry and leave it out of the public API
for everyone else.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
nice. It gives me the ability to keep a clean, sane API while
at
the same time making sure that my most important customer (Barry) gets his
needs
met.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
condescending or
> trying to be funny. I'm going to go with the latter. Good one! :)
Neither. I was serious. You are a principal customer for setobjects.
It seems that you make extensive use of them in your code.
While I don't favor the proposed API, I think is essentia
Barry, go ahead with PySet_Clear().
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Gareth McCaughan]
> For what it's worth[1], I think Raymond is absolutely on crack here.
Nope. No mind-altering drugs here. Based on real-word experience, I have
found
PySet_Next() to be a bug factory and do not want it included in the API.
The story is different for PySe
[Raymond Hettinger]
> > Barry, go ahead with PySet_Clear().
[Barry]
Cool thanks. I think we've also compromised on _PySet_Next(), correct?
Yes, _PySet_Next() is a good compromise for you and me -- it saves you from
writing a hack and saves my API from including a bug factory. The
s:
a = Object.copy()
b = a.copy()
def b.f(x):
return x+1
c = b.copy()
def c.f(x):
return x+2
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
a microscopically shorter call. Sorry, I need to stop
wasting
time on this thread. It has consumed far too much development time already.
Please write a one-line macro for yourself and leave this alone so I can
continue the development efforts at a thoughtful pace.
Raymond
_
That way if someone gets interested in the
> future, your code is still available.
FWIW, I think that is not a good idea. Guido shot it down for good reason.
Once a patch is loaded, the question will continually resurface every few
months and waste everyo
tries, counts of true and false items.
FWIW, sum() works nicely for counting true entries:
>>> sum(x%3==0 for x in range(100))
34
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
ybench.py.
If you want to thoroughly exercise the language, use the parrot benchmark in
the
sandbox.
Of course, the only truly useful benchmark is how Python performs on your own
apps.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http
> a while ago, Raymond proposed str.partition, and I guess the reaction
> was positive. So what about including it now?
Neal approved this for going into the second alpha.
Will do it this month.
Raymond
___
Python-Dev mailing list
Pyth
> that it's not used in any third party code. But, then again, anyone using it
> isn't free of leaks.
> Should removing or renaming it be done in 2.5 or in Py3K?
Since it is intrinsically buggy, I would support removal in Py2.5
Raymond
___
thiskey' for x in seq)
> I think it makes a lot of sense for any and all to take optional
> predicate function arguments.
I think you don't understand what you already have to work with in Py2.5a -- a
boolean expression in a genexp should always suffice -- no separate lambda
bas
't be bad either.
>>
>>Jeremy
>>
>>On 4/11/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>>
>>
>>>On 4/11/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>>>It strikes me that it should not be
M.-A. Lemburg wrote:
>I could contribute pybench to the Tools/ directory if that
>makes a difference:
>
>
>
+1 on adding pybench.
And we already have parrotbench in the sandbox.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
e style of template markup and prefer
delimiters instead, then check-out the recipe at:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3053
> a = 3
> b = 7
> print e"the function is y = {a}x + {b}"
> for x in range(10):
&
>
>If you don't like the $name style of template markup and prefer
>delimiters instead, then check-out the recipe at:
>
>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/3053
>
>
The link should have been:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/305306
x series with warnings and deprecations for everything
that is going to change in Py3.0.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
one of many set-up tasks (others include
downloading and compiling psyco, pypy, etc).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
likely start-off as third-party extension
modules, and if they prove essential, they may make it to the
collections module.
As for the built-in set types, I recommend leaving those alone and
keeping a API as simple as possible.
The __rand__ idea is interesting but I don&
kely fix bugs, apply long standing patches, and
improve performance for Py2.5.
Also, we could use another bugday after the next alpha.
Some "gelling" time would be helpful.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http:
y,
you could expose a function styled after fscanf(). IOW, better to
provide to general purpose text parsing tool than to muck-up the whole
language for one specialized application.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
;m not clear on the rationale for transforming negative
repetition counts to zero instead of raising an exception. OTOH,
neither of these has EVER been an issue for me or anyone I know.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
Fredrik Lundh wrote:
Yes. It went to my todo list and is awaiting some free raymond-cycles
to finish it up. I've been task saturated of late but would like to get
this a number of other patches complete for Py2.5.
no need to wait for any raymond-cycles here; just
Steve Holden wrote:
>
> This reminds me I am tasked with trying to find out what the interface
> to timeit.py is supposed to look like. Raymond, your name has been
> mentioned as someone who took part int he discussions. Google hasn't
> given me a lot to go on. Anyone?
&g
this than to go through the whole API
debate again.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> 1) Is str.rpartition() still wanted?
Yes.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ed/Failures
http://wiki.python.org/moin/NeedForSpeed/Deferred
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
t;>> the generator return no value at all or one window that is too small?
An itertools windowing function was previously discussed and rejected.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
a
zip-type tool whenever presented with lock-step iteration issues, even when the
inputs are of uneven length. Note, that the signature for izip_longest() needs
to include an optional pad value (defaulting to None) -- there are plenty of
use
e 2.2), so would it be appropriate to
> end
> support for it in 2.5?
FWIW, I wouldn't miss it, nor would any of the code I've ever seen.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
From: "Armin Rigo" <[EMAIL PROTECTED]>
> I've finally come around to writing a patch that stops dict lookup from
> eating all exceptions that occur during lookup, like rare bugs in user
> __eq__() methods.
Is there a
> On Mon, May 29, 2006 at 12:20:44PM -0700, Raymond Hettinger wrote:
>> > I've finally come around to writing a patch that stops dict lookup from
>> > eating all exceptions that occur during lookup, like rare bugs in user
>> > __eq__() methods.
>>
>&g
Armin Rigo wrote:
Hi Raymond,
On Mon, May 29, 2006 at 02:02:25PM -0700, Raymond Hettinger wrote:
Please run some better benchmarks and do more extensive assessments on the
performance impact.
At the moment, I'm trying to, but 2.5 HEAD keeps failing mysteriously o
gt;
>>> re.search('pycon', string.letters)
>>> if _ is not None:
... print _.group()
lmnop
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
s a trivial exception to the "most recently printed result" rule.
>>> 13
13
>>> _ = None
>>> _ # _ is no longer the most recently printed result
Raymond
___
Python-Dev mailing li
;
>>> re.search('pycon', string.letters)
>>> if _ is not None:
... print _.group()
lmnop
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
useful, but the "rather small" wording
should be replaced by something most precise (such as the
value of n=len(x) where n! > 2**19997).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
(self, y):
return self.value == y
x = X(2)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
inalize() because cleaning "interned" set cannot be done after the
>set module is finalized.
>
>If there is any interest, I will submit a patch, but it does not seem
>to affect performance in any meaningful way.
>
>
I would be curious to see your patch.
Raymond
__
Alexander Belopolsky wrote:
> This is very raw, but in the spirit of "release early and often",
> here it is:
>
> http://sourceforge.net/tracker/download.php?
> group_id=5470&atid=305470&file_id=181807&aid=1507011
>
> On Jun 15, 2006, at 8:47 PM,
Each of the six combinations needs to be evaluated on its own
merits. Do you have use case where it is important to know that
you have a set, that it is not frozen, and that it is not a subtype?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://
d
change all the exception messaging. Instead, devote some thought to
which messages are detrimentally uninformative and are not part of time
critical execution paths.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
at's, what, 18 months away?
>
>
I recommend holding-off on a 2.6 branch until someone actually
has some non-trivial amount of 2.6 code ready for a commit.
My guess is that we are all focused on 2.5 or are participating
in intoxicating Py3k discussions.
Raymond
_
te to
local variables (see sre_compile.py and sre_parse.py for code would
would see a speed benefit but almost no improvement in readability).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
if/elifs. As long as the compiler can tell the difference.
>
That's a worthy goal; of course, the devil is in the details. Given:
switch x:
case 1: one()
case 2: two()
case 3: three()
default: too_many()
Do we require that x be hashable so that the compiler can use a look
of existing knowledge and therefore has a near
zero learning curve. The implementation is straight-forward and there
are none of the hidden surprises that we would have with
fastpath/slowpath approaches which use different underlying magic
methods and do not guarantee order of execution.
and then try
> to modify as much standard library code as possible to use it. Then
> report back. That would be a very interesting experiment to do. (And
> thanks for the pointer to sre_compile.py as a use case!)
Hmm, it could be time for the Georg bot to graduate to big game.
Georg, ar
RUE':
reljumps +=1
case 'JUMP_ABSOLUTE', 'CONTINUE_LOOP':
absjumps += 1
. . .
So, that is it, my proposal for simple switch statements with a straight-forward
implementation, fast execution, simply ex
tch colorname[color]:
case 'RED', 'YELLOW', 'BLUE':
handle_primary()
case 'MAGENTA':
get_another_color()
default:
handle_rest()
colormixer(RED)
colormixer(ORANGE)
Raymond
__
something concrete at EuroPython.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
it fit
effortlessly and that the code was much improved. Also, there was some
appeal in knowing that if some constantification proposal gets accepted,
then those would become allowable values also.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rtcut in the event of an identity match.
OTOH, if the goal is having several distinct cases that are equal but
not identical, then that's another story. I suggest leave the initial
switch syntax as simple as possible and just switch on id(object).
Raymond
w modules. In practice,
it's probably not a problem. Next time, type faster ;-)
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opti
iss is about as expensive as a floating point division).
See dictnotes.txt for a few thoughts on the subject.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyth
eaking anything that currently works.
+1
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Raymond]
> > The above recommendations should get the PEP ready for judgement
day.
[David Eppstein]
> I thought judgement day already happened for this PEP in the "Parade
of
> PEPs". No?
The parade's text said the main gripe was having the index in the
middle,
ion is entirely unintuitive (it has
to be studied a bit before being able to see what it is for). Also, the
OP is short on use cases (none were presented). IMO, this belongs as a
cookbook recipe.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
; logic without locking it down to
> string manipulation...
How do you build, scan, and extract the buffer in a type independent
manner? Are there any use cases for non-string data buffers, a stream
of integers or somesuch?
Raymond
___
Pyth
I'm getting a compiler warning from your checkin:
C:\py25\Objects\floatobject.c(1430) : warning C4244: 'initializing' :
conversion from 'double ' to 'float ', possible loss of data
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
1201 - 1300 of 1495 matches
Mail list logo
