«

Hi folks,

I'm trying to write tidy, modular code which includes a long-running process. From time to time I MIGHT like to check in on the progress being made by that long-running process, in various ways. Other times, I'll just want to let it run. So I have a section of code which, generally, looks like this:

def _pass(*args):
pass

def long_running_process(arg1, arg2, arg_etc, report = _pass):
result1 = do_stuff()
report(result1)
result2 = do_some_different_stuff()
report(result2)
result3 = do_even_more_stuff()
report(result3)
return result3

This does what I want. When I do not specify a report function, the process simply runs. Typically, when I do supply a report function, it would print something to stdout, or draw an update through a GUI.

But this approach seems a tad cumbersome and unPythonic to me, particularlythe part where I define the function _pass() which accepts an arbitrary argument list, and does nothing but... pass.

This has led me to ask the question, what exactly IS pass? I played with the interpreter a bit.

IDLE 2.6.6 ==== No Subprocess ====
>>> pass
>>> pass()
SyntaxError: invalid syntax
>>> type(pass)
SyntaxError: invalid syntax

So, pass does not appear to be a function, nor even an object. Is it nothing more than a key word?

And would there be any merit to having some syntactic sugar which allows pass to behave like the _pass() function I wrote, if it were called?

As you can see, I'm programming in Python 2.6. I don't know whether pass is handled differently in Python 3.

On Thu, Nov 17, 2011 at 6:18 PM, John Ladasky <> wrote:
> Hi folks,
>
> I'm trying to write tidy, modular code which includes a long-running process. Â*From time to time I MIGHT like to check in on the progress beingmade by that long-running process, in various ways. Â*Other times, I'll just want to let it run. Â*So I have a section of code which, generally, looks like this:
>
> def _pass(*args):
> Â* Â*pass
>
> def long_running_process(arg1, arg2, arg_etc, report = _pass):
> Â* Â*result1 = do_stuff()
> Â* Â*report(result1)
> Â* Â*result2 = do_some_different_stuff()
> Â* Â*report(result2)
> Â* Â*result3 = do_even_more_stuff()
> Â* Â*report(result3)
> Â* Â*return result3
>
> This does what I want. Â*When I do not specify a report function, theprocess simply runs. Â*Typically, when I do supply a report function, it would print something to stdout, or draw an update through a GUI.
>
> But this approach seems a tad cumbersome and unPythonic to me, particularly the part where I define the function _pass() which accepts an arbitrary argument list, and does nothing but... pass.

Seems fine to me (good use of the null object pattern), although I
might define _pass() to instead take exactly 1 argument, since that's
all you ever call report() with in your example.

> This has led me to ask the question, what exactly IS pass? Â*I playedwith the interpreter a bit.
>
> IDLE 2.6.6 Â* Â* Â*==== No Subprocess ====
>>>> pass
>>>> pass()
> SyntaxError: invalid syntax
>>>> type(pass)
> SyntaxError: invalid syntax
>
> So, pass does not appear to be a function, nor even an object. Â*Is it nothing more than a key word?

Correct:
http://docs.python.org/reference/simple_stmts.html#pass
http://docs.python.org/reference/lex....html#keywords

Cheers,
Chris

On 11/17/2011 6:45 PM, Chris Rebert wrote:
> On Thu, Nov 17, 2011 at 6:18 PM, John Ladasky<> wrote:
>> Hi folks,
>>
>> I'm trying to write tidy, modular code which includes a long-running process. From time to time I MIGHT like to check in on the progress being made by that long-running process, in various ways. Other times, I'll just want to let it run. So I have a section of code which, generally, looks like this:
>>
>> def _pass(*args):
>> pass
>>
>> def long_running_process(arg1, arg2, arg_etc, report = _pass):
>> result1 = do_stuff()
>> report(result1)
>> result2 = do_some_different_stuff()
>> report(result2)
>> result3 = do_even_more_stuff()
>> report(result3)
>> return result3
>>
>> This does what I want. When I do not specify a report function, the process simply runs. Typically, when I do supply a report function, it would print something to stdout, or draw an update through a GUI.
>>
>> But this approach seems a tad cumbersome and unPythonic to me, particularly the part where I define the function _pass() which accepts an arbitrary argument list, and does nothing but... pass.
>
> Seems fine to me (good use of the null object pattern), although I
> might define _pass() to instead take exactly 1 argument, since that's
> all you ever call report() with in your example.
>
>> This has led me to ask the question, what exactly IS pass? I played with the interpreter a bit.
>>
>> IDLE 2.6.6 ==== No Subprocess ====
>>>>> pass
>>>>> pass()
>> SyntaxError: invalid syntax
>>>>> type(pass)
>> SyntaxError: invalid syntax
>>
>> So, pass does not appear to be a function, nor even an object. Is it nothing more than a key word?
>
It is a keyword that can appear in a position where a statement is
required by the grammar but there is nothing to do. For example if ..
then .. else .. where nothing happens in the else condition is effectively:

