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

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

lambdak: multi-line lambda implementation in native Python

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

Contents

  lambdak: multi-line lambda implementation in native Python yawar.amin@gmail.com - 2015-01-14 21:54 -0800
    Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve@pearwood.info> - 2015-01-15 06:06 +0000
      Re: lambdak: multi-line lambda implementation in native Python Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-14 23:39 -0700
        Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-16 01:29 +1100
          Re: lambdak: multi-line lambda implementation in native Python Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-15 08:38 -0600
        Re: lambdak: multi-line lambda implementation in native Python Yawar Amin <yawar.amin@gmail.com> - 2015-01-15 18:07 -0800
          Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-16 15:17 +1100
      Re: lambdak: multi-line lambda implementation in native Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-15 17:22 +0000
    Re: lambdak: multi-line lambda implementation in native Python Roy Smith <roy@panix.com> - 2015-01-15 08:04 -0500
      Re: lambdak: multi-line lambda implementation in native Python Chris Angelico <rosuav@gmail.com> - 2015-01-16 00:09 +1100
      Re: lambdak: multi-line lambda implementation in native Python Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-15 07:11 -0600
        Re: lambdak: multi-line lambda implementation in native Python Marko Rauhamaa <marko@pacujo.net> - 2015-01-15 15:24 +0200
          Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-16 01:24 +1100
            Re: lambdak: multi-line lambda implementation in native Python Chris Angelico <rosuav@gmail.com> - 2015-01-16 01:50 +1100
            Re: lambdak: multi-line lambda implementation in native Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-01-15 19:47 -0500
              Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-17 00:21 +1300
                Re: lambdak: multi-line lambda implementation in native Python Marko Rauhamaa <marko@pacujo.net> - 2015-01-16 14:06 +0200
                  Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-17 10:24 +1300
                    Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-17 21:33 +1100
                      Re: lambdak: multi-line lambda implementation in native Python alister <alister.nospam.ware@ntlworld.com> - 2015-01-17 18:30 +0000
          Re: lambdak: multi-line lambda implementation in native Python Roy Smith <roy@panix.com> - 2015-01-15 20:34 -0500
            Re: lambdak: multi-line lambda implementation in native Python Michael Torrie <torriem@gmail.com> - 2015-01-15 18:44 -0700
            Re: lambdak: multi-line lambda implementation in native Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-16 02:14 +0000
            Re: lambdak: multi-line lambda implementation in native Python Chris Angelico <rosuav@gmail.com> - 2015-01-16 15:00 +1100
              Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-17 10:29 +1300
                Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-17 21:30 +1100
                  Re: lambdak: multi-line lambda implementation in native Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-01-17 12:49 +0200
                    Re: lambdak: multi-line lambda implementation in native Python Marko Rauhamaa <marko@pacujo.net> - 2015-01-17 13:07 +0200
                      Re: lambdak: multi-line lambda implementation in native Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-01-17 13:59 +0200
                        Re: lambdak: multi-line lambda implementation in native Python Marko Rauhamaa <marko@pacujo.net> - 2015-01-17 14:15 +0200
                          Re: lambdak: multi-line lambda implementation in native Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-01-17 14:54 +0200
                        Re: lambdak: multi-line lambda implementation in native Python Skip Montanaro <skip.montanaro@gmail.com> - 2015-01-17 06:19 -0600
                          Re: lambdak: multi-line lambda implementation in native Python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2015-01-17 15:19 +0200
                          Re: lambdak: multi-line lambda implementation in native Python Roy Smith <roy@panix.com> - 2015-01-17 12:24 -0500
                        Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-18 11:41 +1300
                      Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-17 23:48 +1100
                        Re: lambdak: multi-line lambda implementation in native Python Roy Smith <roy@panix.com> - 2015-01-17 12:20 -0500
                          Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-18 13:45 +1100
                        Re: lambdak: multi-line lambda implementation in native Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-01-17 17:21 -0500
                      Re: lambdak: multi-line lambda implementation in native Python Danilo Coccia <daniloco@acm.org> - 2015-01-17 15:20 +0100
                    Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-17 23:49 +1100
                    Re: lambdak: multi-line lambda implementation in native Python Chris Angelico <rosuav@gmail.com> - 2015-01-18 00:33 +1100
                      Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-18 10:56 +1300
                        Re: lambdak: multi-line lambda implementation in native Python Chris Angelico <rosuav@gmail.com> - 2015-01-18 09:04 +1100
                  Re: lambdak: multi-line lambda implementation in native Python Roy Smith <roy@panix.com> - 2015-01-17 11:56 -0500
                    Re: lambdak: multi-line lambda implementation in native Python Grant Edwards <invalid@invalid.invalid> - 2015-01-17 18:51 +0000
                  Re: lambdak: multi-line lambda implementation in native Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-18 10:48 +1300
                Re: lambdak: multi-line lambda implementation in native Python Grant Edwards <invalid@invalid.invalid> - 2015-01-17 18:44 +0000
                  Re: lambdak: multi-line lambda implementation in native Python Dan Sommers <dan@tombstonezero.net> - 2015-01-17 19:08 +0000
                    Re: lambdak: multi-line lambda implementation in native Python alister <alister.nospam.ware@ntlworld.com> - 2015-01-17 20:22 +0000
            Factories and Builders [was Re: lambdak...] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-16 16:08 +1100
              Re: Factories and Builders [was Re: lambdak...] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-01-17 10:25 +1300
            Re: lambdak: multi-line lambda implementation in native Python Ian Kelly <ian.g.kelly@gmail.com> - 2015-01-15 22:29 -0700
            Re: lambdak: multi-line lambda implementation in native Python Ethan Furman <ethan@stoneleaf.us> - 2015-01-15 21:42 -0800
            Re: lambdak: multi-line lambda implementation in native Python Michael Torrie <torriem@gmail.com> - 2015-01-16 09:23 -0700
    Re: lambdak: multi-line lambda implementation in native Python Rustom Mody <rustompmody@gmail.com> - 2015-01-15 09:19 -0800
      Re: lambdak: multi-line lambda implementation in native Python Yawar Amin <yawar.amin@gmail.com> - 2015-01-15 18:18 -0800
        Re: lambdak: multi-line lambda implementation in native Python Rustom Mody <rustompmody@gmail.com> - 2015-01-15 18:48 -0800
          Re: lambdak: multi-line lambda implementation in native Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-01-16 03:02 +0000
            Re: lambdak: multi-line lambda implementation in native Python Rustom Mody <rustompmody@gmail.com> - 2015-01-15 19:14 -0800
          Re: lambdak: multi-line lambda implementation in native Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-01-16 15:16 +1100
            Re: lambdak: multi-line lambda implementation in native Python Rustom Mody <rustompmody@gmail.com> - 2015-01-15 20:58 -0800
    Re: lambdak: multi-line lambda implementation in native Python Rick Johnson <rantingrickjohnson@gmail.com> - 2015-01-15 19:06 -0800
      Re: lambdak: multi-line lambda implementation in native Python Yawar Amin <yawar.amin@gmail.com> - 2015-01-15 19:20 -0800

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

