Live data from Hacker News

Python 2.x vs 3.x use survey

surveymonkey.com

71–80 of 119 posts

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

#71
post #16

Earlier quoted context omitted.

The inability to use string manipulation functions on bytestrings without converting them to unicode and back for each operation.

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

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

#72
In my view, the importance of the 2 vs 3 issue depends on who you think the typical Python user is, and the user population may be changing rapidly.

I'm not a CSist or professional programmer. I use programming as a tool, typically to solve short term problems for myself or for a small circle of colleagues. When I started using Python, not too long ago, it seemed like I had discovered a secret productivity tool. A project manager asked me: "What's a Python?"

Today, Python seems to be everywhere. It's been taken up by curious characters such as scientists and hobbyists. It seems to be the lingua franca of the Raspberry Pi. My non-CSist colleagues are getting into it, and I don't think it's just because of my incessant evangelism. ;-) A great thing about Python is that you can use it at whatever skill level you happen to be at, by ignoring its advanced features until you need them.

I could switch from 2 to 3 today, but I'm lazy. I'd get bonked by errant print statements for a while, and probably not experience any other hurdles. I spend more time already, keeping up with the changes that I make to my own libraries.

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

#73
post #60

Earlier quoted context omitted.

oh please. one single dependency that doesn't support py3 is the death knell to using it for anything, EVER I use python daily at work and you can be safely assured the state of py3 on pypi is fu$$$$ed. (we use pyramid not django for what it's worth)

one single dependency that doesn't support py3 is the death knell to using it for anything, EVER Can't you logically extend that across language boundaries, and if so, why would you ever try to use a different language? A needed library or feature of a library might be missing. Is it really that hard to take whatever dependency isn't supported and patch it? Isn't that one of the benefits of running an interpreted lan…

No, if it is a library, that you use all over your code. And you will not risk that your project fails, just because somebody wants to use only the newest stuff. Nobody in a time critical project (when it is not?), will switch from Py2 to Py3 just because it is the most recent version of Python and replace at least one library that is written in C and does not work in Py3. Either you have to replace the whole lib or you have to port the lib itself (what is not easy, when you don't have an experienced extension coder in team -- and also than, it is a risk!).

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

#74
post #66

Earlier quoted context omitted.

> If you google "Python training" you're going to get books, sites that offer training from 2.5 to 3.3. And those are recent sites (like 2012+). That's because these are all still valid versions of Python (which are still shipped with OSes). Most of the concepts you learn in Python 2.5 are still valid in Python 3.3; the changes weren't that dramatic. There are still strings, the control mechanisms didn't change, logi…

I wish it were true that existing online materials are appropriate for both Python 2 and 3. It's true that experienced Python programmers can easily identify the distinctions, and thus translate back and forth in their minds. But for a newbie, the fact that print("abc") works on Python 3 and 2.7, but not on earlier editions of 2 (and yes, many people still use those earlier versions) is confusing and frustrating. Whe…

Might I be so bold as to recommend not using print in the first place? Print's behavior changes depending on the environment, the capabilities of your terminal, and if you're piping to something else.

Instead teach people how to use sys.stdout to get properly deterministic behavior.

Print is useful in the repl, and in quick one-offs, but I would never use it for production deployments. And I never let it survive a code review either. It's bad practice to rely on it.

It's better in Python3, but I'd still probably use explicit file streams.

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

#75
post #25

"Do you think Python 3.x was a mistake?" That's where I stop filling out the survey. And that's the python community biggest problem. Moving forward, everyone needs to pick a version (and I'd pick 3). A new user just sits and spins his head. Even the training materials are all over the place.

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 will loose also many friends (like myself).

There was a blog post recently and stated an other option: Bring Py2 and Py3 nearer together to make the switch easier -- than more people would willingly move.

Some obstacles for moving where removed -- but a little late (e.g. the u"-Syntax was used many times in Py2 (at least outside english speaking countries or where localization is a topic) -- but abandoned in Py3. That was not necessary, but blocked an easy migration, because there are so many positions the code can be in. Now Py3 also supports the syntax and just ignores it ... why was that option not taken in the first place???) and not all. As much I know, there are still major differences when programming C extension libraries .... that makes porting existing libraries unnecessary troublesome.

Such things where not recognized early enough and still hamper adoption of Py3. Remove the blocks and you will gain more ground!

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

#76
I don't think people realize how easy it is to run a Python2 and Python3 codebase at the same time if you have decent test coverage and run tox.

Before PyCon SurveyMonkey(my employer) will be deploying a major part of our application on Python3.

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

#77
post #65
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.

It's way way way higher than 50%, if my sample is accurate. I've been teaching Python in China, Europe, Israel, and the US for years. In the last four years alone, I've taught about 2-3 Python courses (usually intro, but sometimes advanced or on specific topics) each month, at companies like Apple, Cisco, Intel, and SANDisk. In only one case did a company ask me to teach them Python 3. The rest of them ask specifical…

Being a newbie at Python myself and seeing how much the Python devs are trying to get people using Python 3, I was initially planning on just using Python 3 for all my Python coding. That was until I realized how many libraries exist only for Python 2.

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

#78
post #67
post #32

Earlier quoted context omitted.

Consider a generator that yields results indefinitely, or even merely millions of results. Are you still sure you want those printed to the repl? :)

The Python interactive shell could check the user's input: If it'll take infinitely long to run (e.g., an infinite generator), then it'll halt. If the code will eventually return, then it'll be run, displaying results to the user. Seems simple enough, no?

You'll need some killer heurstics: https://en.wikipedia.org/wiki/Halting_Problem

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

#79
post #17

The biggest thing that drives me nuts about py3 is just that its repl doesn't evaluate generators. I'm sure they had their reasons, but I use python as my go-to calculator, and when simple operations with maps/ranges give me a representation of a generator ("<map object at ...", whatever), then it's just less useful to me. I could be alone in that use case though...

> The biggest thing that drives me nuts about py3 is just that its repl doesn't evaluate generators. If by evaluate you mean "convert to a list", that's sensible, since a generator may or may not be safe to convert to a list. If you want a list, wrap the generator to a call to the list() builtin function, and, voila.

[deleted]

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

#80
post #11

For Mercurial, this is the biggest problem with Python 3: http://bugs.python.org/issue3982 They got rid of format for ordinary strings, and since we have to use bytestrings for handling hg's binary format, converting back and forth with .decode and .encode just to get the formatting is a lot of work. The Python devs have actually acknowledged this use case and apologised to hg. Kinda weird, considering how Python its…

Why not write it yourself, as a utility method rather than something built-in? Granted it would be nice to be built in, but that shouldn't stop anyone. Or is there some other reason?
Post reply on HN