Python Idioms in Rust

http://benjamincongdon.me/blog/2018/03/23/Python-Idioms-in-Rust/

by cicero • 8 years ago

182 78 8 years ago

benjamincongdon.me

marshray• 8 years ago

Very strange to see the core primitives of functional programming being sold as 'Pythonic'.

I suppose we all look at the world from the perspective of our own experience.

kbenson3• 8 years ago

I suppose we all look at the world from the perspective of our own experience.

Yes, but in addition to that, I think you can likely sell an idea to people much easier when it's couched in something they are already familiar with. There's been lots said about the functional programming capabilities of Rust, but if people don't already equate what they do as following some functional paradigm, they might find themselves uninterested in the discussion.

I think Python especially, with its "one way to do it" and (my perception) how people adhere to "the way to do it in Python", there's a good chance some people don't really know when they are using common functional patterns.

spyspy• 8 years ago

Python especially, with its "one way to do it"

Despite being a core tenet of the language, Python is _really, really_ bad at following that rule. I agree with everything else you're saying, though. Those are still Python idioms even if they originated elsewhere.

tomsthumb• 8 years ago

Python has good facilities for a solid chunk of functional programming “in the small”. List comprehensions, map, filter, and reduce are all there with clear, easy to understand syntax. It’s no Haskell, but these are definitely niceties.

That said, I don’t see where the author put forward the idea that functional programming is Pythonic so much as “these are functional things that are great in python, here are some analogs in rust”.

ubernostrum5• 8 years ago

I feel like list comprehensions have always been emphasized as an important part of writing idiomatic Python. And as Python added more constructs in that vein (generator expressions, dict and set comprehensions) the tutorials people used didn't really keep up.

In the same way, map and filter were often covered, but not always with an explanation of the style of programming they supported, or why that style could be useful. I do remember the original Dive Into Python did a good job of this, and of encouraging people to explore a more functional style, but I don't recall many other resources, at least from the (2004-ish) era when I was first learning Python, doing that.

As a result I have to be a bit careful these days; I still use Python's more functional constructs regularly, but I've learned to go easy on them when collaborating with others, since I know a lot of people who learn Python now are using materials that mostly only touch on list comprehensions.

tzahola2• 8 years ago

I think it's nice that more and more languages take inspiration from the Python community.

For example, I've recently found a way to use Python-like type hints in C++. Crazy, huh? The trick is to replace "auto" with the concrete type name, e.g.:

auto x = 5;

becomes:

int x = 5;

tathougies3• 8 years ago

This is a joke right?

apendleton2• 8 years ago

Honestly I suspect that this stems from a perception particularly among people from a non-traditional CS background that "functional programming" is intimidating, whereas Python is seen as approachable in a get-shit-done kind of way for programming novices. Python definitely did co-opt a lot of traditionally functional stuff, but did it in a way that obviates needing to know what a monad is, concern oneself with functional purity, etc., so there's a community of people now who don't care about any of that but are still familiar with some of these idioms, and this post is meant to make Rust look more accessible to them in a way that "Rust supports functional programming idioms" would not.

supergarfield• 8 years ago

This is tangential to your main point, but:

did it in a way that obviates needing to know what a monad is, concern oneself with functional purity,

Caring about both of these things in the context of functional programming essentially dates from the early 1990s. According to Wikipedia (I have no better source, but it matches what I know of pre-1990s functional languages),

Eugenio Moggi first described the general use of monads to structure programs in 1991.

Functional programming existed before then. Scheme, an early functional language, is from the 1970s. It has basically all the FP idioms that you have in Python, is not pure, is dynamically typed, and the doc never once references monads.

I'd actually say the definition of FP has shifted towards pure, category-theory oriented languages, but "traditionally functional stuff" definitely doesn't include monads.

coldtea4• 8 years ago

Honestly I suspect that this stems from a perception particularly among people from a non-traditional CS background that "functional programming" is intimidating, whereas Python is seen as approachable in a get-shit-done kind of way for programming novices.

Just people from a "non-traditional CS background"? Most CS graduates today will say the same thing with regards to e.g. Python vs Scheme or CL.

Python definitely did co-opt a lot of traditionally functional stuff, but did it in a way that obviates needing to know what a monad is, concern oneself with functional purity, etc.

If you hanged around HN pre 2010, you'd seen that FP was all about Lisp (and things like map, reduce, macros, first class functions, etc), and few gave a rat's arse about "monads" and "purity" -- it was only starting to emerge in general consciousness, not dominant as it is today in FP circles.

