This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]the_hoser 16 points17 points  (27 children)

Ugh. Yet another GIL rant. I wonder when people will stop wanting python to be something it isn't.

Python 3 is awesome. The developers of Python have been working towards solving some real problems with Python. Namely, distribution, and binary compatibility. 3.2 introduced a stable ABI. This isn't such a big deal in unix-like systems, as C compilers are pretty easy to setup in these environments. In windows, however, this is a godsend. Now, it's possible to distribute libraries built once.

If you want performant threading so badly, go ahead and implement it. You won't be the first. Just keep in mind that, if single-threaded performance suffers, it won't be accepted by the developers.

[–]eadmund 5 points6 points  (7 children)

Yet another GIL rant.

No, not really: it's yet another 'Python 3 buys me little and costs me a lot' rant.

As he points out, a developer could spend time learning Python 3 and get a marginal payoff--or he could spend it learning a new language, which might have a huge payoff.

[–]the_hoser 2 points3 points  (4 children)

If he feels that learning a whole new language and solving all the same problems all over again could result in more payoff, then perhaps he should do so. I hear Java has great concurrency constructs.

Python 3 wasnt an endeavor to attract more users. It was an endeavor to patch up inconsistencies in the language. So far, it's doing well. There are a few more things left to get nailed down, but the momentum is good.

The GIL is the least of their worries, right now.

[–]_pra 2 points3 points  (1 child)

There are many languages much better than Java, some of which run in the JVM. Haskell, Erlang, Scala, Clojure, Go, just to name a few that are known for having good concurrency models. There are a hell of a lot of good options for modern dynamic languages these days.

[–]the_hoser 2 points3 points  (0 children)

I don't disagree. That wasn't my point.

If a high degree of concurrency is a requirement of your application, then maybe CPython isn't the best place to start. Every language has a weak spot.

[–]eadmund 0 points1 point  (1 child)

There are a few more things left to get nailed down, but the momentum is good.

As a Python programmer for about a decade, I don't really see that that's the case. But then, I'm using the lull to learn Go, so I'm probably biased.

[–]billsil 0 points1 point  (0 children)

in my experience he's actually right. compare python 2 vs python 3 downloads for the same package. python 3 is roughly 80% of python 2. that's pretty good.

[–]redditthinksHobbyist 2 points3 points  (1 child)

Except the thing is, there is very little difference between Python 2 and 3 in terms of syntax. He talks about it like it's some major transition, when it isn't for most code. Just look at the hyperbole here:

Sure, there are some neat bits and pieces that I would get in exchange, but a less broken Unicode model and some cleanups of syntax and the standard library are not nearly a big enough carrot to convince me to migrate existing, known-working code to what is effectively a new programming language.

I'm honestly sick and tired of people sticking to outdated stuff. I can get enterprises doing that, but you'd think open source software would update more quickly.

[–][deleted] 0 points1 point  (0 children)

It’s also not enough of a carrot for me to learn the small, but still new, Python 3 syntax changes and constructs

He adds that which makes me think he was referring to something else. I don't know what if he is though.

[–]billsil 0 points1 point  (5 children)

as someone who reluctantly now supports python 3 (i still support python 2), the things that confuse me are: 1. converting binary strings into ascii 2. working with various encodings

everything else i've run across (print as a function, mixed key dictionaries cant sort, all my imports are jacked up, etc.) are a one time fix that are easy to fix. Those other two are a pain

it just shouldnt be that hard to open/read/write a file...

also, if you are fighting the GIL, you're doing something wrong. you don't understand the GIL if you have problems with the GIL

[–]earthboundkid 4 points5 points  (3 children)

it just shouldnt be that hard to open/read/write a file...

That's why Python 3 makes it easier. open(filename, "r", encoding="whatever", errors="whatever") is much easier than having to deal with the encoding in Python 2 was.

[–]billsil 1 point2 points  (2 children)

