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

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

the global keyword:

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

Contents

  the global keyword: Marcin Rak <mrak@sightlineinnovation.com> - 2016-06-11 16:44 -0700
    Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-11 19:50 -0400
      Re: the global keyword: Marcin Rak <mrak@sightlineinnovation.com> - 2016-06-11 17:12 -0700
        Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-11 21:27 -0400
      Re: the global keyword: Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-11 20:15 -0700
        Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-12 14:46 -0400
    Re: the global keyword: MRAB <python@mrabarnett.plus.com> - 2016-06-12 01:09 +0100
      Re: the global keyword: Marcin Rak <mrak@sightlineinnovation.com> - 2016-06-11 17:13 -0700
        Re: the global keyword: Ned Batchelder <ned@nedbatchelder.com> - 2016-06-11 20:41 -0700
    Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-11 21:26 -0400
      Re: the global keyword: Steven D'Aprano <steve@pearwood.info> - 2016-06-12 13:38 +1000
        Re: the global keyword: Ned Batchelder <ned@nedbatchelder.com> - 2016-06-11 20:48 -0700
          Re: the global keyword: Marcin Rak <mrak@sightlineinnovation.com> - 2016-06-12 11:31 -0700
    Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-12 20:07 +0100
      Re: the global keyword: Ned Batchelder <ned@nedbatchelder.com> - 2016-06-12 12:25 -0700
        Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-12 22:10 +0100
          Re: the global keyword: Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-19 16:35 +0200
            Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-19 22:20 +0100
              Re: the global keyword: Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-20 13:14 +0200
                Re: the global keyword: Steven D'Aprano <steve@pearwood.info> - 2016-06-20 22:15 +1000
                  Re: the global keyword: Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-20 15:04 +0200
                  Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-20 09:29 -0400
                    Re: the global keyword: Steven D'Aprano <steve@pearwood.info> - 2016-06-21 00:53 +1000
                      Re: the global keyword: Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-21 10:08 +0200
                        Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-21 11:41 +0100
                          Re: the global keyword: Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-21 13:01 +0200
          Re: the global keyword: Joel Goldstick <joel.goldstick@gmail.com> - 2016-06-19 13:16 -0400
            Re: the global keyword: Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-19 22:50 -0700
            Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-20 11:21 +0100
              Re: the global keyword: Steven D'Aprano <steve@pearwood.info> - 2016-06-20 22:03 +1000
      Re: the global keyword: Rick Johnson <rantingrickjohnson@gmail.com> - 2016-06-21 10:04 -0700
        Re: the global keyword: Random832 <random832@fastmail.com> - 2016-06-21 13:15 -0400
          Re: the global keyword: Rick Johnson <rantingrickjohnson@gmail.com> - 2016-06-21 15:20 -0700
            Re: the global keyword: Chris Angelico <rosuav@gmail.com> - 2016-06-22 08:32 +1000
              Re: the global keyword: Rick Johnson <rantingrickjohnson@gmail.com> - 2016-06-21 16:43 -0700
            Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-22 00:15 +0100
              Re: the global keyword: Rick Johnson <rantingrickjohnson@gmail.com> - 2016-06-21 17:24 -0700
                Re: the global keyword: BartC <bc@freeuk.com> - 2016-06-22 10:24 +0100
                  Re: the global keyword: Steven D'Aprano <steve@pearwood.info> - 2016-06-24 11:00 +1000
                    Re: the global keyword: Chris Angelico <rosuav@gmail.com> - 2016-06-24 11:19 +1000
                    Re: the global keyword: eryk sun <eryksun@gmail.com> - 2016-06-24 02:19 +0000
            Re: the global keyword: Rick Johnson <rantingrickjohnson@gmail.com> - 2016-06-21 16:50 -0700

Page 1 of 3  [1] 2 3  Next page →

#109827 — the global keyword:

Hi to all.

I have the following file named Solver.py:
*****************************************
from Test import some_function, my_print
from Test import test_var

