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

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

LangWart: Method congestion from mutate multiplicty

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

Contents

  LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-08 17:50 -0800
    Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-09 14:36 +1100
      Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-09 19:54 -0800
        Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-10 15:20 +1100
        Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-09 20:53 -0800
          Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 01:29 +1100
            Re: LangWart: Method congestion from mutate multiplicty Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-10 14:03 -0500
              Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 11:11 +1100
            Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-10 13:28 -0800
              Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 11:10 +1100
                Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-10 17:14 -0800
            Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-11 08:51 +1100
            Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-10 14:01 -0800
        Re: LangWart: Method congestion from mutate multiplicty Terry Reedy <tjreedy@udel.edu> - 2013-02-10 03:39 -0500
          Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 10:45 -0800
            Re: LangWart: Method congestion from mutate multiplicty Terry Reedy <tjreedy@udel.edu> - 2013-02-10 16:44 -0500
            Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 11:11 +1100
          Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 10:45 -0800
        Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-10 22:29 +1100
          Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-11 00:24 +1100
            Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 01:00 +1100
          Re: LangWart: Method congestion from mutate multiplicty Tim Chase <python.list@tim.thechases.com> - 2013-02-10 07:52 -0600
          Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 15:59 -0800
            Re: LangWart: Method congestion from mutate multiplicty Tim Chase <python.list@tim.thechases.com> - 2013-02-10 18:12 -0600
              Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 17:24 -0800
              Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 17:24 -0800
            Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 11:36 +1100
              Re: LangWart: Method congestion from mutate multiplicty MRAB <python@mrabarnett.plus.com> - 2013-02-11 02:03 +0000
              Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 04:53 -0800
                Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-12 00:27 +1100
                  Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:55 -0800
                    Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-11 21:28 -0800
                      Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-12 12:46 -0800
                      Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-12 12:46 -0800
                  Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-11 20:55 -0800
            Re: LangWart: Method congestion from mutate multiplicty alex23 <wuwei23@gmail.com> - 2013-02-10 18:05 -0800
              Re: LangWart: Method congestion from mutate multiplicty Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-11 07:19 +0000
              Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-11 18:24 +1100
              Re: LangWart: Method congestion from mutate multiplicty Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-02-11 07:35 +0000
              Re: LangWart: Method congestion from mutate multiplicty Tim Chase <tim@thechases.com> - 2013-02-11 06:04 -0600
              Re: LangWart: Method congestion from mutate multiplicty Serhiy Storchaka <storchaka@gmail.com> - 2013-02-11 19:07 +0200
        Re: LangWart: Method congestion from mutate multiplicty Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-10 13:30 +0000
          Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 16:25 -0800
            Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-11 11:42 +1100
          Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 16:25 -0800
        Re: LangWart: Method congestion from mutate multiplicty Mark Janssen <dreamingforward@gmail.com> - 2013-02-10 10:45 -0800
      Re: LangWart: Method congestion from mutate multiplicty 88888 Dihedral <dihedral88888@googlemail.com> - 2013-02-10 06:33 -0800
    Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-09 15:51 +1100
      Re: LangWart: Method congestion from mutate multiplicty alex23 <wuwei23@gmail.com> - 2013-02-10 17:56 -0800
        Re: LangWart: Method congestion from mutate multiplicty Chris Angelico <rosuav@gmail.com> - 2013-02-12 19:06 +1100
    Re: LangWart: Method congestion from mutate multiplicty Neil Hodgson <nhodgson@iinet.net.au> - 2013-02-10 20:53 +1100
      Re: LangWart: Method congestion from mutate multiplicty Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-10 22:30 +1100
      Re: LangWart: Method congestion from mutate multiplicty Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-10 10:55 -0800
        Re: LangWart: Method congestion from mutate multiplicty Neil Hodgson <nhodgson@iinet.net.au> - 2013-02-11 08:57 +1100

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

#38699

On 11.02.13 09:24, Chris Angelico wrote:
> Can I get a ringside seat at the debate between Rick and jmf on which
> kind of string theory was the wronger decision?

