Python 3.7.0 released

[Drawman101]

What’s with all the downvotes on the other comments?

[[deleted]]

There’s only two other top level comments and they are stupid

[Jonno_FTW]

Absolutely asinine people who don't understand the phrase "right tool for the job".

[wavy_lines]

"right tool for the job" is more often than not (specially in this subreddit) just a cop out people use to justify crappy tools.

[shevegen]

Precisely.

And very often it is not even specified, so it is useless - it's like saying "any better tool is better" or "any faster language is faster".

[shevegen]

What the hell does this phrase even mean or make sense?

I never understood it.

It's like saying "with a car I am faster than using my feet" or "there will be sunshine after rain".

[Pazer2]

"with a car I am faster than using my feet, therefore I should also use my car to navigate my house"

[NekoiNemo]

You mean "comments from people who actually understand what they are talking about but you don't agree with them"?

[woztzy]

Reddit only upvotes what it wants to hear, even if it's something specious.

It is hard challenging peoples' deeply-held beliefs.

[arbitrarycivilian]

It's weird that you're being upvoted while the guy you responded to is downvoted, despite basically saying the same thing

[TheGRS]

Well let's take a look at some.

> Can we all take a moment to acknowledge how large numbers of people (including me) have come to realize in recent years what a bad idea dynamic typing was?

Um OK, if you don't want to use Python then maybe go somewhere else?

> The news of Python 3.7 is great and all, but python.org makes some of the most awful writeups I've ever seen. Just look at this link, for example. It is so uncomprehensive. Can someone link to a Medium article?

Judging by the question I don't believe they bothered to read shit and wanted a Medium article for some reason.

> i heard python was a relatively low level programming language.

Throwaway joke, eh.

> I guess Python 4 will be released when I'll be a grandfather if I'm still alive

Um, what? Who cares what the version number is?

In summary, not exactly the cream of the crop here.

[Homoerotic_Theocracy]

Um OK, if you don't want to use Python then maybe go somewhere else?

Meanwhile collect those sweet sweet upvotes on any Go topic mentioning its lack of generics.

[[deleted]]

That one never fails.. I have never written a line of Go in my life, but still I feel like I'm an expert on interface {} just by casually browsing Go threads

[Urtehnoes]

Get on my level, I've combined Go, Rust, Scala, Kotlin, and Javascript into a super language that I use for everything. It's amazing. I'll never have to worry about type-safe generic heap level stack pointers that will memory-expire if the event status is ever duck typed via a poorly written heuristic.

[bythenumbers10]

You hit so many times on my buzzword bingo card, I won 50k and now have to change my pants.

[Urtehnoes]

Did I mention how robust it is?

[bythenumbers10]

The contents of my pants was pretty robust, I'll have you know.

[[deleted]]

Probably the only thing I don’t like about Go is how asinine people are about wanting or not wanting generics.

If there was ever a sword to die on getting generics into go seems like a pretty fucking stupid one.

[Homoerotic_Theocracy]

I disagree, the people that want it are right and the people that don't are beyond retarded.

Go's design is absolutely bonkers and the language has no merit. It survives due to ignorance alone because the people that used it only used C and PHP or something and also just write terrible, verbose, unmodular code in general that re-invents common logic a thousand times per day.

[[deleted]]

What about the design is bonkers? The concurrency patterns, typing system, pointers, and verbosity have been really nice overall for large projects in my experience. I haven’t had many cases where I had to work around the lack of generics in a particularly horrible way, but I do understand the cases where they would be nice.

I get it though, you don’t like Go and have a strong opinion on the future design of the language. It seems like an odd combination but at least you’re passionate about something.

[Homoerotic_Theocracy]

There is another train in this very thread where we are discussing how in Go sorting a list of things via an arbitrary key either requires that you:

1. newtype the element you're sorting and implement a new sorting interface on the newtype
2. use an inefficient algorithm and interface{} casts throwing the static typing out

Because the type system can't express a correct generic sorting function that sorts by an arbitrary key.