papito• 8 years ago

You are saying that Python is like the Bill Nye of functional programming: not really a scientist, but does make it accessible to the masses.

ceronman• 8 years ago

Python had the primitives of functional programming since its conception. Those are not exclusive of pure FP languages.

Some particular names used in the examples were introduced by Python. For example the `enumerate` function or `zip`. I haven't seen those names used in programming languages older than Python, I know I might wrong. The point is that it's not crazy to believe that Rust design does borrow some things from Python (among other languages of course).

The article is comparing some particular Python idioms with Rust. The fact that those are functional I think is not particularly relevant. It's like someone seeing a comparison of Java and Go and saying that those are just the principles of imperative programming, or object oriented programming.

fjh• 8 years ago

Some particular names used in the examples were introduced by Python. For example the `enumerate` function or `zip`. I haven't seen those names used in programming languages older than Python, I know I might wrong.

All the ML dialects that I know have a zip function and ML pre-dates Python by about 20 years. This is particularly relevant since Rust is clearly strongly influenced by ML.

The fact that those are functional I think is not particularly relevant. It's like someone seeing a comparison of Java and Go and saying that those are just the principles of imperative programming, or object oriented programming.

The comparison feels right, but I think it would certainly be odd if somebody explained loops in Go as "a Java idiom".

agumonkey• 8 years ago

Python FP primitives came from an early friend or codev of Guido. He had experience in FP or Lisp and felt he needed them. Guido never really wanted that and just left them there.

All these names and ideas are clearly rooted in FP circles

slaydemons• 8 years ago

Except the article contained non-functional concepts in it also. But hey at least you got to announce the fact you use/like functional programming languages.

ubernostrum5• 8 years ago

It's possible for these constructs to be present in many languages and predate Python's adoption of them, and for it to be simultaneously true that a lot of idiomatic Python relies on these constructs.

c3534l• 8 years ago

I suppose it makes sense in weird way, since both Python and Rust have these features implemented in similar ways because it stems from more traditional functional programming. You could also compare Java to C++ on account of them both being inspired by C.

monocasa• 8 years ago

The 'single line if' is even cooler than that in rust, IMO. Everything being an expression allows really neat combinations inside statements.

dom96• 8 years ago

If as a Python programmer you're looking for a compiled language that is similar to Python, check out Nim: https://nim-lang.org/.

alehander42• 8 years ago

There is even a library(in a very early stage) that tries to semi-automatically translate Python programs to equivalent Nim idioms: https://github.com/metacraft-labs/py2nim

ubernostrum5• 8 years ago

Since it just came up again yesterday, it's worth noting that the term "compiled language" is a tricky one to use here:

https://nedbatchelder.com//blog/201803/is_python_interpreted...

So: is Python compiled? Yes. Is Python interpreted? Yes. Sorry, the world is complicated...

leshow4• 8 years ago

I can't speak for OP but I think they are just differentiating between languages that produce an executable binary versus one that is interpreted/runs in a VM/is compiled to bytecode/whatever else

cup-of-tea6• 8 years ago

The Rust version of "zip" seems a bit odd as it's implemented like a method rather than a function. Little things like make me not enjoy a language as much.

microtonal• 8 years ago

The itertools crate has you covered:

https://docs.rs/itertools/0.7.8/itertools/fn.zip.html

By the way, the Iterator's zip function is no magic. You could trivially implement a standalone function using the zip method yourself:

https://docs.rs/itertools/0.7.8/src/itertools/free.rs.html#7...

Rusky• 8 years ago

There's also UFCS:

    for (a, b) in Iterator::zip(as, bs) {
        // ...
    }

coldtea4• 8 years ago

as it's implemented like a method rather than a function

Why should it be a function? It can be a method on sequence like objects (trait)...

Python itself has tons of those...

cup-of-tea6• 8 years ago

Because the parameters to zip aren't positional, they are just multiple parameters of the same type.

Python does have some that annoy me a bit. I think str.join would be clearer as a function, but at least that does have a positional parameter.

yxhuvud• 8 years ago

Personally, I like Rust’s extensive iterator functions even better than Python’s

Funny, when the rust example that gave rise to the comment looks more or less like Ruby[ * ] but with other syntax for blocks. The writer should get around more and try more other languages.

[ * ] Or any of a zillion other object oriented languages that have decent support for functional looking code.

apendleton2• 8 years ago