some_function()
my_print()
print(test_var)
*****************************************

and I have the following Test.py:
*****************************************
test_var = 5

def some_function():
    global test_var
    test_var = 44
    print("f {0}".format(test_var))

def my_print():
    print(test_var)
*****************************************

Would you believe it that when I run Solver.py I get the following output:
f 44
44
5

So my question is, how the heck is it possible that I get 5 as the last value printed? the global test_var (global to Test.py) I set to 44 when I ran some_function()???  does anyone have a clue they could throw my way?

Much thanks

[toc] | [next] | [standalone]

#109828

On Sat, Jun 11, 2016, at 19:44, Marcin Rak wrote:
> So my question is, how the heck is it possible that I get 5 as the last
> value printed? the global test_var (global to Test.py) I set to 44 when I
> ran some_function()???  does anyone have a clue they could throw my way?

Importing a variable from a module copies its value into your own
module's variable. Updates to the source module's variable will not be
reflected in your module.

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

#109830

On Saturday, 11 June 2016 18:51:11 UTC-5, Random832  wrote:
> On Sat, Jun 11, 2016, at 19:44, Marcin Rak wrote:
> > So my question is, how the heck is it possible that I get 5 as the last
> > value printed? the global test_var (global to Test.py) I set to 44 when I
> > ran some_function()???  does anyone have a clue they could throw my way?
> 
> Importing a variable from a module copies its value into your own
> module's variable. Updates to the source module's variable will not be
> reflected in your module.

As I suspected.  Nice to have it confirmed.  
So it copies any imported variable that is of simple type (string, int, float...)
What about variables that are user defined classes?  Are they referenced or copied?

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

#109834

On Sat, Jun 11, 2016, at 20:12, Marcin Rak wrote:
> What about variables that are user defined classes?  Are they referenced
> or copied?

It will reference the same object, but if the variable is reassigned in
the original module it will still not update the imported variable.

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

#109836

On Sunday, June 12, 2016 at 11:51:11 AM UTC+12, Random832 wrote:
> Importing a variable from a module copies its value into your own
> module's variable.

Every name in Python is a variable, and can be assigned to to change its value at any time.

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

#109864

On Sat, Jun 11, 2016, at 23:15, Lawrence D’Oliveiro wrote:
> On Sunday, June 12, 2016 at 11:51:11 AM UTC+12, Random832 wrote:
> > Importing a variable from a module copies its value into your own
> > module's variable.
> 
> Every name in Python is a variable, and can be assigned to to change its
> value at any time.

Sure, but that doesn't really help explain this situation, since your
statement doesn't make clear the fact that by importing foo.a into bar
you are really merely assigning to bar.a rather than having continuous
access to foo.a, unlike how importing things works in static languages.

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

#109829

On 2016-06-12 00:50, Random832 wrote:
> On Sat, Jun 11, 2016, at 19:44, Marcin Rak wrote:
>> So my question is, how the heck is it possible that I get 5 as the last
>> value printed? the global test_var (global to Test.py) I set to 44 when I
>> ran some_function()???  does anyone have a clue they could throw my way?
>
> Importing a variable from a module copies its value into your own
> module's variable. Updates to the source module's variable will not be
> reflected in your module.
>
Not true. Importing doesn't copy the value.

Importing a name creates a new name in the local scope that refers to 
the same object that the imported name referred to.

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

#109831

On Saturday, 11 June 2016 19:09:29 UTC-5, MRAB  wrote:
> On 2016-06-12 00:50, Random832 wrote:
> > On Sat, Jun 11, 2016, at 19:44, Marcin Rak wrote:
> >> So my question is, how the heck is it possible that I get 5 as the last
> >> value printed? the global test_var (global to Test.py) I set to 44 when I
> >> ran some_function()???  does anyone have a clue they could throw my way?
> >
> > Importing a variable from a module copies its value into your own
> > module's variable. Updates to the source module's variable will not be
> > reflected in your module.
> >
> Not true. Importing doesn't copy the value.
> 
> Importing a name creates a new name in the local scope that refers to 
> the same object that the imported name referred to.