#83793 — lambdak: multi-line lambda implementation in native Python

Hi all,

First off, to each reader--if you believe that 'multi-line' lambdas are
no good and we can just use functions, decorators, &c. to accomplish
everything in Python, advance warning: this post will annoy you.

Now, the crux of my message. I have implemented what I believe is a
fairly robust, if ugly-looking, native Python module made up of
combinator functions which compose together to form function expressions
(well, callable expressions).

I've seen a lot of discussions on possibly introducing syntax support
for multi-line lambdas in some future version, but I've never seen
anyone say, here's a way you can do this in Python _today._ So I believe
lambdak fits in that niche.

    https://github.com/yawaramin/lambdak

Would anyone care to try it out? I would be happy to answer questions
whenever I can.

Regards,

Yawar

[toc] | [next] | [standalone]

#83795

On Wed, 14 Jan 2015 21:54:52 -0800, yawar.amin wrote:

> Now, the crux of my message. I have implemented what I believe is a
> fairly robust, if ugly-looking, native Python module made up of
> combinator functions which compose together to form function expressions
> (well, callable expressions).

How about a demo?

I have a function, which I put into an expression like this:

def func(a, b=None):
    global spam
    import math
    spam = [a, b]*3
    print spam
    del spam


value = [1, "hello", int, func]
del func