I want to see it.

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

#38568

On 10 February 2013 04:53, Mark Janssen <dreamingforward@gmail.com> wrote:
> On Sat, Feb 9, 2013 at 8:20 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> On Sun, Feb 10, 2013 at 2:54 PM, Rick Johnson
>> <rantingrickjohnson@gmail.com> wrote:
>>> My point was this: All mutate methods should mutate "in-place", if the programmer wishes to create a mutated copy of the object, then the programmer should /explicitly/ create a copy of the object and then apply the correct mutator method to the copy.
>>
>> I agree. And we can go further and declare that there is only one data
>> [sarcasm]
>
> I have to agree with Rick, I think requiring the user to explicitly
> create a new object, which is already a good and widely-used practice,
> should be the Only One Way to Do It.

Why should I copy a potentially large data structure just to iterate
over it in reverse order? And why on earth would you want to remove
the more efficient ways of doing this?

> Guessing method names is far suboptimal to this simple, easy idiom.

There is no guessing. If the object has a __reverse__ method then it
specifically advertises that it knows how to create an iterator that
gives its values in reverse order. Otherwise __len__ and __getitem__
are used.


Oscar

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

#38621

On Sunday, February 10, 2013 7:30:00 AM UTC-6, Oscar Benjamin wrote:
> On 10 February 2013 04:53, Mark Janssen wrote:
> > [...]
> > I have to agree with Rick, I think requiring the user to explicitly
> > create a new object, which is already a good and widely-used practice,
> > should be the Only One Way to Do It.
> 
> Why should I copy a potentially large data structure just to iterate
> over it in reverse order? 

That's a good question, and the answer is: "Only a fool would make a copy of ANY data structure only to simply iterate over it; be it forwards or backwards or sideways". 

> And why on earth would you want to remove
> the more efficient ways of doing this?

Well these "ways"(sic) might be more efficient, at this time, because the Python developers have defined them to be. This could be changed if they would drop the aversion to true OOP paradigm.

To make this work properly you would need to optimize the constructor of the sequence object. If the user presents the seq object (say for example a list) with variable that points to an already existing list like:

py> a = [1,2,3]
py> for x in list(a).reverse():
...     do_something

Python will not actually create a copy of the list because that would be foolish! Python would instead ITERATE over the existing object transparently. It's called OPTIMIZING CODE! By doing this we gain many things:

  * We don't have these foolish "mutate"<->"copy mutate"
    method "pairs" like: "seq.reverse()" and
    "seq.reversed()"
  
  * We are writing maintainable code by explicitly calling
    "Sequence(seq).mutate()". The intent becomes obvious
    even though Python may "optimize" our intentions "behind
    the scenes".
  
> > Guessing method names is far suboptimal to this simple, easy idiom.
> 
> There is no guessing. If the object has a __reverse__ method then it
> specifically advertises that it knows how to create an iterator that
> gives its values in reverse order. Otherwise __len__ and __getitem__
> are used.

Really. 

And you know that simply from intuiting a seemingly unrelated method? Wow, i'd bet the detectives of many municipalities would love to rent some of your powers. What sort of esoteric rule book are you reading from my friend?

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

#38624

Rick Johnson wrote:

> On Sunday, February 10, 2013 7:30:00 AM UTC-6, Oscar Benjamin wrote:
>> On 10 February 2013 04:53, Mark Janssen wrote:
>> > [...]
>> > I have to agree with Rick, I think requiring the user to explicitly
>> > create a new object, which is already a good and widely-used practice,
>> > should be the Only One Way to Do It.
>> 
>> Why should I copy a potentially large data structure just to iterate
>> over it in reverse order?
> 
> That's a good question, and the answer is: "Only a fool would make a copy
> of ANY data structure only to simply iterate over it; be it forwards or
> backwards or sideways".

Aren't you the fool who wants to remove reversed() and have people write:

