rited, we should change the Python locks so that
they get auto-released on fork (unless otherwise specified on lock
creation). This may sound like an uphill battle, but if there was a
smart and easy solution to the problem, POSIX would be providing it.
Regards,
Martin
ond
writer would just fail. This is but the only IO operation that is
guaranteed to be atomic (along with mkdir(2)), so reusing the current
approach doesn't work.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
if there was a
>> smart and easy solution to the problem, POSIX would be providing it.
>>
>> Regards,
>> Martin
>
> Posix threads expose the _atfork function
Yes - that's a solution, but one that I would call neither smart nor
simple. It requires you to regis
ve the parent and child
handlers release the locks. Of course, unless your locks are recursive,
you still have to know what locks you are already holding.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
> Le lundi 01 février 2010 à 23:58 +0100, "Martin v. Löwis" a écrit :
>> Interestingly, the POSIX pthread_atfork documentation defines how you
>> are supposed to do that: create an atfork handler set, and acquire all
>> mutexes in the prepare handler. Then fork
the
> exact program workflow to take locks in the right order.
That's not true. If the creator of the locks would register an atfork
callback set, they could arrange it to acquire the locks in the right
order (in cases where the order matters).
Regards,
Martin
__
already gone in 3.x.
Precisely my view.
Regards,
Martin
___
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
e that this works also in 2.5:
py> def foo(**kw):pass
...
py> foo(**{'':None})
py> foo(**{'\0':None})
Regards,
Martin
___
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
7;d offer a special version of the five-for-one deal: review five Mac
issues, and I review this one, despite not being one of the core Mac people.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
ne of them will be used. Having to check for all of
> the possible compiled versions of a module is just a waste of time;
> you should only care about what import used to load the module.
I agree.
Martin
___
Python-Dev mailing list
Python-Dev@python.or
yte code files.
What I really wanted to suggest is that it should be possible to tell
what gets really executed, plus what source file had been considered.
So if __file__ is always the source file, a second attribute should tell
whether a byte code file got read (so that you can delete t
ng the way we are doing it for
2to3 right now?
Regards,
Martin
___
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
> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> one - http://bugs.python.org/issue6608 Is it ok to release new
> versions that are known to crash?
As a general principle: yes, that's ok. We even distribute known
crashers with every releas
be ok
to delay 2.6.5. If 2.6.2 breaks in a case where all prior releases also
broke, it would NOT be ok, IMO, to block 2.6.5 for that. There can
always be a 2.6.6 release.
Of course, if this gets fixed before the scheduled release of 2.6.5,
anyway,
release blockers should only be used if something
really bad would happen that can be prevented by not releasing. If
nothing actually gets worse by the release, the release shouldn't be
blocked.
Regards,
Martin
___
Python-Dev mailing list
Python
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> IOW, I feel that release blockers should only be used if something
>> really bad would happen that can be prevented by not releasing. If
>> nothing actually gets worse by the release, the release shouldn'
> On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis" wrote:
>>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>>>> one - http://bugs.python.org/issue6
ecurity-critical at all.
People just don't pass out-of-range values to asctime, but instead
typically pass the result of gmtime/localtime, which will not cause any
problems.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
s will not actually happen. If
we can agree to give up the 2to3 sandbox, we should incorporate
find_pattern into the tree, and perhaps test.py as well.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
>> On Fri, Feb 12, 2010 at 11:17, "Martin v. Löwis" wrote:
>>> IMO, it is realistic to predict that this will not actually happen. If
>>> we can agree to give up the 2to3 sandbox, we should incorporate
>>> find_pattern into the tree, and perhaps test.
iltin lib2to3 would take
precedence over the lib2to3 bundled with the application.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/p
oubt.
Alterntively, the email notification sent to python-checkins could could
report who the pusher was.
Dirkjan: if you agree to such a strategy, please mention that in the PEP.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://ma
ready thinking about having a
> similar hook for Python repos.
This seems to just be the code that generates the feed, out of a
database pushlog2.db that somehow must be created. So where is the code
to actually fill that database?
Regards,
Martin
___
Py
load a newer version of 2to3 that fixes
them. For this use case, a tightly-integrated lib2to3 (with that name
and sole purpose) is the best thing.
Regards,
Martin
___
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
ctually happen, although this is probably a cure
worse than the disease.
We are not going to throw away the subversion repository, so it would
always be possible to go back and look at the actual history.
Regards,
Martin
___
Python-Dev mailing l
and how
many back-references then get actually generated.
Regards,
Martin
___
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
Georg Brandl wrote:
> Am 13.02.2010 13:19, schrieb Antoine Pitrou:
>> Martin v. Löwis v.loewis.de> writes:
>>> Alterntively, the email notification sent to python-checkins could could
>>> report who the pusher was.
>> This sounds reasonable, assuming it does
Starting around 14:00 UTC today, we will take the trackers at
bugs.python.org, bugs.jython.org, and psf.upfronthosting.co.za offline
for a system upgrade. The outage should not last longer than four hours
(probably much shorter).
Regards,
Martin
indefinite delay, which would
be bad.
Of course, for releases managed by Barry (i.e. 2.6), Barry said that you
can declare anything a blocker - whether it then will block the release
is a different matter (and one that Barry then decides on a case-by-case
basis).
Regards,
Martin
__
>> That information is also
>> available from the system on Mac OS and Windows.
>
> It is not available on Windows in any reasonable and useable form.
That's not true. The registry is readable by any user, and the format is
fully docum
> It's time to comment and review.
Unfortunately, it's not. I strongly object to any substantial change to
the code base without explicit approval by Fredrik Lundh.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@py
Antoine Pitrou wrote:
> Le Thu, 18 Feb 2010 22:46:41 +0100, Martin v. Löwis a écrit :
>>> It's time to comment and review.
>> Unfortunately, it's not. I strongly object to any substantial change to
>> the code base without explicit approval by Fredrik Lu
in practice at all, but if the policy was in
place and just not followed, that's a bug.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
fending right now, that's why I'm defending it: no
substantial changes without his explicit approval (breakage due to
language changes is about the only exception - not even bug fixes are
allowed).
Regards,
Martin
___
Python-Dev mailing list
P
, and am not contributing any patches back to
# upstream, I suggest renaming it instead.
This may be politely phrased, but it seems that he is quite upset about
these proposed changes.
I'd rather drop ElementTree from the standard library than fork it.
Regards,
Martin
__
else.
Unfortunately, it hurts ET users if it ultimately leads to a fork, or to
a removal of ET from the standard library.
Please be EXTREMELY careful. I urge you not to act on this until
mid-March (which is the earliest time at which Fredrik has sa
sed if SMB didn't support
both symbolic and hard links, given the right server and client versions.
Regards,
Martin
___
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
be Guido, and if it is not Fredrik, somebody else must step
forward. I would then ask that person, as the first thing, to rename the
package when making incompatible changes.
> I also do not find your idea of dropping the module productive either
> Martin. Just dropping it for no other r
27;ll find a need for additional changes
in doing so.
Regards,
Martin
___
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
r now" is fine; in the long term, I
propose to add an X-hgrepo header to the messages so that people can
filter on that if they want to.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
t.
When the switchover happens, 2to3 should not be converted to its own hg
repository, yes.
Regards,
Martin
___
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
Ah, this shouldn't be used at all for anything (except for studying how
Mercurial works). Along with the cpython repository, it is Dirkjan's
test conversion. Even if it survived the ultimate migration (which it
probably won't), it would get regenerated from scratch, probably
> Sorry, I meant "pull from". I want an updated snapshot of 2to3 for the
> benchmark suite, and I'm looking for the best place to grab it from.
The 2to3 code currently still lives in the subversion sandbox.
Regards,
Martin
___
Py
Dirkjan Ochtman wrote:
> On Mon, Feb 22, 2010 at 16:06, "Martin v. Löwis" wrote:
>> I think sending them there "for now" is fine; in the long term, I
>> propose to add an X-hgrepo header to the messages so that people can
>> filter on that if they want to.
> On Tue, Feb 23, 2010 at 00:55, "Martin v. Löwis" wrote:
>> Ah, this shouldn't be used at all for anything (except for studying how
>> Mercurial works). Along with the cpython repository, it is Dirkjan's
>> test conversion. Even if it survived the ultim
e anything I can do to
> help move it forward to be included in a patch release for 2.6?
The usual 5-for-one deal applies: review five issues, and I'll review
that one (with more energy than at the moment).
Regards,
Martin
___
Python-Dev mail
Doug Hellmann wrote:
>
> On Feb 25, 2010, at 2:34 PM, Martin v. Löwis wrote:
>
>> Doug Hellmann wrote:
>>> We've recently run into an issue with subprocess on Solaris, as
>>> described (by an earlier reporter) in issue #7242. The patch there
>>> so
I don't recall whether we have already decided about continued support
for Windows 2000.
If not, I'd like to propose that we phase out that support: the Windows
2.7 installer should display a warning; 3.2 will stop supporting Windows
2000.
Opinions?
Regar
>> If not, I'd like to propose that we phase out that support: the Windows
>> 2.7 installer should display a warning; 3.2 will stop supporting Windows
>> 2000.
>
>Is there any reason for this? I can understand dropping Windows 9x
> due to the lack of Unicode support but is there anything missi
Neil Hodgson wrote:
> Martin v. Löwis:
>
>> See http://bugs.python.org/issue6926
>>
>> The SDK currently hides symbolic constants from us that people are
>> asking for.
>
>Setting the version to 0x501 (XP) doesn't actively try to stop
> runnin
s there
> ( at http://code.python.org/hg ). Until we make the official switch,
> these mirrors are still useful.
Do you know who is in charge of creating the site? I could restore it,
but I would need help to make it actually work (such as giving it a
working Docume
> It seems someone has decided that code.python.org doesn't resolve
> anymore.
I have now restored it.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
and b) it makes the test less readable.
I would like to find a solution where this gets automatically corrected,
e.g. through 2to3, or through changes to doctest, or through changes of
str.__repr__.
Any proposal appreciated.
Regards,
Martin
___
Pytho
Andrew Bennetts wrote:
> "Martin v. Löwis" wrote:
> [...]
>> Any proposal appreciated.
>
> I propose screaming “help me, I have written a test suite using nothing
> but string matching assertions, what is wrong with me?!”
ot; repr results. Of course, this wouldn't catch repr
strings that were ultimately print()ed (not sure whether that
restriction would affect Django).
The other (more aggressive) approach is the heuristics you propose,
which may end up with false negatives. doctest already has a wildcard
matching
iling.
Enable the D() debugging in parser.c (configure with --with-pydebug,
and set PYTHONDEBUG).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
> thanks for any tips.
Set sqlite_setup_debug to True in setup.py
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-
s kind of question is off-topic for python-dev (which is about
development of Python, not about using it).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.py
log please? :-)
That would be even more effort than looking into the existing issue,
unless code is provided.
Regards,
Martin
___
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
> Any thoughts?
My initial reaction to this report, and still my current opinion is:
This issue is not a problem.
It's a boundary case, so it's not clear whether Python should be able to
deal with it gracefully. I doubt it's a realistic case
> Speaking for myself, I have an app with a daemon mode which I expect
> will sometimes behave as described; it answers requests and thus has I/O
> bound threads waiting for requests and dispatching replies, and threads
> doing data handling, which make constant use of the zlib library.
This is th
> Testing with a modified server that reflects the above indicates the new
> GIL behaves just fine in terms of throughput.
> So a change to the GIL may not be required at all.
Thanks - I think you put it better than I did.
Regards,
Martin
_
p
> off.
Why do you say that? The other threads continue to be served - and
Python couldn't use more than one CPU, anyway. Can you demonstrate that
in an example?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
that is simple and
> which either improves or doesn't negatively impact the performance of
> existing applications, why wouldn't you want to do it? Seems like a
> no-brainer.
Unfortunately, a simple improvement doesn't really seem to exist.
Regards,
Martin
_
Cameron Simpson wrote:
> On 15Mar2010 09:28, Martin v. L�wis wrote:
> | > As for the argument that an application with cpu intensive work being
> | > driven by the IO itself will work itself out... No it won't, it can
> | > get into beat patterns where it is handling
a point in time where you know the system will be idle for
the entire run of that task.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
he "daemon" world.
Unfortunately, you are not able to demonstrate this (because the effect
would only be subtle).
My claim is that the scenario where the effect is *visible* is
unrealistic, i.e. that, in realistic scenarios, tons of other effects
actually lessen the problem.
Regards,
Ma
Benjamin Peterson wrote:
> My plan is to tag 3.1.2 sometime on Thursday, so binaries can be built
> for the final release on Saturday. Agreeable?
Fine with me.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
people to run if they have the hardware and the time. If somebody wanted
to contribute such hardware as a build slave - that could certainly be
arranged.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
oach (which I doubt).
FWIW, the unicode_file_names function *is* removed in Python 2.7.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/o
ver, the learning curve is not to be underestimated: the first few
changes will rather be in the "one change per week" range.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-de
> Darn. I bet I broke it when I added the 'languishing' status. I even
> thought about that at the time but didn't follow up on it. I'll see
> if I can figure out where the script lives.
My guess is that the Debian upgrad
equested, so it may have a reason.
Regards,
Martin
___
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
d it may
well be the case that you don't have write permission at all, which
would trigger lots of ImportWarnings).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
), I think my proposal is
"tough luck". Don't try to be super-smart; as Antoine explains, it gets
worse, not better. If the user has arranged that Python will create
unusable directories, the user better changes his setup.
Regards,
Martin
__
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> If certain use cases
>> make it problematic (e.g. Apache creating directories which you then
>> cannot delete), there should be a way to turn it *off*. Perhaps the
>> existing machinery to turn of byte c
is is any more unfriendly than creating .pyc files in
the first place, and the advantages of uniformity of this new approach
certainly outweigh the disadvantages.
Regards,
Martin
___
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
really recommend reexamining it, rather than falling for the
> shiny new thing.
I think the appropriate action at this point is to record this specific
objection in the PEP.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
t down
> the road.
For 2.x, nothing will happen, anyway (except for Linux distributions
perhaps integrating a patch on their own): 2.7b1 is about to be
released, after which point 2.x will not see any new features.
Regards,
Martin
___
Python-Dev mailing
g access to Brian (in
particular due to the endorsements that have already been posted). I
still would like somebody to step forward as a mentor, and I would need
Brian to send me his SSH key.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@p
aptop, and you didn't really mean to contribute it).
Of course, committing it to subversion is an even stronger indication
that you wanted to contribute it :-)
The PSF then immediately exercises its right to relicense the code,
currently under the PSF license.
Regards,
Martin
__
hands, rather than letting
the new developer ask for himself.
Regards,
Martin
___
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
willing to elaborate on implementation?
Notice that the first beta release of Python 2.7 will be made on April
3. Any new feature that you propose must be committed by then.
I suggest focusing on Python 3.2 instead.
Regards,
Martin
___
Python-Dev mai
ag too, both on trunk and py3k.
Not sure what you are asking for. If you want confirmation that this
change is desirable, it seems you got that already. If you are asking
for someone to make that change - go ahead and make it yourself. You
just need to change the buildbottest target.
. (Feel
> free to point me to an appropriate section of the docs ...)
I guess being able to do inspect.currentframe() is a "SHOULD"
requirement for Python implementations. It's clear that it will be
difficult to provide, so portable applicat
ting, Zope page templates, and
the like (although some of them already have compilers of some form on
their own).
HTH,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pyt
Benjamin Peterson wrote:
> I propose that we freeze the trunk except for fixes for the buildbots.
> Thoughts?
Freezing sounds fine with me.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
)
This issue doesn't get noticed, because it doesn't hurt today's email
readers and MTAs to process 8-bit MIME, even if 7-bit had been
sufficient.
HTH,
Martin
P.S. Notice that Tokio's original patch had the spelling right.
___
Pyth
;t go into 2.7b1,
by the decision of the release manager. Please accept that.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
anatoly techtonik wrote:
> On Wed, Apr 7, 2010 at 2:10 PM, "Martin v. Löwis" wrote:
>>> There is still a serious regression in zipfile module:
>>> http://bugs.python.org/issue6090
>>>
>>> And I would really like to see my issue with difflib tabs c
#x27;
>
> It's on the buildbots, too. See:
>
> http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk/builds/208/steps/compile/logs/stdio
Instead of submitting a bug report, it would be better to submit a
patch, th
most likely will come from the submitter, as nobody else might
have access to the platform, and the knowledge about the platform details.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
is still exists in the libffi hg
repository.
Regards,
Martin
___
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
I have commented out all tests in test_gdb, yet
http://www.python.org/dev/buildbot/all/builders/sparc%20Ubuntu%20trunk/builds/47/steps/test/logs/stdio
still shows them being run. Can anybody explain that, please?
TIA,
Martin
___
Python-Dev mailing
> FWIW I've attached a patch [1] to http://bugs.python.org/issue8330 which
> I believe may fix the issues seen in that log.
Thanks! I'll apply them after the beta release (don't want to mess with
it before).
Regards,
Martin
___
Py
rse, cases where dicts do show collisions (namely when
all keys hash equal), however, I'm uncertain whether the approach would
help in that case.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
ither be a commitment nor a guarantee that you will
actually mentor a project - this depends on a lot of factors (your
interest in a specific project, Google's ultimate assigment of slots,
and so on).
Regards,
Martin
___
Python-Dev mailing list
that any AC bugs in the
original field will also spread to the new field :-(
HTH,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python
y to this mail in three weeks.
That is not surprising: none of the webmaster people would be able to
answer the question. python-dev is indeed the right place to ask.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
ialbility of binaries is going to lag source
> releases forever.
Tres,
can you be more explicit? How would such hardware help (whom specifically)?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
1401 - 1500 of 5755 matches
Mail list logo
