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

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

Slices time complexity

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

Contents

  Slices time complexity Mario Figueiredo <marfig@gmail.com> - 2015-05-18 20:23 +0100
    Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-19 05:36 +1000
      Re: Slices time complexity Mario Figueiredo <marfig@gmail.com> - 2015-05-18 20:49 +0100
        Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-19 06:04 +1000
    Re: Slices time complexity Todd <toddrjen@gmail.com> - 2015-05-18 21:42 +0200
    Re: Slices time complexity Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-18 13:49 -0600
      Re: Slices time complexity Fabien <fabien.maussion@gmail.com> - 2015-05-18 21:54 +0200
        Re: Slices time complexity Todd <toddrjen@gmail.com> - 2015-05-18 22:23 +0200
      Re: Slices time complexity Mario Figueiredo <marfig@gmail.com> - 2015-05-18 22:04 +0100
        Re: Slices time complexity Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-18 22:38 +0100
        Re: Slices time complexity Terry Reedy <tjreedy@udel.edu> - 2015-05-18 19:04 -0400
      Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-18 19:20 -0700
        Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 15:13 +1000
          Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-18 22:33 -0700
            Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-19 10:12 +0300
              Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 18:16 +1000
                Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-19 11:39 +0300
                  Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-19 18:50 +1000
                    Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-19 12:35 +0300
                      Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 23:44 +1000
                        Re: Slices time complexity Christian Gollwitzer <auriocus@gmx.de> - 2015-05-20 23:54 +0200
                    Re: Slices time complexity Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-19 23:00 +1200
                      Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 11:47 +1000
                        Re: Slices time complexity Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-05-20 08:07 -0400
                    Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 22:42 +1000
                      Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-19 23:24 +1000
                      Re: Slices time complexity Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-20 12:31 +1200
                        Re: Slices time complexity Ben Finney <ben+python@benfinney.id.au> - 2015-05-20 10:42 +1000
                          Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-20 07:24 +0300
                            Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 21:30 -0700
                              Re: Slices time complexity Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-20 06:06 +0100
                              Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 15:57 +1000
                                Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-20 09:17 +0300
                                Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 23:23 -0700
                                  Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-20 09:46 +0300
                                    Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-20 00:03 -0700
                                      Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-20 10:45 +0300
                                  List semantics [was Re: Slices time complexity] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 17:23 +1000
                                    Re: List semantics [was Re: Slices time complexity] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-20 20:54 +1200
                                      Re: List semantics [was Re: Slices time complexity] Ned Batchelder <ned@nedbatchelder.com> - 2015-05-20 04:08 -0700
                                      Re: List semantics [was Re: Slices time complexity] Terry Reedy <tjreedy@udel.edu> - 2015-05-20 14:42 -0400
                                        Re: List semantics [was Re: Slices time complexity] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-21 11:06 +1200
                                      Re: List semantics [was Re: Slices time complexity] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-21 12:10 +1000
                                Re: Slices time complexity "Bartc" <bartc@freeuk.com> - 2015-05-20 10:56 +0100
                                  Re: Slices time complexity Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-05-20 10:16 +0100
                                  Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-21 15:19 +1000
                                    Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-21 09:20 +0300
                                    Re: Slices time complexity bartc <bart4858@gmail.com> - 2015-05-21 06:34 -0700
                                      Re: Slices time complexity MRAB <python@mrabarnett.plus.com> - 2015-05-21 17:50 +0100
                                      Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-22 03:16 +1000
                                        Re: Slices time complexity bart4858@gmail.com - 2015-05-21 12:48 -0700
                        Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 12:26 +1000
                          Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-20 12:36 +1000
                          Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 20:02 -0700
                  Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 21:43 +1000
                    Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-19 18:59 +0300
                      Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 03:46 +1000
                        Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-20 04:12 +1000
                        Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-19 21:19 +0300
                          Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 10:43 +1000
                            Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-20 07:30 +0300
                              Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 15:33 +1000
                                Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 15:58 +1000
                  Re: Slices time complexity Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-05-19 15:18 +0100
              Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 04:46 -0700
                Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 05:14 -0700
            Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 18:19 +1000
              Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 04:41 -0700
    Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 19:45 +1000
      Re: Slices time complexity Serhiy Storchaka <storchaka@gmail.com> - 2015-05-19 13:15 +0300
      Re: Slices time complexity Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-05-19 12:09 +0100
      Re: Slices time complexity "Bartc" <bartc@freeuk.com> - 2015-05-19 15:52 +0100
        Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 03:07 +1000
          Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-20 03:19 +1000
          Re: Slices time complexity Mario Figueiredo <marfig@gmail.com> - 2015-05-20 20:51 +0100
            Re: Slices time complexity Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-20 14:33 -0600
            Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-21 06:35 +1000
            Re: Slices time complexity Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-20 21:47 +0100
              Re: Slices time complexity Mario Figueiredo <marfig@gmail.com> - 2015-05-20 22:23 +0100
            Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-21 17:35 +1000
              Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-21 18:25 +1000
      Re: Slices time complexity Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-19 09:15 -0600
      Re: Slices time complexity Serhiy Storchaka <storchaka@gmail.com> - 2015-05-19 22:51 +0300

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

#90974 — Re: List semantics [was Re: Slices time complexity]

On 5/20/2015 4:54 AM, Gregory Ewing wrote:

> At this point the student thinks, "Um... what? How
> can an object contain another object *twice*?"
> If he's still thinking in physical terms, this
> sentence is nonsensical.
>
> It gets even worse with:
>
> x = [1, 2]
> x[1] = x
>
> Now you have to say that the list contains *itself*
> in some weird Tardis-like fashion!
>
> I can't think of any way to dispel the confusion
> verbally without using some word like "reference"
> or "pointer" or something with an equivalent meaning.
> Something that suggests a level of indirectness.

Python sets and lists (and frozen versions) are like clubs.  A club 
roster contains identifiers that refer to and identify the members. 
Kids who can read and write names usually have no problem with this. The 
roster for the Recursive Club (of recursive clubs) would contain the 
identifier 'Recursive Club'.

-- 
Terry Jan Reedy

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

#90989 — Re: List semantics [was Re: Slices time complexity]

Terry Reedy wrote:
> A club 
> roster contains identifiers that refer to and identify the members.

Exactly: the roster "refers to" the members, rather
than "containing" them. Or equivalently, it contains
references to the members.

-- 
Greg

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

#90994 — Re: List semantics [was Re: Slices time complexity]

On Wed, 20 May 2015 06:54 pm, Gregory Ewing wrote:

> Steven D'Aprano wrote:
> 
>> Code snippet 1:
>> 
>>     x = [[1,2],[1,2]]
>> 
>> creates a list bound to the name "x", containing a list containing ints 1
>> and 2, and a second independent list also containing ints 1 and 2.
> 
> Using the word "contains" here is misleading, because
> it conjures a mental picture of physical containment,
> which is exactly what you *don't* want to suggest.
> 
>>     z = [1,2]
>>     y = [z, z]
>> 
>> creates a list bound to the name "z", ints 1 and 2; then it creates a
>> second list, bound to name "y", containing the first list "z" twice.
> 
> At this point the student thinks, "Um... what? How
> can an object contain another object *twice*?"
> If he's still thinking in physical terms, this
> sentence is nonsensical.
> 
> It gets even worse with:
> 
> x = [1, 2]
> x[1] = x
> 
> Now you have to say that the list contains *itself*
> in some weird Tardis-like fashion!

Yes. And why is this a problem?

This may be a bit elitist, but that's not a bad thing. As a programmer, you
will be expected to deal with many things *much more confusing* than
objects appearing in two places at once. Any child over the age of about
five is capable of understanding such things -- it's a staple of fantasy,
science fiction and cartoons.

In a virtual world, having an object in two places at once, or even
contained within itself, is *easy*.

Of course, adults knows that real-world objects cannot really be in two
places at once, except maybe in the vicinity of rapidly spinning neutron
stars, or in the realm of quantum mechanics. So there may be some students,
of an excessively literal mind, who can't get past the idea of objects
being in two places at once. For them, you can drop down a level and start
to talk about the implementation. Lists don't actually contain the items
themselves, they hold an indirect reference to the item. (You don't even
need to use the word "pointer", since pointer is a data primitive which
some implementations do not use.) You can have multiple references to the
same object, obviously. A name is such a reference: [z, z].

The point which I am trying to get across is not that talking about the
implementation of the Python virtual machine is *necessarily always* a bad
thing, but it can *and should* be carefully distinguished from the
interface to the Python virtual machine, that is, the Python language.

The Python language has no pointers. It has objects which can be in
multiple "places" (by which I mean, bound to names, contained by lists or
dicts, etc.) at once, and indeed objects can even contain themselves. As a
Python programmer, you never deal with pointers, you deal with objects, and
in the virtual world of the Python language, objects being in two places at
the same time is no more strange than objects in the real world existing in
two times at the same place.

The Python *implementation* uses pointers, C++ references, Java objects, or
whatever. Note that the implementation itself may not directly use
pointers, e.g. Java, but the *implementation of the implementation* may. If
you go down far enough, and ask how the physical hardware machine
implements pointers, you start talking about "copying memory", which
actually implemented by flipping bits.

Oh, and just for the record, it is possible to create a Python
implementation which doesn't use pointers or any form of indirect
addressing *at all*. It wouldn't be efficient, but it would be possible.
And of course there is one actually implementation of the Python virtual
machine which doesn't use any sort of conventional implementation. Any time
you simulate executing a chunk of Python code in your head, you're running
a virtual Python interpreter.


-- 
Steven

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

#90946

"Steven D'Aprano" <steve+comp.lang.python@pearwood.info> wrote in message
news:555c225b$0$2769$c3e8da3$76491128@news.astraweb.com...

> The mental gymnastics they go through to force the round peg of pass-by-
> sharing object semantics into the false dichotomy "pass-by-value versus
> pass-by-reference" is just crazy.
>
> One consequence of this is that the meaning of "call by value" depends on
> whether the value you are talking about is a boxed or unboxed value.
> Unboxed
> values are copied. Boxed values are not. Except that they are, if you
> understand that "the value" doesn't refer to the actual value, but to some
> hidden and implementation-dependent reference to the value.

I have a language where everything is boxed (the data that isn't boxed, has
to be before it can be manipulated).