[quote]
reversed = list(seq).reverse()


Oh yes, you are the fool. And me the bigger fool for listening to you.

Time for another six months in my killfile, methinks.




-- 
Steven

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

#38622

On Sunday, February 10, 2013 7:30:00 AM UTC-6, Oscar Benjamin wrote:
> On 10 February 2013 04:53, Mark Janssen wrote:
> > [...]
> > I have to agree with Rick, I think requiring the user to explicitly
> > create a new object, which is already a good and widely-used practice,
> > should be the Only One Way to Do It.
> 
> Why should I copy a potentially large data structure just to iterate
> over it in reverse order? 

That's a good question, and the answer is: "Only a fool would make a copy of ANY data structure only to simply iterate over it; be it forwards or backwards or sideways". 

> And why on earth would you want to remove
> the more efficient ways of doing this?

Well these "ways"(sic) might be more efficient, at this time, because the Python developers have defined them to be. This could be changed if they would drop the aversion to true OOP paradigm.

To make this work properly you would need to optimize the constructor of the sequence object. If the user presents the seq object (say for example a list) with variable that points to an already existing list like:

py> a = [1,2,3]
py> for x in list(a).reverse():
...     do_something

Python will not actually create a copy of the list because that would be foolish! Python would instead ITERATE over the existing object transparently. It's called OPTIMIZING CODE! By doing this we gain many things:

  * We don't have these foolish "mutate"<->"copy mutate"
    method "pairs" like: "seq.reverse()" and
    "seq.reversed()"
  
  * We are writing maintainable code by explicitly calling
    "Sequence(seq).mutate()". The intent becomes obvious
    even though Python may "optimize" our intentions "behind
    the scenes".
  
> > Guessing method names is far suboptimal to this simple, easy idiom.
> 
> There is no guessing. If the object has a __reverse__ method then it
> specifically advertises that it knows how to create an iterator that
> gives its values in reverse order. Otherwise __len__ and __getitem__
> are used.

Really. 

And you know that simply from intuiting a seemingly unrelated method? Wow, i'd bet the detectives of many municipalities would love to rent some of your powers. What sort of esoteric rule book are you reading from my friend?

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

#38594

On Sun, Feb 10, 2013 at 5:30 AM, Oscar Benjamin
<oscar.j.benjamin@gmail.com> wrote:
> On 10 February 2013 04:53, Mark Janssen <dreamingforward@gmail.com> wrote:
>> I have to agree with Rick, I think requiring the user to explicitly
>> create a new object, which is already a good and widely-used practice,
>> should be the Only One Way to Do It.
>
> Why should I copy a potentially large data structure just to iterate
> over it in reverse order? And why on earth would you want to remove
> the more efficient ways of doing this?

You're right.  I responded too fast. I think reversed() and sorted()
might be the only legit methods in this regard and I thank Steve
D'Aprano for pointing that out.

But Rick still has a valid point: it should not be taken as a general
practice.  The point, as I see it, is that there's no clear,
documented standard on the "right way" for people to think about the
issue.  The existence of sorted() and reversed() actually *misinform*
programmers as if this is the best practice.  It isn't, it just that
these are very special cases (one for a real machine efficiency and
one for a very common "user efficiency") and there should probably be
documentation to make that clear, so programmers don't start going
that direction.  I don't think there are other cases where such an
idiom would be recommended.

Mark

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

#38573