My understanding, though, is that idiomatic Ruby inverts the control for iteration (array.each(|thing| do stuff)), which leads to slightly different ergonomics, whereas idiomatic Python is like what Rust is now; see http://journal.stuffwithstuff.com/2013/01/13/iteration-insid... for a comparison. Interestingly, Rust used to have iteration styled after Ruby's, and explicitly switched in rust 0.7: https://www.reddit.com/r/programming/comments/1hl2qr/rust_07...

I think the comparison here is also to Python because the specifics of the API, rather than just the patterns, are pretty obviously inspired specifically by Python (names of functions like zip, etc.), as opposed to other external-iterator languages like C#

sampo• 8 years ago

Not sure if there is any point in implementing map_on_vec using map, but this code

    fn map_on_vec(vec: &Vec<i32>, func: fn(i32) -> i32) -> Vec<i32>
    {
        let mut new_vec = Vec::new();
        for i in 0..vec.len() {
            new_vec.push(func(vec[i]));
        }
        new_vec
    }

doesn't need to be based on mut, push and for. Something like this works, too:

    fn map_on_vec(vec: &Vec<i32>, func: fn(i32) -> i32) -> Vec<i32>
    {
        let new_vec: Vec<i32> = vec
            .iter()
            .map(|x| func(*x))
            .collect();
        new_vec
    }

At least it runs a tiny bit faster, without all the pushing.

vvanders2• 8 years ago

I'm also looking forward to the impl trait work where you can return partial iterators as well instead of the massive type signature that they are today.

shepmaster• 8 years ago

And getting into idiomatic Rust + a bit of code golf + a bit of showing-off:

    fn map_on_vec(vec: &[i32], func: F)
    where
        F: Fn(i32) -> i32,
    {
        vec.iter().map(|x| func(*x)).collect()
    }

- There's no need for the temporary variable, can just return directly

- The `vec` argument should be a `&[T]` not a `&Vec<T>` [discouraged]

- The `func` argument shouldn't be a function pointer but instead take an unboxed, generic closure (no forced pointer indirection, can take a closure). You may even want to accept a `FnMut` to allow the closure to mutate itself.

[discouraged]: https://stackoverflow.com/q/40006219/155423

leshow4• 8 years ago

shep! you forgot map_on_vec's return type. Thanks for writing the comment though, I was just about to point out Fn

raymondh• 8 years ago

Thanks for the nicely written Python/Rust comparison :-)

Is Rust's flat_map() equivalent to this in Python?

    def flat_map(func, it):
        return map(func, chain.from_iterable(it))

edflsafoiewq• 8 years ago

No, it's

    def flat_map(func, it):
        return chain.from_iterable(map(func, it))

weatherlight• 8 years ago

looks more like ruby to me than python.

tabtab• 8 years ago

Sorry, but language doesn't matter that much if the entire environment/stack is decent. If you are using overly "clever" features of the language, then you may be writing write-only code that has a high probability of tripping up new hires.

I see too many trying to reinvent the database or operating system in application code. Don't.

leshow4• 8 years ago

We have different definitions of clever. Using iterator combinators is pretty par for the course and sort of a minimum understanding I would expect anyone to have.

GolDDranks• 8 years ago

What that has to do with anything? The author didn't advocate for reinventing the database or operating system in application code.

Also, Rust is very much an antithesis of write-only code; it's specifically aimed for programming at large.

ubernostrum5• 8 years ago

I'm a bit surprised nobody has tried to start up the "what are tuples really for in Python" argument in this thread.

The definition given -- "Python tuples act like immutable lists" -- is correct as a description of behavior, but the decision of when and whether to use a tuple versus a list or some other structure can be a pretty contentious one in some Python circles.

cup-of-tea6• 8 years ago

Lists are for iterating, tuples are for unpacking.

kzrdude2• 8 years ago

Wouldn't you say that lists are for homogenous collections and tuples for short heterogeneous ones? Of course we use the Python "duck typing" definition for homogenous.

stochastic_monk• 8 years ago

It’s worth noting that C++ has been adopting python’s functional attributes, from range-based loops, <algorithm> , duck-typing, and fold expressions, to libraries supporting Python’s style more directly. Range-v3 [0] and cppitertools [1] stand out to me. The former is in a current proposal for inclusion in the C++20 standard.

[0] https://github.com/ericniebler/range-v3

[1] https://github.com/ryanhaining/cppitertools

recursive• 8 years ago

Neither Python nor Rust has ternary operators (which may be for the best).

Then it goes on to show the ternary conditional operator from python.

Python Idioms in Rust

Related Stories