[Martin v. Löwis]
I disagree that our users are served by constantly breaking the
API, and removing stuff just because we can. I can't see how
removing API can possibly serve a user.
Am not following you here. My suggestion was to remove the two
methods in Py3.1 which isn't even in alpha
[Guido van Rossum]
Based on our experiences so far, I think that of the two options we
have, both of which are bad, it's better to keep things in 3.1 that we
were planning to remove but forgot, than to make 3.1 have a whole slew
of additional removals. We've removed cmp() in 3.0.1, and I think
Beware, deleting an item from an OrderedDict (in the current
implementation) is O(N).
Am I correct in presuming that that would not be true of .popitem?
Yes. The popitem() method is O(1).
Raymond
___
Python-Dev mailing list
Just notices that the empty() and full() methods were still there.
IIRC, we agreed to take them out (but leaving qsize() exposed).
The docs entries and test cases were taken out, but the actual
methods were accidentally left in.
Raymond
___
Python-Dev
Just noticed that the empty() and full() methods were still there.
IIRC, we agreed to take them out (but leaving qsize() exposed).
The docs entries and test cases were taken out, but the actual
methods were accidentally left in.
If so, the only thing to do is deprecate it in 3.1 for removal in
Yup, I'd need to remove support in multiprocessing too.
ahead and tried adding a warning to my local checkout.
Thanks for quickly checking this out.
Will be nice to get the API cleaned-up.
Leaving out part of the clean-up was a mistake.
Raymond
[Forest]
Okay, but I'd also like a convenient and fast way to find the oldest entry
in an OrderedDict, which I think I'd need for an LRU cache. Skimming the
current patch (od7.diff), I didn't notice one. Perhaps I simply missed
something. Shouldn't popitem() allow the caller to choose which
I recommend that you either make this a
__private variable (signalling strongly that people shouldn't ever
reference it),
Will do. We want to make sure we can substitute a C implementation that has a completely different underlying structure (hash table
plus a doubly linked list).
Raymond
[Forest]
Perhaps a new method like getfirst() would be worth while here?
Guido already gave you a way to access the first item using the existing API.
Using next(iter(d)) also works.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
It may be too late to rename the existing accidents, but why not add
consistently-named aliases (socket.Socket, datetime.DateTime, etc) and
strongly encourage their use in new code?
Or make the old names aliases for the new names and start a
PendingDeprecationWarning on the old names so they
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
itself sorted in key order
+1
FIFOdict ? Yeah, that blows the capitalization scheme, way, way out.
Issues:
* The popitem() method is LIFO.
* In a
[Antoine Pitrou]
Given you were bitten by it in your own unit tests (the eval(repr()) does not
maintain ordering problem pointed by Georg),
Completely unrelated. The original test passed because the arbitrarily
ordered data in the regular dict happened to match the order added in
a regular
But you'll have to convince me,
Okay, here's one stab at it. If it doesn't take, I give in.
ISTM, either way is right depending on your point of view and what
you're trying do at the time. My judgment tips in favor of not
specializing the __eq__ method. But it is not lost on me why
one might
[Me]
In this case, Armin wants to be able to pass in an ordered dictionary to functions that weren't designed with ordered dicts in
mind (config parser, json/yaml parsers, nose, unittest, etc.). Those functions should be able to assume that all the usual
dictionary properties are still true.
Compromise?
def __eq__(self, other):
if isinstance(other, OrderedDict):
return all(map(operator.eq, self.items(), other.items()))
if isinstance(other, Mapping):
return dict.__eq__(self, other)
return NotImplemented # Give other a chance; defaults to
/bikeshedding
Yes. Also we need to paint it green with pink polka dots :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
[Nick Coghlan]
The examples in the PEP used 'odict' (until recently), but the patch was
for OrderedDict.
As an experiment, try walking down the hall asking a few programmers who aren't in this conversion what they think
collections.odict() is?
Is it a class or function? What does it do?
Unfortunately PEP 8 never really took off naming-wise, so we're mostly following
the reuse the naming scheme from existing code in the same module rule, and I
think there lowercase wins, thanks to defaultdict.
Traditionally, the all lowercase name referred to a C type. The other classes
in
[GvR]
*Maybe* the built-in status should guide the
capitalization, so only built-in types are lowercase (str, int, dict
etc.).
That makes sense.
Anyway, it seems the collections module in particular is already
internally inconsistent -- NamedTuple vs. defaultdict.
FWIW, namedtuple() is a
-
From: Guido van Rossum gu...@python.org
To: Raymond Hettinger pyt...@rcn.com
Cc: python-dev@python.org; Armin Ronacher armin.ronac...@active-4.com
Sent: Monday, March 02, 2009 3:38 PM
Subject: Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections
ready for pronouncement
[Chris Withers]
I want to work on these issues:
http://bugs.python.org/issue1823
http://bugs.python.org/issue1874
...and I'd also like to commit the patch I submitted with this one:
http://bugs.python.org/issue1974
Barry usually takes ownership of changes to the email package.
Do you have
[Chris Withers]
Barry usually takes ownership of changes to the email package.
Do you have patches ready for him to review?
Not yet for 1974, but given that I submitted a patch for this issue:
http://bugs.python.org/issue4308
...some months ago, and nothing has happened with it, I want to
You might also want to collect a list of serious changes that you want
in this release; I know I/O in C is on the list (and without it I
wouldn't consider it worth releasing) but there may be others. The
developers of such features ought to be on board with delivering their
code before the
[Brett]
With io getting rewritten as an extension module, I think it's time to try to
come up with a good best practice scenario for how to be able to control
when a module uses a pure Python implementation and when it uses
extension module optimizations. This is really only important for
as
dominant.
- Original Message -
From: Brett Cannon
To: Raymond Hettinger
Cc: Python Dev
Sent: Friday, February 20, 2009 12:41 PM
Subject: Re: [Python-Dev] Choosing a best practice solution for
Python/extensionmodules
On Fri, Feb 20, 2009 at 12:33, Raymond Hettinger
[Venkatraman S]
the following line
kind of confuses me and wasnt sure what exactly Raymond(et al) is planning,
I think the AST optimization work is being pursued by tlee.
See his current results on the branch: tlee-ast-optimize/
I don't know if this work has stalled but it was off to a good
If someone sets the -3 option to get py3k warnings, should the classic division
warning get turned-on automatically?
Right now, I get no warnings for:
python -3 -c 9 / 5
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
[Greg Ewing]
I've discovered something slightly misleading in the docs
for PyObject_IsInstance:
When testing if B is a subclass of A, if A is B, PyObject_IsSubclass
returns true. If A and B are different objects, B‘s __bases__
attribute is searched...
This suggests that issubclass(A, A)
C:\py27py27 lib\test\regrtest.py -uall test_tk
test_tk
test test_tk failed -- Traceback (most recent call last):
File c:\py27\lib\lib-tk\test\test_tkinter\test_text.py, line 32, in
test_search
self.failUnlessEqual(text.search('-test', '1.0', 'end'), '1.2')
AssertionError: textindex object at
[Daniel (ajax) Diniz]
Now will I'll start verifying, adding tests, updating or closing as
needed the recently changed old issues, until I've taken a good look
at these. Then, if there's still time left before Saturday, I'll focus
on verifying/flagging more ancient ones.
Thanks for your
- Original Message -
From: Cesare Di Mauro cesare.dima...@a-tono.com
To: Python-Dev python-dev@python.org
Sent: Tuesday, February 10, 2009 8:24 AM
Subject: [Python-Dev] Expression optimizations
In peephole.c I noticed some expression optimizations:
/* not a is b -- a is not b
[Cesare Di Mauro]
I'm playing with the virtual machine and I have some ideas about possibile
optimizations that could be applyed. But I need to verify them, so
understanding what is possible and what is not, is a primary goal for me.
The best way to understand what is possible is to
ISTM, that when closing duplicate bug reports, both should reference one
another so that the combined threads don't get lost.
Also, assigning bugs to people who haven't asked to handle them doesn't seem like it is actually cleaning-up anything. If something
is assigned to someone, I usually
import os
os.tmpnam()
RuntimeWarning: tmpnam is a potential security risk to your program
Are these runtime warnings necessary? Suppressing these warnings is a pita for
one-off uses of os.tmpnam() or os.tempnam().
I would hate for this sort of thing to propagate throughout the standard
I still haven't seen any real code presented that would benefit from
partial.skip or partial_right.
# some Articles have timestamp attributes and some don't
stamp = partial_right(getattr, 'timestamp', 0)
lastupdate = max(map(stamp, articles))
# some beautiful soup nodes have a name attribute
[Hrvoje Niksic]
The one thing missing from the array
module is the ability to directly access array values from C.
Please put a feature request on the bug tracker.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
From: Guido van Rossum gu...@python.org
On the one hand I understand that those folks want a stable target. On
the other hand I think they would prefer to find out sooner rather
than later they're using stuff they shouldn't be using any more. It's
a delicate balance for sure, and I certainly
In the past couple of days, test_distutils started failing.
It looks like a pure python error and may have been
introduced by guilherme.polo's checkins:
File c:\py27\lib\distutils\tests\test_sdist.py, line 119, in test_make_distr
ibution
spawn('tar --help')
File
[Tarek Ziadé]
That's me. I'll fix this problem right now.
Thanks. I appreciate it.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
[Aahz]
At the same time, I think each individual
change that doesn't clearly fall into the PEP6 process of being a bugfix
needs to be vetted beyond what's permitted for not-yet-released versions.
To get the ball rolling, I have a candidate for discussion.
Very late in the 3.0 process (after
On the one hand, it is an API change or new feature because people can
(if they choose) access the dbm directly. OTOH, it is basically a
performance fix for shelves whose API won't change at all. The part that is
visible
and incompatible is that 3.0.1 shelves won't be readable by 3.0.0.
A couple additional thoughts FWIW:
* whichdb() selects from multiple file formats, so 3.0.1 would still
be able to read 3.0.0 files. It is the 2.x shelves that won't be
readable at all under any scenario.
* If you're thinking that shelves have very few users and that
3.0.0 has had few
Along the lines of what others have said: pprint() cannot consume an
unknown iterator.
Perhaps so. It's nice to have printing be free of side-effects (other than
the actual printing).
I've been working with 3.0 daily for several months (on a book project)
and mostly think it's great. But
[Guido van Rossum]
Sorry, not convinced.
No worries. Py3.1 is not far off.
Just so I'm clear. Are you thinking that 3.0.x will never have
fast shelves, or are you thinking 3.0.2 or 3.0.3 after some
external deployment and battle-testing for the module?
Raymond
[Scott David Daniels]
Comparison of three cases (including performance rations):
MB/S MB/SMB/S
in C in py3k in 2.7 C/3k 2.7/3k
** Text append **
10M write 1e6 units at a time261.00 218.000 1540.000
[Adam Olsen]
It'd also help if the file repr gave the encoding:
+1 from me too. That will be a big help.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
With the extensive changes in the works, Python 3.0.1 is shaping-up to be a complete rerelease of 3.0 with API changes and major
usability fixes. It will fully supplant the original 3.0 release which was hobbled by poor IO performance.
I propose to make the new release more attractive by
From: Guido van Rossum gu...@python.org
In that case, I recommend just releasing it as 3.1. I had always
anticipated a 3.1 release much sooner than the typical release
schedule.
That is great idea. It's a strong cue that there is
a somewhat major break with 3.0 (removed functions,
API fixes,
From: Martin v. Löwis mar...@v.loewis.de
Releasing 3.1 6 months after 3.0 sounds reasonable; I don't think
it should be released earlier (else 3.0 looks fairly ridiculous).
I think it should be released earlier and completely supplant 3.0
before more third-party developers spend time migrating
[Guido van Rossum]
My only thought is that whatever you do, target Python 3.1, not 3.0.1.
Of course.
Do you have any thoughts on the most useful display format?
What do you want to see from pprint(mydict.items())?
Raymond
___
Python-Dev
[Benjamin Peterson]
It seems like we are arguing over the version number of basically the
same thing. I would like to see 3.0.1 released in early February for
nearly the reasons you name. However, it seems to me that there are
two kinds of issues: those like __cmp__ removal and some silly IO
[Martin]
I would fear that than 3.1 gets the same fate as 3.0. In May, we will
all think what piece of junk was that 3.1 release, let's put it to
history, and replace it with 3.2. By then, users will wonder if there
is ever a 3.x release that is any good.
I thought the gist of Guido's idea
If something gets left in 3.0.1 and then ripped-out in 3.1, I think we're
doing more harm than good. Very little code has been ported to 3.0
so far. One there is a base, all changes become more difficult.
In the interests of our users, I vote for sooner than later.
Also, 3.0 is a special case
[Matthew Wilkes]
I didn't know 3.0 is considered a broken release, but teething
troubles are to be expected. Knowing this, I would be reluctant to
use 3.0.1, it sounds like too small a change.
Not to worry. Many of the major language features are stable
and many of the rough edges are
practice to introduce oneself when posting the first
time, so: Hello, my name is Konrad, I'm an IT student and I'm
following python-dev for some time, but never posted before.
Hello Konrad. Welcome to python-dev.
Raymond Hettinger
___
Python-Dev mailing
I would like to deprecate some outdated functions in the operator module.
The isSequenceType(), isMappingType(), and isNumberType()
functions never worked reliably and now their
intended purpose has been largely fulfilled by
ABCs.
The isCallable() function has long been deprecated
and I think
Raymond Hettinger wrote:
Since I expect students to be among the users for the comb/perm
functions, there is some merit to keeping the API as simple as possible.
Besides, it is not hard to use the existing tool as a primitive to get to
the one you want:
def mycombinations(iterable, r_seq
[Terry Reedy]
Bottom line to me. The current notion of copyright does not work too
well with evolving, loosely collective works (which eventually become
'folklore').
I'm at a loss of why the notice needs to be there at all. AFAICT, we've
had tons of contributions from googlers and only one
[Raymond Hettinger]
I'm at a loss of why the notice needs to be there at all.
[GvR]
There's a difference between contributing a whole file and
contributing a patch. Patches do not require copyright notices. Whole
files do. This is not affected by later edits to the file.
That makes sense
Why does numbers.py say:
# Copyright 2007 Google, Inc. All Rights Reserved.
# Licensed to PSF under a Contributor Agreement.
Weren't there multiple contributors including non-google people?
Does Google want to be associated with code that
was submitted with no tests?
Do we want this
From: Brett Cannon br...@python.org
1. Why is three space indents the preferred indentation level?
I've also wondered about this. It is somewhat incovenient
when bringing in code samples from files with four space indents.
Raymond
___
Python-Dev
I have another question about doc formatting.
What controls whether section headers get urls with a custom named jump target instead of
a default name like id1?
In particular, look at the urls for:
http://docs.python.org/dev/library/collections.html#id1
versus
In particular, look at the urls for:
http://docs.python.org/dev/library/collections.html#id1 versus
http://docs.python.org/dev/library/collections.html#abcs-abstract-base-classes
I would like all of the targets to have meaningful names.
[Brett]
Not sure from a sphinx perspective, but
_PyObject_LengthHint() is specified to never fail.
If any exception occurs along the way, it returns a
default value. In the context of checking for length
hints from an iterator, this seems reasonable to me.
If you want this changed, I can use a negative return
value for other than an
If you want this changed, I can use a negative return
value for other than an attribute error, and modify
the calling code to handle the exception.
To me this isn't worth making the code slower and
more complex. But I can also see wanting to catch
a SystemError at any possible step.
It has
Martin closed a patch http://bugs.python.org/issue4933 for adding support so
that Python runs on Haiku.
The theory is that we don't want to support minority operation systems. My view is that we should support those systems to the
extent that someone like the OP is willing to maintain the
From: M.-A. Lemburg m...@egenix.com
The question to put up against this is: How often do you get
irritated by lines not being correctly indented ?
Basically never.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
Does anyone here have access to Mathematica?
I would like to know what it returns for:
In[1]:= Permutations({a, b, c}, {5})
Knowing this will help resolve a feature request
for itertools.permutations() and friends.
Thanks,
Raymond
___
Python-Dev
From: Victor Stinner victor.stin...@haypocalc.com
Why an svn account instead of just using the amazing bug tracker? Just because
there are not enough people to review/commit patches on the tracker and so
there are more and more open issues (and so more and more lost patches) :-( I
will be
BTW, 3.0 went out the door with test_binascii failing on windows.
Was surprised that some buildbot wasn't complaining.
- Original Message -
From: Antoine Pitrou [EMAIL PROTECTED]
To: python-dev@python.org
Sent: Saturday, December 06, 2008 3:15 PM
Subject: [Python-Dev] Buildbots for 2.6
Strong +1
Are the RMs on board?
- Original Message -
From: Benjamin Peterson [EMAIL PROTECTED]
To: python-dev@python.org
Sent: Saturday, December 06, 2008 3:18 PM
Subject: [Python-Dev] 3.0.1 possibilities
Since the release of 3.0, several critical issues have come to our
attention.
From: A.M. Kuchling [EMAIL PROTECTED]
I think we should also have a statement upon on python.org about
future plans: e.g.
* that there will be a Python 2.7 that will incorporate what we learn from
people trying to port,
* that 3.1 will rearrange the standard library in mostly-known ways, and
From: A.M. Kuchling [EMAIL PROTECTED]
Perhaps the statement could say something like we do not expect
most Python packages will be ported to the 3.x series until
around the time 3.1 is released in X months. (where X=12? 6?)
I would leave out any discussion of 3.1. Its content and release
2008/12/4 Raymond Hettinger [EMAIL PROTECTED]:
Also, we don't know the timing of the third-party updates.
Some may never get converted. Some may convert quickly
and easily. Someone (perhaps me) may organize a series of
funded sprints to get many of the major packages converted.
From: Paul
In concur that it is not a regression (esp for Py2.6).
OTOH, it would be nice to have -m run as expected.
It seems reasonable to me to get this working for 3.0.
Raymond
- Original Message -
From: Guido van Rossum [EMAIL PROTECTED]
To: Lisandro Dalcin [EMAIL PROTECTED]
Cc: Nick
From: Guido van Rossum [EMAIL PROTECTED]
The right thing to do with XXX comments is to read them when you're in
their vicinity, and to act when the urge becomes too strong to deal
with any one in particular. Dealing with them en masse is just asking
for a migraine.
I concur.
Raymond
I think this should be taken off of python-dev until
you have some quality measurements,
know what's going on, and have an actionable idea.
Aside from list specialization versus a general iterator
protocol, there is no fat in the min/max implementation.
It loops, it compares, it returns.
If we
Raymond Hettinger wrote:
* It will assist pypy style projects and other python implementations
when they have to build equivalents to CPython.
* Will eliminate confusion about what functions were exactly intended to
do.
* Will confer benefits similar to test driven development where
From: Doug Hellmann [EMAIL PROTECTED]
This seems like a large undertaking.
Not necessarily. It can be done incrementally, starting with things like str.split() that almost no one understands completely. It
should be put here and there where it adds some clarity.
I'm sure you're not
Background
--
In the itertools module docs, I included pure python equivalents for each of the C functions. Necessarily, some of those
equivalents are only approximate but they seem to have greatly enhanced the docs. Something similar is in the builtin docs for
any() and all(). The
[Christian Heimes]
The idea sounds great!
Are you planing to embed the pure python code in C code?
Am experimenting with a descriptor that fetches the attribute string from a separate text file. This keeps the C build from getting
fat. More importantly, it let's us write the execable
Yes, I'm looking a couple of different approaches to loading the strings.
For now though, I want to focus on the idea itself, not the implementation.
The important thing is to gather widespread support before getting into
the details of how the strings get loaded.
Raymond
- Original
[Neal Norwitz]
Should we plan to put out a final 2.5 release? If so, should we
continue to backport fixes (like Martin's removal of Alpha in
setup.py)? My preference is that we do put out a final 2.5 that has
all accumulated bug fixes. Then close the branch. That way if we put
out a security
[A.M. Kuchling]
Can you please clarify your meaning? Do you mean that
* we haven't been backporting fixes to 2.5?
Unsure. I surely have given zero attention to 2.5.
* we should wait to see if any horrible problems are reported in 2.6?
Yes. That would be a great idea.
* we need to
[Barry Warsaw]
So, we need to come up with a new release schedule for Python 3.0. My
suggestion:
15-Oct-2008 3.0 beta 4
05-Nov-2008 3.0 rc 2
19-Nov-2008 3.0 rc 3
03-Dec-2008 3.0 final
Given what still needs to be done, is this a reasonable schedule? Do
we need two more betas?
Yes to
[Steve Holden]
Of course there is also the option of treating Python 3 as a different
language, and having a Py3Pi website as well. This might not be as
wasteful as it at first seems.
It would be nice if we had a way of marking Py2.6 recipes that still
work when run through 2-to-3 and then
[Guido van Rossum]
Well, from the number of release blockers it sounds like another 3.0
beta is the right thing. For 2.6 however I believe we're much closer
to the finish line -- there aren't all those bytes/str issues to clean
up, for example! And apparently the benefit of releasing on schedule
[C. Titus Brown]
I'm happy to be told that bsddb is too much of a maintenance burden for
Python 2.6/3.0 to have -- especially since it's gone from 3.0 now ;) --
but I don't think the arguments that *it won't matter that it's not
there* have been very credible.
Not credible, not widely
I think this should be deferred to Py3.1.
This decision was not widely discussed and
I think it likely that some users will
be surprised and dismayed. The release
candidate seems to be the wrong time to
yank this out (in part because of the surprise
factor) and in part because I think the
[Barry]
I'm not going to release rc1 tonight.
Can I go ahead with some bug fixes and doc improvements
or should I wait until after Friday?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
From: [EMAIL PROTECTED]
I think it would benefit everyone if this discussion would end up with
some patches to the library documentation that documented the semantics
of super() more completely in the reference documentation and the
multiple inheritance area of the tutorial, so that when
[Michele Simionato]
Recently I have opened a blog on Artima and I am publishing a
few Python-related essays I had in store. In particular a trilogy
of papers about super. From the foreword:
In 2004 I decided to write a comprehensive paper documenting
``super`` pitfalls and traps, ...
Thanks
[Raymond]
Cooperative multiple inheritance is *not* about mixing two unrelated
parents that just happen to use the same method name but have
different semantics and were not designed to cooperate with each other.
The A-B-C-D diagrams and foo/bar methods in the examples are
deceptive because
From: Armin Ronacher [EMAIL PROTECTED]
len(ri)
4
ri.next()
4
len(ri)
3
This is the only reverse iterator with that sort of behavior.
Use the bug tracker please and assign to me.
At one time, some iterators had the ability to know
their own length and that would change as the
iterator
Further, while A**B is not so common, A**n is quite common (for
integral n, in the sense of repeated matrix multiplication). So a
matrix multiplication operator really should come with a power
operator cousin.
Which obviously should be @@ :-)
I think much of this thread is a repeat of
From: Karen Tracey
I noticed when trying out Python's 2.6b2 release that the repr of Decimal has
changed since 2.5. On 2.5:
...
quotes were used whereas on 2.6b2:
...
single quotes are used. Searching around I see this was done in r60773 with
the log message:
Fix decimal repr which
The new float.hex() is really nice. Would like to augment it with a matching float.bin() method using the same notation and
normalization and leaving all the rightmost bits as Guido suggested. I think this would help demystify floats and make it
straightforward to show exactly what is happening
From: Eric Smith [EMAIL PROTECTED]
I have this ready for checkin (with docs and tests). I'd like to get it
in for this beta, since it does involved changed behavior, no matter how
small ('1e+100' becomes '1E+100' with '%F'). But it relies on the
platform's vsnprintf to do the right thing with
From: Michael Foord [EMAIL PROTECTED]
I assume this doesn't rule out the addition of [some of..] the new
convenience test methods?
In Kent Beck's book on Test Driven Development, he complains that most
unittest implementations spawned from his original work have grown far
too complicated and
If some people want to proceed down the path of useful additions,
I challenge them to think bigger. Give me some test methods that
improve my life. Don't give me thirty ways to spell something I can
already do.
From: Michael Foord [EMAIL PROTECTED]
I assert that... the following changes do
601 - 700 of 1337 matches
Mail list logo