Steven D'Aprano於 2013年2月9日星期六UTC+8上午11時36分52秒寫道：
> Rick Johnson wrote:
> 
> 
> 
> > The solution is simple. Do not offer the "copy-mutate" methods and force
> 
> > all mutation to happen in-place:
> 
> > 
> 
> > py> l = [1,2,3]
> 
> > py> l.reverse
> 
> > py> l
> 
> > [3,2,1]
> 
> > 
> 
> > If the user wants a "mutated copy" he should explicitly create a new
> 
> > object and then apply the correct mutator method:
> 
> > 
> 
> > py> a1 = [1,2,3]
> 
> > py> a2 = list(a1).reverse()
> 
> 
> 
> 
> 
> Oh wow, Rick has re-discovered programming in Python during the mid to late
> 
> 1990s!
> 
> 
> 
> I was there, and I remember what it was like. For about a month, you try
> 
> hard to follow Rick's prescription. Then you realise that with a small
> 
> helper function, you can halve the amount of code it takes to do a common
> 
> operation:
> 
> 
> 
> def reversed(sequence):
> 
>     seq = list(sequence)
> 
>     seq.reverse()
> 
>     return seq
> 
> 
> 
> 
> 
> Soon you've copied this reversed() function into all your projects. And of
> 
> course, they start to diverge... in project A, you only care about lists.
> 
> In project B, you realise that you also need to support tuples and strings:
> 
> 
> 
> 
> 
> def reversed(sequence):
> 
>     seq = sequence[:]
> 
>     try:
> 
>         seq.reverse()
> 
>     except AttributeError:
> 
>         seq = seq[::-1]
> 
>     return seq
> 
> 
Will a temprary new list be formed here?
If it is not necessary, I'll prefer a reverse 
generator for all lists to save the heap space
and the GC burden.


> 
> which in project C you realise can be shortened:
> 
> 
> 
> def reversed(sequence):
> 
>     return sequence[::-1]
> 
> 
> 
> 
> 
> until you get to project D when you realise that you also want this to work
> 
> on dicts:
> 
> 
> 
> def reversed(sequence):
> 
>     everything = list(sequence)
> 
>     return everything[::-1]
> 
> 
> 
> 
> 
> and then in project E you wonder why reversed(string) returns a list:
> 
> 
> 
> def reversed(sequence):
> 
>     everything = list(sequence)[::-1]
> 
>     if isinstance(sequence, tuple):
> 
>         return tuple(everything)
> 
>     elif isinstance(sequence, str):
> 
>         return ''.join(everything)
> 
>     return everything
> 
> 
> 
> 
> 
> and then finally you learn about iterators and generators and become more
> 
> comfortable with a flow-based programming paradigm and generators:
> 
> 
> 
> def reversed(sequence):
> 
>     for item in list(sequence)[::-1]:
> 
>         yield item
> 
> 
> 
> at which point you realise that, hell, this is so useful that pretty much
> 
> everyone has implemented it a dozen times or more in their own projects,
> 
> and you start to agitate for it to be added to the builtins so that there
> 
> is *one* implementation, done *right*, that everyone can use.
> 
> 
> 
> And then you get told that Guido's time machine has struck again, because
> 
> Python has already had this since Python 2.4.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

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

#38496

On Sat, Feb 9, 2013 at 12:50 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> I really don't like to read docs when learning a language, especially a "so-called" high level language. I prefer to learn the language by interactive sessions and object introspection. Then, when i have exhausted all abilities to intuit the solution, i will roll my eyes, maybe blubber an expletive, and then reluctantly crack open a user manual.


What Rick means: "I want to claim that I've learned a new language,
but I want it to work exactly like the imaginary language in my mind,
and if it doesn't, I'm going to complain about it, rather than,
yaknow, actually learn a new language."

I have learned *many* languages in the past couple of decades. Some of
them are excellent and I keep using them (Pike). Others are excellent
and I keep talking about them (Python). Some are mediocre or poor, but
I keep using them anyway (bash). Some are not particularly enjoyable
to me and I use them only in the one application that embeds them
(Lua, Scheme, DML). And some, I'm just not going to touch any more
(Q-BASIC). But there is not a single language that hasn't taught me
something new. I'm a better C++ programmer for having learned Python;
a better Python programmer for having grokked Scheme and Lua; and,
believe it or not, a better Scheme programmer for having mastered DML.
And that's a language so obscure it doesn't even have a Wikipedia
page... just a redlink here[1].