But simple data such as small integers and floats are passed by value.
Bigger data is 'sort of' passed by reference, but not full reference (the
details are a bit messy, but if an object consists of two parts (A,B), then
a copy of descriptor A is passed, which contains a pointer to B. For small
scalars, the B part doesn't exist).

(A proper reference is available when passing arguments to functions:
a boxed pointer to (A,B) is constructed.)

However, I was so impressed with how (C)Python does things (working
exclusively with pointers, doing assignments by simply copying pointers, and
using reference counting to manage memory), that I'm experimenting with
letting my language work the same way. (Also then I can benchmark the two
more fairly.)

Then I get a little disillusioned when I find out in this thread that a
simple slice of an array actually copies every element! Since I currently
create a view (a good term I'd never come across before) for a slice, does
that mean I now also have to do what Python does?

(Currently, /assignments/ of arrays - and slices - involve a deep copy. But
for use as operands or passing as function arguments, only the lightweight
descriptor A is passed, the 'view' in the case of a slice.)

-- 
Bartc

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

#90947

On 20 May 2015 at 10:56, Bartc <bartc@freeuk.com> wrote:
>
> However, I was so impressed with how (C)Python does things (working
> exclusively with pointers, doing assignments by simply copying pointers, and
> using reference counting to manage memory), that I'm experimenting with
> letting my language work the same way. (Also then I can benchmark the two
> more fairly.)
>
> Then I get a little disillusioned when I find out in this thread that a
> simple slice of an array actually copies every element!

It's not an array, it's a list. Lists are often used in Python where
arrays would be used in other languages but they are not the same as
arrays in many other languages since they are not of homogeneous type.
Python has an array module but AIUI it's not used very much. Certainly
whenever I would have a use for the array module I would use numpy's
ndarray instead.

Slicing a list does not copy every element. It copies the references
to each element. The slice creates a new list (of references) rather
than referencing the original but otherwise it is a shallow copy.

> Since I currently
> create a view (a good term I'd never come across before) for a slice, does
> that mean I now also have to do what Python does?

No, creating a view is just fine if that's what you want in your
language. In CPython I use numpy's ndarray for which slices create
views. Sometimes one behaviour is useful and sometimes the other. In
practice I rarely find that list slicing is a performance bottleneck
for anything.


--
Oscar

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

#90995

On Wednesday 20 May 2015 19:56, Bartc wrote:

> "Steven D'Aprano" <steve+comp.lang.python@pearwood.info> wrote in message
> news:555c225b$0$2769$c3e8da3$76491128@news.astraweb.com...
> 
>> The mental gymnastics they go through to force the round peg of pass-by-
>> sharing object semantics into the false dichotomy "pass-by-value versus
>> pass-by-reference" is just crazy.
>>
>> One consequence of this is that the meaning of "call by value" depends on
>> whether the value you are talking about is a boxed or unboxed value.
>> Unboxed
>> values are copied. Boxed values are not. Except that they are, if you
>> understand that "the value" doesn't refer to the actual value, but to
>> some hidden and implementation-dependent reference to the value.
> 
> I have a language where everything is boxed (the data that isn't boxed,
> has to be before it can be manipulated).
> 
> But simple data such as small integers and floats are passed by value.
> Bigger data is 'sort of' passed by reference, but not full reference (the
> details are a bit messy, but if an object consists of two parts (A,B),
> then a copy of descriptor A is passed, which contains a pointer to B. For
> small scalars, the B part doesn't exist).

Sounds complicated and confusing. In my opinion, you would be better off 
picking a well-known argument passing convention (call by value, reference, 
name, sharing) and using that, always. Or at least have a simple, objective 
rule for when you swap from one convention to another, like "arrays are 
passed by reference, everything else is passed by value".

What you *shouldn't* do is implement your own argument convention, then call 
it "pass by value" if it is not the standard meaning of pass by value. Don't 
do what the Java community does, which is implement pass by sharing but call 
it pass by value. Don't do what the Ruby community does, which is implement 
pass by sharing but call it pass by reference.

Don't do what the Lua community does, which is invent a stupid distinction 
between "reference types" and "value types" so they too can misuse 
terminology:

http://stackoverflow.com/questions/6128152/lua-function-variable-scope-pass-
by-value-or-reference

Take note of the highest voted answer, by Bas Bossink, claiming that Lua 
uses pass-by-value for some values and pass-by-reference for others. He is 
wrong. Just like Python, Lua uses the same calling convention for all types, 
and it is neither pass by value nor pass by reference.

This calling convention has been known as pass by sharing (or variations of 
that, like "pass by object sharing") since it was named by Barbara Liskov in 
the 1970s, for the language CLU, but the convention itself goes back to Lisp 
in the 1950s.

Fuzzy thinking leads to confusion, error, and PHP.


> (A proper reference is available when passing arguments to functions:
> a boxed pointer to (A,B) is constructed.)
> 
> However, I was so impressed with how (C)Python does things (working
> exclusively with pointers, doing assignments by simply copying pointers,
> and using reference counting to manage memory), that I'm experimenting
> with letting my language work the same way. (Also then I can benchmark the
> two more fairly.)

Most modern application languages (as opposed to systems languages) use the 
same convention, pass by sharing. Java uses it for objects; Python, Ruby and 
Lua use it for everything. I'm *guessing* that Javascript also uses the same 
convention, but I'm not sure.

Perl, I imagine, does the most complicated thing that can possibly not 
collapse in a heap of internal self-contradiction :-)


> Then I get a little disillusioned when I find out in this thread that a
> simple slice of an array actually copies every element! Since I currently
> create a view (a good term I'd never come across before) for a slice, does
> that mean I now also have to do what Python does?

You only have to do what Python does if you wish to claim that your language 
is an implementation of Python.

Feel free to borrow slicing syntax list[start:stop:step] but return a view. 
That's what Go does. Views and copies each have their own advantages and 
disadvantages. As the designer of your own language, you get to decide which 
trade-offs your language makes.


-- 
Steve

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

#90997

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> On Wednesday 20 May 2015 19:56, Bartc wrote:
>> But simple data such as small integers and floats are passed by
>> value. Bigger data is 'sort of' passed by reference, but not full
>> reference (the details are a bit messy, but if an object consists of
>> two parts (A,B), then a copy of descriptor A is passed, which
>> contains a pointer to B. For small scalars, the B part doesn't
>> exist).
>
> Sounds complicated and confusing. In my opinion, you would be better
> off picking a well-known argument passing convention (call by value,
> reference, name, sharing) and using that, always.

I wonder if BartC refers to the conceptual model or implementation.
Elisp uses the waste bits of pointers as flags; (small) integers are
represented as fake (illegal) pointers. However, the implementation
choice is in no way visible at the Lisp level.


Marko

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

#91006

On Thursday, 21 May 2015 06:19:39 UTC+1, Steven D'Aprano  wrote:
> On Wednesday 20 May 2015 19:56, Bartc wrote:

> What you *shouldn't* do is implement your own argument convention,

(That's exactly what I did for my static language compiler which
generates x64 code. The Win64 calling convention was far too
complicated, and required 16-byte stack alignment which was another
headache. My private calling convention works fine! But I have to use the
official one for calling foreign (eg. C) functions.

This is at a lower level than the logical or language view of parameter passing, but still, you don't always have to do what everyone else does.)

> Don't do what the Lua community does, which is invent a stupid distinction 
> between "reference types" and "value types" so they too can misuse 
> terminology:

But in the mind of the user, such a distinction can be intuitive. If
I'm passing a 32-bit integer, it is easy to think of the value being
passed. With a 100 million element array, it harder to think of it being
passed by value than by reference.

> This calling convention has been known as pass by sharing (or variations of 
> that, like "pass by object sharing") since it was named by Barbara Liskov in 
> the 1970s, for the language CLU, but the convention itself goes back to Lisp 
> in the 1950s.

I looked it up expecting a new convention to solve all my problems.
But it's just a re-statement of how Python works anyway!

So a mutable object passed to a function can be changed by that function,
so that the caller sees the change. An immutable object can't be
changed in the same way, but only because Python doesn't allow it to
be modified. (But it does allow assignment to the version in the
function.)

Using what is really pass-by-reference for everything is fine, but
I'm having some trouble with making it efficient for small integer
values (I think this is a weak area of Python). Even with my clunky system
of passing descriptors, the equivalent of BINARY_ADD for two small
integers can be reduced to perhaps 10 or 12 machine instructions,
byte-code dispatch *and* double type-dispatch overheads included (using ASM that is; and technically the type-dispatching is by-passed).

If small integers need to be heap-allocated and managed, then it might need a few more. (And then Python will auto-range these to arbitrary precision as needed, another difference.)

-- 
Bartc

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

#91016

On 2015-05-21 14:34, bartc wrote:
> On Thursday, 21 May 2015 06:19:39 UTC+1, Steven D'Aprano  wrote:
>> On Wednesday 20 May 2015 19:56, Bartc wrote:
>
>> What you *shouldn't* do is implement your own argument convention,
>
> (That's exactly what I did for my static language compiler which
> generates x64 code. The Win64 calling convention was far too
> complicated, and required 16-byte stack alignment which was another
> headache. My private calling convention works fine! But I have to use
> the official one for calling foreign (eg. C) functions.
>
> This is at a lower level than the logical or language view of
> parameter passing, but still, you don't always have to do what
> everyone else does.)
>
>> Don't do what the Lua community does, which is invent a stupid
>> distinction between "reference types" and "value types" so they too
>> can misuse terminology:
>
> But in the mind of the user, such a distinction can be intuitive. If
> I'm passing a 32-bit integer, it is easy to think of the value being
> passed. With a 100 million element array, it harder to think of it
> being passed by value than by reference.
>
>> This calling convention has been known as pass by sharing (or
>> variations of that, like "pass by object sharing") since it was
>> named by Barbara Liskov in the 1970s, for the language CLU, but the
>> convention itself goes back to Lisp in the 1950s.
>
> I looked it up expecting a new convention to solve all my problems.
> But it's just a re-statement of how Python works anyway!
>
> So a mutable object passed to a function can be changed by that
> function, so that the caller sees the change. An immutable object
> can't be changed in the same way, but only because Python doesn't
> allow it to be modified. (But it does allow assignment to the version
> in the function.)
>
> Using what is really pass-by-reference for everything is fine, but
> I'm having some trouble with making it efficient for small integer
> values (I think this is a weak area of Python). Even with my clunky
> system of passing descriptors, the equivalent of BINARY_ADD for two
> small integers can be reduced to perhaps 10 or 12 machine
> instructions, byte-code dispatch *and* double type-dispatch overheads
> included (using ASM that is; and technically the type-dispatching is
> by-passed).
>
> If small integers need to be heap-allocated and managed, then it
> might need a few more. (And then Python will auto-range these to
> arbitrary precision as needed, another difference.)
>
If memory addresses aren't byte-aligned, you could use the least-
significant bit to indicate whether it's a small integer, i.e. if it's
zero, then it's an address, else shift right by 1 bit arithmetically
for the integer value.

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

#91019

On Thu, 21 May 2015 11:34 pm, bartc wrote:

> On Thursday, 21 May 2015 06:19:39 UTC+1, Steven D'Aprano  wrote:
>> On Wednesday 20 May 2015 19:56, Bartc wrote:
> 
>> What you *shouldn't* do is implement your own argument convention,
> 
> (That's exactly what I did for my static language compiler which
> generates x64 code. The Win64 calling convention was far too
> complicated, and required 16-byte stack alignment which was another
> headache. My private calling convention works fine! But I have to use the
> official one for calling foreign (eg. C) functions.

You deleted the rest of my sentence, where I said and then call it by a
standard name that it is not. If you really need your own invented calling
conventions, then I suppose you can do so, but there's really only so many
ways you can do it.


> This is at a lower level than the logical or language view of parameter
> passing, but still, you don't always have to do what everyone else does.)
> 
>> Don't do what the Lua community does, which is invent a stupid
>> distinction between "reference types" and "value types" so they too can
>> misuse terminology:
> 
> But in the mind of the user, such a distinction can be intuitive.

But it's *wrong*. When your intuition gives you the wrong answer, you need
to stop relying on "gut feelings" and *learn some facts*.

Lua has a much smaller set of types than Python, and I'm not an expert on
it, so it may be that there are so few types that you can pass around in
Lua that (wrong or not) it doesn't matter. But I doubt it.


> If 
> I'm passing a 32-bit integer, it is easy to think of the value being
> passed. With a 100 million element array, it harder to think of it being
> passed by value than by reference.

Huh? This doesn't make any sense. The value either *is* or *isn't* passed by
value. That's a property of the language, it doesn't depend on what you
think of it.

If the value is passed by value, then regardless of whether it is a 32-bit
integer or an 1GB array, the value *will be copied*. If it is not copied,
then it isn't pass by value.


>> This calling convention has been known as pass by sharing (or variations
>> of that, like "pass by object sharing") since it was named by Barbara
>> Liskov in the 1970s, for the language CLU, but the convention itself goes
>> back to Lisp in the 1950s.
> 
> I looked it up expecting a new convention to solve all my problems.
> But it's just a re-statement of how Python works anyway!

Exactly.


> So a mutable object passed to a function can be changed by that function,
> so that the caller sees the change. An immutable object can't be
> changed in the same way, but only because Python doesn't allow it to
> be modified. (But it does allow assignment to the version in the
> function.)

I don't understand what your last sentence there means. What do you
mean "the version in the function"? What do you mean by "allow assignment"?

There are three common calling conventions: by value, reference and sharing.
If you have a function with a parameter:

function func(arg)

and then call it with a named variable as argument:

x := something
result := func(x)


*all three conventions* allow assignment to arg inside func. It would be a
pretty strange language which didn't! But the *effect* of such assignment
may vary, depending on the calling convention.

In call-by-value and call-by-sharing, the parameter "arg" is local to func,
so any assignment to arg changes only the local scope, *not* the outer
scope; consequently, the global variable x does not get assigned. arg and x
merely have the same value, they aren't the same variable.

(The difference between the two is that call-by-value *copies* the value, so
in-place modifications to arg don't affect the original x; call-by-sharing
doesn't copy the value, so in-place modifications to arg does affect the
original x.)

In call-by-reference, the compiler treats the parameter "arg" as just
another way of saying "x". So assigning to arg is the same as assigning to
x: for the duration of the function call, arg and x are two names for the
same variable.

(The usual implementation of this is for the compiler to pass a pointer to
x, and then automatically dereference that pointer whenever it refers to
arg, regardless of whether arg is on the left or right of an assignment. C
does not have call-by-reference, but you can fake it by manually doing the
pointer dereferencing yourself.)

Call-by-name is a fourth technique, not common but nevertheless historically
significant. "Call by name" is a bit of misnomer, because it's really more
of call by expression, where the expression is sometimes a single name.

In call-by-name, when you call func(some expression), "some expression" is
recorded in a lightweight anonymous function (called a thunk). Then, inside
the body of func, every time you refer so the parameter name arg, that
expression is re-evaluated.



> Using what is really pass-by-reference for everything is fine, 

I'm really sure it isn't fine. You could use pass-by-reference for
everything, but if you do, you will surprise a lot of people:

def func(arg):
   arg = 1

x = 23
func(x)
assert x == 23  # this will fail

Pass-by-reference does NOT just mean "pass a reference". There's more to it
than that. This is what people don't get.



> but 
> I'm having some trouble with making it efficient for small integer
> values (I think this is a weak area of Python). 

I can imagine that pass-by-reference would be a bit tricky to implement in a
dict-based namespace language, but that has nothing to do with the size of
the value.


> Even with my clunky system 
> of passing descriptors, the equivalent of BINARY_ADD for two small
> integers can be reduced to perhaps 10 or 12 machine instructions,
> byte-code dispatch *and* double type-dispatch overheads included (using
> ASM that is; and technically the type-dispatching is by-passed).
> 
> If small integers need to be heap-allocated and managed, then it might
> need a few more. (And then Python will auto-range these to arbitrary
> precision as needed, another difference.)

Are you talking about Python or your custom language?


> 

-- 
Steven

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

#91021

On Thursday, 21 May 2015 18:16:33 UTC+1, Steven D'Aprano  wrote:
> On Thu, 21 May 2015 11:34 pm, bartc wrote:
> > On Thursday, 21 May 2015 06:19:39 UTC+1, Steven D'Aprano  wrote:

> > Using what is really pass-by-reference for everything is fine, 
> 
> I'm really sure it isn't fine. You could use pass-by-reference for
> everything, but if you do, you will surprise a lot of people:

Yes, I using the term informally (as in, 'reference count'). I meant
how CPython appears to pass data around (as Py_Object* types).

> > If small integers need to be heap-allocated and managed, then it might
> > need a few more. (And then Python will auto-range these to arbitrary
> > precision as needed, another difference.)
> 
> Are you talking about Python or your custom language?

My language, and the problems there might be in adopting the CPython
style of passing pointers around. (Another problem I've just realised
is that everything in my language is mutable: I can even change the
the bits of a small integer in-place. That will be interesting to
solve.)

(I came into this trying to investigate why CPython was so slow, I may
end up wondering how it manages to be as fast as it is!)


-- 
Bartc

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

#90914

On Wed, 20 May 2015 10:31 am, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> Chris, that is one of the best explanations for why "references equals
>> pointers" is *not* a good explanation for Python's behaviour.
> 
> Many people here seem to have lost sight of the
> fact that the word "pointer" existed in the English
> language long before C, and even long before computers.

Many people here seem to have lost sight of the fact that the
word "computer" existed in the English language long before ENIAC and
Colossus, and even before Babbage's Difference Engine.


> If I draw two boxes on a blackboard with an arrow
> between them, I think it's perfectly reasonable to
> call that arrow a pointer.

Given how rich the English language is, and how many other words people
could use (arrow, cue, finger, guide, index, indicator, lead, needle,
signpost...) but don't, I think it is quite disingenuous to claim that
people describing Python references as "pointers" mean it in the generic
sense rather than the computer science sense.

Especially when those people often explicitly state that they are
using "pointer" in order to make it easier for C programmers to understand.



-- 
Steven

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

#90917

On Wed, May 20, 2015 at 12:26 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Wed, 20 May 2015 10:31 am, Gregory Ewing wrote:
>
>> Steven D'Aprano wrote:
>>> Chris, that is one of the best explanations for why "references equals
>>> pointers" is *not* a good explanation for Python's behaviour.
>>
>> Many people here seem to have lost sight of the
>> fact that the word "pointer" existed in the English
>> language long before C, and even long before computers.
>
> Many people here seem to have lost sight of the fact that the
> word "computer" existed in the English language long before ENIAC and
> Colossus, and even before Babbage's Difference Engine.

I have a laser printer. Its address is 192.168.0.119. I also have a
laser pointer; is it equal to 192.168.0.119?

Ahh, English. So rich with equivocations.

ChrisA

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

#90919

On Wednesday, May 20, 2015 at 7:56:43 AM UTC+5:30, Steven D'Aprano wrote:
> On Wed, 20 May 2015 10:31 am, Gregory Ewing wrote:
> 
> > Steven D'Aprano wrote:
> >> Chris, that is one of the best explanations for why "references equals
> >> pointers" is *not* a good explanation for Python's behaviour.
> > 
> > Many people here seem to have lost sight of the
> > fact that the word "pointer" existed in the English
> > language long before C, and even long before computers.
> 
> Many people here seem to have lost sight of the fact that the
> word "computer" existed in the English language long before ENIAC and
> Colossus, and even before Babbage's Difference Engine.
> 
> 
> > If I draw two boxes on a blackboard with an arrow
> > between them, I think it's perfectly reasonable to
> > call that arrow a pointer.
> 
> Given how rich the English language is, and how many other words people
> could use (arrow, cue, finger, guide, index, indicator, lead, needle,
> signpost...) but don't, I think it is quite disingenuous to claim that
> people describing Python references as "pointers" mean it in the generic
> sense rather than the computer science sense.
> 
> Especially when those people often explicitly state that they are
> using "pointer" in order to make it easier for C programmers to understand.


So...

Pascal is not Niklaus Wirth's Pascal but some vague pidgin extension(s) of it.
Whereas pointer is a specific C semantics, not a broader implication from C, 
nothing connected with the general English usage.  

Playing humpty dumpty arent we?

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

#90842

On Tuesday 19 May 2015 18:39, Marko Rauhamaa wrote:

> What I'm saying is that it doesn't matter what semantic description you
> give Python constructs as long as the observed behavior is correct.

You really think that it doesn't matter which of the following two 
explanations I give for this behaviour?

x = 2
y = 3
print x+y  # prints 5

Explanation #1:

"Python adds 2 and 3 together and prints 5."

Explanation #2:

"Python takes the 2nd decimal place of pi (4), and the 3rd decimal place of 
e (8), multiplies them (32), then prints the sum of the digits (5)."

The first explanation has the advantage that it actually describes Python's 
semantic model for the + operator, and consequently it is far more likely to 
allow the user to predict the output of (say) 5+2. The second explanation 
explains the observed behaviour, but doesn't have any predictive power:

Explanation #2 continued:

"Of course Python only does that when the arguments are 2 and 3. With 
arguments 5 and 2, it takes the tenth decimal place of pi (5), the 9th 
decimal place of e**2 (8), and subtracts them from 20 (7)."

Explanations shouldn't just explain the observed behaviour. Any semi-
arbitrary collection of special cases can do that. To be useful, 
explanations ought to give the user *predictive power* -- if I calculate 
32767 + 1, what will Python do?

Explanation #1 predicts that Python will return 32768.
Explanation #2 makes no prediction at all.

Explanation #3, assuming that Python follows the same rules as C, might 
predict overflow to -32768, saturation (32767 + 1 = 32767), or "undefined 
behaviour" up to and including erasing your hard drive.

Only one of these models for Python allows you to make correct predictions, 
even though all three explain the observations given.

Having a good, consistent model for the programming language allows one to 
predict not just *what* it will do, but (in a rough and ready fashion) *how* 
it will do it. Having the *right* model allows you to predict *correctly*.


> For example, you could explain Python's object references as pointers
> (memory addresses) if you considered that helpful. (That's how Lisp
> textbooks often explain cons cells.)

Well, you could do that, but it would fail to explain the behaviour of 
Jython and IronPython.

Mixing descriptions of a specific implementation with descriptions of the 
high level semantics is sometimes useful but often misleading, and one needs 
to be careful how and when one does it.



-- 
Steve

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

#90864

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> To be useful, explanations ought to give the user *predictive power*
> -- if I calculate 32767 + 1, what will Python do?
>
> Explanation #1 predicts that Python will return 32768.
> Explanation #2 makes no prediction at all.

Any semantic ruleset that correctly predicts the behavior of any given
Python program is equally valid.

> Only one of these models for Python allows you to make correct
> predictions, even though all three explain the observations given.

You're slaying straw men.

>> For example, you could explain Python's object references as pointers
>> (memory addresses) if you considered that helpful. (That's how Lisp
>> textbooks often explain cons cells.)
>
> Well, you could do that, but it would fail to explain the behaviour of 
> Jython and IronPython.

Jython, CPython and IronPython are supposed to be semantically
equivalent. So any valid CPython model is also a valid model for Jython
and IronPython.

Coincidentally:

   The reference values (often just references) are pointers to these
   objects, and a special null reference, which refers to no object.

   <URL: https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.htm
   l#jls-4.3.1>

(without any explanation as to what a "pointer" might be).

> Mixing descriptions of a specific implementation with descriptions of
> the high level semantics is sometimes useful but often misleading, and
> one needs to be careful how and when one does it.

Nobody has proposed doing that.


Marko

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

#90882

On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> 
>> To be useful, explanations ought to give the user *predictive power*
>> -- if I calculate 32767 + 1, what will Python do?
>>
>> Explanation #1 predicts that Python will return 32768.
>> Explanation #2 makes no prediction at all.
> 
> Any semantic ruleset that correctly predicts the behavior of any given
> Python program is equally valid.

This is a more reasonable position to take than your earlier stance that the
only thing that matters is whether it explains observed behaviour. It's
still wrong, but at least it is defensible in the sense that sometimes a
ruleset which is objectively wrong but still gives the right answer might
be *preferred* over one which is objectively correct but hard to
understand.

But some rulesets may have perfect predictive power, and still be rejected:

http://star.psy.ohio-state.edu/coglab/Pictures/miracle.gif

Unlike scientific theories about the universe, where we have to hypothesise
what the rules are, we can actually look at the source code for the Python
interpreter and see exactly what the rules are. We don't have to guess how
list.sort() works, we have the documentation, we have the source code, we
can ask the author, and if all else fails, we can run the interpreter in a
debugger and watch what it does.

A ruleset which corresponds to the facts of how list.sort() works is more
valid than a counter-factual ruleset which does not. "Python uses timsort"
is usually to be preferred over "Python uses bubblesort" because at least
two interpreters (CPython and Jython) use timsort, while no interpreter
uses bubblesort. (Here, "Python" is to be understood as referring to a
specific interpreter, not the language itself.)



>> Only one of these models for Python allows you to make correct
>> predictions, even though all three explain the observations given.
> 
> You're slaying straw men.

"I was wrong, but I don't want to admit it" is not spelled "straw man".

You made a claim that was not defensible, and I tore that claim to shreds.
Have the good grace to admit that your earlier position:

    "it doesn't matter what semantic description you give Python 
    constructs as long as the observed behavior is correct"

doesn't stand up to scrutiny. If you can't do that, at least let it pass in
silence without trying to pretend that you never made that argument and
falsely accusing me of misrepresenting you.



>>> For example, you could explain Python's object references as pointers
>>> (memory addresses) if you considered that helpful. (That's how Lisp
>>> textbooks often explain cons cells.)
>>
>> Well, you could do that, but it would fail to explain the behaviour of
>> Jython and IronPython.
> 
> Jython, CPython and IronPython are supposed to be semantically
> equivalent. So any valid CPython model is also a valid model for Jython
> and IronPython.

They are only supposed to equivalent in regards to behaviour specified by
the language specifications, and that gives plenty of opportunity for
implementation-dependent behaviour. And of course performance and memory
use is a measure of quality of implementation.

One such implementation-dependent behaviour is whether Python objects have a
fixed location or not. CPython objects currently do. Jython and IronPython
objects do not, they can move in memory, so references in those two
implementations cannot be implemented as pointers or memory addresses.

PyPy objects don't even have a fixed existence, there are circumstances
where objects in PyPy can disappear, only to be recreated (possibly in a
new location).


>> Mixing descriptions of a specific implementation with descriptions of
>> the high level semantics is sometimes useful but often misleading, and
>> one needs to be careful how and when one does it.
> 
> Nobody has proposed doing that.

You did. Pointers are the CPython implementation, they are not the high
level semantics.




-- 
Steven

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

#90885

On Wed, May 20, 2015 at 3:46 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:
>
>> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>>
>>> To be useful, explanations ought to give the user *predictive power*
>>> -- if I calculate 32767 + 1, what will Python do?
>>>
>>> Explanation #1 predicts that Python will return 32768.
>>> Explanation #2 makes no prediction at all.
>>
>> Any semantic ruleset that correctly predicts the behavior of any given
>> Python program is equally valid.
>
> This is a more reasonable position to take than your earlier stance that the
> only thing that matters is whether it explains observed behaviour. It's
> still wrong, but at least it is defensible in the sense that sometimes a
> ruleset which is objectively wrong but still gives the right answer might
> be *preferred* over one which is objectively correct but hard to
> understand.

Perfect parallel with Magic: The Gathering, where a card may have
reminder text on it which is, in the strictest sense of the
definition, inaccurate, but covers 99%+ of situations without being
horrendously wordy. The fundamental rulebook (the "Comp Rules") goes
into excruciating detail, and is about as readable as the CPython
source code (that is: pretty readable, but too verbose to use as
documentation).

For example, the "First Strike" ability is described simply as "This
creature deals combat damage before creatures without first strike"
[1], but the Comp Rules explain how there are two combat damage steps,
and detail what happens if a creature gains or loses First Strike
during combat.

Even worse, "Madness" is described as "If you discard this card, you
may cast it for its madness cost instead of putting it into your
graveyard" [2]; the Comp Rules divide this into two parts, explaining
in full how the card actually gets from one place to another, where
it's cast from, and so on.

Both of these reminder texts are technically inaccurate, but are
massively preferred over the full text, because they actually fit
inside your brain. Same thing happens with networking; when you go to
https://www.python.org/ in a web browser, your browser establishes an
encrypted connection with the server at www.python.org, and requests
the "/" page. Well, actually, first there are DNS lookups, and IP
routing, and TCP handshakes, and then the whole "establishes an
encrypted connection" bit elides a ton of work involving certificate
checks and so on... but it's much easier to just talk in very high
level terms, even if it's not perfectly accurate. As predictive power
goes, this explanation will adequately tell you what to expect a
request for https://github.com/Rosuav to do; that makes it useful.

An explanation that's more accurate is better than one that's less
accurate; an explanation that's more complicated is worse than one
that's simpler. Somewhere in the middle is an optimal descriptive
style for a given situation.

ChrisA

[1] http://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=134753
[2] http://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=382849

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

#90887

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:
>> You're slaying straw men.
>
> "I was wrong, but I don't want to admit it" is not spelled "straw man".
>
> You made a claim that was not defensible, and I tore that claim to shreds.
> Have the good grace to admit that your earlier position:
>
>     "it doesn't matter what semantic description you give Python 
>     constructs as long as the observed behavior is correct"

I stand by that position and haven't changed it.

> doesn't stand up to scrutiny.

But it does.

>> Jython, CPython and IronPython are supposed to be semantically
>> equivalent. So any valid CPython model is also a valid model for
>> Jython and IronPython.
>
> They are only supposed to equivalent in regards to behaviour specified by
> the language specifications,

Naturally.

> One such implementation-dependent behaviour is whether Python objects
> have a fixed location or not.

Whatever that means.

> CPython objects currently do.

As far as the process's virtual memory goes...

> Jython and IronPython objects do not, they can move in memory, so
> references in those two implementations cannot be implemented as
> pointers or memory addresses.

Semantics can be given in terms of memory addresses even if the
implementation does not have memory addresses (in the sense you're
describing).

>>> Mixing descriptions of a specific implementation with descriptions
>>> of the high level semantics is sometimes useful but often
>>> misleading, and one needs to be careful how and when one does it.
>> 
>> Nobody has proposed doing that.
>
> You did. Pointers are the CPython implementation, they are not the
> high level semantics.

The semantics can be expressed in any manner whatsoever regardless of
how Python has been "really" implemented. Formally, informally. In
English. In Russian. Using Turing machines, using x86 machine language,
using Forth. There's an infinitum of isomorphic descriptions, some
instructive, some confusing.

The touchstone is the observed behavior.


Marko

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

#90906

On Wed, 20 May 2015 04:19 am, Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
> 
>> On Wed, 20 May 2015 01:59 am, Marko Rauhamaa wrote:
>>> You're slaying straw men.
>>
>> "I was wrong, but I don't want to admit it" is not spelled "straw man".
>>
>> You made a claim that was not defensible, and I tore that claim to
>> shreds. Have the good grace to admit that your earlier position:
>>
>>     "it doesn't matter what semantic description you give Python
>>     constructs as long as the observed behavior is correct"
> 
> I stand by that position and haven't changed it.
> 
>> doesn't stand up to scrutiny.
> 
> But it does.


Right. So you stand by the position that this explanation for how the Python
interpreter does integer arithmetic is equally good as any other:

There is a little magic elf hiding inside the computer, and when you type an
expression like '2 + 3', little tiny hammers bang it out in Morse Code on
the elf's head; in response, the elf calculates the answer on his teeny
tiny abacus and passes it back to the interpreter.

The elf also does calculations with decimal numbers like '1.1*2.3', but
they're harder which explains why sometimes the elf gets the calculations
slightly wrong.

Since this explanation explains the observed behaviour, according to you it
is equally valid as one involving, you know, actual facts.

Why am I talking to you?



-- 
Steven

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

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

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

csiph-web