Live data from Hacker News

Python 2.x vs. 3.x use survey

docs.google.com

11–20 of 72 posts

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

#11

This reminds me of a Flask mini project I did. I was doing it in Ubuntu (LTS if I'm not mistaken). I picked python3 and ran with it. As I tried to use Python's virtualenv (venv), I went down the rabbit hole of a broken mess that was left in Ubuntu. I just reinstalled Ubuntu this week so I might give it another shot, but every time I try to do something with Python I end up with a broken mess, and that's disheartening

I'm also sorry that Ubuntu broke venv, but there were many (edit: at least a few that I remember) attempts to file tickets to get that fixed in Ubuntu, lots of stupid arguments against fixing it

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

#12
post #8

That's a useless survey. Answers by random people aren't particularly useful. It doesn't reflect how much of a Python code base one is responsible for. Analysis of major code bases written in Python would be more useful.

To be pedantic, answers by randomly sampled people would be more useful than this, which is so skewed it's useless.

In either case, it's irrelevant

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

#13
post #9

I was super turned off of Python 3 when it came out and I promptly tried it and ran open("/dev/urandom").read(20) and was confronted with UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 2: invalid start byte If I had realized at the time that this error would be averted with open("/dev/urandom", "rb").read(20) I might have felt more charitable and less shocked (although I can see in retrospect th…

Your first version was already not correct/portable. When reading binary files on Windows, you have to include the binary mode. Otherwise you'll drop bytes semi-randomly.

This change only made that mistake visible on other systems.

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

#14

This reminds me of a Flask mini project I did. I was doing it in Ubuntu (LTS if I'm not mistaken). I picked python3 and ran with it. As I tried to use Python's virtualenv (venv), I went down the rabbit hole of a broken mess that was left in Ubuntu. I just reinstalled Ubuntu this week so I might give it another shot, but every time I try to do something with Python I end up with a broken mess, and that's disheartening

AFAIK -mvenv is still kaput in Ubuntu. I just this instead:

    sudo apt-get install python-virtualenv python3
    virtualenv -p/usr/bin/python3 
Yes, it'd be way cooler if -mvenv wasn't crippled in Ubuntu, but this still works fine.

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

#15

This reminds me of a Flask mini project I did. I was doing it in Ubuntu (LTS if I'm not mistaken). I picked python3 and ran with it. As I tried to use Python's virtualenv (venv), I went down the rabbit hole of a broken mess that was left in Ubuntu. I just reinstalled Ubuntu this week so I might give it another shot, but every time I try to do something with Python I end up with a broken mess, and that's disheartening

> As I tried to use Python's virtualenv (venv), I went down the rabbit hole of a broken mess that was left in Ubuntu.

What do you mean? virtualenv exists exactly so that your libs are installed in your local directory and not globally in the system. I'm not sure how it could result in broken mess in the system that way.

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

#16
post #9

I was super turned off of Python 3 when it came out and I promptly tried it and ran open("/dev/urandom").read(20) and was confronted with UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 2: invalid start byte If I had realized at the time that this error would be averted with open("/dev/urandom", "rb").read(20) I might have felt more charitable and less shocked (although I can see in retrospect th…

Your first version was already not correct/portable. When reading binary files on Windows, you have to include the binary mode. Otherwise you'll drop bytes semi-randomly. This change only made that mistake visible on other systems.

There is no /dev/random on windows anyway. Not every piece of code has to be portable.

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

#17
post #16

Earlier quoted context omitted.

Your first version was already not correct/portable. When reading binary files on Windows, you have to include the binary mode. Otherwise you'll drop bytes semi-randomly. This change only made that mistake visible on other systems.

There is no /dev/random on windows anyway. Not every piece of code has to be portable.

Yes, I definitely wouldn't have expected or intended that code to work on Windows.

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

#18
I mainly use Python to write Robot Framework libraries. RF needs to support Jython, Jython will not support Python 3 in near future, so I'm stuck. There is a Python 3 fork of RF (https://bitbucket.org/userzimmermann/robotframework-python3) which I might use next time I get to start writing RF libraries from scratch.

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

#19

This reminds me of a Flask mini project I did. I was doing it in Ubuntu (LTS if I'm not mistaken). I picked python3 and ran with it. As I tried to use Python's virtualenv (venv), I went down the rabbit hole of a broken mess that was left in Ubuntu. I just reinstalled Ubuntu this week so I might give it another shot, but every time I try to do something with Python I end up with a broken mess, and that's disheartening

Ubuntu, at least some versions, ship with a horribly broken Python3. Broken because pip and virtualenv is somehow screwed up.

It's an Ubuntu bug, not Python3. Install Python3 from python.org an everything is fine, except then apt-get of cause won't give you the bug fixes.

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

#20
post #16

Earlier quoted context omitted.

Your first version was already not correct/portable. When reading binary files on Windows, you have to include the binary mode. Otherwise you'll drop bytes semi-randomly. This change only made that mistake visible on other systems.

There is no /dev/random on windows anyway. Not every piece of code has to be portable.

It doesn't have to be, but going for a more correct/portable code (than absolutely necessary minimum) helps avoid such problems. In this case binary file was opened - if the "rb" mode was added anyway, the exception mentioned above wouldn't happen.

Edit: Actually python doesn't even mention windows. It's simply "Add a 'b' to the mode for binary files." (in python 2.7 documentation) According to the docs it should be specified regardless.

Post reply on HN