
Best Practices for Using Functional Programming in Python - BerislavLopac
https://kite.com/blog/python/functional-programming
======
jo-wol
No thanks
[https://news.ycombinator.com/item?id=14902630](https://news.ycombinator.com/item?id=14902630)

~~~
bryanrasmussen
is it no thanks I don't want to go to kite.com because they spy or no thanks I
don't want programming suggestions from people who spy?

~~~
craftyguy
Yes.

~~~
objektif
“Both” is better way to put it.

------
hasperdi
Is this not the company that put on spyware in a package for Sublime text?

~~~
tempodox
> _Kite is a plugin for your code editor that uses machine learning to provide
> you with code completions in real time sorted by relevance._

The whole article seems to be nothing but a transport vehicle for that ad.
Spyware for even more editors.

~~~
xte
Well... In my case it keep saying

Huh... that's weird

Something unexpected occurred. We'll investigate what happened

Refresh the page

Anyway, Python actually support limited functional programming so I only get
it for that topic :-)

------
JustSomeNobody
Here's another article on FP in Python for those who'd rather an alternate
than go to kite.com.

[https://maryrosecook.com/blog/post/a-practical-
introduction-...](https://maryrosecook.com/blog/post/a-practical-introduction-
to-functional-programming)

Edit: After scanning the kite.com article for a second time, I see the author
actually links to Mary Rose Cook's article.

------
sireat
How is Kite still in business after telemetry abuse?

Sadly I would not be shocked if they managed to gather additional funding.

------
xte
Well... If I'm looking for functional programming in python... I'll choose hy
(hylang) witch is actually Cython with a lisp-y syntax.

Otherwise if I'm accustomed to Python but feel the need of something
functional and scheme/lisp are too hard well... I go for Nim...

Python is FANTASTIC as a simple language to tech programming these days and to
glue stuff together, with the benefit of a respectful standard library but
frankly if we go beyond we have other options perhaps with some sharp corners
(less easy to code, less complete standard library, less documented etc).

------
h8hawk
Beside python has pretty awful support for functional programming, I don't get
what is purpose of this. Is it just a Facebook for developers? Why anyone
should use autocomplete sever in others computer? What is advantage of this
over other autocomplete API's such Jedi, Pycharm, Microsoft python server,
that doesn't run in other computer? I hope these sort of thing's won't become
popular.

~~~
optimuspaul
> Beside python has pretty awful support for functional programming

That seems counter to my experience and understanding of things. Python has
adequate support for functional programming. And bonus you can mix in some
object oriented things as well.

~~~
sevensor
What Python has, is really good support for procedural programming. You can
write pure functions when it makes sense, and you can write side-effecting
procedures wherever you want. You have a bag full of useful data structures,
and an extensive standard library to hand. Python's biggest drawback for me is
that it's what I'd call a "surprisingly typed" language. Values in Python are
strongly typed, but we pretend they're not. Until, surprise! AttributeError!
That thing isn't what you thought it was. Optional typing has started to help
with that.

~~~
bunderbunder
"surprisingly typed" is a good term. It sounds, though, like you're using it
to mean "dynamically typed", which is maybe overly harsh.

What I think it captures well, though, is an unfortunate habit among many
dynamic languages' communities to pretend that types don't matter. Python is
getting better, but it used to be really bad about this. The standard
library's documentation, for example, would give only the names of a
function's parameters, and leave it to you to figure out, presumably by guess
and check (and prayer), what kind of input it was prepared to accept. It's
still really common for the documentation to force you to go to the REPL to
ask a function's return value what its type is.

~~~
sevensor
I work in Python day to day and have done for several years, so I think I'm
entitled to describe Python's type system as "surprising." I generally think
duck typing is great, and I always appreciate the flexibility it gives me. But
the flip side of that is -- surprise! -- you can't use me as an index! --
surprise! -- I'm not hashable! -- surprise! -- you can't pickle me!.

I've been looking at how other languages handle this, and I think typeclass /
trait systems seem to strike a good balance, allowing flexibility without
surprises.

~~~
bunderbunder
The typeclass approach can be just as surprising. Possibly more so, because it
means that a type's implementation of a class can come from literally
anywhere. So the universe of surprises still includes "Surprise! It's not
hashable!", but now also includes, "Surprise! It was hashable, but now isn't,
because you stopped importing this seemingly unrelated package."

If you do get surprised that X doesn't support Y, though, you have ability to
provide your own implementation without resorting to monkey patching.

~~~
sevensor
That's a good point! I suppose the grass is always greener...

------
depressedpanda
tl;dr

\- Use pure functions

\- Avoid mutability

\- Limit use of classes

\- Strive for idempotency

\- Use lambdas and higher order functions sparingly, only when they actually
simplify the code

\- Use generators where applicable

All in all, it's good advice which shouldn't be ignored just because she works
at kite.

She should probably go back and proof read the article and fix the code and
terminology errors, though.

~~~
maweki
But generators are inherently stateful and don't have referential transparency
because of their consumption semantics.

~~~
black-tea
You can't get away from using state in Python because it lacks TCO.

------
wybiral
Python doesn't even have tail call recursion optimization (you'll hit a
RecursionError exception if you go too deep).

Using first-class functions is great but I hesitate to call any serious use of
Python "functional programming".

~~~
bunderbunder
Many Common Lisp implementations also lack TCO.

That said, I do agree that you probably shouldn't go crazy with FP in Python.
At its core, it's a procedural language. It has some useful things from OO and
FP, but you'll be more comfortable if you keep procedural techniques in the
top tray of your toolbox.

Which isn't all that bad a thing. IMO, well-done modern procedural programming
looks a lot like functional programming with more loops and less recursion.

~~~
wybiral
Common Lisp is one of the least "functional" of the major lisp dialects too.
Without TCO you generally need state for iteration.

That being said, I agree, there's nothing wrong with taking aspects that you
like (first-class functions mainly) without having to be a purist. In fact,
imo purely functional languages are tedious compared to procedural languages
like Python.

~~~
bunderbunder
That said, the ML/Haskell-like functional languages do have one thing that
most procedural languages do not, which is that they help you keep side
effects under control.

I'd like to find a procedural language that allows for side effects (it is
still procedural programming, after all), but encourages keeping them under
control. I've been toying with Nim lately, and it's been a good experience. I
think that it's possible to do even better, but it's already way ahead of
anything else I've tried.

------
macintux
Adding FP features to an otherwise-mutable language has always seemed a mixed
bag to me. Obviously it’s nice to have those features, but you don’t get the
immutability constraint that makes development so much more predictable.

~~~
sevensor
Python offers immutable data structures in addition to the mutable ones.
Tuples are immutable, we've had namedtuple for a while, and now it's possible
to write immutable data classes as well. As time goes by, I find myself using
less and less mutability in Python. At this point I default to immutable
structures, and I bring in mutable ones only if I need them for performance or
there's no reasonable immutable alternative.

~~~
macintux
Tangentially, I was extremely annoyed to discover that tuple unpacking in
function headers was removed with Python 3. Coming from Erlang, tuples were
quite appealing, but that was frustrating.