If that's the case, how is it that I get 5 for test_var???

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

#109838

On Saturday, June 11, 2016 at 8:13:50 PM UTC-4, Marcin Rak wrote:
> On Saturday, 11 June 2016 19:09:29 UTC-5, MRAB  wrote:
> > On 2016-06-12 00:50, Random832 wrote:
> > > On Sat, Jun 11, 2016, at 19:44, Marcin Rak wrote:
> > >> So my question is, how the heck is it possible that I get 5 as the last
> > >> value printed? the global test_var (global to Test.py) I set to 44 when I
> > >> ran some_function()???  does anyone have a clue they could throw my way?
> > >
> > > Importing a variable from a module copies its value into your own
> > > module's variable. Updates to the source module's variable will not be
> > > reflected in your module.
> > >
> > Not true. Importing doesn't copy the value.
> > 
> > Importing a name creates a new name in the local scope that refers to 
> > the same object that the imported name referred to.
> 
> If that's the case, how is it that I get 5 for test_var???

Assignment makes a name refer to a value:

    x = 12        # Now x refers to 12

More than one name can refer to a value:

    x = 12
    y = x         # Now x and y both refer to 12

Re-assigning one name doesn't affect other names referring to 
the old value:

    x = 12
    y = x
    x = 24        # Now x refers to 24, and y still refers to 12

