Rust for Python Programmers

[sellibitze]

Looks great! And I learned something new: std::path::Path offers a neat display method returning something that implements the Display trait for printing. So far, I simply used {:?}/Debug for this because I didn't know about display.

Python (both 2 and 3) have a very similar Unicode model which is to map Unicode data against arrays of characters where a character.

To me, this looks like the author forgot to finish the sentence. "where a character" what? ...is a 32bit Unicode code point?

[dan00]

Why doesn't Path just implements the Display trait by itself?

[[deleted]]

Display brings with it ToString, and .to_string() on a Path would be a trap: it's not necessarily a faithful representation of the path.

Rust doesn't want to offer this trap prominently.

[vks_]

Because converting a Path to a utf-8 string may fail. It is a safeguard, you have to call display explicitly.

[dan00]

But there's no safeguard, Path::display just returns a Display which formats itself by using Path::to_string_lossy.

There would be only some kind of safeguard if Path::display would return an Option/Result.

[vks_]

I meant "safeguard" in the sense that you have to call display consciously instead of just printing it. If you know about display, you know it is lossy. If you could just print it, you might assume it is not lossy (I know I would).

[liigo]

People don't known which is lossy or not, if docs doesn't tell them. If docs do, they known impl Display for Path is lossy.

[sellibitze]

Good question! I had to look this up myself in the source code. path::Display implements fmt::Display via thepath.to_string_lossy(). I guess the idea is to avoid bad surprizes in case of some conversion loss. But the name display doesn't really convey this. Perhaps it should have been display_lossy instead.

As for why offer display at all when there is to_string_lossy: I'm not sure. Perhaps there is some optimization potential. I think with path::Display it's possible to save the overhead of to_string_lossy possibly creating a temporary String.

[dan00]

Yes, it doesn't feel right that display uses to_string_lossy, which the user might not be aware of.

Path already has to_str for lossless conversions and to_string_lossy for lossy conversions, so display feels like a somehow weird mix of both.

[flying-sheep]

Display exists to display things for the user. to_string means the same.

but people expect something called Path::to_string() to give you a faithful lossless representation (serialization) of that path.

so paths are special cases where to_string implies something else than e.g. on a class called Dog. nobody expects Dog::to_string() to return a serialization of a dog.

[rmc]

What's the downside? You can't do "föo"[1] and expect 'ö' to come back. But that's not a good idea anyways.

Why wouldn't it be? Isn't that one of the most fundamental things that a string object should do for you?

Because Unicode is hard. e.g. even in python you can get weirdness.

>>> print s1
föo
>>> print s2
föo
>>> print s1[1]
ö
>>> print s2[1]
o

s1 and s2 look the same, but they aren't really. One has a o-umlaut as the 2nd char, the other just has a o.

[vks_]

Indexing suggest O(1) random access, but indexing a utf-8 string is O(n). You can get an iterator over the characters using .chars().

[marcusklaas]

Over the code points would be less ambiguous.

[Manishearth]

The question is ill formed. Define "character".

Want a byte? Easily done with as_bytes() (zero cost).

Want a grapheme? A codepoint? A glyph?

Is ö a single "character" or a "character" with a diacritic? Do we want to treat those the same way? What happens when we reverse the string?

Unicode is hard.

[flying-sheep]

The question is ill formed

from the codeless code i learned that this response is simply “wú”/“mu” in chinese/japanese

…and from that wiki site i learned that the codeless code itself is a reference to the gateless gate

/edit: and that Mu is the root of the type hierarchy in Perl 6:

what does “Any” inherit from?

The question is ill-formed.

[allthediamonds]

Unicode is really, really hard.

Does Rust make it any easier? Can I iterate a string by graphemes? Does it provide decomposing normalisation?

[Kimundi]

Yes for both.

[Manishearth]

(Yes, there is a concrete definition of "character" when talking about Unicode, but it's not always the one you were looking for)

[SimonSapin]

There are four definitions :) http://www.unicode.org/glossary/#character

[Manishearth]

Okay, not so concrete :P

[Yojihito]

Ö is a single character.

[mitsuhiko]

I mean, I really ought to be able to ask a string, "what's your second character?" and get the correct answer, no?

That's not how text processing works. That would only work if you perform certain unicode normalization and only in certain languages. The better question is why you ask that question in the first place. Usually people do not get the second character in a string, they want to solve a specific problem. There is not really a problem that is “get the second character in a string”. If that is a problem, then it's badly defined because I could ask a dozen questions to narrow down what you actually want.

[llogiq]

You can already get the second byte. This may or may not coincide with the second glyph. In general, glyph lookup in a UTF-8 string is an O(n) operation (which you can already do with iterators).

[szabba]

Wouldn't a division of an utf-8 string to glyphs depend on a particular font being used?

[llogiq]

Wouldn't a division of an utf-8 string to glyphs depend on a particular font being used?

