Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #25341 > unrolled thread

Implicit conversion to boolean in if and while statements

Back to article view | Back to comp.lang.python

Contents

  Implicit conversion to boolean in if and while statements Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-15 03:34 -0500
    Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-15 10:56 +0000
      Re: Implicit conversion to boolean in if and while statements Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-15 10:19 -0600
        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-15 09:50 -0700
          Re: Implicit conversion to boolean in if and while statements Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-15 12:01 -0600
            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-15 11:56 -0700
              Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2012-07-16 07:53 +1000
                Re: Implicit conversion to boolean in if and while statements Ranting Rick <rantingrickjohnson@gmail.com> - 2012-07-15 18:21 -0700
                  Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2012-07-16 11:51 +1000
                    Re: Implicit conversion to boolean in if and while statements Ranting Rick <rantingrickjohnson@gmail.com> - 2012-07-15 19:31 -0700
                      Re: Implicit conversion to boolean in if and while statements Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-16 17:57 +0000
                        Re: Implicit conversion to boolean in if and while statements Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-17 00:44 -0400
                  Re: Implicit conversion to boolean in if and while statements Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-15 22:15 -0400
                    Re: Implicit conversion to boolean in if and while statements Ranting Rick <rantingrickjohnson@gmail.com> - 2012-07-15 19:58 -0700
                    Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-16 04:03 +0000
                      Re: Implicit conversion to boolean in if and while statements Ranting Rick <rantingrickjohnson@gmail.com> - 2012-07-15 21:53 -0700
                        Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2012-07-16 15:57 +1000
                        Re: Implicit conversion to boolean in if and while statements alex23 <wuwei23@gmail.com> - 2012-07-16 00:21 -0700
                      Re: Implicit conversion to boolean in if and while statements Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-17 00:18 -0400
                        Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-17 06:25 +0000
                          Re: Implicit conversion to boolean in if and while statements Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-17 05:38 -0400
                  Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-16 02:58 +0000
                    Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2012-07-16 13:05 +1000
                    Re: Implicit conversion to boolean in if and while statements Ranting Rick <rantingrickjohnson@gmail.com> - 2012-07-15 20:21 -0700
                      Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-16 04:20 +0000
                        Re: Implicit conversion to boolean in if and while statements Ranting Rick <rantingrickjohnson@gmail.com> - 2012-07-15 22:03 -0700
                          Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2012-07-16 16:00 +1000
                          Re: Implicit conversion to boolean in if and while statements alex23 <wuwei23@gmail.com> - 2012-07-16 00:27 -0700
                          Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-16 07:52 +0000
                          Re: Implicit conversion to boolean in if and while statements Laszlo Nagy <gandalf@shopzeus.com> - 2012-07-16 23:26 +0200
                        Re: Implicit conversion to boolean in if and while statements Laszlo Nagy <gandalf@shopzeus.com> - 2012-07-16 23:17 +0200
                    Re: Implicit conversion to boolean in if and while statements Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-16 07:30 +0100
                    Re: Implicit conversion to boolean in if and while statements Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-16 18:03 +0000
            Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-15 11:56 -0700
          Re: Implicit conversion to boolean in if and while statements Serhiy Storchaka <storchaka@gmail.com> - 2012-07-16 16:01 +0300
          Re: Implicit conversion to boolean in if and while statements rusi <rustompmody@gmail.com> - 2012-07-16 18:45 -0700
        Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-15 09:50 -0700
        Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-16 02:13 +0000
          Re: Implicit conversion to boolean in if and while statements Ranting Rick <rantingrickjohnson@gmail.com> - 2012-07-15 19:41 -0700
            Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2012-07-16 12:58 +1000
            Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-16 08:05 +0000
          Re: Implicit conversion to boolean in if and while statements Ethan Furman <ethan@stoneleaf.us> - 2012-07-16 11:13 -0700
            Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-17 06:14 +0000
      Re: Implicit conversion to boolean in if and while statements Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-15 12:02 -0500
        Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-16 02:38 +0000
          Re: Implicit conversion to boolean in if and while statements Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-16 13:28 -0400
            Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-17 01:12 +0000
              Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-17 01:13 +0000
          Re: Implicit conversion to boolean in if and while statements Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-16 15:33 -0500
          Re: Implicit conversion to boolean in if and while statements Ethan Furman <ethan@stoneleaf.us> - 2012-07-16 13:54 -0700
            Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-17 00:43 +0000
              Re: Implicit conversion to boolean in if and while statements Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-16 20:57 -0500
                Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-17 04:39 +0000
                  Re: Implicit conversion to boolean in if and while statements Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-17 00:19 -0500
                    Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-17 07:08 +0000
                      Re: Implicit conversion to boolean in if and while statements Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-17 03:23 -0500
                        Re: Implicit conversion to boolean in if and while statements alex23 <wuwei23@gmail.com> - 2012-07-17 18:35 -0700
                      Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2012-07-17 18:32 +1000
                      Re: Implicit conversion to boolean in if and while statements Laszlo Nagy <gandalf@shopzeus.com> - 2012-07-17 14:43 +0200
                      Re: Implicit conversion to boolean in if and while statements Laszlo Nagy <gandalf@shopzeus.com> - 2012-07-17 14:59 +0200
                      Re: Implicit conversion to boolean in if and while statements Terry Reedy <tjreedy@udel.edu> - 2012-07-17 13:57 -0400
                  Re: Implicit conversion to boolean in if and while statements Ethan Furman <ethan@stoneleaf.us> - 2012-07-17 05:35 -0700
              Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2012-07-17 12:13 +1000
      Re: Implicit conversion to boolean in if and while statements Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-15 12:16 -0500
      Re: Implicit conversion to boolean in if and while statements Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-15 11:45 -0600
      Re: Implicit conversion to boolean in if and while statements Terry Reedy <tjreedy@udel.edu> - 2012-07-15 16:09 -0400
      Re: Implicit conversion to boolean in if and while statements Terry Reedy <tjreedy@udel.edu> - 2012-07-15 16:28 -0400
      Re: Implicit conversion to boolean in if and while statements Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-16 20:22 -0500
        Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-17 04:11 +0000
          Re: Implicit conversion to boolean in if and while statements Ranting Rick <rantingrickjohnson@gmail.com> - 2012-07-16 21:18 -0700
            Re: Implicit conversion to boolean in if and while statements Chris Angelico <rosuav@gmail.com> - 2012-07-17 14:24 +1000
          Re: Implicit conversion to boolean in if and while statements Andrew Berg <bahamutzero8825@gmail.com> - 2012-07-16 23:44 -0500
      Re: Implicit conversion to boolean in if and while statements Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-17 04:47 +0000
    Re: Implicit conversion to boolean in if and while statements John Nagle <nagle@animats.com> - 2012-07-17 00:26 -0700

