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

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

from future import pass_function

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

Contents

  from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-25 10:40 +0200
    Re: from future import pass_function Philipp Hagemeister <phihag@phihag.de> - 2012-07-25 12:30 +0200
    Re: from future import pass_function Nicholas Cole <nicholas.cole@gmail.com> - 2012-07-25 11:33 +0100
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-25 07:02 -0400
    Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-25 11:33 +0000
      Re: from future import pass_function Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-07-25 21:42 -0400
        Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 02:38 +0000
          Re: from future import pass_function Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-07-25 23:30 -0400
            Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-26 13:53 +1000
              Re: from future import pass_function Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-07-26 00:03 -0400
                Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-25 21:32 -0700
                  Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 13:55 -0700
                  Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-26 14:23 -0700
                    Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 15:20 -0700
                    Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 15:20 -0700
                  Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 13:55 -0700
                Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-26 08:43 +0100
            Re: from future import pass_function alex23 <wuwei23@gmail.com> - 2012-07-25 21:20 -0700
          Re: from future import pass_function Rusi <rustompmody@gmail.com> - 2012-07-25 22:09 -0700
          Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 08:59 +0200
            Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 09:26 +0000
              Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 13:45 +0200
                Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 15:21 +0000
                  Re: from future import pass_function Joel Goldstick <joel.goldstick@gmail.com> - 2012-07-26 12:55 -0400
                  RE: from future import pass_function "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-07-26 17:19 +0000
                  Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-27 03:33 +1000
                  Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-27 00:25 +0100
                  Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-27 00:23 +0100
        Re: from future import pass_function alex23 <wuwei23@gmail.com> - 2012-07-25 21:17 -0700
    Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-26 02:05 +1000
      Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 08:39 +0200
        Re: from future import pass_function Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-26 08:36 +0000
        Re: from future import pass_function Terry Reedy <tjreedy@udel.edu> - 2012-07-26 10:38 -0400
    Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-25 09:28 -0700
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-25 12:48 -0400
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-25 14:17 -0400
    Re: from future import pass_function Michael Hrivnak <mhrivnak@hrivnak.org> - 2012-07-26 01:20 -0400
      Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-26 08:42 +0200
        Re: from future import pass_function Michael Hrivnak <mhrivnak@hrivnak.org> - 2012-07-26 17:15 -0400
    Re: from future import pass_function Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-26 08:50 +0100
      Re: from future import pass_function Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-07-27 08:39 +0200
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-26 05:16 -0400
    Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-26 19:42 +1000
    Re: from future import pass_function Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-26 06:00 -0400
    Re: from future import pass_function rusi <rustompmody@gmail.com> - 2012-07-26 08:01 -0700
    Re: from future import pass_function Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-26 14:01 -0400
    Re: from future import pass_function Chris Angelico <rosuav@gmail.com> - 2012-07-27 04:14 +1000
    Re: from future import pass_function John Ladasky <john_ladasky@sbcglobal.net> - 2012-07-26 13:48 -0700
      Re: from future import pass_function Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-26 15:18 -0600
      Re: from future import pass_function Ethan Furman <ethan@stoneleaf.us> - 2012-07-26 15:35 -0700
      Re: from future import pass_function Terry Reedy <tjreedy@udel.edu> - 2012-07-27 00:21 -0400
    Re: from future import pass_function Michael Hrivnak <mhrivnak@hrivnak.org> - 2012-07-26 17:20 -0400

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

#26133

Am 26.07.2012 09:50, schrieb Mark Lawrence:
> And if we could persuade the BDFL to introduce braces, we could have {()
> and }()

What do you mean "persuade"? Braces work perfectly:

    def foo():
        {}

<grin, duck and run faster as the impacts get closer>

Uli

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

#26073

On Thu, Jul 26, 2012 at 1:20 AM, Michael Hrivnak <mhrivnak@hrivnak.org> wrote:
> If we want pass(), then why not break() and continue()?  And also
> def() and class()?  for(), while(), if(), with(), we can make them all
> callable objects!

No, you actually can't.

You omit the one control flow statement that could actually be turned
into a function, raise. None of the rest could in Python (except
class), and one of the rest couldn't in any language (def).

-- Devin

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

#26075