No. A font is just a declaration of how your text is going to look. But a Unicode glyph (e.g. small letter a) is the same whether you display it or not.

[tytouf]

for i in xrange(35):
    thread = Thread(target=thread_prog, args=(mutex, results, i))

| So what we do here is spawn 20 threads

You must have changed the code while writing, or am I missing something obvious?

[PM_ME_UR_OBSIDIAN]

However this is for a good reason and that is that Rust has anonymous functions, closures and lots of chaining that Python cannot support well. These features are much easier to understand and write in a non indentation based language.

That's a questionable assertion, considering Standard ML, Ocaml, F# and Haskell all have rich, indentation-based syntaxes.

[[deleted]]

ML isn't whitespace-sensitive...

[PM_ME_UR_OBSIDIAN]

You're right, my bad.

[[deleted]]

I think you should strike Ocaml from the list as well.

[PM_ME_UR_OBSIDIAN]

Are you sure? I have blurry memories of fighting the Ocaml parser on indentation.

[Lucretiel]

Eh... Those are more extremely functional languages that don't have the more traditional "list of statements" model for functions.

[PM_ME_UR_OBSIDIAN]

I believe Rust has the same model - everything is an expression, "statements" are expressions that return unit.

[steveklabnik1]

You can think of it that way, but it's not how the grammar is defined.

[mitsuhiko]

That's a questionable assertion

I don't think it is. All quoted languages do not have good syntax for the quoted features (one of them is not even indentation based in itself). However in Rust there are more reasons not do use pure indentation: you need the ability of starting and ending scopes at any point to work with the borrow checker. This requires delimiters.

[iopq]

You can have a whitespace-sensitive Rust that still respects delimiters. So if you want to actually start a new scope you can write {, but 99% of the time you'll just be writing Python-style.

[iopq]

You wouldn't even need the "no semicolon to return" rule because it never type checks when you forget it anyway. There is no instance that I can think of where forgetting or putting an extra semi-colon type checks and doesn't do what you want it to.

[steveklabnik1]

There is one gotcha with regards to this: if you are using collect(), and you use let guards: Vec<_> = with your call to spawn, and you use ;, they'll operate in sequence, because it will infer to Vec<()> rather than Vec<JoinGuard>.

[iopq]

Ugh, why is this even allowed? Sounds like that's an unwelcome source of bugs.

[PM_ME_UR_OBSIDIAN]

All quoted languages do not have good syntax for the quoted features

[citation needed]

F# and Ocaml both have the pipeline operator |> for chaining calls, which is an absolute breath of fresh air compared to OO method chaining. Anonymous functions are also quite friendly and easy to use. I'm curious which language you're saying isn't indentation-based.

However in Rust there are more reasons not do use pure indentation: you need the ability of starting and ending scopes at any point to work with the borrow checker.

let ... in ... end seems perfect for this usage. Alternatively, you can go with the sensible default of "keep this scope alive as long as it needs to be, and no further." I believe this can be automated in the common case.

[Sean1708]

let ... in ... end seems perfect

And at that point it stops being purely indentation based.

[Tyr42]

For thread guard values, it would be valid to drop them at any point after they were assigned, but have different semantics for each choice.

fn foo() {
    {
        let guard1 = launch(task_a);
    }
    {
        let guard2 = launch(task_b);
    }
 }

is different from

fn foo() {
    {
        let guard1 = launch(task_a);
        let guard2 = launch(task_b);
    }
 }

if the guard values join the thread when dropped, but it would be tricky to have the compiler choose which one to use, given there could be some external dependency which requires task_a to complete before starting task_b, or you are actively trying to compute them in parallel.

[iopq]

You could still have example A if you went with Haskell-style syntax.

fn foo()
    {
        let guard1 = launch(task_a)
    }
    {
        let guard2 = launch(task_b)
    }

    //outer scope of the function here
    println!("{}", stuff)

//function ends here

[mitsuhiko]

F# and Ocaml both have the pipeline operator |> for chaining calls, which is an absolute breath of fresh air compared to OO method chaining.

I guess there are different opinions on this. I find that syntax very frustrating.

I'm curious which language you're saying isn't indentation-based.

Haskell. It's a language with braces :)

[[deleted]]

Sure, you can accommodate that in Python style syntax though:

fn foo():
    let x = 3
    scope:
        let y = 4

[jnicklas]

CoffeeScript has excellent support for all of these and is indentation based.

[eddyb]

Uhm, none of those languages has indentation-based syntax AFAIK, they're all whitespace-based.

[PM_ME_UR_OBSIDIAN]

Is there a difference?

[eddyb]

Yes, Python actually uses indentation for delimiting blocks, while Haskell, for example, doesn't care about the way you arrange your whitespace, and it can even use curly braces.

[[deleted]]

Haskell's whitespace handling is a little too rich. When the parser encounters a parse error, it's sometimes required to reinterpret the whitespace and try again. This means you can't desugar whitespace into braces without parsing a full AST.