Page 4 of 4 — ← Prev page 1 2 3 [4]

#25524

On 7/17/2012 4:23 AM, Andrew Berg wrote:
> On 7/17/2012 2:08 AM, Steven D'Aprano wrote:
>> The default behaviour is that every object is something, hence true-like,
>> unless explicitly coded to be treated as false-like. Since both loggers
>> and functions are objects, they are true-like unless the default is
>> overridden.
> I am aware of the default behavior, but the reason for it still eludes me.

Ultimately, because Guido's intuition said that the current behavior is 
the best. I happen to agree on this one.

Quoting from elsewhere:
 > If it truly is about something vs. nothing, why is a NameError (or
 > AttributeError) raised when testing with an undefined variable?


Python does not have 'undefined variable' objects in the way that some 
other languages do. There is nothing to test 'with'. 'if 
undefined_name:' raises NameError because all uses of undefined_names 
other that assignments do. The actually execution order is expression 
first, then if. You can explicitly test "'some_name' in namespace" or 
"hasattr(obj, 'somename') by turning the possibly undefined name into a 
string object.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#25493

Andrew Berg wrote:
> To put it in duck-typing terms, why should everything have to quack like
> True or False? Sure, I can see why 1 quacks like True or [] quacks like
> False, but I don't see why say, a Logger or function should quack like
> either. Should a Thread object be True if it's been started and False
> otherwise?