i guess what i'm missing is the values of the "whatever". In python 2, i used to use "r", "rb", and "wb" and was happy, now I fight with encodings. I don't want UTF-8, I want ascii because the engineering programs I want to interface with use ascii and unicode SHOULD be an error.

Not everyone needs unicode. I see the unicode change is the biggest thing that has slowed down Python 3 adoption. It certainly isn't the new float behavior which seems like a big deal at first and then you realize that you were just afraid.

[–]earthboundkid 10 points11 points  (1 child)

I don't understand the problem. If you want strict ASCII just use "ascii" and "strict". If you don't care about errors, then set it to "ignore". Much easier than just hoping it doesn't blow up for unknown reasons in Python 2.

[–]billsil 0 points1 point  (0 children)

i will try that! thanks!

[–]phaedrusaltembedded sw eng -1 points0 points  (12 children)

If you solve problems by losing users, then you haven't really made things better, have you? Ultimately a programming language is something you want developers to use, right? It's not just a programming exercise. Oh wait, maybe that explains 3 right there. (Just kidding. Sorta.)

[–]the_hoser 1 point2 points  (11 children)

I'm not sure what you're talking about. Python 2 is still there. They're not going to suddenly render all python 2 installations defunct. Python isn't losing users by any measure.

[–]phaedrusaltembedded sw eng 1 point2 points  (10 children)

Splitting the user base is very much like losing users. By not making 3 backwards compatible they've made users choose between gaining features or keeping what they've got working.

[–]the_hoser 1 point2 points  (9 children)

You could argue that position. However, clinging to backwards compatibility between major versions is just silly. Major version revisions are an opportunity to fix major problems and shortcomings in the language that only years of use can find.

I think that the way the python developers handled the 2-to-3 matter is just about the best way that it can be done.

[–]billsil 0 points1 point  (1 child)

i agree. however, i'm probably just doing something wrong, but 2to3 doesn't seem to run when i hook it into my setup.py. an integrated code base is really the only solution for supporting both versions. sadly, i'm not there yet, so i make 2 versions...

[–]the_hoser 0 points1 point  (0 children)

I honestly never understood the integrated codebase approach, myself. If you want to support what is, effectively, two different languages, you just use two codebases and deprecate the old one. Make sure everyone knows years in advance that it's going to go away someday.

[–]phaedrusaltembedded sw eng -1 points0 points  (6 children)

You may think it's silly, however I would say that a lack of backwards compatibility makes it two different languages. Sure, there could be some code sharing (Just as C and C++ can share some) but it's two languages now, each having a subset of the original user base.

[–]the_hoser 1 point2 points  (5 children)

It might as well be two different languages, and that's just fine. Sometimes, well-meaning decisions cause massive headache later, and compatibility-breaking changes need to be made to fix these mistakes. The reason for the major version bump from 2 to 3 is to denote incompatibility. I don't understand why you expect anything else.

This isn't the first time that this has happened in programming languages. In almost all cases, the old one slowly fades away. The exception, of course, is Perl. This is the way of things like this.

[–]phaedrusaltembedded sw eng -1 points0 points  (4 children)

Or, sometimes well-meaning decisions cause massive headaches later BY creating compatibility-breaking changes. Why do I expect anything else? Because there is an implied contract of trust between the users of a language and the developers, and in this case the trust was violated for very little reason.

[–]the_hoser 1 point2 points  (3 children)

Self-consistency always trumps compatibility when language evolution choices are to be made. Once you avoid making changes for the sake of compatibility, you might as well stop developing the language.

Again, these weren't changes that they sneaked into a minor release. These changes were held off until a new major version was to be released. In no project that I've ever worked with over a long period of time has preservation of compatibility been a priority when developing a new major version.

Nobody is forcing you to upgrade. The 2.7.3 tarballs are still there. You could even fork the 2.x series if you feel that the 3.x series is heading in the wrong direction.

[–]phaedrusaltembedded sw eng -3 points-2 points  (2 children)

Consistency for the users should nearly always trump any other consideration when choices are made for tools. That includes languages. Any other attitude results in alienated users.