Live data from Hacker News

Python 2.x vs 3.x use survey

surveymonkey.com

101–110 of 119 posts

Re: Python 2.x vs 3.x use survey

#101
post #69

Earlier quoted context omitted.

Its all well saying Django supports Python 3, but when you reply on a dependency, such as MySQL connector (which I assume a LOT of Django users will want to use), then Django effectively doesn't work with Python 3.

I just stumbled on PyMySQL[0], who supports Python 3. Is there any issue with using this library, since it seems an obvious solution to this problem? [0] https://github.com/PyMySQL/PyMySQL/

No, there isn't.

CyMySQL and oursql are also viable options.

Re: Python 2.x vs 3.x use survey

#102
post #51

Earlier quoted context omitted.

I think that's a very significant question. I would guess that 50%+ of Python users don't use Python 3, and thus would be counted as anti-Python-3, if not for that question which allows them to say "I don't think Python 3 is inherently a bad idea." It would be nice if the question were more specific and more positive, but the survey would be worse if it were simply taken out.

Why not the question "Is staying on Python 2.x a mistake?" The whole survey is bunk. Too much misinformation and misbeliefs regarding Python 3. The only valid informed answers would be from those who've used (or used and failed) >= Py3.3 for something significant.

I agree that the survey is poor, but it is not bunk.

It should have had more questions attempting to discover why those who don't adopt Python3 don't. Then, if a major problem turns out to be misinformation, it could be addressed with evangelism. If a problem is a shortcoming of Python3, that shortcoming could be addressed. Etc.

Re: Python 2.x vs 3.x use survey

#103

Earlier quoted context omitted.

The migration is so difficult that you might as well migrate to a different language and solve the speed and memory usage issues while you're at it.