True and False are red herrings.  It is more appropriate to think that 
True quacks like something and False like nothing than the other way 'round.

Maybe some examples from my own code will help:

DbfTable    --> True if any records in table, False otherwise

DbfIndex    --> True if any records in index, False otherwise

DbfList     --> True if any records in list, False otherwise

DbfDate     --> True if a date, False otherwise (could be eight spaces 
instead of a real date)

DbfDateTime --> True if a datetime, False otherwise

DbfRecord   --> True always

DbfRecordTemplate --> True always

DbfRecordVaporware --> False always

While I could have DbfRecord be False if, for example, it had no data 
stored in it, I have no use case for that scenario so haven't bothered. 
  Also, at this point I am using the distinction of True/False with 
regards to records to determine if I have a real record (True means a 
record/template I can read/write, False means I don't).


> If it truly is about something vs. nothing, why is a NameError (or
> AttributeError) raised when testing with an undefined variable? Being
> undefined quacks like nothing, doesn't it?

It's about /representing/ something vs. nothing. An undefined name isn't 
representing anything (except a bug, of course ;).

~Ethan~

[toc] | [prev] | [next] | [standalone]

#25452

On Tue, Jul 17, 2012 at 11:57 AM, Andrew Berg <bahamutzero8825@gmail.com> wrote:
> I could do:
>
> if has_message:
>         send('{command} {args} :{message}')
> else:
>         send('{command} {args}')
>
> but then I'd have to make sure has_message stays accurate since message
> won't necessarily be. Or maybe I could leave message undefined and catch
> the appropriate exception. However, using None is the cleanest and most
> obvious.
>
> I know Rick likes to troll, but I do agree with him that "if something:"
> for arbitrary objects can be ambiguous or confusing. I don't think
> if/while must have True or False, but not every object has an obvious
> truth value.

Using None when '' is a valid token is the right thing to do (see
also, for instance, SQL's NULL, which is often used the same way). And
then you have gone away from the language's idea of whether a string
is truthy or not, so you get explicit:

if message is not None:
   send('{command} {args} :{message}')

Easy! Or if the language went the other way ("all strings are true"),
it would be the other way around, you'd use "if message!=''" for the
other case. It's not a difficult problem.

Carry on bikeshedding. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#25360

On 7/15/2012 11:19 AM, Ian Kelly wrote:
> Ugh, that's irritating.  I can't think of any scenario where I would
> ever want the semantics "if timeval (is not midnight):".
It's not implemented with such a test, but
logging.handlers.TimedRotatingFileHandler has an option to rollover at
midnight.
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803

[toc] | [prev] | [next] | [standalone]

#25362

On Sun, Jul 15, 2012 at 11:16 AM, Andrew Berg <bahamutzero8825@gmail.com> wrote:
> On 7/15/2012 11:19 AM, Ian Kelly wrote:
>> Ugh, that's irritating.  I can't think of any scenario where I would
>> ever want the semantics "if timeval (is not midnight):".
> It's not implemented with such a test, but
> logging.handlers.TimedRotatingFileHandler has an option to rollover at
> midnight.

Nor could it be implemented with such a test, since the rollover check
would then have to run at exactly midnight for the test to evaluate
false.  If it were off by 1 microsecond, it would miss it.

[toc] | [prev] | [next] | [standalone]

#25372

On 7/15/2012 12:19 PM, Ian Kelly wrote:
> On Sun, Jul 15, 2012 at 4:56 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> (For the record, I can only think of one trap for the unwary: time
>> objects are false at *exactly* midnight.)
>
> Ugh, that's irritating.  I can't think of any scenario where I would
> ever want the semantics "if timeval (is not midnight):".  This

When printing time tables, midnight may be either 24:00 or 0:00, 
depending on whether it is the end or start of a journey. That could, of 
course, be done by explicit if time == midnight: rather than if not time:.

Whether to change the current behavior was discussed on python-ideas a 
couple of months ago. I believe inertia and back-compatibity and the 
rare use case won.

 > reinforces the point that if you only want to test whether you have
 > None, you should use "is not None" rather than relying on __bool__.

Right.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#25373

On 7/15/2012 1:02 PM, Andrew Berg wrote:
> On 7/15/2012 5:56 AM, Steven D'Aprano wrote:
>> 3) Rather than distinguishing "true" from "false", a more useful
>> dichotomy is between "something" and "nothing". Python includes a number
>> of ways of spelling "nothing" of various types, such as:
>>
>>      None, 0, 0.0, '', [], {}, set()
>>
>> and nearly everything else is "something".
> Okay, I see the value in this, but I don't understand why None has a
> truth value.

Because everything does (or should).

 > I would expect None to mean "doesn't exist" or "unknown" or
> something like that - e.g., a value of 0 means 0 jelly beans in the jar
> and None means there isn't a jar.
>
> FWIW, I have, for a reason I forget, gotten into the habit of writing
> "if x is not None" when testing for None.

If x might possibly be any other false value (as is, I think, the usual 
case), that is the right thing to do. Even if no other false value is 
possible, I would still use 'is not None' just to be clear what the 
false alternative is, and to guard against mistakes (like not knowing 
that time values can be false) or code changes that add the possibility 
of ohter false values.

> However, I have not been
> writing "if x is True: ..."/"elif x is False: ..."/"else: 'ruh-roh'"
> when testing for True (in cases where a value of True or False makes
> sense, but any other value would not). Should I?

If you only want to execute the if branch when x is literally the bool 
object True and x could be some other non-bool true value such as 1 or 
'a' or [1], etc, then you should.

If x is guaranteed to be True or False, which is the case you more or 
less proposed, then you should not. For instance, "if isinstance(x, int) 
is True:" or "if (n > 3) is True:" are redundant.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#25449

On 7/15/2012 3:28 PM, Terry Reedy wrote:
> Because everything does (or should).
I can see how truth testing for empty values is convenient, but perhaps
objects should only have a truth value if explicitly given one -
particularly in cases where such a value wouldn't be obvious or the
obvious value isn't the actual one:

>>> c = types.SimpleNamespace()
>>> if c: print('c')
...
c
>>> c.__dict__
{}

Would it not be reasonable to expect an empty namespace to have a truth
value of False since [] and friends do? It's a bit of a gray area for an
object defined by "class C: pass", but this is *specifically intended*
to be a namespace. Why should things like functions or exceptions have
truth values?

Note: For those who aren't aware, types.SimpleNamespace was added in
3.3.0b1.

On a side note, I tend to do this:

x = some_list
try:
	y = x.pop()
except IndexError:
	do_something_else()

rather than:

if x:
	y = x.pop()
else:
	do_something_else()

but of course that only applies to empty lists/sets/related and not
0/0.0/None and only when I want something from the list/set/whatever.
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803

[toc] | [prev] | [next] | [standalone]

#25453

On Mon, 16 Jul 2012 20:22:18 -0500, Andrew Berg wrote:

> On 7/15/2012 3:28 PM, Terry Reedy wrote:
>> Because everything does (or should).
> I can see how truth testing for empty values is convenient, but perhaps
> objects should only have a truth value if explicitly given one -
> particularly in cases where such a value wouldn't be obvious or the
> obvious value isn't the actual one:

You have run into Python's default behaviour: objects are treated as 
something by default. If you want them to represent nothing, you have to 
explicitly code that case.

py> o = object()
py> bool(o)
True

Yet again, thinking about something versus nothing instead of true/false 
makes the behaviour both obvious and correct: of course an object should 
be treated as something (true-like) rather than nothing (false-like) by 
default, it's an *object* is it not?

If you want your type to implement non-default semantics, such as 
container semantics, then you need to code it.


>>>> c = types.SimpleNamespace()
>>>> if c: print('c')
> ...
> c
>>>> c.__dict__
> {}
> 
> Would it not be reasonable to expect an empty namespace to have a truth
> value of False since [] and friends do? It's a bit of a gray area for an
> object defined by "class C: pass", but this is *specifically intended*
> to be a namespace. Why should things like functions or exceptions have
> truth values?

And this is a good life-lesson that any class called "SimpleFoo" will not 
stay simple for long.

If you are right that SimpleNamespace should be treated as a container, 
then it should implement container semantics. Since it doesn't, that is 
either:

1) a bug; or
2) a triumph of laziness over correctness

