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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#83918

Jussi Piitulainen wrote:

> I've only seen small amounts of Ruby code on the net. The only way I
> can make some sense of that is if it gets analyzed as follows, using
> parentheses for calls:
> 
>  a + b => 7  # a() + b => a(4) + b => 4 + 2 + 1
>  a+b   => 7  # a() + b
>  a+ b  => 7  # a() + b
>  a +b  => 3  # a(+b)   => a(b) => a(1) = 1 + 2
> 
> I'm not quite fond of such surprise in programming language syntax.

Full marks!



-- 
Steven

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

#83922

On Sat, Jan 17, 2015 at 9:49 PM, Jussi Piitulainen
<jpiitula@ling.helsinki.fi> wrote:
> I've only seen small amounts of Ruby code on the net. The only way I
> can make some sense of that is if it gets analyzed as follows, using
> parentheses for calls:
>
>  a + b => 7  # a() + b => a(4) + b => 4 + 2 + 1
>  a+b   => 7  # a() + b
>  a+ b  => 7  # a() + b
>  a +b  => 3  # a(+b)   => a(b) => a(1) = 1 + 2
>
> I'm not quite fond of such surprise in programming language syntax.

Every once in a while, someone looks at Py2's print statement and
Py3's print function and says, "why not allow function calls without
parentheses". This right here is why not. Wow. That is one nasty
surprise.

ChrisA

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

#83953

Chris Angelico wrote:
> Every once in a while, someone looks at Py2's print statement and
> Py3's print function and says, "why not allow function calls without
> parentheses". This right here is why not.

There's also the fact that the parens are needed to
distinguish between calling a function and using the
function itself as a value.

Ruby doesn't have that problem because it doesn't
have functions, only methods, and the only thing you
can do with a method in Ruby is call it.

-- 
Greg

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

#83954

On Sun, Jan 18, 2015 at 8:56 AM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Ruby doesn't have that problem because it doesn't
> have functions, only methods, and the only thing you
> can do with a method in Ruby is call it.

So functions aren't first-class objects in Ruby? Bleh. I've become
quite accustomed to passing them around casually, in several
languages. Even C lets you pass function pointers around.

ChrisA

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

#83933

In article <54ba39e0$0$13008$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> Every time I think I would like to learn a new language, I quite quickly run
> into some obvious feature that Python has but the newer language lacks, and
> I think "bugger this for a game of soldiers" and abandon it.

Wow.  Another wonderful English phrase to add to my vocabulary.  That's 
up there with Bob's your uncle :-)

> Ah, wait, I forgot Ruby's brilliant "feature" that whitespace *between*
> expressions is significant:
> 
> [steve@ando ~]$ cat ~/coding/ruby/ws-example.rb
> #!/usr/bin/ruby
> 
> def a(x=4)
>     x+2
> end
> 
> b = 1
> print "a + b => ", (a + b), "\n"
> print "a+b   => ", (a+b), "\n"
> print "a+ b  => ", (a+ b), "\n"
> print "a +b  => ", (a +b), "\n"
> 
> [steve@ando ~]$ ruby ~/coding/ruby/ws-example.rb
> a + b => 7
> a+b   => 7
> a+ b  => 7
> a +b  => 3
> 
> 
> A shiny new penny for any non-Ruby coder who can explain that!

The last time I looked at Ruby was when it was brand new.  I bought the 
original pickaxe book and read it on a plane trip.  It looked pretty 
cool at the time, but I never really got into it.  So I think I qualify.

Anyway, I'm going to guess from the above examples, that uttering a name 
means, "If the referent is callable, call it, if not, get its value".  
This is the same, for example, as django's template language.  Or, kind 
of like Python's properties.  So

(a + b)

means "Call a(), and add the value of b to that".  I'm going to further 
guess that

def a(x=4)

means a() takes an optional argument, with a default value of 4, just 
like in Python.  So

a

returns 6, i.e. 4 + 2.  I'm going to further guess that

(a +b)

is parsed as "call a, passing +b as an argument", and the "+" is taken 
as a unary prefix.

I want my penny.

This is not the only example of significant whitespace in programming 
languages.

Old-style C/C++ allowed either += or =+ for the increment operator.  
This led to parsing ambiguity for things like a=+b, where (IIRC), "a = 
+b" was parsed as an assignment and unary +, and "a =+ b" was parsed as 
an increment.  Eventually, the syntax was changed to make += the only 
legal way to write increment.

There was also the problem with nested template operators in C++, where 
"Foo<T1<T2>>" was mis-parsed, and you had to write it as "Foo <T1 <T2> 
>" (or something like that) to get it to parse right.

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

