Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Python developers need to know before migrating to Go

blog.repustate.com

Post reply on HN
Print view View original

91–100 of 117 posts

Re: What Python developers need to know before migrating to Go

#91

Post by ANTSANTS »

n1ghtm4n wrote: post #90
ANTSANTS wrote: post #78

Earlier quoted context omitted.

>Python somehow magically slices unicode strings without chopping characters in half. You need a byte offset to slice a string, and it's impossible to convert from a Unicode rune offset to a byte offset without parsing the entire string up until that point. I'm not all that familiar with Python, but if the language works as you implied, it is basically doing this behind the scenes in common string processing tasks: 1…

You're right. You're not very familiar with Python. String slicing with numbered indices is used all the time. And you can slice more than just strings! It's one of the coolest features of Python and you're really missing out if your favorite language doesn't have that. This might explain why my comments seem like heresy to you. I would point out that the OP is about Python programmers switching to Go.

>String slicing with numbered indices is used all the time.

Ok, so it (EDIT FOR YOUR BENEFIT: I'm talking about slicing strings with rune indices here, not slicing in general. Array slicing is a useful language feature, and, uh, it's not unique to Python or anything) is not just a language wart, but a fertile source of pointless inefficiency in everyday Python code, glad to know.

>This might explain why my comments seem like heresy to you.

You aren't challenging my beliefs or anything, I'm just trying to make you see that you don't understand how UTF-8 string operations work very well. If you did, you'd understand that Python is doing the exact same thing as Go here, but in a less efficient manner.

Re: What Python developers need to know before migrating to Go

#92

Post by n1ghtm4n »

neild wrote: post #87
n1ghtm4n wrote: post #69

Earlier quoted context omitted.

Why not a 2-word struct with the rune count instead of the byte count? There's zero performance cost for many strings because the rune count is known at compile time. For the rest, most strings are too short for Big-O analysis to be relevant and I would guess (enlighten me if I'm wrong) that the cost of computing the bounds of each character is negligible on a modern processor. Multi-byte chars in a string are going…

It is very seldom that you really want to deal with a string as an array of runes. (If actually you do want to, Go makes it fairly easy: Just use []rune rather than string.) Consider a simple string: "école". How many runes does it contain? Possibly five: LATIN SMALL LETTER E WITH ACUTE LATIN SMALL LETTER C LATIN SMALL LETTER O LATIN SMALL LETTER L LATIN SMALL LEtTER E Possibly six: LATIN SMALL LETTER E COMBINING ACU…

Thank you for the explanation! Converting to a rune slice and back does give me the behavior that I wanted. It still looks butt ugly to me, but at least it works.

In Go:

    fmt.Printf("%s", string([]rune("нєℓℓσ")[1:4]))
    // єℓℓ
In Python:

    print("нєℓℓσ"[1:4])
    # єℓℓ

Re: What Python developers need to know before migrating to Go

#93

Post by n1ghtm4n »

ANTSANTS wrote: post #91
n1ghtm4n wrote: post #90

Earlier quoted context omitted.

You're right. You're not very familiar with Python. String slicing with numbered indices is used all the time. And you can slice more than just strings! It's one of the coolest features of Python and you're really missing out if your favorite language doesn't have that. This might explain why my comments seem like heresy to you. I would point out that the OP is about Python programmers switching to Go.

>String slicing with numbered indices is used all the time. Ok, so it (EDIT FOR YOUR BENEFIT: I'm talking about slicing strings with rune indices here, not slicing in general. Array slicing is a useful language feature, and, uh, it's not unique to Python or anything) is not just a language wart, but a fertile source of pointless inefficiency in everyday Python code, glad to know. >This might explain why my comments s…

>Ok, so it's not just a language wart, but a fertile source of pointless inefficiency in everyday Python code, glad to know.

The fact that it's used all the time would suggest it's not pointless inefficiency, no? Maybe you should try Python before bashing it.

>Python is doing the exact same thing as Go here, but in a less efficient manner.

It's not doing the same thing. "�є" is not the same as "єℓℓ".

Re: What Python developers need to know before migrating to Go

#94

Post by n1ghtm4n »

cbhl wrote: post #89
n1ghtm4n wrote: post #46

Some thoughts after spending ~100 hours with Go. - Function overloading is a major convenience that you will miss. There are differently named versions of every function and you will call the wrong version with the wrong arguments all the time . The number of functions in the standard library could be reduced by at least 1/4 if they'd got this right. The official FAQ ( http://golang.org/doc/faq#overloading ) explains…

