Status of side-effecting functions in python

[Wolfgang Maier]

On 25.10.2014 19:27, Rustom Mody wrote:
> 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]]
>

As Chris and Steven have pointed out, picking print() as an example does 
not make too much sense since it returns None.
It may be rare to use an expression both for its side-effects and its 
return value, but, provided you document the intention appropriately, I 
do not see what would generally be wrong with it.

A quick example that's not quite as silly as all your print() ones:

 >>> with open('longnumber.txt', 'w') as out:
	print(sum(out.write(str(x)) for x in range(100)), 'characters written.')

	
190 characters written.