I imagine though that the Python dev's answer will basically be #2: "it 
isn't a container, it just behaves a little bit like a container, except 
when it doesn't" kinda thing. But feel free to report it as a bug and see 
what happens.

(This is not *entirely* wrong, because SimpleNamespace certainly doesn't 
*claim* to be a container, nor does it expose the full container API. But 
it should, even if that means it is no longer quite so simple.)



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#25454

On Jul 16, 11:11 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:

> I imagine though that the Python dev's answer will basically be #2: "it
> isn't a container, it just behaves a little bit like a container, except
> when it doesn't" kinda thing.

The emperor has no clothes!

[toc] | [prev] | [next] | [standalone]

#25456

On Tue, Jul 17, 2012 at 2:18 PM, Ranting Rick
<rantingrickjohnson@gmail.com> wrote:
> On Jul 16, 11:11 pm, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>
>> I imagine though that the Python dev's answer will basically be #2: "it
>> isn't a container, it just behaves a little bit like a container, except
>> when it doesn't" kinda thing.
>
> The emperor has no clothes!

The Troll's New Point.

ChrisA

[toc] | [prev] | [next] | [standalone]

#25459

On 7/16/2012 11:11 PM, Steven D'Aprano wrote:
> If you are right that SimpleNamespace should be treated as a container, 
> then it should implement container semantics. Since it doesn't, that is 
> either:
> 
> 1) a bug; or
> 2) a triumph of laziness over correctness
> 
> I imagine though that the Python dev's answer will basically be #2: "it 
> isn't a container, it just behaves a little bit like a container, except 
> when it doesn't" kinda thing. But feel free to report it as a bug and see 
> what happens.
I'm not saying it's necessarily wrong, but I do think it quacks a lot
like a container, even though it isn't one, especially if you're
listening for quacks instead of looking for ducks.
-- 
CPython 3.3.0b1 | Windows NT 6.1.7601.17803