#83943

On 2015-01-17, Roy Smith <roy@panix.com> wrote:
> In article <54ba39e0$0$13008$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>
>> Every time I think I would like to learn a new language, I quite quickly run
>> into some obvious feature that Python has but the newer language lacks, and
>> I think "bugger this for a game of soldiers" and abandon it.
>
> Wow.  Another wonderful English phrase to add to my vocabulary.  That's 
> up there with Bob's your uncle :-)

Yup, that one's brilliant.  While it's pretty much obvious what
phrases like that mean when one stumbles across them for the first
time, I find I sometimes don't have a very good grasp of where they
fall on the offensive<->polite scale...

--
Grant

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

#83952

Steven D'Aprano wrote:

> def a(x=4)
>     x+2
> end
> 
> a + b => 7
> a+b   => 7
> a+ b  => 7
> a +b  => 3
> 
> A shiny new penny for any non-Ruby coder who can explain that!

Seems pretty obvious to me: the Ruby interpreter is
infested with demons.

DWIM = Demonic Whim Infers Meaning

-- 
Greg

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

#83941

On 2015-01-16, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:

> We're really quite spoiled in Python-land. It's easy
> to forget just *how* spoiled we are until you go back
> and try to do something in one of the more primitive
> languages...

I had to do some work in PHP yesterday -- fixing up some code that was
written by somebody who only knows how to write C++ [though he can do
it in several different languages].

There was lot's of quiet swearing.

--
Grant

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

#83944

On Sat, 17 Jan 2015 18:44:42 +0000, Grant Edwards wrote:

> ... somebody who only knows how to write C++ [though he can do it in
> several different languages].

+1 QOTW (brilliant phrases in other threads are off topic and are
disqualified)

I have also suffered through such maintenance, but I have never described
it quite so succinctly.

> There was lot's of quiet swearing.

"Quiet" is *not* one of my strong points.

-- 
Dan

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

#83946

On Sat, 17 Jan 2015 19:08:21 +0000, Dan Sommers wrote:

> On Sat, 17 Jan 2015 18:44:42 +0000, Grant Edwards wrote:
> 
>> ... somebody who only knows how to write C++ [though he can do it in
>> several different languages].
> 
> +1 QOTW (brilliant phrases in other threads are off topic and are
> disqualified)
> 
> I have also suffered through such maintenance, but I have never
> described it quite so succinctly.
> 
>> There was lot's of quiet swearing.
> 
> "Quiet" is *not* one of my strong points.

How about "Some programmes have 20 years of experience, some have 1 year 
of experience 20 times"

it covers pretty much the same poor coding practices.

-- 
Ditat Deus.
	[God enriches]

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

#83866 — Factories and Builders [was Re: lambdak...]

Roy Smith wrote:

> The ebb and flow of technology has recently brought me someplace I never
> thought I'd be.  Java-land.  And what I've discovered is that factories
> are so last year.  Apparently builders are the new thing.


I've never really understand why "abstract factory", "factory method"
and "builder" are considered different design patterns. They're variants on
the same idea.

class Spam:
    def create(self, a, b, c, d):
        if a == "fast":
            theclass = FastClass
        elif a == "steady":
            theclass = SteadyClass
        obj = theclass(b, c, d)
        # obj.extra_stuff = self.get_stuff()
        return obj


As I understand it, if FastClass and SteadyClass are subclasses of Spam,
then this is the Factory Method design pattern, but if they are independent
classes unrelated to Spam, then it is the Abstract Factory design pattern.
But if I uncomment out the "obj.extra_stuff" line, it becomes a Builder.



-- 
Steven

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

#83900 — Re: Factories and Builders [was Re: lambdak...]

Steven D'Aprano wrote:
> I've never really understand why "abstract factory", "factory method"
> and "builder" are considered different design patterns. They're variants on
> the same idea.

I think it's because they address different problems. Factories
are for hiding the details of how an object is constructed.
Builders are for working around the fact that there are no
keyword arguments in your language.

Builders are sometimes also used for algorithmic reasons;
e.g. Java's StringBuilder exists to save you from O(n**2)
behaviour when creating a string from many small parts.

Factories of various kinds can be useful in Python;
builders, not so much.

-- 
Greg

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

#83867

On Thu, Jan 15, 2015 at 9:00 PM, Chris Angelico <rosuav@gmail.com> wrote:
> My first response was going to be "Well, you can always add another
> layer of indirection to try to solve your problem", but then I went
> and looked up builders on Wikipedia. Now I'm confused. What can you do
> with a builder that you can't do with a constructor?

