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

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

Function passed as an argument returns none

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

Contents

  Function passed as an argument returns none Shiva <shivaji_tn@yahoo.com> - 2014-10-01 22:37 +0000
    Re: Function passed as an argument returns none Denis McMahon <denismfmcmahon@gmail.com> - 2014-10-02 00:23 +0000
    Re: Function passed as an argument returns none Rustom Mody <rustompmody@gmail.com> - 2014-10-01 19:29 -0700
      Re: Function passed as an argument returns none Chris Angelico <rosuav@gmail.com> - 2014-10-02 14:02 +1000
        Re: Function passed as an argument returns none Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-02 17:59 +1000
          Re: Function passed as an argument returns none cl@isbd.net - 2014-10-02 10:43 +0100
            Re: Function passed as an argument returns none Rustom Mody <rustompmody@gmail.com> - 2014-10-02 04:30 -0700
          Re: Function passed as an argument returns none Rustom Mody <rustompmody@gmail.com> - 2014-10-02 04:38 -0700
            Re: Function passed as an argument returns none Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-03 10:10 +1000
              Re: Function passed as an argument returns none Rustom Mody <rustompmody@gmail.com> - 2014-10-02 18:49 -0700
                Re: Function passed as an argument returns none Chris Angelico <rosuav@gmail.com> - 2014-10-03 12:08 +1000

#78567 — Function passed as an argument returns none

Hi,
I am learning Python (version 3.4) strings.I have a function that takes in a
parameter and prints it out as given below.

def donuts(count):
  if count <= 5:
    print('Number of donuts: ',count)
  else:
    print('Number of donuts: many')
    return

It works fine if I call 
donuts(5)

It returns:
we have 5 DN  (as expected)

However if I do :

test(donuts(4), 'Number of donuts: 4')


where test is defined as below:

def test(got, expected):
  print('got: ', got, 'Expected:' ,expected)
  if got == expected:
    prefix = ' OK '
  else:
    prefix = '  X '
  print (('%s got: %s expected: %s') % (prefix, repr(got), repr(expected)))


Only 'None' gets passed on to parameter 'got' instead of the expected value
of 4.
Any idea why 'None' is getting passed even though calling the donuts(4)
alone returns the expected value?

Thanks,
Shiva.

[toc] | [next] | [standalone]

#78572

On Wed, 01 Oct 2014 22:37:13 +0000, Shiva wrote:

> Hi,
> I am learning Python (version 3.4) strings.I have a function that takes
> in a parameter and prints it out as given below.
> 
> def donuts(count):
>   if count <= 5:
>     print('Number of donuts: ',count)
>   else:
>     print('Number of donuts: many') return
> 
> It works fine if I call donuts(5)
> 
> It returns:

No it doesn't

> we have 5 DN  (as expected)

It doesn't return anything, it prints something out.

Printing something out from within a function is not the same as 
returning something.

Consider the following::

def nonsense( something ):
    print( "something is", something )
    return ( 5, "elephants", { "monkey": "peanut", "baboon": 
             "banana", "numbers": ( 1, ), }, [ 1, 2, 3, 4, 5, 
             "mouse",( -6.34565e-35, 4.765213e84, ), ], 
             None, True, False, )

print( "nonsense( 10 ) is", nonsense( 10 ) )
print( "nonsense( None ) is", nonsense( None ) )
print( "nonsense( ( 5, \"donuts\", ) ) is", nonsense( ( 5, "donuts", ) ) )

The above code shows there is no automatic connection between data output 
carried out within a function and the value (if any) returned by that 
function.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#78574

On Thursday, October 2, 2014 4:07:44 AM UTC+5:30, Shiva wrote:
> Hi,
> I am learning Python (version 3.4) strings.I have a function that takes in a
> parameter and prints it out as given below.

> def donuts(count):
>   if count <= 5:
>     print('Number of donuts: ',count)
>   else:
>     print('Number of donuts: many')
>     return

> It works fine if I call 
> donuts(5)

> It returns:
> we have 5 DN  (as expected)

> However if I do :

