that calls those
functions.
Perhaps another section for External Libraries? If you're doing serious number
crunching in Python, using NumPy is practically a requirement.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
with the DNS server, maybe they could add
wiki.python.org while they're at it :)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
it be possible for the New-style classes link to be added to the sidebar
menu for the individual version's documentation pages? Or else given its own
link on the Topic Guides page?
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
notifications work correctly, the updates would even come with automatic diffs :)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
):
x.read()
do any type checking at all?
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing
and 2.4.
I realised after posting that the exec-based hack only works for poking values
into the _current_ frame's locals, so my trick wouldn't have done what you
needed, anyway.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
function doesn't have that
association. Any code which makes use of im_class on unbound methods (even
without involving pickling)is going to have trouble with the change. (Someone
else will need to provide a real-life use case though, since I certainly don't
have one).
Regards,
Nick.
--
Nick
M.-A. Lemburg wrote:
Nick Coghlan wrote:
Guido van Rossum wrote:
What do people think? (My main motivation for this, as stated before,
is that it adds complexity without much benefit.)
I'm in favour, since it removes the an unbound method is almost like
a bare function, only not quite as useful
to PyUnicode, PyObject_Unicode's handling of subclasses of builtins
is decidedly odd:
Py class C(str):
... def __str__(self): return I am a string!
... def __unicode__(self): return I am not unicode!
...
Py c = C()
Py str(c)
'I am a string!'
Py unicode(c)
u''
Cheers,
Nick.
--
Nick Coghlan
experience)
think such a class would be beneficial in encouraging good practices?
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
example, here's how to skip the head of a zero-numbered list:
for i, item in enumerate(ABCDEF)[1:]:
print i, item
Is this idea a non-starter, or should I spend my holiday on Wednesday finishing
it off and writing the documentation and tests for it?
Regards,
Nick.
--
Nick Coghlan | [EMAIL
are easily used both from Python and as direct entries in a C API.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http
.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
, and running the long ones
only if -uall or -usubprocess are given would seem reasonable.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
.__hash__ would seem
to provide such a spelling, and allow object.__hash__ to be removed (fixing the
above bug).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http
definitions - require inheriting from ClassicClass instead. This would also have
the benefit that the elimination of defaulting to classic classes would cause a
syntax error rather than subtle changes in behaviour.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
instance at 0x00A95710, 'e', 0)
Notice that you *don't* want to use partialmethod when creating a static method.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http
. 'partialmethod' fixes that - it allows creating a
partial function which expects the next positional argument to be the first
argument to the underlying function, while remaining positional arguments are
appended as usual.
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
, for negative n
it is the index of the last argument that is locked.
An argument could be made for providing the names 'leftpartial' (fixing
left-hand arguments) and 'rightpartial' (fixing right-hand arguments) as aliases
for partial() and partial(-1) respectively.
Regards,
Nick.
--
Nick Coghlan
Samuele Pedroni wrote:
Nick Coghlan wrote:
The initial suggestion was to provide a __get__ method on partial
objects, which forces the insertion of the reference to self at the
beginning of the argument list instead of at the end:
def __get__(self, obj, type=None):
if obj is None
Python 2.5's C implementation of Decimal follow the standard numeric
coercion rules as described above?
2. Is it reasonable to class this as a bugfix and fix the Python version for
2.4.2? (2.4.1's a bit too soon for my liking)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane
would continue to function.
I didn't suggest this initially, since I didn't realise Decimal wasn't the only
class with the problem, and I'm sure messing with PyNumber_* isn't possible for
the 2.4 series :)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
.
Particularly if we actually try to find a way to make it easier to 'do the right
thing', rather than just changing Decimal.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http
it interesting that string objects share the same characteristic
of not respecting __rop__ when it is provided by another class that is not a
subclass of string.
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
.
JJL's last comment applies to me, too, naturally :)
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
Steven Bethard has put together some text to add __new__ to the list of Basic
Customisation methods in the language reference. Would one of the documentation
folks care to take a look at it?
The relevant SF tracker item is http://www.python.org/sf/1156412
Regards,
Nick.
--
Nick Coghlan
the default context that the
binary operators pick up.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
attribute).
For itemgetter, I'd like to see multiple arguments eventually map to
multi-dimensional slices (to preserve symmetry with indexing syntax).
Call it -1 for itemgetter and -0 for attrgetter.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
: On the gripping hand :)
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http
benefit me because
I would no longer have to waste time figuring out what such code was doing - it
would already be an explicit loop, or it would be using one of the standard
reductive operations.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
a
specific key function:
x = collections.OrderedDict(sorted(d.itervalues(), key=keyfunc))
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
'from':
(x from seq if f(x))
That rather breaks TOOWTDI though (since it is essentially new syntax for a for
loop). And I have other hopes for the meaning of (x from ()). . .
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
Reinhold Birkenfeld wrote:
Nick Coghlan wrote:
A utility method on function objects could simplify this:
newFunc.update_info(func)
+1. This is really good for 90% of all decorator uses. But maybe a
better name should be found, perhaps update_meta.
I like update_meta
Patch against current CVS
(first)()
value += first
# Add the elements
for item in itr:
value += item
return value
Py sum([])
0
Py seq = ([1], [2], [3])
Py sum(seq)
[1, 2, 3]
Py seq
([1], [2], [3])
Py seq = ('1', '2', '3')
Py sum(seq)
'123'
Py seq
('1', '2', '3')
Cheers,
Nick.
--
Nick Coghlan | [EMAIL
of a metadata transfer method, though,
since they're highly decorator dependent.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
Alex Martelli wrote:
On Mar 14, 2005, at 11:20, Nick Coghlan wrote:
...
Somewhat ugly, but backwards compatible:
I realize you're mostly talking semantics, not implementation, but, as
long as we're at it, could we pretty please have back the optimization
indicated by...:
It turns out
Guido van Rossum wrote:
On Tue, 15 Mar 2005 00:05:32 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
... try:
... value += first
... except TypeError:
... raise TypeError(Cannot add first element %r to initial value %r %
(first, value))
No, no, no! NO! Never catch a general exception
'.
With the above compatibility change, getting all the way back to the existing
sum() behaviour only requires changing point b. to say use zero as the initial
value
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
Phillip J. Eby wrote:
At 10:36 PM 3/15/05 +1000, Nick Coghlan wrote:
Does deciding whether or not to supply the function really need to be
dependent on whether or not a format for __signature__ has been chosen?
Um, no. Why would you think that?
Pronoun confusion. I interpreted an 'it' in your
or not supplying a string of some
description as the initial value can be legitimately translated to:
if isinstance(initial, basestring):
return initial + type(initial)().join(seq)
rather than raising the current TypeError that suggests the programmer may want
to rewrite their code.
Cheers,
Nick.
--
Nick
= iter_factory(item)
except TypeError:
yield item
else:
if depth_first:
itr = chain(walk(subitr), itr)
else:
itr = chain(itr, walk(subitr))
break
else:
break
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane
all :)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http
,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http
class additive_identity(object):
... def __add__(self, other):
... return other
...
Py sum([a] * 5, additive_identity())
'a'
This is fairly abusive of sum, though :)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
Phillip J. Eby wrote:
At 10:11 AM 3/19/05 +1000, Nick Coghlan wrote:
'Meta1' is NOT a subclass of 'Meta2', yet the exception is not thrown.
Instead, the explicitly requested metaclass has been silently replaced
with a subclass. I think the OP is justified in calling that 'suprising
Kurt B. Kaiser wrote:
Nick Coghlan [EMAIL PROTECTED] writes:
This is fairly abusive of sum, though :)
[snip Kurt's timings]
Even avoiding the object instantiation doesn't help much:
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type help, copyright, credits
6 (to 22)
16 STORE_FAST 0 (item)
3 19 JUMP_ABSOLUTE 13
22 POP_BLOCK
23 LOAD_CONST 0 (None)
26 RETURN_VALUE
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
failures left in test_grammar are those relating to
generator expressions.
I've put a patch on SF (1166879) and assigned it to Jeremy with group AST.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
interested in better access to the SF trackers, rather than CVS access, though.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
without allowing class decoration contains an important caveat: it requires that
the decorators be written to support doing that. Allowing class decoration means
any appropriate decorators can be used, unmodified, to affect classes as well as
functions.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL
as a single unit.
Anyway, I don't particularly feel the lack of class decorators, but I thought I
should mention this (perhaps small) category of non-transforming decorators as a
situation where class decoration would make more sense to me than using a metaclass.
Cheers,
Nick.
--
Nick Coghlan
AttributeError: yyy
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev
/?func=detailaid=1044089group_id=5470atid=305470
[2] http://mail.python.org/pipermail/python-dev/2004-August/047870.html
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
,
Nick.
[1] http://www.python.org/patches/
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python
.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http
a SyntaxError, so it isn't ambiguous in any way)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev
Nick Coghlan wrote:
Alternately, PEP 310 could be defined as equivalent to:
if hasattr(x, '__enter__'):
x.__enter__()
try:
try:
...
except:
if hasattr(x, '__except__'):
x.__except__(*sys.exc_info())
else
/else definition for 'with' blocks, I guess.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev
Aahz wrote:
On Sat, Apr 23, 2005, Nick Coghlan wrote:
In light of Alex's comments, I'd actually like to suggest the below as a
potential new definition for PEP 310 (making __exit__ optional, and adding
an __else__ handler):
if hasattr(x, '__enter__'):
x.__enter__()
try:
try
):
self:
return ._cache[key]
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
Shane Hathaway wrote:
Nick Coghlan wrote:
Which means finding a different name for '__else__'. Two possibilities that
occur to me are '__ok__' or '__no_except__'. The latter makes a fair
amount of sense, since I can't think of a way to refer to the thing other
than as a 'no exception' handler
Reinhold Birkenfeld wrote:
Nick Coghlan wrote:
Guido van Rossum wrote:
[snip]
- I think there's a better word than Flow, but I'll keep using it
until we find something better.
How about simply reusing Iteration (ala StopIteration)?
Pass in 'ContinueIteration' for 'continue'
Pass
()
The non-looping version of with seems to give the best of both worlds -
multipart operation can be handled by multiple with statements, and repeated use
of the same suite can be handled by nesting the with block inside iteration over
an appropriate generator.
Cheers,
Nick.
--
Nick Coghlan
the inability to get out of the loop
without exhausting the entire iterator.
I need to think about some ideas involving iterator factories, then my
objections may disappear.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
raising it.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev
I'd say 'could' rather than 'should', as it was an idle
thought, rather than something I actually consider a good idea.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http
with that, and my reservations about PEP
340 are basically gone.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
in the except clause)
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http
- if I break out of a standard
for loop before exhausting the iterator, I would expect to be able to resume the
iterator afterwards, rather than having it flushed behind my back.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
the generator should be finalised or not.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing
, myLock) as f:
for line in f:
print line.rstrip()
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
and the new
block statement, but I'm also a little concerned about incorrectly passing a
block template to a for loop.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http
to it if it
means that for l in synchronized(lock) raises an immediate error instead of
silently doing the wrong thing.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http
for lock in synchronized(mylock):
# When lock gets released is Python implementation dependent
Cheers,
Nick.
P.S. Dear lord, synchronized is an aggravating name for that function. I keep
wanting to spell it with a second letter 's', like any civilised person ;)
--
Nick Coghlan | [EMAIL
= f
yield
finally:
sys.stdout = save_stdout
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
= getcontext()
try:
setcontext(context)
yield
finally:
setcontext(old_context)
Used as follows:
block decimal.in_context(Context(prec=12)):
# Perform higher precision operations here
Cheers,
Nick.
--
Nick Coghlan | [EMAIL
,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http
construct is:
yield itr.next()
Wrapping that in StopIteration can be quite convenient, and is probably too
common to ignore - Phillip's examples reminded me that some my _own_ code uses
this trick.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
)
into a block iterator.
I think this would also do wonders for emphasising the difference between for
loops and block statements.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http
no keyword,
is perfectly acceptable. As I write, I'm finding it more and more
natural.
Same here. Especially if the semantics are tweaked so that it *is* a
straightforward statement instead of a loop.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
the appropriate __exit__() method.
You must be reading my mind or something. . .
Unless there is something in today's 80-odd messages to make it redundant, look
for a post entitled something like Minimalist PEP 340 (aka PEP 310 redux)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED
to push the try/finally into a function, then call
that function inside the loop. The introduction of block statements means that
a
number of those inner functions are likely to be handled as block statements
instead - with the above highly confusing result.
Cheers,
Nick.
--
Nick Coghlan
.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
to convince
me :)
Cheers,
Nick.
P.S. Well, assuming the flattened version is faster. . .
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
not in self.outer.exc
raise exc_type, value, traceback
@statement
def last_attempt(self):
yield None
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http
.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
:
finalisation()
I like it - I'll update the PEP redraft to use it instead of the 'del' idea.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
Nick Coghlan wrote:
The whole PEP draft can be found here:
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
I've updated this based on the feedback so far. The biggest change is that I've
dropped the 'del' idea in favour of an optional 'finally' clause on for loops
that finalises
Raymond Hettinger wrote:
[Nick Coghlan]
The number of good use cases for a looping block statement currently
stands at
exactly 1 (auto_retry). Every other use case suggested (locking,
opening,
suppressing, etc) involves factoring out try statement boiler plate
that
is far
easier
the PEP more self-contained, with significantly fewer references to PEP
340.
These changes try to take into account the feedback I got on the previous
drafts, as well as fixing a few problems I noticed myself.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http
Nick Coghlan wrote:
Draft 1.3 of my PEP 310/PEP 340 merger is now up for public consumption:
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
This draft was meant to drop the idea of __enter__() raising TerminateBlock
preventing execution of the statement body. I dropped it out
an arbitrary try statement can be converted to a statement
template.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
, then I'm happy to change it back (I think I just talked myself into
doing that, actually).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
clauses, not arbitrary exception handling. I believe he's
misinterpreting the cause of the pushback against PEP 340 (I think it was the
looping that was found objectionable, not the ability to suppress exceptions),
but *shrug* :)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED
Steven Bethard wrote:
On 5/11/05, Nick Coghlan [EMAIL PROTECTED] wrote:
The gist is that the alternative is to require an __exit__() method to raise
TerminateBlock in order to suppress an exception.
So I didn't see any examples that really needed TerminateBlock to
suppress an exception
to deal with, and allowing a different call
to potentially *suppress* those exceptions is a recipe for serious confusion.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http
1 - 100 of 6273 matches
Mail list logo