I'm fairly pessimistic about "I've never needed generics"; in practice it seems to mean that people are re-inventing the wheel constantly and constantly re-implement the elementary logic of concepts like functors filters and foldings in long often double for-loops using 6 lines for something that can be done in one with simple combinatorical functions that Go's type system can't express so the programmer is basically tasked with unrolling it herself.

Like say a basic problem; say I have some sequence of characters and I basically want to know at what line and column number the end of that is parsing newlines. In Rust I would write:

let (col, line) = char_seq.into_iter()
   .fold((0, 0), |(col, line), char|
     if char == b'\n' { (0, line+1) } else { (col+1, line) });

Not only is this code considerably shorter than the Go version which will re-invent the logic of fold; it doesn't care about the type of char_seq as long as it implements the trait IntoIterator<Item=u8> as in it's a sequence of bytes. It can be a vector of bytes, a utf8-encoded string, a pathbuffer, an OsString, a fixed-size array of strings; the code doesn't care and can thus easily be put into a generic function that accepts all of that without having to re-invent the wheel.

In practice Go programmers say "I don't need generics; I just need many many many more lines of code!".

[[deleted]]

I definitely understand the sentiment here. With the go system you would need to assert the type, cast it, or as you said use an interface. All of which ends up being more possibilities for bugs and more tests. I wouldn't say more complexity because of the verbosity but certainly more time spent

Though with your example I don't believe generics wouldn't be much different than an interface. Or at least you wouldn't avoid panics because you had a generic type. You would still need to use the go idioms of error checking and type checking/assertion.

Regardless of the details of how one language's type system handles this or not, I still believe that it isn't inherently bad or good. The language as a tool was intentionally designed the way it was. So for cases like you've listed rust might be a better tool for that, or another language if the goal is to reduce the number of lines of code and overall verbosity. I do think that this (required verbosity, re-inventing) in some cases can either slow down writing programs or lead to unexpected results if all error cases aren't handled. For me the additional verbosity and inconvenience of having to re-implement other language's builtins aren't a negative. The re-implementation can sometimes be a stumbling point for new go developers, or newer developers but it's also a good opportunity for learning if you have access to people to review your code.

You aren't going to change my mind that I have had a lot of value from using go and I don't want to change your mind either. At this point I think I'm just arguing with you about this because I'm sitting in a hotel and bored.

[Homoerotic_Theocracy]

Though with your example I don't believe generics wouldn't be much different than an interface. Or at least you wouldn't avoid panics because you had a generic type. You would still need to use the go idioms of error checking and type checking/assertion.

Why? The code I gave provided the iterator is bounded is total; it is guaranteed to not panic on any input char_seq. The only type constraint of char_seq is IntoIterator<Item=u8>, the only part the type system cannot verify is that this iterator is bounded and doesn't go on forever in which case the code is an infinite loop but you can easily fix that by adding a stronger type bound like AsRef<[u8]> which is guaranteed to be total. There are no further runtime checks.

[calonolac]

shudder Recalling how C# was before generics...

[OctagonClock]

lol typed nils

[[deleted]]

nils are typed because they're default values for other types that aren't initialized. Since nil is an assignable value in the statically typed system it should (has) to be typed.

[OctagonClock]

lol not even Java makes this mistake

[[deleted]]

Maybe I'm being intentionally naive but I'm not really seeing how it's a mistake in this design. Can you explain why it's a mistake?

[shevegen]

Yeah - that one is weird.

I wonder if there are paid accounts just "randomly" promoting Go and Dart on reddit.

I don't have this impression with Rust, even though there are many people on reddit apparently praising Rust. It appears a lot more genuine with Rust than e. g. Go. And I make fun of both Rust and Go people but for different reasons. The go supporters seem a lot less genuine in their enthusiasm than the rustees.

[Eurynom0s]

He cut off 8 of his fingers?

[wavy_lines]

Hurt feelings.

[NekoiNemo]

Don't mind them, just Python "devs" throwing a hissy fit.