Each module has its own globals (this makes the name "global" a bit
of a misnomer.  Importing a name from a module is an assignment
statement in disguise, and each module has its own names:

    # Test.py
    test_var = 5

    # Solver.py
    from Test import test_var
        # This import is effectively:
        #    Solver.test_var = Test.test_var
        #
        # Now Test.test_var and Solver.test_var both refer to 5

Reassigning one name doesn't affect other names referring to
the old value:

    # Test.py
        global test_var
        test_var = 44 
            # Test.test_var refers to 44
            # Solver.test_var still refers to 5

After all of your code is run, the test_var in Solver.py is still 5.

A longer explanation is at http://bit.ly/pynames1 that may help.

--Ned.

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

#109833

On Sat, Jun 11, 2016, at 20:09, MRAB wrote:
> Not true. Importing doesn't copy the value.
> 
> Importing a name creates a new name in the local scope that refers to 
> the same object that the imported name referred to.

Yes, the value of a variable is a reference to an object. Can we not
have another round of this right now?

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

#109837

On Sun, 12 Jun 2016 11:26 am, Random832 wrote:

> On Sat, Jun 11, 2016, at 20:09, MRAB wrote:
>> Not true. Importing doesn't copy the value.
>> 
>> Importing a name creates a new name in the local scope that refers to
>> the same object that the imported name referred to.

MRAB is correct here.


> Yes, the value of a variable is a reference to an object. Can we not
> have another round of this right now?

Sure, if you stop spreading misinformation about variables in Python and
cease the insanity of claiming that the value of a variable is not the
value you assign to it, but some invisible, unreachable "reference".

x = 999

The value of x is 999, not some invisible reference.

x = []

The value of x is an empty list, not some invisible reference.




-- 
Steven

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

#109839

On Saturday, June 11, 2016 at 11:38:33 PM UTC-4, Steven D'Aprano wrote:
> On Sun, 12 Jun 2016 11:26 am, Random832 wrote:
> 
> > On Sat, Jun 11, 2016, at 20:09, MRAB wrote:
> >> Not true. Importing doesn't copy the value.
> >> 
> >> Importing a name creates a new name in the local scope that refers to
> >> the same object that the imported name referred to.
> 
> MRAB is correct here.
> 
> 
> > Yes, the value of a variable is a reference to an object. Can we not
> > have another round of this right now?
> 
> Sure, if you stop spreading misinformation about variables in Python and
> cease the insanity of claiming that the value of a variable is not the
> value you assign to it, but some invisible, unreachable "reference".
> 
> x = 999
> 
> The value of x is 999, not some invisible reference.
> 
> x = []
> 
> The value of x is an empty list, not some invisible reference.

We just went through all this.  It's clear to me that there are different
ways of looking at these underlying mechanisms, and different people find
truth in different ways of describing them.  The virtual world we live in
is complex because of the differing levels of abstraction that are possible.
Some of this disagreement is really a matter of choosing different
abstractions to focus on.

Most importantly, it's clear to me that we aren't going to come to some
simple consensus, certainly not by throwing around words like "insanity."

Perhaps at least in this thread we can limit ourselves to addressing the
OP and their question directly, rather than fighting with each other over
which answer is correct?

--Ned.

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

#109863

Much thanks to all for their time, but Ned in particular...I learned something new about Python!!

On Saturday, 11 June 2016 22:48:32 UTC-5, Ned Batchelder  wrote:
> On Saturday, June 11, 2016 at 11:38:33 PM UTC-4, Steven D'Aprano wrote:
> > On Sun, 12 Jun 2016 11:26 am, Random832 wrote:
> > 
> > > On Sat, Jun 11, 2016, at 20:09, MRAB wrote:
> > >> Not true. Importing doesn't copy the value.
> > >> 
> > >> Importing a name creates a new name in the local scope that refers to
> > >> the same object that the imported name referred to.
> > 
> > MRAB is correct here.
> > 
> > 
> > > Yes, the value of a variable is a reference to an object. Can we not
> > > have another round of this right now?
> > 
> > Sure, if you stop spreading misinformation about variables in Python and
> > cease the insanity of claiming that the value of a variable is not the
> > value you assign to it, but some invisible, unreachable "reference".
> > 
> > x = 999
> > 
> > The value of x is 999, not some invisible reference.
> > 
> > x = []
> > 
> > The value of x is an empty list, not some invisible reference.
> 
> We just went through all this.  It's clear to me that there are different
> ways of looking at these underlying mechanisms, and different people find
> truth in different ways of describing them.  The virtual world we live in
> is complex because of the differing levels of abstraction that are possible.
> Some of this disagreement is really a matter of choosing different
> abstractions to focus on.
> 
> Most importantly, it's clear to me that we aren't going to come to some
> simple consensus, certainly not by throwing around words like "insanity."
> 
> Perhaps at least in this thread we can limit ourselves to addressing the
> OP and their question directly, rather than fighting with each other over
> which answer is correct?
> 
> --Ned.

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

#109868

On 12/06/2016 00:44, Marcin Rak wrote:
> Hi to all.
>
> I have the following file named Solver.py:
> *****************************************
> from Test import some_function, my_print
> from Test import test_var
>
> some_function()
> my_print()
> print(test_var)
> *****************************************
>
> and I have the following Test.py:
> *****************************************
> test_var = 5
>
> def some_function():
>     global test_var
>     test_var = 44
>     print("f {0}".format(test_var))
>
> def my_print():
>     print(test_var)
> *****************************************
>
> Would you believe it that when I run Solver.py I get the following output:
> f 44
> 44
> 5
>
> So my question is, how the heck is it possible that I get 5 as the last value printed? the global test_var (global to Test.py) I set to 44 when I ran some_function()???  does anyone have a clue they could throw my way?

I was puzzled too. Apparently importing stuff using 'from':

  from Test import a,b,c

is equivalent to:

  import Test

  a = Test.a
  b = Test.b
  c = Test.c

which I hadn't been aware of. Then the link between a and Test.a (eg. 
Test.test_var) is broken (unless Test.a is something like a list so both 
still refer to the same data. But assignment to either - not an in-place 
mod - will break the connection).

Your code could be rewritten as:

from Test import some_function, my_print
import Test

some_function()
my_print()
print(Test.test_var)


Anyway, it shows Python doesn't have true cross-module globals.

