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

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

Re: Why no warnings when re-assigning builtin names?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-15 23:15 +0100
    Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-16 11:32 +1000
      Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-15 23:23 -0400
        Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-16 15:15 +1000
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 10:13 -0400
            Re: Why no warnings when re-assigning builtin names? rantingrick <rantingrick@gmail.com> - 2011-08-16 08:44 -0700
              Re: Why no warnings when re-assigning builtin names? Andrew Berg <bahamutzero8825@gmail.com> - 2011-08-16 12:23 -0500
          Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-16 16:12 +0100
          Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-16 08:41 -0700
            Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-16 17:11 +0000
              Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-16 10:48 -0700
              Re: Why no warnings when re-assigning builtin names? Tim Chase <python.list@tim.thechases.com> - 2011-08-16 13:34 -0500
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 11:31 -0400
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 11:38 -0400
          Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-16 09:19 -0700
            Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-16 17:11 +0000
              Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-16 10:43 -0700
                Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-16 18:56 +0000
                  Re: Why no warnings when re-assigning builtin names? Terry Reedy <tjreedy@udel.edu> - 2011-08-16 19:32 -0400
                    Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-16 23:49 +0000
                      Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-17 01:02 +0100
                        Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 01:35 +0000
                          Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-17 08:27 +0100
                            Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 16:33 +0000
                      Re: Why no warnings when re-assigning builtin names? Terry Reedy <tjreedy@udel.edu> - 2011-08-16 22:10 -0400
              Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-16 19:23 +0100
          Re: Why no warnings when re-assigning builtin names? Tim Chase <python.list@tim.thechases.com> - 2011-08-16 11:10 -0500
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 12:32 -0400
            Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-17 11:29 +1000
              Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 22:16 -0400
          Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-16 10:07 -0700
          Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-16 17:11 +0000
            Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-17 10:58 +1000
              Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 03:17 +0000
                Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-17 18:15 +1000
                  Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 16:33 +0000
                    Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-17 10:36 -0700
                      Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 17:36 +0000
                        Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-17 11:13 -0700
                          Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 18:09 +0000
                    Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-17 18:42 +0100
                      Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 17:38 +0000
                        Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-17 19:02 +0100
                    Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-18 10:36 +1000
              Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-17 08:34 +0100
          RE: Why no warnings when re-assigning builtin names? "Gerrat Rickert" <grickert@coldstorage.com> - 2011-08-16 13:15 -0400
          Re: Why no warnings when re-assigning builtin names? Terry Reedy <tjreedy@udel.edu> - 2011-08-16 19:29 -0400
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 20:18 -0400
          Re: Why no warnings when re-assigning builtin names? Terry Reedy <tjreedy@udel.edu> - 2011-08-16 22:15 -0400
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 22:51 -0400
          RE: Why no warnings when re-assigning builtin names? "Gerrat Rickert" <grickert@coldstorage.com> - 2011-08-17 09:30 -0400
      Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-16 09:16 +0100
    Re: Why no warnings when re-assigning builtin names? Chris Torek <nospam@torek.net> - 2011-08-31 21:30 +0000
      Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-31 21:57 +0000

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

#11704

On Wed, Aug 17, 2011 at 5:33 PM, Seebs <usenet-nospam@seebs.net> wrote:
> If it's such a bad thing, *why is it allowed*?  Why are you proud of the
> ability to do something that you are never socially-allowed to do?
>

Going back to my original three examples:

> 1) Deliberate shadowing because you want to change the behavior of the
> name. Extremely rare.
> 2) Shadowing simply by using the name of an unusual builtin (like
> 'file') in a context where you never use it. Very common.
> 3) Unintentional shadowing where you create a variable, but then
> intend to use the builtin. This is the only one that's a problem.

All three are allowed, but it's the first one that's considered
unusual. The second one is simply that Python doesn't have a million
and one reserved words. Yes, you probably don't want to use 'print' as
a variable name, but shadowing it with an exact equivalent would be
fine (eg to automatically date-stamp or log your output, without
changing your code). And as described above, using list/str/id etc is
not uncommon.

I greatly prefer this to the alternative, which is another 133
reserved words (based on Python 3.2 for Windows).

ChrisA

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

#11705

On 2011-08-17, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Aug 17, 2011 at 5:33 PM, Seebs <usenet-nospam@seebs.net> wrote:
>> If it's such a bad thing, *why is it allowed*? ?Why are you proud of the
>> ability to do something that you are never socially-allowed to do?

> Going back to my original three examples:

I may have been unclear about jumping topics; that comment was about
monkey-patching, not about shadowing.

> I greatly prefer this to the alternative, which is another 133
> reserved words (based on Python 3.2 for Windows).

You have a point there.