if <condition>:
<then-part>
else:
pass

Bourne shell has a similar construct with the colon statement :

Another python example is where you need to catch an exception (or all
exceptions but don't actually care about what they are)

try:
<european swallows>
except:
pass

> Correct:
> http://docs.python.org/reference/simple_stmts.html#pass
> http://docs.python.org/reference/lex....html#keywords
>
> Cheers,
> Chris


--
Dominic Binks:
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

On Thu, 17 Nov 2011 18:18:11 -0800 (PST), John Ladasky
<> declaimed the following in
gmane.comp.python.general:

> I'm trying to write tidy, modular code which includes a long-running process. From time to time I MIGHT like to check in on the progress being made by that long-running process, in various ways. Other times, I'll just want to let it run. So I have a section of code which, generally, looks like this:
>
> def _pass(*args):
> pass
>
This is the equivalent of

def _pass(*args):
return None

(functions with no explicit return statement implicitly return None)

> def long_running_process(arg1, arg2, arg_etc, report = _pass):
> result1 = do_stuff()
> report(result1)

So this is a call to a function that just returns a None, which is
dropped by the interpreter...

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

On Thursday, November 17, 2011 6:45:58 PM UTC-8, Chris Rebert wrote:

> Seems fine to me (good use of the null object pattern), although I
> might define _pass() to instead take exactly 1 argument, since that's
> all you ever call report() with in your example.

Oops, I over-simplified the calls to my report() function. The truth is that report() can accept a variable argument list too.

On Thursday, November 17, 2011 6:45:58 PM UTC-8, Chris Rebert wrote:

> Seems fine to me (good use of the null object pattern), although I
> might define _pass() to instead take exactly 1 argument, since that's
> all you ever call report() with in your example.

Oops, I over-simplified the calls to my report() function. The truth is that report() can accept a variable argument list too.

On Thursday, November 17, 2011 8:34:22 PM UTC-8, Dennis Lee Bieber wrote:
> On Thu, 17 Nov 2011 18:18:11 -0800 (PST), John Ladasky
> <lad...@my-deja.com> declaimed the following in
> gmane.comp.python.general:
> > def _pass(*args):
> > pass
> >
> This is the equivalent of
>
> def _pass(*args):
> return None
>
> (functions with no explicit return statement implicitly return None)

OK, that works for me, and now I understand.

One of my questions was: would there be any merit to having the Python "pass" token itself defined exactly as _pass() is defined above?

On Thursday, November 17, 2011 8:34:22 PM UTC-8, Dennis Lee Bieber wrote:
> On Thu, 17 Nov 2011 18:18:11 -0800 (PST), John Ladasky
> <lad...@my-deja.com> declaimed the following in
> gmane.comp.python.general:
> > def _pass(*args):
> > pass
> >
> This is the equivalent of
>
> def _pass(*args):
> return None
>
> (functions with no explicit return statement implicitly return None)

OK, that works for me, and now I understand.

One of my questions was: would there be any merit to having the Python "pass" token itself defined exactly as _pass() is defined above?

On Fri, Nov 18, 2011 at 4:07 PM, John Ladasky <> wrote:
> One of my questions was: would there be any merit to having the Python "pass" token itself defined exactly as _pass() is defined above?

No, there wouldn't. The Python 'pass' statement is a special statement
that indicates a lack of anything to execute; a dummy function call
isn't this. What I would kinda like to see, though, is function
versions of many things. Your basic operators exist in the 'operator'
module, but the syntax is rather clunky; for comparison, Pike has
beautifully simple (if a little cryptic) syntax: back-tick followed by
the operator itself, very similar to the way C++ does operator
overloading.

In Python 2, back-tick has a special meaning. In Python 3, that
meaning is removed. Is the character now available for this
"function-version" syntax?

ChrisA

On Thu, Nov 17, 2011 at 9:34 PM, Chris Angelico <> wrote:
> On Fri, Nov 18, 2011 at 4:07 PM, John Ladasky <> wrote:
>> One of my questions was: would there be any merit to having the Python "pass" token itself defined exactly as _pass() is defined above?
>
> No, there wouldn't. The Python 'pass' statement is a special statement
> that indicates a lack of anything to execute; a dummy function call
> isn't this. What I would kinda like to see, though, is function
> versions of many things. Your basic operators exist in the 'operator'
> module, but the syntax is rather clunky; for comparison, Pike has
> beautifully simple (if a little cryptic) syntax: back-tick followed by
> the operator itself, very similar to the way C++ does operator
> overloading.
>
> In Python 2, back-tick has a special meaning. In Python 3, that
> meaning is removed. Is the character now available for this
> "function-version" syntax?

Negative. I know this from personal experience.

Things that will Not Change in Python 3000
(http://www.python.org/dev/peps/pep-3099/ ):
"No more backticks."

Cheers,
Chris R.