On Thu, Jul 26, 2012 at 7:16 PM, Devin Jeanpierre
<jeanpierreda@gmail.com> wrote:
> On Thu, Jul 26, 2012 at 1:20 AM, Michael Hrivnak <mhrivnak@hrivnak.org> wrote:
>> If we want pass(), then why not break() and continue()?  And also
>> def() and class()?  for(), while(), if(), with(), we can make them all
>> callable objects!
>
> No, you actually can't.
>
> You omit the one control flow statement that could actually be turned
> into a function, raise. None of the rest could in Python (except
> class), and one of the rest couldn't in any language (def).

Well, if/while/for could be functions. So could with, probably. Now,
def would be a little tricky...

ChrisA

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

#26077

On Thu, Jul 26, 2012 at 5:42 AM, Chris Angelico <rosuav@gmail.com> wrote:
>> You omit the one control flow statement that could actually be turned
>> into a function, raise. None of the rest could in Python (except
>> class), and one of the rest couldn't in any language (def).
>
> Well, if/while/for could be functions. So could with, probably. Now,
> def would be a little tricky...

In Haskell, sure.

-- Devin

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

#26097

On Jul 25, 1:40 pm, Ulrich Eckhardt <ulrich.eckha...@dominolaser.com>
wrote:
> Hi!
>
> I just had an idea, it occurred to me that the pass statement is pretty
> similar to the print statement, and similarly to the print() function,
> there could be a pass() function that does and returns nothing.
>
> Example:
>     def pass():
>         return

Since many have said NO but I see no good reasons for this no yet,
here's mine:

tl;dr version: Do-nothing statements are easy just do nothing, ie
pass.
Do-nothing expressions are hard. In the fully generic context they are
impossible to implement.

Longer version:

Consider the if expression and the if statement. The if statement can
have its else part elided in which case it defaults to pass.  The if
expression cannot so elide. Why?

Consider the expression: (exp if cond)  # no else
Now in "x + (exp if cond)" if cond is false it should presumably be 0
However in "x * (exp if cond)" it should presumably be 1?
And in the first case if x were a list should it not be [] ?

Now consider your suggestion:
def pass(): return
is identical to
def pass(): return None

So you are saying that None can serve as a "generic zero"?
Of course as you know (no suggestion that you are a noob on my part!!)

Python 2.7.3rc2 (default, Apr 22 2012, 22:35:38)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0+3
3
>>> None+3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
>>> None+[1,2,3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'NoneType' and 'list'
>>>

So now you (may) retort but these have nothing to do with what you
asked.

You see what youve asked for is moving pass from the statement world
to the expression world.
The meaning of a do-nothing statement is easy to give.  The meaning of
a do-nothing expression is hard because we are obliged to specify a
type for expressions and the only value that can possibly belong to
all types is the error-value (what denotational semantics calls bottom
⊥ )

A more laymanish example:
I have a multiplication
I want one of the operands to be a 1, ie the identity
I substitute it with the nearest available value ie 0

And out goes the baby with the bathwater!

So to come back to your proposal:

> there could be a pass() function that does and returns nothing.

does nothing: easy
returns nothing: impossible (None is not "nothing", its more like
"error")

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

#26104

On Thu, 26 Jul 2012 19:42:11 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:


> Well, if/while/for could be functions. So could with, probably. Now,
> def would be a little tricky...
>
	And how would a function "if" perform

	if(conditional):
would become
	True:
or
	False:

	What determines that branching is desired? The colon? (then what
does the colon on "def x():" perform?)

	Or take "while"...

	while condition: #implies a loop

	while(condition): #as a function implies a return value so again we
have

	True:
or
	False:

	Now, how does the language differentiate between a loop and an if?

	if(conditional):
		do something and continue with next statement

turns into
	True:
		do something and continue with next statement

while

	while(conditional):
		do something and go back to the test

turns into
	True:
		do something and go back to the test



-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#26107

On Fri, Jul 27, 2012 at 4:01 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Thu, 26 Jul 2012 19:42:11 +1000, Chris Angelico <rosuav@gmail.com>
> declaimed the following in gmane.comp.python.general:
>
>> Well, if/while/for could be functions. So could with, probably. Now,
>> def would be a little tricky...
>>
>         And how would a function "if" perform

It'd be much more similar to the ternary operator. Currently there's
no way to pass an unevaluated expression to a Python function, but the
concept isn't impossible. It's just more suited to functional
languages (someone mentioned Haskell) than to imperative ones.

>         Now, how does the language differentiate between a loop and an if?
>
>         if(conditional):
>                 do something and continue with next statement
>
> turns into
>         True:
>                 do something and continue with next statement
>
> while
>
>         while(conditional):
>                 do something and go back to the test
>
> turns into
>         True:
>                 do something and go back to the test

Oh THAT's easily solved. A while loop is an if with a goto!

Okay, was that sufficiently incendiary? Have fun! :)