I guess I'm just used to the assumption that the confusion caused by
shadowing names outweighs the benefits of using them -- the world is rich
with plausible names.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#11707

On Wed, Aug 17, 2011 at 6:38 PM, Seebs <usenet-nospam@seebs.net> wrote:
> I may have been unclear about jumping topics; that comment was about
> monkey-patching, not about shadowing.
>

Ah, apologies.

Monkey-patching is a way of using the middle of a stack of code
without using what's below it. If everything is statically linked,
then every function does exactly what it was written to do and no
more; if it accepts a file object as an argument, you could give it
some other file-like object, but that's all. However, if the function
was written to use print() and you don't want it to print to the
screen, what do you do? Obviously it's your responsibility to ensure
that your replacement is 100% equivalent in the required
functionality, but it's a great flexibility to simply change the
meaning of "print"; the alternative is to copy and paste the code,
make one change (or even no change at all, if your replacement print()
is a global), and run that.

As Ethan posted while I was typing this, you're allowed to do it, but
you just need to have a good reason for it. I like to explain/justify
myself in comments when these things crop up in my code.

ChrisA

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

#11731

Seebs wrote:

> On 2011-08-17, Steven D'Aprano <steve+comp.lang.python@pearwood.info>
> wrote:

>> Fortunately, while we are proud of having that ability, actually *using*
>> it is considered a mortal sin. We're not Ruby developers -- if you
>> actually monkey-patch something, especially built-ins, you can expect to
>> be taken outside and slapped around with a fish if you get caught.
> 
> Okay, so.
> 
> Here's what I don't get.
> 
> If it's such a bad thing, *why is it allowed*?  Why are you proud of the
> ability to do something that you are never socially-allowed to do?

Why does any language allow monkey-patching? Because:

(1) it is a consequence of a clean language design that doesn't special case
things unless absolutely necessary -- monkey-patching wasn't added to the
language, it just emerged given the basic language design;

(2) consequently it isn't some special technique, it is just a special name
given to ordinary, humdrum, everyday things like name-binding within a
namespace;

(3) and yet it is a powerful and useful ability that lets you extend both
the language and libraries (yours or third party) while still writing very
clean code;

(4) it's also pretty cool that you can do these things; and most importantly

(5) all of the above.


Even if we shouldn't (ab)use it in production, it is still greatly useful
for quick and dirty scripts, testing, experimentation and debugging.

And sometimes monkey-patches end up in production. For example, the standard
library site.py file adds help() and quit() commands to builtins at
startup. Or you might grab an instance of some third-party class, and
dynamically adding a method or an attribute to it. Why bother sub-classing
it?

There's a scene in James Clavell's "Shogun" which is relevant. Toranaga, the
Japanese warlord, discovers that the Englishman John Blackthorne has
betrayed his rightful ruler. Blackthorne protests that there are mitigating
circumstances. Toranaga says that there can never be any mitigating
circumstances for disloyalty to one's liege-lord.

Blackthorne replies that there is one: if you win.

The same applies for monkey-patching and other dangerous techniques. There
can be no excuse for doing something like that in production... unless it
is better than the alternatives.


[...]
> It sounds to me like Python is very proud of having a feature which no
> one would ever use.  ... Why?

Don't get me wrong, there are plenty of people who would give up Python's
extreme dynamicism is a heartbeat, if it were up to them. It does play
havoc with the ability to optimise Python code, and is one of the reasons
why CPython isn't as fast as (say) Lua. But the PyPy people are well on the
way to blunting that criticism, with a fast, effective JIT optimising
compiler that will be fast in the common case and no worse off in the rare
times that built-in functions have been shadowed or modified.

(PyPy is already about twice as fast as CPython, and in a few carefully
crafted examples faster than C code.)



-- 
Steven

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

#11663

On Wed, Aug 17, 2011 at 1:58 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> My thoughts would be:
>> 1.  It's hard to avoid shadowing anything unless you know the entire
>> language and never forget things.
>
> Define the "entire language". Does that include the names of all the
> plethora of exceptions? How about the standard library?

