Procedures and functions [was Re: Why not allow empty code blocks?]
Rustom Mody
rustompmody at gmail.com
Sun Jul 31 02:47:38 EDT 2016
On Sunday, July 31, 2016 at 12:10:33 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 31 Jul 2016 02:01 pm, D'Arcy J.M. Cain wrote:
>
> > On Sun, 31 Jul 2016 13:32:16 +1000
> > Steven D'Aprano wrote:
> >> Many beginners make the mistake of writing:
> >>
> >> mylist = mylist.sort()
> >>
> >> or try to write:
> >>
> >> mylist.sort().reverse()
> >>
> >> If we had procedures, that would be an obvious error (possibly even a
> >> compile-time syntax error) instead of a perplexing source of mystery
> >> bugs.
> >
> > While neither is a syntax error, the latter is definitely a run-time
> > error:
> >
> >>>> mylist.sort().reverse()
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > AttributeError: 'NoneType' object has no attribute 'reverse'
>
> Hence my description of it as a perplexing source of mystery bugs. How did
> mylist suddenly turn into None?
>
> Well, it didn't, but it sure looks like it did, for those who didn't realise
> that sort() is intended to be used *as if* it were a procedure with no
> return value. If it *actually* had no return value, Python could give a
> more useful error message:
>
> ProcedureError: list.sort() has no return value
>
> as soon as the interpreter tries to push the non-existent return value onto
> the stack. Python can't do that, because None is an ordinary object line
> any other. There's no practical way for Python to distinguish (whether at
> compile-time or run-time) None as an ordinary object from None as a
> stand-in for "no object at all".
>
> In practice, for moderately experienced programmers, the difference is minor
> and most people quickly learn how to debug "None object has no attribute"
> exceptions. But for a teaching language where we want to be stricter about
> the dichotomy of:
>
> - subroutines that transform values (functions); and
> - subroutines with side-effects (procedures)
>
> its a little sub-optimal.
That’s a nice summary of my position — tnx.
Not that python as a production language with a fundamentally dynamic DNA needs
to change. Rather that beginners not having procedure←→function as abstractions
of effect←→value are subjected to a more than necessarily arduous learning curve
More information about the Python-list
mailing list