ChrisA

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

#26113

On Wednesday, July 25, 2012 1:40:45 AM UTC-7, Ulrich Eckhardt wrote:
> Hi!
> 
> I just had an idea, it occurred to me that the pass statement is pretty 
> similar to the print statement, and similarly to the print() function, 
> there could be a pass() function that does and returns nothing.

I had very similar thoughts about eight months ago, and posted them here:

https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A

I'm no computer science guru, but the idea that pass should be a function rather than a statement continues to appeal to me.  As you can see, I actually wrote just such a function so that I could use it as an argument in my code.

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

#26118

On Thu, Jul 26, 2012 at 2:48 PM, John Ladasky
<john_ladasky@sbcglobal.net> wrote:
> On Wednesday, July 25, 2012 1:40:45 AM UTC-7, Ulrich Eckhardt wrote:
>> Hi!
>>
>> I just had an idea, it occurred to me that the pass statement is pretty
>> similar to the print statement, and similarly to the print() function,
>> there could be a pass() function that does and returns nothing.
>
> I had very similar thoughts about eight months ago, and posted them here:
>
> https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A
>
> I'm no computer science guru, but the idea that pass should be a function rather than a statement continues to appeal to me.  As you can see, I actually wrote just such a function so that I could use it as an argument in my code.

As long as 1) the name can't be reassigned (like None) and 2) the
compiler is able to optimize it out when used by itself as a statement
(to avoid incurring the expense of a common but pointless name
lookup), then I kind of agree.  The added complexity of those two
restrictions detracts a bit from the appeal to elegance, though.

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

#26124

John Ladasky wrote:
> I had very similar thoughts about eight months ago, and posted them here:
> 
> https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A
> 
> I'm no computer science guru, but the idea that pass should be a function rather than a statement continues to appeal to me.  As you can see, I actually wrote just such a function so that I could use it as an argument in my code.

I would have called `no_op` or `nop` -- `pass` does just what it says: 
it passes and does zero work.  Your _pass does do work, just useless 
work.  Sometimes that's necessary, but I wouldn't call it `_pass`.

~Ethan~

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

#26132

On 7/26/2012 4:48 PM, John Ladasky wrote:

> I had very similar thoughts about eight months ago, and posted them
> here:
>
> https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/CB_5fek2b8A
>
>  I'm no computer science guru, but the idea that pass should be a
> function rather than a statement continues to appeal to me.

A do nothing statement is standard in statement based languages. It is 
not going away.

> can see, I actually wrote just such a function so that I could use it
> as an argument in my code.

For one time use: lambda:None

For multiple use: def none: pass  # same as return None in this context

A function needs a lot more meat than that to be added as a builtin.

---
Terry Jan Reedy

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

#26119

In case the rest of the email didn't make it obvious, everything you
quoted me on was sarcasm.  I know those things can't be done, and I
explained why they can't and shouldn't be done.

Michael

On Thu, Jul 26, 2012 at 5:16 AM, Devin Jeanpierre
<jeanpierreda@gmail.com> wrote:
> On Thu, Jul 26, 2012 at 1:20 AM, Michael Hrivnak <mhrivnak@hrivnak.org> wrote:
>> If we want pass(), then why not break() and continue()?  And also
>> def() and class()?  for(), while(), if(), with(), we can make them all
>> callable objects!
>
> No, you actually can't.
>
> You omit the one control flow statement that could actually be turned
> into a function, raise. None of the rest could in Python (except
> class), and one of the rest couldn't in any language (def).
>
> -- Devin

[toc] | [prev] | [standalone]

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

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

csiph-web