How would I use lambdak to write that as an expression

value = [1, "hello", int, ??????? ]

without the intermediate def?

    
-- 
Steve

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

#83796

On Wed, Jan 14, 2015 at 11:06 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> I have a function, which I put into an expression like this:
>
> def func(a, b=None):
>     global spam
>     import math
>     spam = [a, b]*3
>     print spam
>     del spam
>
>
> value = [1, "hello", int, func]
> del func
>
> How would I use lambdak to write that as an expression
>
> value = [1, "hello", int, ??????? ]
>
> without the intermediate def?


# Untested, but seems like this should work.

value = [1, "hello", int, given_(lambda a, b=None:
    import_("math", lambda math:
    import_("operator", lambda operator:
    do_(lambda: operator.setitem(globals(), 'spam', [a, b]*3), lambda:
    print_(globals()['spam'], lambda:
    do_(lambda: operator.delitem(globals(), 'spam')))))))]


To the OP: I note that although import_ is used in the examples, it's
not found in the list of functions in the README.

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

#83830

Ian Kelly wrote:

> On Wed, Jan 14, 2015 at 11:06 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> I have a function, which I put into an expression like this:
>>
>> def func(a, b=None):
>>     global spam
>>     import math
>>     spam = [a, b]*3
>>     print spam
>>     del spam
>>
>>
>> value = [1, "hello", int, func]
>> del func
>>
>> How would I use lambdak to write that as an expression
>>
>> value = [1, "hello", int, ??????? ]
>>
>> without the intermediate def?
> 
> 
> # Untested, but seems like this should work.
> 
> value = [1, "hello", int, given_(lambda a, b=None:
>     import_("math", lambda math:
>     import_("operator", lambda operator:
>     do_(lambda: operator.setitem(globals(), 'spam', [a, b]*3), lambda:
>     print_(globals()['spam'], lambda:
>     do_(lambda: operator.delitem(globals(), 'spam')))))))]

Thank you for showing me that.

Now I shall try very hard to forget I ever saw it. 

*shudders at the thought of maintaining such a beast*



-- 
Steven

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

#83831

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jan 15, 2015 at 8:29 AM, Steven D'Aprano <
steve+comp.lang.python@pearwood.info> wrote:

> Now I shall try very hard to forget I ever saw it.


There are some things, no matter how hard you try, which cannot be
"unseen". :-)

Skip

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

#83848

On Thursday, January 15, 2015 at 1:40:09 AM UTC-5, Ian wrote:
> On Wed, Jan 14, 2015 at 11:06 PM, Steven D'Aprano
> <steve@...> wrote:
> [...]
> > def func(a, b=None):
> >     global spam
> >     import math
> >     spam = [a, b]*3
> >     print spam
> >     del spam
> >
> > value = [1, "hello", int, func]
> > del func
> [...]
> # Untested, but seems like this should work.
> [...]
> To the OP: I note that although import_ is used in the examples, it's
> not found in the list of functions in the README.

Thanks Ian. I'll update the readme soon. It's still a little behind the
actual code.

Steve, here is your example translated, about as simple as I can make
it:

    from lambdak import *

    value = [
      1,
      "hello",
      int,
      given_(lambda a, b = None:
        import_("math", lambda math:
        given_(lambda globs = globals(), spam = "spam":

        assign_(spam, [a, b] * 3, globs, lambda:
        print_(get_(spam, globs), lambda:
        del_(spam, globs))))))
    ]

    value[3](1)
    del value[3]

The problem with globals is that a Python module can't easily manipulate
the globals of its caller modules. Here you can see I had to work around
the issue by just creating a few functions[1] which generically work
with dicts and then explicitly passing in the globals dict on each call.
I don't see any other reasonable way to do it. I would welcome being
proven wrong here.

To the responders in the 'beauty of the code' subthread: yes, I realise
that lambdak is not Pythonic, and it will make angels cry, and all that.
My view is you should actually be _happy_ that it looks like this. If
anyone ever asks about multi-line lambdas again, you can point to
lambdak and say, 'See! This is what happens if you try to go against
Pythonic style.' And then you can shrug your head in disgust if they
continue to use it anyway.