> test(donuts(4), 'Number of donuts: 4')

> where test is defined as below:

> def test(got, expected):
>   print('got: ', got, 'Expected:' ,expected)
>   if got == expected:
>     prefix = ' OK '
>   else:
>     prefix = '  X '
>   print (('%s got: %s expected: %s') % (prefix, repr(got), repr(expected)))

> Only 'None' gets passed on to parameter 'got' instead of the expected value
> of 4.
> Any idea why 'None' is getting passed even though calling the donuts(4)
> alone returns the expected value?

Others have given you the correct python-technicalities answer: 

print ≠ return

However given your starting point – I am learning Python – let me try 
a less technical one.

You start from the assumption that your donuts returns 5, which it
seems to in some contexts and not in others.

So by now you know there are 2 kinds of return:

>>> def foo(x): return x+5
... 
>>> def bar(x): print(x+5)
... 
>>> foo(4)
9
>>> bar(4)
9


So they seem identical here, right?

But as you further discover bar is useless to do anything other than
being called at the command line, whereas foo can be used in all sorts of 
ways: in particular you can use foo to write bar:

def bar(x): print(foo(x))

But not conversely.

So the morals in short: 

1. Stick to the return that works -- python's return statement --
and avoid the return that seems to work -- the print statement
2. print is good for debugging code. When your code is bugfree it should have
few/no prints
3. The official tutorial/docs unfortunately foster bad habits in children by showing prints early --
Know better!

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

#78576

On Thu, Oct 2, 2014 at 12:29 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> So by now you know there are 2 kinds of return:
>
> So the morals in short:
>
> 1. Stick to the return that works -- python's return statement --
> and avoid the return that seems to work -- the print statement

Please. There are not two types of return; there are two completely
different things here. Don't pretend that print is a bad form of
return. It isn't.

ChrisA

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

#78585

Chris Angelico wrote:

> On Thu, Oct 2, 2014 at 12:29 PM, Rustom Mody <rustompmody@gmail.com>
> wrote:
>> So by now you know there are 2 kinds of return:
>>
>> So the morals in short:
>>
>> 1. Stick to the return that works -- python's return statement --
>> and avoid the return that seems to work -- the print statement
> 
> Please. There are not two types of return; there are two completely
> different things here. Don't pretend that print is a bad form of
> return. It isn't.

I strongly agree with Chris here. The OP's problem was due to confusion
between print and return, and the solution is to learn the difference
between printing output to the screen and returning values from a function,
and under what circumstances Python will automatically print said returned
values as a convenience. Conflating the two as "2 kinds of return" is an
invitation to even more confusion: "which was the 'good' return again?".

While it is true that both return and print are related in the sense that
they are both ways of having a function produce output, that's about the
end of the similarity. One might as well say that assignment is a third
kind of return, because one can assign output to a global variable.

(Since print does not actually exit the current sub-routine, it definitively
is not a kind of return.)


-- 
Steven

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

#78591

Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> between printing output to the screen and returning values from a function,
> and under what circumstances Python will automatically print said returned
> values as a convenience. Conflating the two as "2 kinds of return" is an

To me automically printing something is a mis-feature!

-- 
Chris Green
·

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

#78597

On Thursday, October 2, 2014 3:18:22 PM UTC+5:30, wrote:
> Steven D'Aprano  wrote:
> > between printing output to the screen and returning values from a function,
> > and under what circumstances Python will automatically print said returned
> > values as a convenience. Conflating the two as "2 kinds of return" is an

> To me automatically printing something is a mis-feature!

Hehe! Nice one!

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

#78598

On Thursday, October 2, 2014 1:30:03 PM UTC+5:30, Steven D'Aprano wrote:
> Chris Angelico wrote:

> > wrote:
> >> So by now you know there are 2 kinds of return:
> >> So the morals in short:
> >> 1. Stick to the return that works -- python's return statement --
> >> and avoid the return that seems to work -- the print statement
> > Please. There are not two types of return; there are two completely
> > different things here. Don't pretend that print is a bad form of
> > return. It isn't.