-- 
Bartc

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

#109871

On Sunday, June 12, 2016 at 3:08:01 PM UTC-4, BartC wrote:
> On 12/06/2016 00:44, Marcin Rak wrote:
> > Hi to all.
> >
> > I have the following file named Solver.py:
> > *****************************************
> > from Test import some_function, my_print
> > from Test import test_var
> >
> > some_function()
> > my_print()
> > print(test_var)
> > *****************************************
> >
> > and I have the following Test.py:
> > *****************************************
> > test_var = 5
> >
> > def some_function():
> >     global test_var
> >     test_var = 44
> >     print("f {0}".format(test_var))
> >
> > def my_print():
> >     print(test_var)
> > *****************************************
> >
> > Would you believe it that when I run Solver.py I get the following output:
> > f 44
> > 44
> > 5
> >
> > So my question is, how the heck is it possible that I get 5 as the last value printed? the global test_var (global to Test.py) I set to 44 when I ran some_function()???  does anyone have a clue they could throw my way?
> 
> I was puzzled too. Apparently importing stuff using 'from':
> 
>   from Test import a,b,c
> 
> is equivalent to:
> 
>   import Test
> 
>   a = Test.a
>   b = Test.b
>   c = Test.c
> 
> which I hadn't been aware of. Then the link between a and Test.a (eg. 
> Test.test_var) is broken (unless Test.a is something like a list so both 
> still refer to the same data. But assignment to either - not an in-place 
> mod - will break the connection).

Just to clarify: there is no link directly between a and Test.a, except that
both refer to the same object.  Just as here there is no link between x
and y:

    x = 12
    y = x

As I explained elsewhere in this thread, import statements behave exactly
like assignments.  The same reasoning that applies to multiple variables
referring to integers applies to multiple names being imported across
modules.

--Ned.

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

#109873

On 12/06/2016 20:25, Ned Batchelder wrote:
> On Sunday, June 12, 2016 at 3:08:01 PM UTC-4, BartC wrote:
>> On 12/06/2016 00:44, Marcin Rak wrote:

>>> from Test import some_function, my_print
>>> from Test import test_var
>>>
>>> some_function()
>>> my_print()
>>> print(test_var)
>>> *****************************************
>>>
>>> and I have the following Test.py:
>>> *****************************************
>>> test_var = 5

>>   from Test import a,b,c
>>
>> is equivalent to:
>>
>>   import Test
>>
>>   a = Test.a
>>   b = Test.b
>>   c = Test.c
>>
>> which I hadn't been aware of. Then the link between a and Test.a (eg.
>> Test.test_var) is broken (unless Test.a is something like a list so both
>> still refer to the same data. But assignment to either - not an in-place
>> mod - will break the connection).
>
> Just to clarify: there is no link directly between a and Test.a, except that
> both refer to the same object.

OK, but I meant the link there have been if 'a' was in fact a synonym 
for Test.a.

   Just as here there is no link between x
> and y:
>
>     x = 12
>     y = x

(And that's a good illustration of why 'y' isn't a name reference to 
'x', referring to the "...ducks limp" thread. But best not to rake it up 
again...)

-- 
bartc

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

#110144

Op 12-06-16 om 23:10 schreef BartC:
> On 12/06/2016 20:25, Ned Batchelder wrote:
>>   Just as here there is no link between x
>> and y:
>>
>>     x = 12
>>     y = x
> 
> (And that's a good illustration of why 'y' isn't a name reference to 'x', referring to the "...ducks limp" thread. But best not to rake it up again...)
> 
I find this rather inaccurate reference to what your opposition is
supposed to have states together with the remark best not to rake
this up again, rather disingenuous

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

#110155

