Willem Broekema wrote:
The AND above (which I uppercased) is subtle but important. In the "x
op y" case with y being of a subclass of the class of x, if there is
no class in between x and y (excluding x, including y) that overrides
the __rop__ method, then y,__rop__(x) is *not* tried before
x.__
Pascal Chambon wrote:
Concerning the naming of truncate(), would it be possible to deprecate
it and alias it to "resize()" ? It's not very gratifying to have
duplicated methods at the beginning of a major release, but I feel too
that "truncate" is a misleading term, that had better be replac
Steven D'Aprano wrote:
Using "truncate" to mean "increase in size" makes about as much sense as
having a list method called "remove" used to insert items. I can't
imagine what the committee who approved this were thinking.
I expect the reason is historical. Some time back in the
early days of
Nick Coghlan wrote:
For example, a file not existing, a file being locked by another
process, and the user not having write permissions to the file are
problems that demand very different responses from the user.
You can display an error-specific message without having
to inspect the error cod
Pascal Chambon wrote:
And let the
filepointer untouched, simply because there are no reasons to move it,
On some systems it may not be possible for the file pointer to
be positioned past the end of the file (I think Classic MacOS
was like that).
I had the feeling that IOErrors were for opera
Eric Smith wrote:
My only concern with this is a possible performance issue with v6
networks. Would this be implemented such that [-1] doesn't need to
iterate through the (possibly large) address space of a v6 network?
I'm not familiar with v6, but if netmasks work the same
way as they do in
Peter Moody wrote:
the address with all of the hosts bits masked to zero is most commonly
referred to as the network address.
Then call the attribute 'network_address', not just 'network'.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
ht
Peter Moody wrote:
I don't see where the confusion lies. You have an address
+ netmask. ergo, you have a Network object. The single address that
defines the base address (most commonly referred to as the network
address) is an Address object. there is no netmask associated with
that single addr
Andrew McNamara wrote:
I also suggest the AddressWithMask classes not have any network/container
behaviours for a similar reason. If the developer needs these, the
.network attribute is only a lookup away.
Another way to approach this would be for the Address
object to potentially have a 'netw
R. David Murray wrote:
A network is conventionally represented by an IP address in which the
bits corresponding to the one bits in the netmask are set to zero, plus
the netmask.
Okay, that's clarified things for me, thanks.
In that case, we shouldn't be talking about a "network address"
at al
Nick Coghlan wrote:
Or, to put it another way, given an arbitrary host in a network (e.g.
your own machine or the default gateway) and the netmask for that
network, calculate the network address.
Some people have claimed that the gateway address of a
network isn't necessarily the zero address
Eric Smith wrote:
Mark Dickinson and I agree that for numeric types, right alignment makes
much more sense as a default. And that's what %-formatting and
str.format() both do.
Is the new formatting supposed to behave the same way
as %-formatting for the same format codes? Because the
default
Xavier Morel wrote:
Methods yes (and that's one of the few Smalltalk design "features" I
consider truly dumb, considering it has message cascading)
Cascading is something different -- it's for sending
multiple messages to the *same* receiver. It's not
dumb to have both.
--
Greg
_
Benjamin Peterson wrote:
It depends on whether you're keeping the "callable" object around or
not. Somebody could add a __call__ method later.
Good point. Removing the check sounds like the
right thing to do, then.
--
Greg
___
Python-Dev mailing lis
Brett Cannon wrote:
It isn't like it is checking
explicitly for a function or method, just that it can be called which
seems reasonable to me (unless PyCallable_Check() is as off as
callable() was).
I think it just checks that there's something in the
tp_call slot, which is reasonable -- if it'
Reid Kleckner wrote:
On one hand, you may not want to call the user's atexit handlers
multiple times from different processes if they have externally
visible effects. On the other hand, people seem to assume that
Py_Finalize will be called at process exit to do various cleanups. On
the third h
Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit :
"We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly.
IIRC, the default return value of a Smalltalk method is
self, not the last thing evaluated.
(And no, that's not going to happen in Python either --
the BDFL has rej
Xavier Morel wrote:
I fail to grasp the unpredictability of "the last expression evaluated
in the body of a function is its return value".
It's unpredictable in the sense that if you're writing
a function that's not intended to return a value, you're
not thinking about what the last call you
Antoine Pitrou wrote:
Did your coworker run any timings instead of basing his assumptions on bytecode
size?
In any case, what are you suggesting -- that the last value
returned by a function call in the body should be the
default return value?
I don't think the unpredictability that would int
Martin Zugnoni wrote:
when I press
the triple zero key once, I receive three events from the single zero key.
I need to make a disctintion between these keys
Sounds like you can't, except perhaps by detecting
three '0' key events arriving at almost the same
time.
--
Greg
__
Scott David Daniels wrote:
No, I don't really need MT. The others would be fine.
I'd love further details.
The one I've been working with is due to Pierre L'Ecuyer [1]
and is known as MRG32k3a. It's a combined multiple recursive
linear congruential generator with 6 words of state. The
formula
Benjamin Peterson wrote:
Why do you need to set Py_TPFLAGS_HEAPTYPE on your C type?
I think he *doesn't* want to set Py_TPFLAGS_HEAPTYPE, but
does want to create the type dynamically.
But I suspect this is actually FUD, and that letting
Py_TPFLAGS_HEAPTYPE be set wouldn't lead to anything
dis
Jason R. Coombs wrote:
I had a use case that was compelling enough that I thought there
> should be something in functools to do what I wanted.
I think this is one of those things that a small minority of
people would use frequently, but everyone else would use
very rarely or never. The decisi
Scott David Daniels wrote:
I find I have a need in randomized testing for a shorter version
of getstate, even if it _is_ slower to restore. When running
exhaustive tests, a failure report should show the start state
of the generator. Unfortunately, our current state includes a
625-element array
Joshua Haberman wrote:
Python as a language has chosen to "lock down" built-in
objects... If it's
important for the built-in types, why should it be less important for
mine?
I'm not really sure why so much trouble is taken to lock
down builtin types -- it seems to go against Python's
general c
Joshua Haberman wrote:
This is not as bad as having someone
set __class__ on one of my instances, or set attributes on my type, etc.
Is there any real need to prevent someone from doing
those things?
Note that even when you are allowed to change the
__class__ of an instance, you're still preve
P.J. Eby wrote:
In effect, 2.6 forces you to have a common known base class *other* than
'object' in order to write co-operative classes. :-(
You have to do that anyway if you want to make cooperative
calls to any method *other* that __init__.
--
Greg
Daniel Diniz wrote:
Apocalypse Python !!, you say? Maybe something that conveys a security
message or anything that doesn't relate to the end of the world could
work better.
I guess the idea is meant to be that it's safe enough to
use for something that would result in the end of the
world if
Lucas P Melo wrote:
Am I understanding this correctly:
* The blocking version would not do any raw reads.
No, the blocking version would keep doing raw reads
until the buffer contains enough bytes.
--
Greg
___
Python-Dev mailing list
Python-Dev@pyth
Lucas P Melo wrote:
The problem is that the chosen
method to accomplish it would read 2 symbols (bytes) ahead and this guy
is using peek() to grab these 2 bytes. The program will seem to work
correctly most of the time, but on the 4095th byte read, he would grab 1
byte at most using peek()
Cameron Simpson wrote:
But people not using threads, or at any rate not
dedicating a thread to the reading task, don't have such luxury.
But without a dedicated thread you need to use
select() or poll(), and then buffering causes other
headaches.
Are we disputing the utility of being able to
Christian Heimes wrote:
But it is a convenient oddity nonetheless.
What's convenient about it? Seems to me it's the
opposite, since you can't just bail out if it
fails, but have to decref the reference you
thought it was going to take care of for you.
--
Greg
_
Lenard Lindstrom wrote:
I assumed that since PyModule_AddObject is documented as
stealing a reference, it always stole a reference. But in reality it
only does so conditionally, when it succeeds.
As an aside, is this a general feature of functions
that steal references, or is PyModule_AddObje
Cameron Simpson wrote:
I normally avoid
non-blocking requirements by using threads, so that the thread gathering
from the stream can block.
If you have a thread dedicated to reading from that
stream, then I don't see why you need to peek into
the buffer. Just have it loop reading a packet at a
Cameron Simpson wrote:
It seems like whenever I want to do some kind of opportunistic but
non-blocking stuff with a remote service
Do you actually do this with buffered streams? I find
it's better to steer well clear of buffered I/O objects
when doing non-blocking stuff, because they don't pla
Cameron Simpson wrote:
For myself, I'd expect more often to want to see if there's stuff in the
buffer _without_ doing any raw reads at all.
What uses do you have in mind for that?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mai
Zooko Wilcox-O'Hearn wrote:
1. Add a "st_crtime" field which gets populated on filesystems
(Windows, ZFS, Mac) which can do so.
"crtime" looks rather too similar to "ctime" for my
liking. People who think that the "c" in "ctime"
means "creation" are still likely to confuse them.
Why not give
Antoine Pitrou wrote:
The original docstring for peek() says:
...we
do at most one raw read to satisfy it.
In that light, I'm not sure it's a bug
It may be behaving according to the docs, but is that
behaviour useful?
Seems to me that if you're asking for n bytes, then it's
b
Michael Foord wrote:
if you are added as nosy on a tracker item (which happens
when you make a comment or you can do yourself) then you get emailed
about new comments.
That's good, but...
only going to the tracker to add responses.
is not so good. If the goal is to ensure that all previou
Robert Kern wrote:
The 'single' mode, which is used for the REPL, is a bit different than
'exec', which is used for modules. This difference lets you insert
"blank" lines of whitespace into a function definition without exiting
the definition.
All that means is that the REPL needs to keep re
Antoine Pitrou wrote:
you can't be sure all the responders are
over 18. Actually, they might even not be human beings!
(hint: I'm not)
Not over 18, or not a human being?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
MRAB wrote:
Next you'll be saying that they should be named after years. Python
2010, anyone? :-)
To keep people on their toes, we should switch to a
completely random new naming scheme with every release,
like Microsoft has been doing with Windows.
--
Greg
___
Are we solving an actual problem by changing the
behaviour here, or is it just a case of foolish
consistency?
Seems to me that trying to pin down exactly what
constitutes a "special method" is a fool's errand,
especially if you want it to include __enter__ and
__exit__ but not __reduce__, etc.
-
Larry Hastings wrote:
Removing tp_reserved would affect everybody, with inscrutable
compiler errors.
This would have to be considered in conjunction with the
proposed programmatic type-building API, I think.
I'd like to see a migration towards something like that,
BTW. Recently I had occasio
Benjamin Peterson wrote:
What's the status of yield from? There's still a small window open for
a patch to be checked into 3.1's branch. I haven't been following the
python-ideas threads, so I'm not sure if it's ready yet.
The PEP itself seems to have settle down, and is
awaiting a verdict from
Nick Coghlan wrote:
Note that such an approach would then require an altaltinstall command
in order to be able to install a specific version of python 3.x without
changing the python3 alias (e.g. installing 3.2 without overriding 3.1).
Seems like what we need is something in between altinstall
Steven Bethard wrote:
That's an unfortunate decision. When the 2.X line stops being
maintained (after 2.7 maybe?) we're going to be stuck with the "3"
suffix forever for the "real" Python.
I don't see why we have to be stuck with it forever.
When 2.x has faded into the sunset, we can start
ali
Steven D'Aprano wrote:
it should be obvious in the
same way that string concatenation is different from numerical
addition:
1 + 2 = 2 + 1
'1' + '2' != '2' + '1'
However, the proposed arithmetic isn't just non-
commutative, it's non-associative, which is a
much rarer and more surprising thing
Steven D'Aprano wrote:
"2rd of March on leap years,
^^^
The turd of March?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
Jess Austin wrote:
This is a perceptive observation: in the absence of parentheses to
dictate a different order of operations, the third quantity will
differ from the second.
Another aspect of this is the use case mentioned right
at the beginning of this discussion concerning a recurring
event
Alexandre Vassalotti wrote:
print("Content-Type: application/json; charset=utf-8")
input_object = json.loads(sys.stdin.read())
output_object = do_some_work(input_object)
print(json.dumps(output_object))
print()
That assumes the encoding being used by stdout has
ascii as a subset.
--
Greg
R. David Murray wrote:
That doesn't make sense to me. str() should return
_something_.
Well, it might return something like "". But you shouldn't rely on it
to give you anything useful for an arbitrary header.
--
Greg
___
Python-Dev mailing list
Py
Barry Warsaw wrote:
For an
Originator or Destination address, what does str(header) return?
It should be an error, I think.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
Barry Warsaw wrote:
The default
would probably be some unstructured parser for headers like Subject.
Only for headers known to be unstructured, I think.
Completely unknown headers should be available only
as bytes.
--
Greg
___
Python-Dev mailing lis
Antoine Pitrou wrote:
Say you are filtering or sorting data based on some URL parameters. If the user
wants to remove one of those filters, you have to remove the corresponding query
parameter.
For an application like that, I would be keeping the
parameters as a list or some other structured w
Chris Withers wrote:
Nick Coghlan wrote:
A similar naming scheme (i.e. msg.headers and msg.headersb) would
probably work for email as well.
That just feels nasty though :-(
It does tend to look like a typo to me. Inserting an
underscore (headers_b) would make it look less
accidental.
--
Gr
Paul Moore wrote:
3. Encoding
JSON text SHALL be encoded in Unicode. The default encoding is
UTF-8.
This is at best confused (in my utterly non-expert opinion :-)) as
Unicode isn't an encoding...
I'm inclined to agree. I'd go further and say that if JSON
is really mean to be a text f
Nick Coghlan wrote:
I sometimes wish for a nice, solid lazy
module import mechanism that manages to avoid the potential deadlock
problems created by using import statements inside functions.
I created an ad-hoc one of these for PyGUI recently.
I can send you the code if you're interested.
I d
John Arbash Meinel wrote:
And the way intern is currently
written, there is a third cost when the item doesn't exist yet, which is
another lookup to insert the object.
That's even rarer still, since it only happens the first
time you load a piece of code that uses a given variable
name anywhere
John Arbash Meinel wrote:
And when you look at the intern function, it doesn't use
setdefault logic, it actually does a get() followed by a set(), which
means the cost of interning is 1-2 lookups depending on likelyhood, etc.
Keep in mind that intern() is called fairly rarely, mostly
only at mo
Alexander Neundorf wrote:
My experience is that people don't need
general computation in their build process.
> ...
CMake supports now more general purpose programming features than it
did 2 years ago, e.g. it has now functions with local variables, it
can do simple math, regexps and other thin
David Cournapeau wrote:
Having a full
fledged language for complex builds is nice, I think most familiar
with complex makefiles would agree with this.
Yes, people will still need general computation in their
build process from time to time whether the build tool
they're using supports it or not
Steve Holden wrote:
Isn't it strange how nobody every complained about the significance of
whitespace in makefiles: only the fact that leading tabs were required
rather than just-any-old whitespace.
Make doesn't care how *much* whitespace there
is, though, only whether it's there or not. If
it
Antoine Pitrou wrote:
Your proposal looks sane, although the fact that a semi-private method
(starting with an underscore) is designed to be overriden in some classes is a
bit annoying.
The only other way I can see is to give up any attempt
in the base class to ensure that flushing occurs befor
Firephoenix wrote:
I basically agreed with renaming the next() method to __next__(), so as
to follow the naming of other similar methods (__iter__() etc.).
But I noticed then that all the other methods of the generator had
stayed the same (send, throw, close...)
Keep in mind that next() is pa
Nick Coghlan wrote:
Still, as both you and Greg have pointed out, even in its current form
memoryview is already useful as a replacement for buffer that doesn't
share buffer's problems
That may be so, but I was more pointing out that the
elementwise functions I'm talking about would be useful
Brian Quinlan wrote:
if not self.__closed:
try:
-self.flush()
+IOBase.flush(self)
except IOError:
pass # If flush() fails, just give up
self.__closed = True
That doesn't seem like a good idea to me at
Nick Coghlan wrote:
Actually *finishing* parts 2 and 3 of PEP 3118 would be a good precursor
to having some kind of multi-dimensional mathematics in the standard
library though.
Even if they only work on the existing one-dimensional
sequence types, elementwise operations would still be
useful
Antoine Pitrou wrote:
Both.
Well, taking a buffer or memoryview to non-bytes data is supported, but since
it's basically unused, some things are likely missing or broken
So you're saying the buffer interface *has* been fully
implemented, it just hasn't been tested very well?
If so, writing so
Antoine Pitrou wrote:
Again, I don't want to spoil the party, but multidimensional buffers are
not implemented, and neither are buffers of anything other than single-byte
data.
When you say "buffer" here, are you talking about the
buffer interface itself, or the memoryview object?
--
Greg
___
C. Titus Brown wrote:
we're having a discussion over on the GSoC mailing list about basic
math types, and I was wondering if there is any history that we should
be aware of in python-dev.
Something I've suggested before is to provide a set of
functions for doing elementwise arithmetic operatio
Jim Fulton wrote:
The original use case for CObjects was to export an API from a module,
in which case, you'd be importing the API from the module. The presence
in the module indicates the type.
Sure, but it can't hurt to have an additional sanity
check.
Also, there are wider uses for CObje
Hrvoje Niksic wrote:
I thought the entire *point* of C object was that it's an opaque box
without any info whatsoever, except that which is known and shared by
its creator and its consumer.
But there's no way of telling who created a given
CObject, so *nobody* knows anything about it for
cert
Jim Fulton wrote:
The only type-safety mechanism for a CObject is it's identity. If you
want to make sure you're using the foomodule api, make sure the address
of the CObject is the same as the address of the api object exported by
the module.
I don't follow that. If you already have the
Nick Coghlan wrote:
'import a.b.c' will look in sys.modules for "a.b.c", succeed and work,
even if "a.b.c" is in the process of being imported.
'from a.b import c' (or 'from . import c' in a subpackage of "a.b") will
only look in sys.modules for "a.b", and then look on that object for a
"c" att
Mike Coleman wrote:
I mentioned this once on the git list and Linus' response was
something like "C lets me see exactly what's going on". I'm not
unsympathetic to this point of view--I'm really growing to loathe C++
partly because it *doesn't* let me see exactly what's going on--but
I'm not con
Nick Coghlan wrote:
Jim Fulton's example in that tracker issue shows that with a bit of
creativity you can provoke this behaviour *without* using a from-style
import. Torsten Bronger later brought up the same issue that Fredrik did
- it prevents some kinds of explicit relative import that look l
Guido van Rossum wrote:
But it's been answered already -- we can't change the meaning of
StopIteration() with a value unequal to None, so it has to be a
separate exception, and it should not derive from StopIteration.
How about having StopIteration be a subclass of the
new exception? Then thin
Guido van Rossum wrote:
I think in either case a check in
PyIter_Next() would cover most cases
If that's acceptable, then the check might as well
be for None as the StopIteration value, and there's
no need for a new exception.
I don't understand this.
Maybe I misunderstood what you were s
Guido van Rossum wrote:
The new exception could either be a designated (built-in) subclass of
StopIteration, or not;
I think it would have to not be; otherwise any existing
code that catches StopIteration would catch the new
exception as well without complaint.
Using a different exception rai
Guido van Rossum wrote:
Perhaps the crux is that *if* you accidentally use "return " in
a vanilla generator expecting the value to show up somewhere, you are
probably enough of a newbie that debugging this will be quite hard.
I'd like not to have such a newbie trap lying around.
Okay, so would
anatoly techtonik wrote:
Correct me if I wrong, but shouldn't Python include function for
version comparisons?
Can't you just compare sys.version_info tuples?
>>> sys.version_info
(2, 5, 0, 'final', 0)
Assuming the other possibilities for 'final' are
'alpha' and 'beta', these should compare
Draft 10 of the PEP. Removed the outer try-finally
from the expansion and fixed it to re-raise
GeneratorExit if the throw call raises StopIteration.
--
Greg
PEP: XXX
Title: Syntax for Delegating to a Subgenerator
Version: $Revision$
Last-Modified: $Date$
Author: Gregory Ewing
Status: Draft
Type
Steve Holden wrote:
I am a *bit* concerned, without really being able to put my finger on
it, that the "yield from" expression's value comes from inside (the
"return" from the nested generator) while the "yield from" expression's
value comes from "outside" (the value passed to a .send() method c
Jim Jewett wrote:
I still don't see why it needs to be a return statement. Why not make
the intent of g explicit
def g():
yield 42
raise StopIteration(43)
Because it would be tedious and ugly, and would actually make
the intent *less* clear in the intended use cases. When
P.J. Eby wrote:
Could we at least have some syntax like 'return from yield with 43', to
distinguish it from a regular return, clarify that it's returning a
value to a yield-from statement, and emphasize that you need a
yield-from to call it?
You don't, though -- yield-from just happens to be
Guido van Rossum wrote:
That +0 could turn into a +1 if there was a way to flag this as an
error (at runtime), at least if the return is actually executed:
def g():
yield 42
return 43
for x in g():
print x# probably expected to print 42 and then 43
Perhaps the exception used i
Nick Coghlan wrote:
Since correctly written generators are permitted to
convert GeneratorExit to StopIteration, the 'yield from' expression
should detect when that has happened and reraise the original exception.
I'll have to think about that a bit, but you're
probably right.
it is also neces
P.J. Eby wrote:
In particular, it should explain why these choices are so costly as to
justify new syntax and a complex implementation:
If avoiding trampolines was the only reason for
yield-from, that mightn't be enough justification
on its own. But it addresses several other use
cases as well.
P.J. Eby wrote:
And they *still* wouldn't be able to do away with their trampolines --
It's not really about doing away with trampolines anyway.
You still need at least one trampoline-like thing at the
top. What you do away with is the need for creating
special objects to yield, and the attend
Guido van Rossum wrote:
(Well here is Greg's requested use case for .send(). :-)
There was a complaint that my return-value-with-send
example was too much of a coroutine scenario, so I
was hoping to find something un-coroutine-like. But
if coroutines are the main uses for send in the first
pla
Olemis Lang wrote:
... well ... it is too long ... :-§ ... perhaps it is better this way ...
--lmdtbicdfyeiwdimoweiiiapiyssiansey ... :P
Isn't that the name of a town in Wales somewhere?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
ht
Guido van Rossum wrote:
Can I suggest that API this takes a glob-style pattern?
Globs would be nice to have, but the minimum
needed is some kind of listdir-like functionality.
Globbing can be built on that if need be.
--
Greg
___
Python-Dev mailing l
Guido van Rossum wrote:
I'll gladly take that as an added rationalization of my plea not to
change datetime.
In the case of datetime, could perhaps just the
module name be changed so that it's not the same
as a name inside the module? Maybe call it
date_time or date_and_time.
--
Greg
__
Antoine Pitrou wrote:
There seems to be a misunderstanding as to how generators
are used in Twisted. There isn't a global "trampoline" to schedule generators
around. Instead, generators are wrapped with a decorator (*) which collects each
yielded value (it's a Deferred object) and attaches to it
Here's a new draft of the PEP. I've added a Motivation
section and removed any mention of inlining.
There is a new expansion that incorporates recent ideas,
including the suggested handling of StopIteration raised
by a throw() call (i.e. if it wasn't the one thrown in,
treat it as a return value)
Trying to think of a better usage example that
combines send() with returning values, I've realized
that part of the problem is that I don't actually
know of any realistic uses for send() in the first
place.
Can anyone point me to any? Maybe it will help
to inspire a better example.
--
Greg
Nick Coghlan wrote:
Although the PEP may still want to mention how one would write *tests*
for these things. Will the test drivers themselves need to be generators
participating in some kind of trampoline setup?
I don't see that tests are fundamentally different
from any other code that wants
Nick Coghlan wrote:
I think the main thing that may be putting me off is the amount of
energy that went into deciding whether or not to emit Py3k warnings or
DeprecationWarning or PendingDeprecationWarning for use of the old
threading API.
Having made that decision, though, couldn't the result
Guido van Rossum wrote:
That's all good. I just don't think that a presentation in terms of
code in-lining is a good idea.
I was trying to describe it in a way that would give
some insight into *why* the various aspects of the
formal definition are the way they are. The inlining
concept seemed
1101 - 1200 of 2443 matches
Mail list logo