> I strongly agree with Chris here. The OP's problem was due to confusion
> between print and return, and the solution is to learn the difference
> between printing output to the screen and returning values from a function,
> and under what circumstances Python will automatically print said returned
> values as a convenience. Conflating the two as "2 kinds of return" is an
> invitation to even more confusion: "which was the 'good' return again?".

Right and the OP subject as well as post are essentially that conflation:

> Any idea why 'None' is getting passed even though calling the donuts(4)
> alone returns the expected value?

And further if you consider that the explanations have aided, here's the most
recent 'conclusion':

> * return 'Number of donuts: ',count    returns a tuple like:
> ('Number of donuts: ',9)

> * To just print the string without returning it as tuple , use string
> formatting. 

You find this understanding satisfactory??

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

#78630

Rustom Mody wrote:

> On Thursday, October 2, 2014 1:30:03 PM UTC+5:30, Steven D'Aprano wrote:
>> Chris Angelico wrote:
> 

Restoring the attribution line you removed:
On Thu, Oct 2, 2014 at 12:29 PM, Rustom Mody <rustompmody@gmail.com>
wrote:
>> >> So by now you know there are 2 kinds of return:
>> >> So the morals in short:
>> >> 1. Stick to the return that works -- python's return statement --
>> >> and avoid the return that seems to work -- the print statement

[Chris]
>> > Please. There are not two types of return; there are two completely
>> > different things here. Don't pretend that print is a bad form of
>> > return. It isn't.

[Steven] 
>> I strongly agree with Chris here. The OP's problem was due to confusion
>> between print and return, and the solution is to learn the difference
>> between printing output to the screen and returning values from a
>> function, and under what circumstances Python will automatically print
>> said returned values as a convenience. Conflating the two as "2 kinds of
>> return" is an invitation to even more confusion: "which was the 'good'
>> return again?".

[Rustom]
> Right and the OP subject as well as post are essentially that conflation:
> 
[allegedly Steven]
>> Any idea why 'None' is getting passed even though calling the donuts(4)
>> alone returns the expected value?

I didn't write that. I don't know who you are quoting, but it isn't me.

[Rustom]
> And further if you consider that the explanations have aided, here's the
> most recent 'conclusion':
> 
[allegedly Steven]
>> * return 'Number of donuts: ',count    returns a tuple like:
>> ('Number of donuts: ',9)

And again, despite you attributing this to me, I did not write that.

[allegedly Steven]
>> * To just print the string without returning it as tuple , use string
>> formatting.
> 
[Rustom]
> You find this understanding satisfactory??

And that's the third time in one post that you have attributed something
written by somebody else to me.

Rustom, I don't consider this blatant misattribution of other people's words
to me is acceptable behaviour. I don't believe that somebody with your
demonstrated competence at following email and usenet quoting conventions
is unaware that you are attributing other people's comments to me. I would
be inclined to chalk it up to an innocent mistake if not for the deliberate
removal of the attribution line showing *your* advice to the OP to consider
print one of "2 kinds of return".

