On Wed, Jul 9, 2014 at 4:43 PM, Steven D'Aprano wrote:
> I don't understand this. You've just shown an example from Python 2 where
> 'in' uses 'is'. How is that a Python 3 change?
A docs change.
https://docs.python.org/2/reference/expressions.html#not-in
"""
For the list and tuple types, x in y
On Wed, 09 Jul 2014 00:57:03 -0400, Terry Reedy wrote:
> On 7/8/2014 8:10 PM, Steven D'Aprano wrote:
>
>> There's no force of law that requires Python to enforce reflexivity on
>> values where reflexivity does not apply,
>
> There are laws of logic that make the lack of reflexivity obnoxious whe
Robin Becker writes:
> I have the following from some production machines when trying to
> clone / pull etc etc using mercurial on ubuntu 10.04
>
> hg clone https://myhost/myrepos
> abort: error: _ssl.c:480: error:0D0C50A1:asn1 encoding
> routines:ASN1_item_verify:unknown message digest algorithm
Ian Kelly wrote:
well, jumping off the cliff could easily be your best chance. ;)
Especially if you have a friend with a TARDIS.
Or you're James Bond, in which case you ski off the
cliff and then open your parachute.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On 7/8/2014 8:10 PM, Steven D'Aprano wrote:
There's no force of law that requires Python to enforce reflexivity on
values where reflexivity does not apply,
There are laws of logic that make the lack of reflexivity obnoxious when
putting objects in collections. Python evaded the problem, at le
On Wed, 09 Jul 2014 00:21:22 +0100, Mark Lawrence wrote:
> This can lead to unforeseen circumstances though
> http://en.wikipedia.org/wiki/The_Flipside_of_Dominick_Hide
I prefer this one:
http://en.wikipedia.org/wiki/Roswell_That_Ends_Well
--
https://mail.python.org/mailman/listinfo/python-
Steven D'Aprano writes:
> On Tue, 08 Jul 2014 11:22:25 +1000, Ben Finney wrote:
>
> > A group of (a particular amount of) U+0020 characters is visually
> > indistinguishable from a U+0009 character, when the default semantics
> > are applied to each.
>
> Hmmm. I'm not sure there actually *is* suc
On Tue, Jul 8, 2014 at 12:19 PM, candide wrote:
> http://www.infoworld.com/d/application-development/python-bumps-java-top-learning-language-245774
As a sort of nano-celebration, here's a blast from Python's past (May, 1997):
https://web.archive.org/web/19970501011626/http://www.python.org/
--
h
In article ,
Tim Chase wrote:
> On 2014-07-09 01:24, Chris Angelico wrote:
> > On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase
> > > Okay, EOF is the canonical way to tell a program reading stdin
> > > that you're done. It just happens that EOF ^D on *nix-likes and
> > > ^Z on Win32. :-)
> > >
> > >
On Tue, 08 Jul 2014 13:57:30 -0600, Ian Kelly wrote:
Decimal(2) == Fraction(2)
> False
>
> I'm not sure exactly when this bug was fixed, but it works as expected
> in 3.4.0.
It isn't a bug, it's a missing feature. The problem is that in Python
2.7, neither Decimal nor Fraction are aware of
On Tue, 08 Jul 2014 16:05:45 -0600, Ian Kelly wrote:
> On Tue, Jul 8, 2014 at 3:53 PM, Ian Kelly wrote:
>> On Tue, Jul 8, 2014 at 2:10 PM, Anders J. Munch <2...@jmunch.dk> wrote:
>>> Steven D'Aprano wrote:
- Keeping reflexivity for NANs would have implied some pretty nasty
things, e.
On Tue, 08 Jul 2014 13:50:06 -0600, Ian Kelly wrote:
> The math module functions raise exceptions instead of returning NaN.
That's not the only way that NANs can be constructed. In particular, the
OP is collecting NANs from some other device. I don't know how it ends up
with NANs, but it does,
On Tue, 08 Jul 2014 21:02:09 +0200, Anders J. Munch wrote:
> Steven D'Aprano wrote:
>> Oh, you've read the IEEE-754 standard, and that's what it says? "We're
>> going to specify this behaviour for NANs just to annoy people" perhaps?
> I was referring to the deliberate choice to enforce IEEE-754 ru
pyt...@bdurham.com writes:
> Looking for your opinions on how you name your functions and
> methods. Example: I have a function that hashes a file. I could
> name this function hash_file() or file_hash().
I'd prefer just ‘hash’. The function name can be considered an action
verb, with its argumen
On 07/08/2014 02:04 AM, Steven D'Aprano wrote:
On Tue, 08 Jul 2014 09:48:08 +0100, Mark Lawrence wrote:
A GIL-less Python? See
http://morepypy.blogspot.co.uk/2014/07/pypy-stm-first-interesting-
release.html
Both Jython and IronPython are GIL-less, and have been forever.
Yeah, but one requi
On 08/07/2014 23:07, Ian Kelly wrote:
On Tue, Jul 8, 2014 at 4:03 PM, Ethan Furman wrote:
On 07/08/2014 11:54 AM, Anders J. Munch wrote:
If a standard tells you to jump of a cliff...
because a bunch of tanks are chasing you down, there's water at the bottom,
and not a helicopter in sight.
On Tue, Jul 8, 2014 at 4:03 PM, Ethan Furman wrote:
> On 07/08/2014 11:54 AM, Anders J. Munch wrote:
>>
>>
>> If a standard tells you to jump of a cliff...
>
>
> because a bunch of tanks are chasing you down, there's water at the bottom,
> and not a helicopter in sight...
>
> well, jumping off the
On Tue, Jul 8, 2014 at 3:53 PM, Ian Kelly wrote:
> On Tue, Jul 8, 2014 at 2:10 PM, Anders J. Munch <2...@jmunch.dk> wrote:
>> Steven D'Aprano wrote:
>>> - Keeping reflexivity for NANs would have implied some pretty nasty
>>>things, e.g. if log(-3) == log(-5), then -3 == -5.
>>
>>
> log(-3)
On 07/08/2014 11:54 AM, Anders J. Munch wrote:
If a standard tells you to jump of a cliff...
because a bunch of tanks are chasing you down, there's water at the bottom, and
not a helicopter in sight...
well, jumping off the cliff could easily be your best chance. ;)
--
~Ethan~
--
https://m
On Tue, Jul 8, 2014 at 2:10 PM, Anders J. Munch <2...@jmunch.dk> wrote:
> Steven D'Aprano wrote:
>> - Keeping reflexivity for NANs would have implied some pretty nasty
>>things, e.g. if log(-3) == log(-5), then -3 == -5.
>
>
log(-3)
> Traceback (most recent call last):
> File "", line 1, i
Steven D'Aprano wrote:
- Dropping reflexivity preserves the useful property that NANs compare
unequal to everything.
Please present an example from real life where that turned out useful, and earn
yourself a beer!
I've only experienced examples to the contrary.
- Keeping reflexivity for
On 07/08/2014 12:50 PM, Ian Kelly wrote:
On Tue, Jul 8, 2014 at 1:16 PM, Ethan Furman wrote:
What you said is: "They just don't appear in normal computation, because the
interpreter raises an exception instead."
I just ran a calculation that created a NaN, the same as 4 - 3 creates a 1,
and n
On Tue, Jul 8, 2014 at 12:54 PM, Anders J. Munch <2...@jmunch.dk> wrote:
>
> Ian Kelly wrote:
>>
>> As far as I know nothing changed between 2.4 and 2.7 in this regard.
>> Python has always had NaN compare unequal to everything, per the
>> standard.
>
> It might have been platform-specific in 2.4.
On Tue, Jul 8, 2014 at 1:16 PM, Ethan Furman wrote:
> What you said is: "They just don't appear in normal computation, because the
>
> interpreter raises an exception instead."
>
> I just ran a calculation that created a NaN, the same as 4 - 3 creates a 1,
> and no exception was raised.
>
> Do you
On 07/08/2014 12:04 PM, Anders J. Munch wrote:
Ethan Furman skrev:
What exception? Apparently your claims about NaN in Python are all wrong --
have you been using a custom interpreter?
>>> float('inf') - float('inf')
nan
If you deliberately try to manufacture NaN's, you can. I never said oth
I wrote:
Steven D'Aprano wrote:
Oh, you've read the IEEE-754 standard, and that's what it says? "We're going
to specify this behaviour for NANs just to annoy people" perhaps?
I was referring to the deliberate choice to enforce IEEE-754 rules in Python.
There is no force of law that requires Py
> On Wed, May 21, 2014 at 3:17 AM, Roland Plüss wrote:
>> The important part are the last two lines. An important module is
>> lacking the __builtins__ dictionary member so I had to add it.
>>
>> Hopefully this works also in Py3 should I switch some time later. But I
>> guess it should seeing how
http://www.infoworld.com/d/application-development/python-bumps-java-top-learning-language-245774
--
https://mail.python.org/mailman/listinfo/python-list
Den 14-07-08 19:23, Skip Montanaro skrev:
In addition to what others have written, I will add one thing. There
are certainly situations where raising an exception is bad. Consider
all the people in the scientific computing community doing fancy
linear algebra sorts of things, often with missing
Ethan Furman skrev:
What exception? Apparently your claims about NaN in Python are all wrong --
have you been using a custom interpreter?
>>> float('inf') - float('inf')
nan
If you deliberately try to manufacture NaN's, you can. I never said otherwise.
regards, Anders
--
https://mail.python.o
Steven D'Aprano wrote:
Oh, you've read the IEEE-754 standard, and that's what it says? "We're going
to specify this behaviour for NANs just to annoy people" perhaps?
I was referring to the deliberate choice to enforce IEEE-754 rules in Python.
There is no force of law that requires Python to do
Ian Kelly wrote:
As far as I know nothing changed between 2.4 and 2.7 in this regard.
Python has always had NaN compare unequal to everything, per the
standard.
It might have been platform-specific in 2.4.
Okay, here's your problem: there isn't just one binary representation
for NaN.
I'm full
On Wed, Jul 9, 2014 at 4:29 AM, Anders J. Munch <2...@jmunch.dk> wrote:
> Chris Angelico wrote:
>> For hash keys, float object identity will successfully look them up:
>
>
> Except you can't expect to rely on object identity in most interesting
> cases.
>
x = float('nan')
import struct
>>
Chris Angelico wrote:
Why *should* all NaNs be equal to each other? You said on the other
list that NaN==NaN was equivalent to (2+2)==(1+3), but that assumes
that NaN is a single "thing".
I don't actually care if all NaN bitpatterns are in the same equivalence group
or if each bitpattern is i
On 8 July 2014 15:59, wrote:
>
> Looking for your opinions on how you name your functions and methods.
> Example: I have a function that hashes a file. I could name this function
> hash_file() or file_hash(). The 1st naming convention sounds more natural,
> the 2nd naming convention allows one
On Tue, 08 Jul 2014 19:16:53 +0300, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Why *should* all NaNs be equal to each other?
>
> I appreciate why you can't say NaN is equal to NaN. However, shouldn't
> the very comparison attempt trigger an arithmetic exception?
No. Why should it? It's not
On Tue, 08 Jul 2014 20:31:25 +0300, Marko Rauhamaa wrote:
> Thus, dict operations never test NaN == NaN
You're assuming that there is only one NAN instance. That is not correct:
py> a = float('nan')
py> b = float('nan')
py> a is b
False
py> a in {b: None}
False
--
Steven
--
https://mail.pyt
On 07/08/2014 07:53 AM, Anders J. Munch wrote:
>
Most people don't need to deal with NaN's in Python at all,
fortunately. They just don't appear in normal computation, because the
interpreter raises an exception instead.
What exception? Apparently your claims about NaN in Python are all
wrong
On Wed, Jul 9, 2014 at 3:54 AM, Chris Angelico wrote:
class X:
> def __eq__(self, other):
> if self is other:
> print("Comparing against self - I am me!")
> return True
> print("Comparing against",other,"-",id(other))
> return False
> de
On Wed, Jul 9, 2014 at 3:31 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> I'd say it would surprise people rather a lot if operations like dict
>> insertion/lookup could trigger arithmetic exceptions. :)
>
> That wouldn't trigger exceptions.
>
> Dict operations do an "is" test before an "==" t
>>> import numpy
>>> a1 = numpy.ones(5)
>>> a1
array([ 1., 1., 1., 1., 1.])
>>> a0 = numpy.zeros(5)
>>> a0
array([ 0., 0., 0., 0., 0.])
>>> a1 / a0
__main__:1: RuntimeWarning: divide by zero encountered in true_divide
array([ inf, inf, inf, inf, inf])
>>> nans = numpy.array([float("nan"
Skip Montanaro :
> In addition to what others have written, I will add one thing. There
> are certainly situations where raising an exception is bad. Consider
> all the people in the scientific computing community doing fancy
> linear algebra sorts of things, often with missing data. They
> genera
Chris Angelico :
> I'd say it would surprise people rather a lot if operations like dict
> insertion/lookup could trigger arithmetic exceptions. :)
That wouldn't trigger exceptions.
Dict operations do an "is" test before an "==" test. In fact, you
couldn't even use NaN as a dict key otherwise. T
On Tue, Jul 8, 2014 at 9:53 AM, Anders J. Munch <2...@jmunch.dk> wrote:
> Most people don't need to deal with NaN's in Python at all,
> fortunately. They just don't appear in normal computation, because the
> interpreter raises an exception instead.
In addition to what others have written, I will
On Wed, Jul 9, 2014 at 3:13 AM, Steven D'Aprano
wrote:
>> Now, all this bothers me. Not that I had to do some work to get stuff
>> to work in an imperfect world. No, what bothers me is that this
>> behaviour was explicitly and deliberately put in for no good reason.
>
> Oh, you've read the IEEE-
On Tue, 08 Jul 2014 16:53:47 +0200, Anders J. Munch wrote:
> Most people don't need to deal with NaN's in Python at all, fortunately.
> They just don't appear in normal computation, because the interpreter
> raises an exception instead.
>
> It happens in my work I come across them quite a lot. I'
On Wed, Jul 9, 2014 at 2:40 AM, Tim Chase wrote:
> On 2014-07-09 01:24, Chris Angelico wrote:
>> I can't think of any Windows-native programs that ask for EOF. Only
>> those which came from POSIX platforms do it. That said, though,
>> Windows doesn't tend to encourage interactive command-line prog
On 2014-07-09 01:24, Chris Angelico wrote:
> I can't think of any Windows-native programs that ask for EOF. Only
> those which came from POSIX platforms do it. That said, though,
> Windows doesn't tend to encourage interactive command-line programs
> at all, so you may as well just follow the Unix
On 2014-07-08, Tim Chase wrote:
> On 2014-07-09 01:49, Chris Angelico wrote:
>> Have you ever used COPY CON to create a binary file?
>
> No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS)
Both.
--
Jan v/d Broek
ba
On Wed, Jul 9, 2014 at 2:16 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Why *should* all NaNs be equal to each other?
>
> I appreciate why you can't say NaN is equal to NaN. However, shouldn't
> the very comparison attempt trigger an arithmetic exception? After all,
> so does a division by z
Chris Angelico :
> Why *should* all NaNs be equal to each other?
I appreciate why you can't say NaN is equal to NaN. However, shouldn't
the very comparison attempt trigger an arithmetic exception? After all,
so does a division by zero.
Marko
--
https://mail.python.org/mailman/listinfo/python-l
On Wed, Jul 9, 2014 at 1:57 AM, Tim Chase wrote:
> On 2014-07-09 01:49, Chris Angelico wrote:
>> Have you ever used COPY CON to create a binary file?
>
> No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS)
I never used a DOS version so old it had DEBUG.COM, but I used
DEBUG.EXE
On 2014-07-09 01:49, Chris Angelico wrote:
> Have you ever used COPY CON to create a binary file?
No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS)
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Jul 9, 2014 at 1:46 AM, Tim Chase wrote:
> On 2014-07-09 01:24, Chris Angelico wrote:
>> On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase
>> > Okay, EOF is the canonical way to tell a program reading stdin
>> > that you're done. It just happens that EOF ^D on *nix-likes and
>> > ^Z on Win32. :-)
On 2014-07-09 01:24, Chris Angelico wrote:
> On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase
> > Okay, EOF is the canonical way to tell a program reading stdin
> > that you're done. It just happens that EOF ^D on *nix-likes and
> > ^Z on Win32. :-)
> >
> > -tkc
>
> I can't think of any Windows-native p
On Wed, Jul 9, 2014 at 1:24 AM, Skip Montanaro wrote:
> On Tue, Jul 8, 2014 at 10:19 AM, Chris Angelico wrote:
>> For hash keys, float object identity will successfully look them up:
> d={}
> d[float("nan")]=1
> d[float("nan")]=2
> x=float("nan")
> d[x]=3
> d[x]
>> 3
>
On Tue, Jul 8, 2014 at 10:19 AM, Chris Angelico wrote:
> For hash keys, float object identity will successfully look them up:
d={}
d[float("nan")]=1
d[float("nan")]=2
x=float("nan")
d[x]=3
d[x]
> 3
d
> {nan: 1, nan: 2, nan: 3}
Neat!
S
--
https://mail.python.or
On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase wrote:
> On 2014-07-08 11:08, Terry Reedy wrote:
>> > Indeed. Ctrl-D is _the_ canonical way to tell a program that's
>> > reading stdin that your're done.
>>
>> Not on Windows.
>
> Okay, EOF is the canonical way to tell a program reading stdin that
> you'
On Tue, Jul 8, 2014 at 8:53 AM, Anders J. Munch <2...@jmunch.dk> wrote:
> And that worked fine in my Python 2.4 apps. Then I upgraded to 2.7
> and it broke. Because 2.7 goes out of it's way to ensure that NaN's
> don't compare equal to themselves.
As far as I know nothing changed between 2.4 and
On 2014-07-08 11:08, Terry Reedy wrote:
> > Indeed. Ctrl-D is _the_ canonical way to tell a program that's
> > reading stdin that your're done.
>
> Not on Windows.
Okay, EOF is the canonical way to tell a program reading stdin that
you're done. It just happens that EOF ^D on *nix-likes and ^Z
On Wed, Jul 9, 2014 at 12:53 AM, Anders J. Munch <2...@jmunch.dk> wrote:
> In the end I came up with this hack: Every time I struct.unpack'd a
> float, I check if it's a NaN, and if it is, then I replace it with a
> reference to a single, shared, "canonical" NaN. That means that
> container objects
On 7/8/2014 10:19 AM, Grant Edwards wrote:
On 2014-07-07, Gregory Ewing wrote:
Terry Reedy wrote:
Avoid EOFError. Much better, I think, is the somewhat customary
s = input("Enter something, or hit to exit")
if not s: sys.exit()
else:
I beg to differ -- on Unix, Ctrl-D *is* the customary
w
Looking for your opinions on how you name your functions and
methods. Example: I have a function that hashes a file. I could
name this function hash_file() or file_hash(). The 1st naming
convention sounds more natural, the 2nd naming convention
allows one to group related functions together by the
Most people don't need to deal with NaN's in Python at all,
fortunately. They just don't appear in normal computation, because the
interpreter raises an exception instead.
It happens in my work I come across them quite a lot. I'm writing
software that talks to embedded applications that can conta
On 7/7/2014 7:10 PM, Mark Lawrence wrote:
On 07/07/2014 23:09, Gregory Ewing wrote:
Marko Rauhamaa wrote:
with open(path) as f:
...
If the open() call is guarded against exceptions (as it usually should),
one must revert to the classic syntax:
Hmmm, maybe we could do with a with-
On 2014-07-07, Gregory Ewing wrote:
> Terry Reedy wrote:
>> Avoid EOFError. Much better, I think, is the somewhat customary
>>
>> s = input("Enter something, or hit to exit")
>> if not s: sys.exit()
>> else:
>
> I beg to differ -- on Unix, Ctrl-D *is* the customary
> way to exit from something
On Tue, Jul 8, 2014 at 9:13 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Not quite; tools like diff that put a character at the beginning of
>> the line are likely to be tab-aware,
>
> No, just tried it again: diff outputs tabs as tabs.
>
>$ diff abc def
>1,2c1,2
>< abc
>
Chris Angelico :
> Not quite; tools like diff that put a character at the beginning of
> the line are likely to be tab-aware,
No, just tried it again: diff outputs tabs as tabs.
$ diff abc def
1,2c1,2
< abc
< abc
---
> def
> def
where line 1 begi
I have the following from some production machines when trying to clone / pull
etc etc using mercurial on ubuntu 10.04
hg clone https://myhost/myrepos
abort: error: _ssl.c:480: error:0D0C50A1:asn1 encoding
routines:ASN1_item_verify:unknown message digest algorithm
I believe that _ssl.c must b
On Tue, Jul 8, 2014 at 7:00 PM, Steven D'Aprano wrote:
> Interestingly, did you know that even *closing* a file can fail?
I know that can happen with SSL sockets (which can require writing and
reading). Can't think of any situations on normal file systems where
that's true, unless the actual fail
On Tue, Jul 8, 2014 at 7:03 PM, Steven D'Aprano wrote:
> On Mon, 07 Jul 2014 14:49:56 -0400, Terry Reedy wrote:
>
>> Avoid EOFError. Much better, I think, is the somewhat customary
>>
>> s = input("Enter something, or hit to exit") if not s:
>> sys.exit()
>> else:
>
> Under many circumstances, I
On Tue, Jul 8, 2014 at 7:09 PM, Marko Rauhamaa wrote:
> The unix tradition is to let the TTY interpret the TABs. Utilities such
> as "ed", "cat", "diff" or "gcc" don't interpret or process TABs in any
> way but simply output them together with the rest of the text.
Not quite; tools like diff that
Steven D'Aprano :
> * editors don't handle tabs correctly
But you said yourself:
> I'm not sure there actually *is* such a thing as "default semantics"
> for tabs.
What is "correct" handling of ASCII TAB characters in a text file?
The unix tradition is to let the TTY interpret the TABs. Utilit
On Tue, Jul 8, 2014 at 6:48 PM, Steven D'Aprano wrote:
> If editors were to standardise on the convention "display a
> HORIZONTAL TAB character as visibly distinct from a sequence of
> spaces" (e.g. by shading the background a different colour, or overlying
> it with an arrow)
DeScribe Word Proce
On Tue, 08 Jul 2014 09:48:08 +0100, Mark Lawrence wrote:
> A GIL-less Python? See
> http://morepypy.blogspot.co.uk/2014/07/pypy-stm-first-interesting-
release.html
Both Jython and IronPython are GIL-less, and have been forever.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-li
On Tue, 08 Jul 2014 01:49:58 +0200, Alex Burke wrote:
> Hi there,
>
> While reading up on a previous thread 'open() and EOFError' I saw the
> following (with minor changes to help make my question clearer) block
> suggested as a canonical way to open files and do something:
Emphasis on "a" canon
On Mon, 07 Jul 2014 14:49:56 -0400, Terry Reedy wrote:
> Avoid EOFError. Much better, I think, is the somewhat customary
>
> s = input("Enter something, or hit to exit") if not s:
> sys.exit()
> else:
Under many circumstances, I would do exactly that. But sometimes an empty
string is valid da
On Tue, 08 Jul 2014 11:22:25 +1000, Ben Finney wrote:
> A group of (a particular amount of) U+0020 characters is visually
> indistinguishable from a U+0009 character, when the default semantics
> are applied to each.
Hmmm. I'm not sure there actually *is* such a thing as "default
semantics" for
A GIL-less Python? See
http://morepypy.blogspot.co.uk/2014/07/pypy-stm-first-interesting-release.html
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because avast! Antivir
Alex Burke :
> While reading up on a previous thread 'open() and EOFError' I saw the
> following (with minor changes to help make my question clearer) block
> suggested as a canonical way to open files and do something:
>
> try:
> f = open(path)
> except IOError:
> handle_error()
> else:
>
80 matches
Mail list logo