Regards,

Yawar

[1] `assign_`, `get_`, `del_`. I haven't pushed these to the project
repo yet. Will do so after writing up the tests and docs.

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

#83862

Yawar Amin wrote:

> To the responders in the 'beauty of the code' subthread: yes, I realise
> that lambdak is not Pythonic, and it will make angels cry, and all that.
> My view is you should actually be happy that it looks like this. If
> anyone ever asks about multi-line lambdas again, you can point to
> lambdak and say, 'See! This is what happens if you try to go against
> Pythonic style.' And then you can shrug your head in disgust if they
> continue to use it anyway.


:-)


-- 
Steven

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

#83839

On 15/01/2015 06:39, Ian Kelly wrote:
> On Wed, Jan 14, 2015 at 11:06 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> I have a function, which I put into an expression like this:
>>
>> def func(a, b=None):
>>      global spam
>>      import math
>>      spam = [a, b]*3
>>      print spam
>>      del spam
>>
>>
>> value = [1, "hello", int, func]
>> del func
>>
>> How would I use lambdak to write that as an expression
>>
>> value = [1, "hello", int, ??????? ]
>>
>> without the intermediate def?
>
>
> # Untested, but seems like this should work.
>
> value = [1, "hello", int, given_(lambda a, b=None:
>      import_("math", lambda math:
>      import_("operator", lambda operator:
>      do_(lambda: operator.setitem(globals(), 'spam', [a, b]*3), lambda:
>      print_(globals()['spam'], lambda:
>      do_(lambda: operator.delitem(globals(), 'spam')))))))]
>
>
> To the OP: I note that although import_ is used in the examples, it's
> not found in the list of functions in the README.
>

Just what I've been looking for, highly readable, higly maintainable 
Python code.  Please put this up as an Activestate recipe so it's 
preserved for prosperity, so that the entire world can see its 
asthetically pleasing properties.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#83821

yawar.amin@gmail.com wrote:

> I have implemented what I believe is a
> fairly robust, if ugly-looking, native Python module 

I don't know which zen this is, but "Beauty is important".

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

#83822

On Fri, Jan 16, 2015 at 12:04 AM, Roy Smith <roy@panix.com> wrote:
> I don't know which zen this is, but "Beauty is important".

How about:
Beautiful is better than ugly.
Readability counts.
If the implementation is hard to explain, it's a bad idea.

ChrisA

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

#83824

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jan 15, 2015 at 7:04 AM, Roy Smith <roy@panix.com> wrote:

> I don't know which zen this is, but "Beauty is important".


Kinda near the front:

% python -m this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
...

:-)

Skip

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

#83825

Skip Montanaro <skip.montanaro@gmail.com>:

> Beautiful is better than ugly.

Yes, our job is to increase the Harmony of the Universe. Useful
applications are happy side effects.

> Explicit is better than implicit.

Corollary: Constructors are usually preferable to factories.

> Simple is better than complex.

Corollary: Make sure the complete definition of every function can be
seen at once without scrolling.


Marko

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

#83829

Marko Rauhamaa wrote:

> Corollary: Make sure the complete definition of every function can be
> seen at once without scrolling.

Problem: I like to view code on a smartphone with a 4x4 pixel screen, and
the scroll bars obscure the text.

Solution: Change the editor to a 1pt font.



-- 
Steven

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

#83832

On Fri, Jan 16, 2015 at 1:24 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Marko Rauhamaa wrote:
>
>> Corollary: Make sure the complete definition of every function can be
>> seen at once without scrolling.
>
> Problem: I like to view code on a smartphone with a 4x4 pixel screen, and
> the scroll bars obscure the text.
>
> Solution: Change the editor to a 1pt font.

Problem: You have a smartphone with a 4x4 pixel screen.

Solution: Utilize hammer, then get a laptop.

ChrisA

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

#83843

On Fri, 16 Jan 2015 01:50:00 +1100, Chris Angelico <rosuav@gmail.com>
declaimed the following:

>On Fri, Jan 16, 2015 at 1:24 AM, Steven D'Aprano
><steve+comp.lang.python@pearwood.info> wrote:
>> Marko Rauhamaa wrote:
>>
>>> Corollary: Make sure the complete definition of every function can be
>>> seen at once without scrolling.
>>
>> Problem: I like to view code on a smartphone with a 4x4 pixel screen, and
>> the scroll bars obscure the text.
>>
>> Solution: Change the editor to a 1pt font.
>
>Problem: You have a smartphone with a 4x4 pixel screen.
>
	BIG problem, considering that a late 70s DECWriter needed 5x7 pixels
for glyphs in an 8x10 pixel character cell {as I recall...}


	Now... maybe a 4x4 POINT screen (1/16 x 1/16 inch, with the superfine
resolutions on some tablets (257DPI) would manage (16x16 pixels) could show
two glyphs side by side with some detail.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#83875

Dennis Lee Bieber wrote:
> On Fri, 16 Jan 2015 01:50:00 +1100, Chris Angelico <rosuav@gmail.com>
> declaimed the following:
 >
>>Problem: You have a smartphone with a 4x4 pixel screen.
>
> 	BIG problem, considering that a late 70s DECWriter needed 5x7 pixels
> for glyphs in an 8x10 pixel character cell {as I recall...}

If those are 24-bit RGB pixels, you could encode
3 characters in each pixel.

You'd need eyes with rather good colour perception
to read it, though.

-- 
Greg

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

#83877

Gregory Ewing <greg.ewing@canterbury.ac.nz>:

> Dennis Lee Bieber wrote:
>> On Fri, 16 Jan 2015 01:50:00 +1100, Chris Angelico <rosuav@gmail.com>
>> declaimed the following:
>>
>>>Problem: You have a smartphone with a 4x4 pixel screen.
>>
>> 	BIG problem, considering that a late 70s DECWriter needed 5x7
>> pixels for glyphs in an 8x10 pixel character cell {as I recall...}
>
> If those are 24-bit RGB pixels, you could encode
> 3 characters in each pixel.

Not since Python3. Characters are Unicode now so you'll need to dedicate
a pixel for each character.


Marko

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

#83899

Marko Rauhamaa wrote:
> Gregory Ewing <greg.ewing@canterbury.ac.nz>:
> 
>>If those are 24-bit RGB pixels, you could encode
>>3 characters in each pixel.
> 
> Not since Python3. Characters are Unicode now so you'll need to dedicate
> a pixel for each character.

Depends on which characters you want. With the
Flexible Chromatic Representation, it could be
anything from 1 to 3.

-- 
Greg

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

#83909

Gregory Ewing wrote:

> Marko Rauhamaa wrote:
>> Gregory Ewing <greg.ewing@canterbury.ac.nz>:
>> 
>>>If those are 24-bit RGB pixels, you could encode
>>>3 characters in each pixel.
>> 
>> Not since Python3. Characters are Unicode now so you'll need to dedicate
>> a pixel for each character.
> 
> Depends on which characters you want. With the
> Flexible Chromatic Representation, it could be
> anything from 1 to 3.

Subpixel rendering is 5% slower than full pixel rendering, so it is provably
mathematically impossible to print Unicode characters.


-- 
Steven

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

#83938

On Sat, 17 Jan 2015 21:33:19 +1100, Steven D'Aprano wrote:

> Gregory Ewing wrote:
> 
>> Marko Rauhamaa wrote:
>>> Gregory Ewing <greg.ewing@canterbury.ac.nz>:
>>> 
>>>>If those are 24-bit RGB pixels, you could encode 3 characters in each
>>>>pixel.
>>> 
>>> Not since Python3. Characters are Unicode now so you'll need to
>>> dedicate a pixel for each character.
>> 
>> Depends on which characters you want. With the Flexible Chromatic
>> Representation, it could be anything from 1 to 3.
> 
> Subpixel rendering is 5% slower than full pixel rendering, so it is
> provably mathematically impossible to print Unicode characters.

:-)



-- 
It's union rules. There's nothing we can do about it. Sorry.

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

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

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

csiph-web