On 19/06/2016 15:35, Antoon Pardon wrote:
> Op 12-06-16 om 23:10 schreef BartC:
>> On 12/06/2016 20:25, Ned Batchelder wrote:
>>>   Just as here there is no link between x
>>> and y:
>>>
>>>     x = 12
>>>     y = x
>>
>> (And that's a good illustration of why 'y' isn't a name reference to 'x', referring to the "...ducks limp" thread. But best not to rake it up again...)
>>
> I find this rather inaccurate reference to what your opposition is
> supposed to have states together with the remark best not to rake
> this up again, rather disingenuous
>


Sorry, haven't been able to parse that.

What is inaccurate? What am I supposed to be opposed to? And why is it 
disingenuous? The original thread is still open to posts AFAIK if 
someone wants to discuss it further.


-- 
bartc

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

#110191

Op 19-06-16 om 23:20 schreef BartC:
> On 19/06/2016 15:35, Antoon Pardon wrote:
>> Op 12-06-16 om 23:10 schreef BartC:
>>> On 12/06/2016 20:25, Ned Batchelder wrote:
>>>>   Just as here there is no link between x
>>>> and y:
>>>>
>>>>     x = 12
>>>>     y = x
>>>
>>> (And that's a good illustration of why 'y' isn't a name reference to
>>> 'x', referring to the "...ducks limp" thread. But best not to rake
>>> it up again...)
>>>
>> I find this rather inaccurate reference to what your opposition is
>> supposed to have states together with the remark best not to rake
>> this up again, rather disingenuous
>>
>
>
> Sorry, haven't been able to parse that.
>
> What is inaccurate? What am I supposed to be opposed to? And why is it
> disingenuous? The original thread is still open to posts AFAIK if
> someone wants to discuss it further.

You are denying a position above. So you oppose the position being denied.
However noone defended the position you denied. So denying a position here
and thus suggesting there are people who defend that position is inaccurate.

And it is disingenuous to inaccurately mention others people's position and
then to try to screen yourself off from reactions by ending with: "Best not
to rake it up again."

-- 
Antoon Pardon 

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

#110193

On Mon, 20 Jun 2016 09:14 pm, Antoon Pardon wrote:

> Op 19-06-16 om 23:20 schreef BartC:
>> On 19/06/2016 15:35, Antoon Pardon wrote:
>>> Op 12-06-16 om 23:10 schreef BartC:
>>>> On 12/06/2016 20:25, Ned Batchelder wrote:
>>>>>   Just as here there is no link between x
>>>>> and y:
>>>>>
>>>>>     x = 12
>>>>>     y = x
>>>>
>>>> (And that's a good illustration of why 'y' isn't a name reference to
>>>> 'x', referring to the "...ducks limp" thread. But best not to rake
>>>> it up again...)
>>>>
>>> I find this rather inaccurate reference to what your opposition is
>>> supposed to have states together with the remark best not to rake
>>> this up again, rather disingenuous
>>>
>>
>>
>> Sorry, haven't been able to parse that.
>>
>> What is inaccurate? What am I supposed to be opposed to? And why is it
>> disingenuous? The original thread is still open to posts AFAIK if
>> someone wants to discuss it further.
> 
> You are denying a position above. So you oppose the position being denied.
> However noone defended the position you denied. 

I'm sorry Antoon, Bart only paid for the ten minute argument.

Bart didn't say anyone had defended it. He made an observation:

"that's a good illustration of why 'y' isn't a name reference to 'x'"

which is factually correct. And this does refer to the "ducks limp" thread.
Nothing he said was wrong or objectionable, and he didn't imply that anyone
was taking the opposite position.


> So denying a position here 
> and thus suggesting there are people who defend that position is
> inaccurate.

There's no "and thus" here. Sometimes people make observations and share
them with the group. You'll notice that I'm taking a position here, but I'm
not accusing you or anyone else of taking the contrary position
(namely "nobody ever makes observations and shares them with the group").


> And it is disingenuous to inaccurately mention others people's position

Bart did not mention anyone's position, accurately or inaccurately.


> and then to try to screen yourself off from reactions by ending with:
> "Best not to rake it up again."


-- 
Steven

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web