What language would you recommend, that would have a similar jump in syntax, and still give you more speed and resolve memory usage? Go? Go is painfully statically typed (painful example: requiring you to cast an int to float32 to do a `>` or ` Ruby? Same speed and memory "problems" as Python. Perl? Faster, but its language design philosophy is diametrically opposed to that of Python. Clojure/Haskel? Syntax and progr…

Go would be my first recommendation. The strictly enforced coding habits, lack of generics, the packaging system without dependency versioning and quirks like typed nil are a small price to pay for the sane syntax, impressive performance and a very easy to use CSP implementation.

P.S.: I don't know what you mean by that example. You don't need to cast an int to anything in order to use comparison operators.

Re: Python 2.x vs 3.x use survey

#104

Earlier quoted context omitted.

The migration is so difficult that you might as well migrate to a different language and solve the speed and memory usage issues while you're at it.

What language would you recommend, that would have a similar jump in syntax, and still give you more speed and resolve memory usage? Go? Go is painfully statically typed (painful example: requiring you to cast an int to float32 to do a `>` or ` Ruby? Same speed and memory "problems" as Python. Perl? Faster, but its language design philosophy is diametrically opposed to that of Python. Clojure/Haskel? Syntax and progr…

I'm actually leaning towards Haskell and Clojure these days. They get me more of the simplicity that Python won me over with along with other benefits.

I gave Go a chance to supplant Python as my main language, and I thin it could do that. I had a few other problems with Go though which led to me looking at Haskell.

I'm giving Haskell a chance to supplant Python/Go as my "go to" language atm and it seems to be winning me over, but only time will tell.

Re: Python 2.x vs 3.x use survey

#105
post #68

Earlier quoted context omitted.

What language would you recommend, that would have a similar jump in syntax, and still give you more speed and resolve memory usage? Go? Go is painfully statically typed (painful example: requiring you to cast an int to float32 to do a `>` or ` Ruby? Same speed and memory "problems" as Python. Perl? Faster, but its language design philosophy is diametrically opposed to that of Python. Clojure/Haskel? Syntax and progr…

I would actually pick Go. Yes, the strong static typing is a pain in the ass, but the rules are simple and regular. It's easy to understand and implement. The same cannot be said for the multitude of changes to Python.

I use/used Go for a while, but early on I thought the type system was stronger than it was. I was disappointed in a later project, and started looking at languages with stronger type systems.

I came across Haskell and Hindley Milner ;)

I believe Haskell replaces Go for me and with some experience (when I can picture types in my head better) it will replace python as my go to dynamic language.

Re: Python 2.x vs 3.x use survey

#106
post #71

Earlier quoted context omitted.

What do you mean by "string manipulation"? bytes are not text strings. If you actually mean text operations, then converting them is something you should also do in py2. Edit: now that I thought about it - since you're able to decode the bytes you're using, it means you are operating on text - why not convert it then?

See http://bugs.python.org/issue3982 that's linked elsewhere in these comments for the kind of things that don't work on bytestrings

I read it all, and to be honest I think I agree the most with http://bugs.python.org/issue3982#msg180441 (.format may be making some things simpler, but it goes against the idea of well separated bytes -vs- text)

But really, I just don't like how http/ftp/similar protocols were designed in the first place. They're mixing binary and text in the same stream. That's ugly and when you have strict rules about text encoding in your language, the implementation also turns out ugly - what a surprise :)

Re: Python 2.x vs 3.x use survey

#107

Earlier quoted context omitted.

I have problems with the way this is worded as well. I don't think Python 3.x was a mistake. I think the mistake is continuing to develop it in parallel with 2.x with no definitive end of life for 2.x is the mistake.

No, I disagree. So many programs rely on further support for Python 2. When you would end the life of Python 2, I myself would think, if I have to make a switch, should I switch to a more reliable codebase??? (Ruby, maybe -- I don't know enough about Ruby, but I would have a look on it) The reliability is one of Pythons strength and one of the reasons I use it. Take away the reliability and you will loose a lot. You…

Setting an end of life for Python 2 would be the forcing function needed to ensure Python 3 is reliable and the migration path is clear. Knowing the end is coming would drive us (the community) together to discuss and resolve these issues.

I for one never even considered that C extensions would be a serious road block. Which is obvious now that you mention it. And my main point, I've never bothered to research moving to Python 3 because there's no sense of urgency.

If Guido set a date, say Jan 1st 2015, it would remove allot of the apathy we're currently seeing.

Re: Python 2.x vs 3.x use survey

#108

Earlier quoted context omitted.

No, I disagree. So many programs rely on further support for Python 2. When you would end the life of Python 2, I myself would think, if I have to make a switch, should I switch to a more reliable codebase??? (Ruby, maybe -- I don't know enough about Ruby, but I would have a look on it) The reliability is one of Pythons strength and one of the reasons I use it. Take away the reliability and you will loose a lot. You…

Setting an end of life for Python 2 would be the forcing function needed to ensure Python 3 is reliable and the migration path is clear. Knowing the end is coming would drive us (the community) together to discuss and resolve these issues. I for one never even considered that C extensions would be a serious road block. Which is obvious now that you mention it. And my main point, I've never bothered to research moving…

Even than, I doubt that it would be helpful, since still so many C extensions are just not available in Python 3. I also don't think that it is a problem of apathy, but of wrong initial planning. With better initial compatibility, a bigger momentum could be reached. Now the decisive point is over and we will have to live long with both versions around (even when Guido sets a date).

Only thing that could really help, I think, would be a really big improvement in Python 3 that makes it more attractive to move, but that could also widen the gap between the two.

Re: Python 2.x vs 3.x use survey

#109
post #71

Earlier quoted context omitted.

See http://bugs.python.org/issue3982 that's linked elsewhere in these comments for the kind of things that don't work on bytestrings

I read it all, and to be honest I think I agree the most with http://bugs.python.org/issue3982#msg180441 (.format may be making some things simpler, but it goes against the idea of well separated bytes -vs- text) But really, I just don't like how http/ftp/similar protocols were designed in the first place. They're mixing binary and text in the same stream. That's ugly and when you have strict rules about text encodin…

[deleted]

Re: Python 2.x vs 3.x use survey

#110

Earlier quoted context omitted.

Do you mean the wall of shame/superpowers? https://python3wos.appspot.com/

From a cursory glance it seems like this may be somewhat inaccurate. It states NLTK doesn't support 3, when it definitely does.

The NLTK site says the Python 3 version is still alpha.
Post reply on HN