The shadowing issue applies to the standard library as well as the
builtins, so yes; to avoid shadowing *anything*, you would have to
know the entire language. I posit that this is a practical
impossibility, and that unexpected shadowing will always be possible
(and won't always be prevented by syntax highlighting). Some day
you'll discover that you can't use module X because you have a
function called X, and you'll have to rename.

ChrisA

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

#11586

> On Aug 16, 2011, at 1:15 AM, Steven D'Aprano wrote:
...
> A warning that is off by default won't help the people who need it,
> because
> they don't know enough to turn the warning on. A warning that is on by
> default will be helpful to the newbie programmer for the first week or
> so,
> and then will be nothing but an annoyance for the rest of their
career.
> 

I think that best practices would suggest that one shouldn't use
variable 
names that shadow builtins (except in specific, special circumstances), 
so I don't really think this would be an annoyance at all.  The number
of
*unwanted* warnings they'd get would be pretty close to zero.  OTOH, in 
response to a question I asked on StackOverflow, someone posted a large 
list of times where this isn't followed in the std lib, so there seems 
to be a precedent for just using the builtin names for anything 
one feels like at the time.

Thinking about it, what about if, by default, python was configured to
emit warnings about this sort of thing, but a simple environment
variable
or config option would turn them off.  That way, new users would get
warnings
when doing this sort of thing, and any experienced user that wanted the
option
of using these variables anywhere would just have a one-time thing to
change 
when they installed python (or any time later).  They'd turn these
warnings off
when they installed Python, and would never have to think about it
again.  New 
users (or experienced ones that prefer this) would be warned by default,

and then could make the conscious decision to shadow the builtin names, 
instead of accidentally doing it.

All the suggestions to just use a linter aren't helpful, since 
new users aren't likely to start with one & and they are the thrust 
of this discussion.  

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

#11621

On 8/16/2011 1:15 PM, Gerrat Rickert wrote:

> I think that best practices would suggest that one shouldn't use
> variable
> names that shadow builtins (except in specific, special circumstances),
> so I don't really think this would be an annoyance at all.  The number
> of
> *unwanted* warnings they'd get would be pretty close to zero.  OTOH, in
> response to a question I asked on StackOverflow, someone posted a large
> list of times where this isn't followed in the std lib, so there seems
> to be a precedent for just using the builtin names for anything
> one feels like at the time.

If you run across that again and email me the link, I will take a look 
and see if I think the issue should be raised on pydev. Of course, some 
modules *intentionally* define an open function, intended to be accessed 
as 'mod.open' and not as 'from mod import *; open'. Also, class/instance 
attributes can also reuse builtin names. But 'open = <True/False>' would 
be bad.


-- 
Terry Jan Reedy

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

#11633

On Aug 16, 2011, at 7:29 PM, Terry Reedy wrote:

> On 8/16/2011 1:15 PM, Gerrat Rickert wrote:
> 
>> I think that best practices would suggest that one shouldn't use
>> variable
>> names that shadow builtins (except in specific, special circumstances),
>> so I don't really think this would be an annoyance at all.  The number
>> of
>> *unwanted* warnings they'd get would be pretty close to zero.  OTOH, in
>> response to a question I asked on StackOverflow, someone posted a large
>> list of times where this isn't followed in the std lib, so there seems
>> to be a precedent for just using the builtin names for anything
>> one feels like at the time.
> 
> If you run across that again and email me the link, I will take a look and see if I think the issue should be raised on pydev. Of course, some modules *intentionally* define an open function, intended to be accessed as 'mod.open' and not as 'from mod import *; open'. Also, class/instance attributes can also reuse builtin names. But 'open = <True/False>' would be bad.


Hi Terry,
To generalize from your example, are you saying that there's a mild admonition against shadowing builtins with unrelated variable names in standard lib code?

Here's an example from Python 3.2.1's argparse.py, lines 466-473. "open" is shadowed on the second line.

        # clean up separators for mutually exclusive groups
        open = r'[\[(]'
        close = r'[\])]'
        text = _re.sub(r'(%s) ' % open, r'\1', text)
        text = _re.sub(r' (%s)' % close, r'\1', text)
        text = _re.sub(r'%s *%s' % (open, close), r'', text)
        text = _re.sub(r'\(([^|]*)\)', r'\1', text)
        text = text.strip()


Thanks
Philip

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

#11651

On 8/16/2011 8:18 PM, Philip Semanchuk wrote:

> Hi Terry,
> To generalize from your example, are you saying that there's a mild admonition
 > against shadowing builtins with unrelated variable names in standard 
lib code?

I would expect that there might be. I would have to check PEP8.

> Here's an example from Python 3.2.1's argparse.py, lines 466-473.
 > "open" is shadowed on the second line.
>
>          # clean up separators for mutually exclusive groups
>          open = r'[\[(]'
>          close = r'[\])]'
>          text = _re.sub(r'(%s) ' % open, r'\1', text)
>          text = _re.sub(r' (%s)' % close, r'\1', text)
>          text = _re.sub(r'%s *%s' % (open, close), r'', text)
>          text = _re.sub(r'\(([^|]*)\)', r'\1', text)
>          text = text.strip()

-- 
Terry Jan Reedy

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

#11652

On Aug 16, 2011, at 10:15 PM, Terry Reedy wrote:

> On 8/16/2011 8:18 PM, Philip Semanchuk wrote:
> 
>> Hi Terry,
>> To generalize from your example, are you saying that there's a mild admonition
> > against shadowing builtins with unrelated variable names in standard lib code?
> 
> I would expect that there might be. I would have to check PEP8.


I was curious, so I checked. I didn't see anything specifically referring to builtins. This is as close as it gets:

"If a function argument's name clashes with a reserved keyword, it is generally better to append a single trailing underscore rather than use an abbreviation or spelling corruption.  Thus "print_" is better than "prnt".  (Perhaps better is to avoid such clashes by using a synonym.)"


bye
Philip

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

#11684

> On 8/16/2011 7:29 PM, Terry Reedy wrote:
> 
> On 8/16/2011 1:15 PM, Gerrat Rickert wrote:
> 
> > I think that best practices would suggest that one shouldn't use
> > variable
> > names that shadow builtins (except in specific, special
> circumstances),
> > so I don't really think this would be an annoyance at all.  The
> number
> > of
> > *unwanted* warnings they'd get would be pretty close to zero.  OTOH,
> in
> > response to a question I asked on StackOverflow, someone posted a
> large
> > list of times where this isn't followed in the std lib, so there
> seems
> > to be a precedent for just using the builtin names for anything
> > one feels like at the time.
> 
> If you run across that again and email me the link, I will take a look
> and see if I think the issue should be raised on pydev. Of course, some
> modules *intentionally* define an open function, intended to be
> accessed
> as 'mod.open' and not as 'from mod import *; open'. Also,
> class/instance
> attributes can also reuse builtin names. But 'open = <True/False>'
> would
> be bad.
> 
> 
> --
> Terry Jan Reedy
> 

See the accepted answer to this question:
http://stackoverflow.com/questions/7079519/is-there-python-code-in-the-python-standard-library-that-uses-variable-names-that

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

#11527

On Tue, Aug 16, 2011 at 2:32 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 16 Aug 2011 08:15 am Chris Angelico wrote:
>
>> It's actually masking, not reassigning. That may make it easier or
>> harder to resolve the issue.
>
> The usual term is "shadowing builtins", and it's a feature, not a bug :)

Sorry, shadowing. And yeah, that's why I said that "fixing" this
"issue" was the domain of linting scripts.

ChrisA

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

#12526

(I realize this thread is old.  I have been away for a few weeks.
I read through the whole thread, though, and did not see anyone
bring up this one particular point: there is already a linting
script that handles this.)

>On Mon, Aug 15, 2011 at 10:52 PM, Gerrat Rickert
><grickert@coldstorage.com> wrote:
>> With surprising regularity, I see program postings (eg. on StackOverflow)
>> from inexperienced Python users accidentally re-assigning built-in names.
>>
>> For example, they'll innocently call some variable, `list', and assign a
>> list of items to it.

In article <mailman.22.1313446504.27778.python-list@python.org>
Chris Angelico  <rosuav@gmail.com> wrote:
>It's actually masking, not reassigning. That may make it easier or
>harder to resolve the issue.
>
>If you want a future directive that deals with it, I'd do it the other
>way - from __future__ import mask_builtin_warning or something - so
>the default remains as it currently is. But this may be a better job
>for a linting script.

The pylint program already does this:

    $ cat shado.py
    "module doc"
    def func(list):
        "func doc"
        return list
    $ pylint shado.py
    ************* Module shado
    W0622:  2:func: Redefining built-in 'list'
    ...
    Your code has been rated at 6.67/10

If your shadowing is done on purpose, you can put in a pylint
comment directive to suppress the warning.

Pylint is the American Express Card of Python coding: "don't leave
$HOME without it!" :-)
-- 
In-Real-Life: Chris Torek, Wind River Systems
Intel require I note that my opinions are not those of WRS or Intel
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)      http://web.torek.net/torek/index.html

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

#12528

On 2011-08-31, Chris Torek <nospam@torek.net> wrote:
> (I realize this thread is old.  I have been away for a few weeks.
> I read through the whole thread, though, and did not see anyone
> bring up this one particular point: there is already a linting
> script that handles this.)

Yes.  I've found pylint... A weird mix of "very helpful, thanks" and
"oh, come off it".  A thread about pylint is where I got my example of
the natural Python way to express a parabola:
	theValueRepresentingTheYAxisLocationOfThePoint = 
		theValueRepresentingTheXAxisLocationOfThe Point *
		theValueRepresentingTheXAxisLocationOfThe Point

I still say that there are times when short names are natural and
idiomatic, and much clearer than long names.  :P

But I do think that, given the basic assumption that pylint is a core
tool for vetting code, it is probably adequate for it to provide the
warnings.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [standalone]

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

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

csiph-web