The original poster was confused about the difference between return and
print. You replied by reinforcing that confusion, explicitly stating that
print is a kind of return (it isn't). I don't hold that against you --
making an ill-thought-out comment in good faith is not a sin.

But in your response to my criticism of that reply, you removed the
attribution to yourself, then agreed with me ("Right") and implied that
*your* comment about there being two kinds of return was the OP's
confusion. To me, that looks like a deliberate, but feeble and pathetic,
attempt to deflect criticism of your advice to the OP onto the OP. If true,
that's a low and sordid thing to do.

Your response to Shiva, the Original Poster:
https://mail.python.org/pipermail/python-list/2014-October/678978.html

Chris' response to you, with attribution line intact:
https://mail.python.org/pipermail/python-list/2014-October/678979.html

My response to Chris, with attribution line intact:
https://mail.python.org/pipermail/python-list/2014-October/678988.html

Your response to me, with attribution line deleted, and misattributing other
people's comments to me:
https://mail.python.org/pipermail/python-list/2014-October/679001.html



-- 
Steven

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

#78631

On Friday, October 3, 2014 5:41:12 AM UTC+5:30, Steven D'Aprano wrote:

> [Rustom]
> > Right and the OP subject as well as post are essentially that conflation:
> [allegedly Steven]
> >> Any idea why 'None' is getting passed even though calling the donuts(4)
> >> alone returns the expected value?

> I didn't write that. I don't know who you are quoting, but it isn't me.


Are you for real Steven??

Ok so there is no conventional attribution line because it was
cut-pasted from elsewhere in the thread but there is a clear
and unequivocal prefix of "OP subject as well as post".

Why/how should there be any ambiguity that that is Shiva??

Since you are merrily throwing around mis-attribution charges please explain the logic by which "Steven" == "OP"

Or are not aware OP means 'original post(er)'?

Likewise all the below '[allegedly Steven]s'...

> [Rustom]
> > And further if you consider that the explanations have aided, here's the
> > most recent 'conclusion':
> [allegedly Steven]
> >> * return 'Number of donuts: ',count    returns a tuple like:
> >> ('Number of donuts: ',9)

> And again, despite you attributing this to me, I did not write that.

> [allegedly Steven]
> >> * To just print the string without returning it as tuple , use string
> >> formatting.
> [Rustom]
> > You find this understanding satisfactory??

> And that's the third time in one post that you have attributed something
> written by somebody else to me.

> Rustom, I don't consider this blatant misattribution of other people's words
> to me is acceptable behaviour.

And what kind of conversation is it if I ask you

> > You find this understanding satisfactory??

as a question ABOUT you?

How you are able to confuse a question addressed TO you into a question
ABOUT you is beyond me.

Did you run out of your morning coffee or somethin?

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

#78632

On Fri, Oct 3, 2014 at 11:49 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> Ok so there is no conventional attribution line because it was
> cut-pasted from elsewhere in the thread but there is a clear
> and unequivocal prefix of "OP subject as well as post".

When I respond to this part...

> Why/how should there be any ambiguity that that is Shiva??

... and then to this, the normal assumption is that, since both are at
the same indentation level, they're both covered by the same heading
line. Compare:

def rustom():
    yield "... there is no conventional ..."
    yield "... elsewhere in the thread ..."
    yield "... unequivocal ..."

# I respond to this...

    yield "... any ambiguity ..."

# Is there any expectation that the above line of code isn't part of
the same function?

And there IS an unequivocal prefix of "OP subject as well as post". It
looks like this:

On Thu, Oct 2, 2014 at 8:37 AM, Shiva
<shivaji_tn@yahoo.com.dmarc.invalid> wrote:
> Any idea why 'None' is getting passed even though calling the donuts(4)
> alone returns the expected value?

And there's even an unambiguous way to indicate that you're responding
to the original poster, but not the original post. Watch!

On Thu, Oct 2, 2014 at 6:46 PM, Shiva
<shivaji_tn@yahoo.com.dmarc.invalid> wrote:
> * return 'Number of donuts: ',count    returns a tuple like:
> ('Number of donuts: ',9)

I can correctly attribute every piece that I respond to. It's really
not hard. In this particular case, I opened two additional replies,
and copied and pasted the bits I want into this reply. Some people
short-cut it, when they're responding to separate posts, and just do
something like this:

[Rustom Mode]
> Are you for real Steven??

Complete with a demonstration of what happens all too often when
things are done manually: a spelling error in the attribution line.
It's still unambiguous as to who wrote what, though a little less
helpful as regards chronology.

Attribution lines are part of being honest about who said what. I
wouldn't say that your post was evidence of malicious intent, but it
was sloppiness that led to an easily misunderstood post. On rereading,
I can see that you did try to indicate (by your text) that it was
meant to be followed by the OP's words, but you didn't put that into
the structure, and you certainly didn't distinguish between the
original post and the one made a little bit later. Please, if you
don't want to be called out for misattribution, just be a bit more
careful. It doesn't take a huge amount of effort.

ChrisA

[toc] | [prev] | [standalone]

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

csiph-web