Is there a way to change the closure of a python function?

[Chris Angelico]

On Wed, Sep 28, 2016 at 3:27 PM, Gregory Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> Lawrence D’Oliveiro wrote:
>>
>> On Wednesday, September 28, 2016 at 3:35:58 AM UTC+13, Peter Otten wrote:
>>
>>> is Python actually a "functional language"?
>>
>>
>> Yes
>> <https://groups.google.com/d/msg/comp.lang.python/P1Edc4eJNkY/D5KBo7skAgAJ>.
>
>
> No, not according to what the term "functional language"
> usually means.
>
> Languages described as "functional" usually incorporate
> all or most of the following characteristics:
>
> * No side effects (new variable bindings may be created, but
>   existing ones cannot be changed; no mutable data structures).

If that's adhered to 100%, the language is useless for any operation
that cannot be handled as a "result at end of calculation" function.
You can't produce intermediate output. You can't even produce
debugging output (at least, not from within the program - you'd need
an external debugger). You certainly can't have a long-running program
that handles multiple requests (eg a web server). That kind of rule is
fine for mathematical systems, and it's fine for certain specific
sub-parts of larger programs, but IMO it's utterly impractical for an
entire programming language.

> * Lazy evaluation by default.

Given that you said "usually means", sure, but only because most
functional programming is abysmal (or impossible - calculating the
squares of all positive integers, then subscripting it) unless
optimized like that.

> * Syntactic support for currying.

Is that really such a big deal? What's the true difference between
syntactic support and stdlib support?

> * Syntactic support for case-analysis-style definition of
>   functions, by matching the arguments against a series of
>   patterns.

Again, why such a big deal? Unless you're deliberately defining
"functional language" as "clone of Haskell" or something, there's no
particular reason for this to be a requirement.

> * A standard library geared towards a programming style
>   that makes heavy use of higher-order functions.

This I would agree with.

> Python has none of these features. It's possible to use a
> subset of Python in a functional way, but it goes against the
> grain, and without all the above support from the ecosystem
> it's clumsier than it would be in a real functional language.
>
> Some parts of Python, such as list comprehensions, have a
> functional flavour, but Python is predominantly an imperative
> language.

Python is predominantly a *practical* language. Since purely
functional programming is fundamentally impractical, Python doesn't
force us into it. You want to work functionally? No problem. Pretend
that "def" is a declaration, make all your functions pure, and either
finish with a single "print(main())" or do your actual work at the
REPL. No problem. Want to make event-driven code? Hide an event loop
(maybe a GUI one, maybe asyncio, whatever) in your main routine, and
do everything through that. Want to use Smalltalk-style "message
passing"? Fits nicely into classes and methods. Want a simple batch
scripting style? Ignore functions and classes, and write your code
flush left. Python doesn't force you into any of these models, ergo
Python isn't a functional language, nor an event-driven language, etc,
etc. It's a general-purpose language.

ChrisA