[toc] | [prev] | [next] | [standalone]

#25460

On Sun, 15 Jul 2012 10:56:57 +0000, Steven D'Aprano wrote:

> On Sun, 15 Jul 2012 03:34:46 -0500, Andrew Berg wrote:
> 
>> This has probably been discussed before,
> 
> By the hoary hosts of Hoggoth, has it ever!

Dammit this topic is a tar-baby.

:(



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#25466

On 7/15/2012 1:34 AM, Andrew Berg wrote:
> This has probably been discussed before, but why is there an implicit
> conversion to a boolean in if and while statements?
>
> if not None:
> 	print('hi')
> prints 'hi' since bool(None) is False.
>
> If this was discussed in a PEP, I would like a link to it. There are so
> many PEPs, and I wouldn't know which ones to look through.
>
> Converting 0 and 1 to False and True seems reasonable, but I don't see
> the point in converting other arbitrary values.

    Because Boolean types were an afterthought in Python.  See PEP 285.
If a language starts out with a Boolean type, it tends towards
Pascal/Ada/Java semantics in this area.  If a language backs
into needing a Boolean type, as Python and C did, it tends to have
the somewhat weird semantics of a language which can't quite decide 
what's a Boolean.  C and C++ have the same problem, for exactly the
same reason - boolean types were an afterthought there, too.

					John Nagle

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.python

csiph-web