In Java you have to write a separate constructor for every conceivable
combination of arguments. If there are a lot of optional arguments,
that's an exponentially large number of constructors. The builder
pattern provides a solution to that problem.

In Python you just have one initializer with defaults for the optional
arguments, so it's not an issue.

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

#83868

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

On 01/15/2015 09:29 PM, Ian Kelly wrote:
> 
> In Python you just have one initializer with defaults for the optional
> arguments, so it's not an issue.

What, Python makes it easy?  That must be a mistake somewhere!  ;)

--
~Ethan~

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

#83883

On 01/15/2015 10:29 PM, Ian Kelly wrote:
> On Thu, Jan 15, 2015 at 9:00 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> My first response was going to be "Well, you can always add another
>> layer of indirection to try to solve your problem", but then I went
>> and looked up builders on Wikipedia. Now I'm confused. What can you do
>> with a builder that you can't do with a constructor?
> 
> In Java you have to write a separate constructor for every conceivable
> combination of arguments. If there are a lot of optional arguments,
> that's an exponentially large number of constructors. The builder
> pattern provides a solution to that problem.
> 
> In Python you just have one initializer with defaults for the optional
> arguments, so it's not an issue.

Which seems to confirm my understanding that these patterns are in large
part a response to limitations in the language, which certainly doesn't
engender a fondness for the Java.

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

#83838

On Thursday, January 15, 2015 at 11:25:11 AM UTC+5:30, Yawar Amin wrote:
> 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.

Looked at your suggestions...
And then got distracted by your other project
https://github.com/yawaramin/vim-cute-python

Reminded me of what I had written some months ago along similar lines
http://blog.languager.org/2014/04/unicoded-python.html

At that time this was not suggested quite seriously.
Now I see that this can be realized at least partially
and on a personal level.

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

#83850

Hi,

On Thursday, January 15, 2015 at 12:19:31 PM UTC-5, Rustom Mody wrote:
> [...]
> Looked at your suggestions...
> And then got distracted by your other project
> https://github.com/yawaramin/vim-cute-python
> 
> Reminded me of what I had written some months ago along similar lines
> http://blog.languager.org/2014/04/unicoded-python.html
> 
> At that time this was not suggested quite seriously.
> Now I see that this can be realized at least partially
> and on a personal level.

Glad it was useful. Although let me clarify that I just forked the repo
from the original on GitHub, to publish my custom version. I have more
conservative tastes than the original, so I chose to keep the `in`, `not
in`, `and`, `or`, `not` keywords as is instead of using the symbols. I
did go through your blog post and got a previously-unused symbol out of
it: '÷' to represent '/'.

Regards,

Yawar

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

#83854

On Friday, January 16, 2015 at 7:48:20 AM UTC+5:30, Yawar Amin wrote:
> Hi,
> 
> On Thursday, January 15, 2015 at 12:19:31 PM UTC-5, Rustom Mody wrote:
> > [...]
> > Looked at your suggestions...
> > And then got distracted by your other project
> > https://github.com/yawaramin/vim-cute-python
> > 
> > Reminded me of what I had written some months ago along similar lines
> > http://blog.languager.org/2014/04/unicoded-python.html
> > 
> > At that time this was not suggested quite seriously.
> > Now I see that this can be realized at least partially
> > and on a personal level.
> 
> Glad it was useful. Although let me clarify that I just forked the repo
> from the original on GitHub, to publish my custom version. I have more
> conservative tastes than the original, so I chose to keep the `in`, `not
> in`, `and`, `or`, `not` keywords as is instead of using the symbols. I
> did go through your blog post and got a previously-unused symbol out of
> it: '÷' to represent '/'.

The more forks the merrier!

Let there be a hundred different versions, then people will 
begin to clamor against the non-necessity of the penury-of-ASCII:

http://blog.languager.org/2015/01/unicode-and-universe.html

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

#83855

On 16/01/2015 02:48, Rustom Mody wrote:
>
> The more forks the merrier!
>

When counting them, or more specifically handles, thou shalt not stop 
counting at three, but thou shalt continue to four, and thou shalt not 
continue on to five https://www.youtube.com/watch?v=Cz2-ukrd2VQ

-- 
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]

#83858

On Friday, January 16, 2015 at 8:33:14 AM UTC+5:30, Mark Lawrence wrote:
> On 16/01/2015 02:48, Rustom Mody wrote:
> >
> > The more forks the merrier!
> >
> 
> When counting them, or more specifically handles, thou shalt not stop 
> counting at three, but thou shalt continue to four, and thou shalt not 
> continue on to five https://www.youtube.com/watch?v=Cz2-ukrd2VQ

Ha Ha -- Thanks

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

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

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

csiph-web