> explains that leaving out overloading is "simpler", meaning _simpler for them_. This also means your program code is simpler, and therefore, faster. Function overloading usually means virtual method tables, and therefore indirect method calls. Depending on how deep your inheritance / overloading structure is, these vtables can get really messy. (I had a class in university where we were given a C++ UML class diagra…

Function overloading can be accomplished by name mangling at compile time.

  PROGRAMMER SEES        INTERNAL REPRESENTATION
  foo(int a, char b)     foo_int_char
  foo(int x)             foo_int

Re: What Python developers need to know before migrating to Go

#95

Post by dragonwriter »

ANTSANTS wrote: post #78
n1ghtm4n wrote: post #72

Earlier quoted context omitted.

> What happens when you take a slice of a string? What happens when you slice a unicode string in Go is that it cuts multi-byte characters right in half, unless you get the byte boundaries just right. I know real programmers keep the byte boundaries for all the chars in all their strings in their head at all times, but for people like me this basically makes string slicing unusable for non-ASCII text. Python somehow…

>Python somehow magically slices unicode strings without chopping characters in half. You need a byte offset to slice a string, and it's impossible to convert from a Unicode rune offset to a byte offset without parsing the entire string up until that point. I'm not all that familiar with Python, but if the language works as you implied, it is basically doing this behind the scenes in common string processing tasks: 1…

> This Python "feature" seems to exist entirely to keep newbies from getting confused when they attempt to slice up strings in their REPL, for I cannot fathom a reason why anyone would write "s[1:4]" in production code.

Dealing with a format where data elements are defined to be fixed length in characters that happens to be encoded in Unicode?

Re: What Python developers need to know before migrating to Go

#96

Post by beagle3 »

ak217 wrote: post #71
dbaupp wrote: post #54

Earlier quoted context omitted.

They're not universal, but they're essentially so; pretty much everyone who's used C(++), Java, C#, ... has seen && and ||, and knows what it is. And people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed (they have the option of spending longer complaining about it if they want).

> people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed No. Cognitive overhead. You pay for it every time you parse these words in your brain. You pay for it by reducing the number of nested/combined clauses that you can parse on the fly. (This is far from the only readability issue with Go, by the way, and you're right in that it's among the more superficial ones. The…

No, laziness.

&& is pronounced "and" but actually means "shortcircuit left-to-right-evaluated and".

If you're coming from a Pascal (or non-programming) background, you do not assume either left-to-right evaluation order, nor short circuit evaluation.

The cognitive overhead is always there, because whether you like to admit it or not, programming is applied math, and exact meaning is very important;

e.g.:

    if a == 0.0 or b/a > 3 then launch_missile();
Without the "cognitive overhead of knowning guaranteed left-to-right + short circuit", this code is wrong.

The hypothetical "newbie programmer who can write a working program but has cognitive overhead deciphering &&" is a mythical creature that does not actually exist.

Re: What Python developers need to know before migrating to Go

#97

Post by lysium »

cbhl wrote: post #89
n1ghtm4n wrote: post #46

Some thoughts after spending ~100 hours with Go. - Function overloading is a major convenience that you will miss. There are differently named versions of every function and you will call the wrong version with the wrong arguments all the time . The number of functions in the standard library could be reduced by at least 1/4 if they'd got this right. The official FAQ ( http://golang.org/doc/faq#overloading ) explains…

> explains that leaving out overloading is "simpler", meaning _simpler for them_. This also means your program code is simpler, and therefore, faster. Function overloading usually means virtual method tables, and therefore indirect method calls. Depending on how deep your inheritance / overloading structure is, these vtables can get really messy. (I had a class in university where we were given a C++ UML class diagra…

He did not mean overriding (methods in derived classes), but overloading (functions with the same name). You can resolve the latter at compile time, no indirection needed. For example you can have two overloaded functions println() and println(String).

Re: What Python developers need to know before migrating to Go

#98

Post by Mr_T_ »

skizm wrote: post #57
callenish wrote: post #53

Earlier quoted context omitted.

> In Go: len("нєℓℓσ") // 12, because there are 12 bytes utf8.RuneCountInString("нєℓℓσ") // 5, plz kill me i am an abomination I'm not sure I understand your objection. Bytes and UTF8 characters are different things, and you can't abstract away the difference. There are also times, perhaps the majority of times, when you will need the byte count of a UTF8 string. That means you need at least two different length funct…

I think the majority of the time you want the number of utf8 characters and not the byte count. In fact I have never wanted the byte count. If I did I would expect something like byteLen and Len. Not the other way around. You should be optimizing the common case, not the exception. Obviously I'm not a language designer so perhaps I'm talking out of my ass but I've heard this complaint A LOT.

You almost always need the byte count for protocols, buffers and stuff. For user-interfacing use-cases (e.g. editors) you probably want the glyph or grapheme count, not the rune count. Please remember, runes / code points, graphemes and glyphs are different things:

http://www.icu-project.org/docs/papers/forms_of_unicode/

Re: What Python developers need to know before migrating to Go

#99

Post by Ziomislaw »

tikhonj wrote: post #65
khyryk wrote: post #60

Earlier quoted context omitted.

Something like this? http://play.golang.org/p/6nvdLWOi5D

Not quite. What you have is a single type interface{} that happens to be the super type of all other types. You still haven't solved the issue of having multiple different types in a tuple--you've just thrown all the type information away! Think of a tuple as an anonymous struct. (Or perhaps think of a struct as a tuple with labels :P.) We want to statically differentiate between a pair of ints, a pair of strings and…

RTFM! of course you can, just switch on a type

    switch x.(type) {
    // cases
    }

Re: What Python developers need to know before migrating to Go

#100

Post by Ziomislaw »

count wrote: post #50
dbaupp wrote: post #49

Earlier quoted context omitted.

> Using && and || for logical operators in this day and age is just ridiculous No it's not, it takes 10 minutes to learn that && means and and || means or (maybe a little longer to get the hang of it properly), and this knowledge transfers to many programming languages. (This is a little like arguing "we shouldn't use + when English has a perfectly good word 'add'"; symbol reasoning is valuable.)

'+' is damn near universal. '&&' && '||' !universal.

they are, unfortunately you need to have paid attention at school when they taught you logic operators
Post reply on HN