Learning a language requires accepting something from it into your
brain, not forcing something from your brain onto the language.

ChrisA

[1] http://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Extension_languages

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

#38631

On Feb 9, 2:51 pm, Chris Angelico <ros...@gmail.com> wrote:
>> Rick Johnson <rantingrickjohn...@gmail.com> wrote:
>> I really don't like to read docs when learning a language,
>> especially a "so-called" high level language. I prefer to learn
>> the language by interactive sessions and object introspection. Then,
>> when i have exhausted all abilities to intuit the solution, i will
>> roll my eyes, maybe blubber an expletive, and then reluctantly crack
>> open a user manual.
>
> What Rick means: "I want to claim that I've learned a new language,
> but I want it to work exactly like the imaginary language in my mind,
> and if it doesn't, I'm going to complain about it, rather than,
> yaknow, actually learn a new language."

Yeah, this is, pardon the french, just batshit crazy. How does one
_ever_ learn _anything_ new if they expect everything to conform with
their pre-established intuitions?

As can be seen by his posts, the outcome is one just _doesn't_ learn.

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

#38736

On Mon, Feb 11, 2013 at 8:52 PM, Jean-Michel Pichavant
<jeanmichel@sequans.com> wrote:
>
>> Yeah, this is, pardon the french, just batshit crazy.
>
> huh ? :)

You're French, ergo you are pardoned. Makes good sense to me!

:)

ChrisA
Cheshire was right, we're all mad here...

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

#38561

Rick Johnson:

> The Ruby language attempted to save the programmer from the scourge of obtaining a four year degree in linguistics just to create intuitive identifiers "on-the-fly", and they tried to remove this ambiguity by employing "post-fix-punctuation" of the exclamation mark as a visual cue for in-place modification of the object:

    Ruby does not use '!' to indicate in-place modification:
http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist

    Neil

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

#38564

Neil Hodgson wrote:

> Rick Johnson:
> 
>> The Ruby language attempted to save the programmer from the scourge of
>> obtaining a four year degree in linguistics just to create intuitive
>> identifiers "on-the-fly", and they tried to remove this ambiguity by
>> employing "post-fix-punctuation" of the exclamation mark as a visual cue
>> for in-place modification of the object:
> 
>     Ruby does not use '!' to indicate in-place modification:
> http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist


Why am I not surprised that Rick's knowledge of Ruby is no deeper than his
knowledge of Python?



-- 
Steven

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

#38596

On Sunday, February 10, 2013 3:53:57 AM UTC-6, Neil Hodgson wrote:
> Ruby does not use '!' to indicate in-place modification:

Really?

rb> a = [1,2,3]
[1, 2, 3]
rb> a.reverse
[3, 2, 1]
rb> a
[1, 2, 3]
rb> a.reverse!
[3, 2, 1]
rb> a
[3, 2, 1]

And now we will verify that a.reverse! has not assigned 'a' to a new object

rb> a = [1,2,3]
[1, 2, 3]
rb> aID = a.object_id
78906770
rb> a.reverse!
[3, 2, 1]
rb> a
[3, 2, 1]
rb> a.object_id
78906770

I'd love to hear an explanation for that.

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

#38605

Rick Johnson:

> Really?

    Yes.

 >> a = [1,2]
=> [1, 2]
 >> a.push(3)
=> [1, 2, 3]
 >> a
=> [1, 2, 3]

    This could be called "mutation without exclamation".

 >> require 'WEBrick'
=> true
 >> vowels = "[aeiou]+"
=> "[aeiou]+"
 >> vowels.object_id
=> 2234951380
 >> WEBrick::HTTPUtils._make_regex!(vowels)
=> /([^\[aeiou\]\+])/n
 >> vowels
=> "[aeiou]+"
 >> vowels.object_id
=> 2234951380

    The counterpart, exclamation without mutation.

    Neil

[toc] | [prev] | [standalone]

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

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

csiph-web