Status of side-effecting functions in python

Rustom Mody rustompmody at gmail.com
Sat Oct 25 19:27:40 CEST 2014


Moved from other (Seymore's) thread where this is perhaps not relevant

On Saturday, October 25, 2014 1:15:09 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
> 
> > On Saturday, October 25, 2014 11:20:03 AM UTC+5:30, Chris Angelico wrote:
> >> On Sat, Oct 25, 2014 at 4:40 PM, Rustom Mody  wrote:
> >> > Its generally accepted that side-effecting functions are not a good
> >> > idea -- typically a function that returns something and changes global
> >> > state.
> >> 
> >> Only in certain circles. Not in Python. There are large numbers of
> >> functions with side effects (mutator methods like list.append,
> >> anything that needs lots of state like random.random, everything with
> >> external effect like I/O, heaps of stuff), and it is most definitely
> >> not frowned upon.
> >> 
> >> In Python 3 (or Python 2 with the future directive), print is a
> >> function, print() an expression. It's not "semantically a statement".
> > 
> > Ok
> > So give me a valid (ie useful) use where instead of the usual
> > l=[1,2,3]
> > l.append(4)
> > 
> > we have
> > 
> > foo(l.append(4))
> 
> Your question seems to be non-sequitor. To me, it doesn't appear to have any
> relationship to Chris' comments.

| Languages like Pascal (many others)... distinguish function which return
| results and procedure which do not...
| Extract from https://en.wikipedia.org/wiki/Subroutine#Language_support

So my point: Whether the language supports it strongly (Pascal'
procedures) weakly (C's void functions) more weakly (Python's None
returning functions), the beginning programmer needs this concept as a core
thinking tool.

Pascal makes this easy -- teach the syntax and the concept will get across
Python is harder because the concept does not correlate with any specific syntax
But its not all that hard unless the teacher is stuck in correlating core concepts
and language syntax.

A teacher who is so stuck is cheating the student.

My version: 
"print may (3) or may not (2) be an expression. Just always consider it as a statement"

Chris version: print() is an expression. 
Technically Chris is correct. Is it methodologically/pedagogically it is sound?

Consider:

>From my explanation this:

>>> [print(x) for x in [1,2,3]]
1
2
3
[None, None, None]
>>> 

is in "Dont Do!" category whether python (3) allows it or python 2 doesn't.
And you "Dont do" because print(x) is a statement -- literally in
python 2; morally in python 3

And from here its only a small step to why l.append(4) should never
be used except as a statement. Python may not literally have Pascal's procedures;
they are morally there if you choose to 'believe' in them.

How would Chris inculcate avoidance of code-smells like
- foo(l.append(4))
- [print(x) for x in [1,2,3]]

  ?

No idea!

I dare say: about print I dont know but
[foo(x) for x in lst]
and foo is used for effect not return-value is
a rather common code-smell in my experience



More information about the Python-list mailing list