Migrating to Python 3 with pleasure • Hacker News Board

Re: Migrating to Python 3 with pleasure

#161

Post by cup-of-tea » Mon, Feb 05, 2018, 3:51 PM UTC

newen wrote: post #160

cup-of-tea wrote: post #115

It's so strange to me that data scientists would need to be convinced to move to Python 3. It's superior in every way to legacy Python. I can understand maintaing Python 3 compatbility for legacy systems if you don't want to have Python 3 as a dependancy, but data scientists will be writing mostly ad hoc code and using Jupyter notebooks. The people around me are not allowed to use Python 2, in fact they're generally…

For me, it's as simple as python is not a moving target. Whatever new changes there are in python 3 doesn't affect me since I won't be using any of the new features even if I were to use python 3.

Why on earth would you not use the new features?

Re: Migrating to Python 3 with pleasure

#162

Post by empthought » Mon, Feb 05, 2018, 3:59 PM UTC

jsjohnst wrote: post #157

djrobstep wrote: post #72

Earlier quoted context omitted.

No, I mean the rows. Each row is semantically an ordered mapping.

Shouldn’t the collection of rows be a set or list, not a dictionary? That said, you disagreed with my question then went on to show my question was on point. The “rows themself” being an ordered map means you are referring to the columns, the order being set by the SELECT clause or table definition order (in case of wildcard). That said, I personally feel iterating over table columns in that way to be a “bad code sme…

Order-significance is exactly how the relational model was defined in the beginning

"An array which represents an n-ary relation R has the following properties:

1. Each row represents an n-tuple of R.

2. The ordering of rows is immaterial.

3. All rows are distinct.

4. The ordering of columns is significant -- it corresponds to the ordering S1, S2, ..., Sn of the domains on which R is defined (see, however, remarks below on domain-ordered and domain-unordered relations).

5. The significance of each column is partially conveyed by labeling it with the name of the corresponding domain."

-- A relational model of data for large shared data banks[1]

[1]: https://cs.uwaterloo.ca/~david/cs848s14/codd-relational.pdf

Re: Migrating to Python 3 with pleasure

#163

Post by donarb » Mon, Feb 05, 2018, 4:26 PM UTC

IshKebab wrote: post #139

makecheck wrote: post #62

I’m a little surprised at this point that Apple still doesn’t include a default Python 3.x on macOS. It’s the single thing keeping me from moving (as there’s a big difference between “just run this” and “first download this, then run this”).

Honestly the fact that they include a system Python 2 is a huge pain. You can't add packages to it, and you shouldn't add another Python 2 interpreter to the PATH. You end up having to use virtualenv which is a stupid hack.

pip takes a --user flag that installs packages to your user's account. It's essentially global unless you have multiple users on your machine.

Re: Migrating to Python 3 with pleasure

#164

Post by donarb » Mon, Feb 05, 2018, 4:31 PM UTC

Another feature is that the mock module is now part of the standard library, no need to install.

Re: Migrating to Python 3 with pleasure

#165

Post by makecheck » Mon, Feb 05, 2018, 4:38 PM UTC

viraptor wrote: post #138

makecheck wrote: post #62

I’m a little surprised at this point that Apple still doesn’t include a default Python 3.x on macOS. It’s the single thing keeping me from moving (as there’s a big difference between “just run this” and “first download this, then run this”).

My theory is that this is not going to be a nice change when they drop 2.7. Maybe one version will be released with both installed by default, then they'll use only 3.7/3.8 for the next decade. MacOS doesn't seem to care a lot about backwards compatibility recently. This is of course pure speculation...

Other OSes just install a “python3” binary, I’d expect Apple to do the same.

Re: Migrating to Python 3 with pleasure

#166

Post by amyjess » Mon, Feb 05, 2018, 4:40 PM UTC

memco wrote: post #81

amyjess wrote: post #63

I'd been a 2.7 holdout for ages, but when f-strings were greenlit for 3.6, I decided then and there that all my new personal projects would be written in 3. I'm glad I did. F-strings are wonderful, as is pathlib and the enhanced unpacking syntax. Since I started my current job, I've also been writing as many scripts as I can in Python 3 as well (and Docker has been a godsend for that because I can now deploy 3.6 scri…

Could you provide more info on your setup for this? I work on some EL 6 servers and would be interested in using this setup.

Honestly, I just wrote my Dockerfile using the example from the official Python container: https://hub.docker.com/_/python/

Then I push the image to my company's internal Docker registry, ssh into the server, and pull the image.

(also, aside from using Python 3 on RHEL 6, it also means using Python 3.6 on RHEL 7 without having to install python36u)

Edit:

Dockerfile (script name redacted)

    FROM python:3
    WORKDIR /usr/src/app

    COPY requirements.txt ./
    RUN pip install --no-cache-dir -r requirements.txt
    COPY . .

    CMD [ "python", "./redacted.py" ]

Build and push commands (company and script names redacted):

    docker build --rm -t dreg.example.com/redactedproject/redacted .
    docker push dreg.example.com/redactedproject/redacted

Pull and run on the server (same stuff redacted as above, plus I redacted the actual port number to be on the safe side):

    docker pull dreg.example.com/redactedproject/redacted
    docker run -p 1337:1337 -d --name redacted dreg.example.com/redactedproject/redacted

And at some point, I'll make proper startup scripts for them. On RHEL 7 boxes, I've made systemd unit files. On RHEL 6... well, I suppose I'll be writing initscripts soon.

Re: Migrating to Python 3 with pleasure

#167

Post by newen » Mon, Feb 05, 2018, 7:16 PM UTC

cup-of-tea wrote: post #161

newen wrote: post #160

Earlier quoted context omitted.

For me, it's as simple as python is not a moving target. Whatever new changes there are in python 3 doesn't affect me since I won't be using any of the new features even if I were to use python 3.

Why on earth would you not use the new features?

Tradition? ;) I only use python for deep learning, which is not really that intensive in terms of code. Also most of the code out there for deep learning works on both python 2 and 3.

Also, your phrasing invites the question. Why on earth would I use a new feature in a turing complete language? Unless using the new feature results in tangible improvements in my code, I don't see a reason to use it.

Re: Migrating to Python 3 with pleasure

#168

Post by viraptor » Mon, Feb 05, 2018, 7:53 PM UTC

makecheck wrote: post #165

viraptor wrote: post #138

Earlier quoted context omitted.

My theory is that this is not going to be a nice change when they drop 2.7. Maybe one version will be released with both installed by default, then they'll use only 3.7/3.8 for the next decade. MacOS doesn't seem to care a lot about backwards compatibility recently. This is of course pure speculation...

Other OSes just install a “python3” binary, I’d expect Apple to do the same.

Sure. What I'm saying is I expect python/python2 to be gone soon after that.

Re: Migrating to Python 3 with pleasure

#169

Post by gh02t » Mon, Feb 05, 2018, 8:02 PM UTC

pletnes wrote: post #105

gh02t wrote: post #18

Earlier quoted context omitted.

What do you mean? `A.dot(B)` and `A @ B` are the same thing for NumPy arrays. You might be mixing it up with the weirdness of `array` versus `matrix`, but that's totally separate.

The @ operator is the same as np.matmul which is different from np.dot for matrices of rank >=3.

Ah you're right, I had that mixed up. matmul should generally be the desired behavior anyway I'd think, the previous behavior of dot was a bit weird IMO, especially the behavior with a scalar. It's not backwards compatible, but I think it'd be better to prefer @/matmul in the future anyway.

I almost think it'd be nice to make matmul undefined for ranks higher than 2, since it's not really matrix multiplication and if you want to do that (or the previous behavior of dot) it can be achieved with einsum, with the advantage that you have to be a lot more explicit about what sort of tensor multiplication you want. That's probably a bit too purist though.

Re: Migrating to Python 3 with pleasure

#170

Post by koshak » Mon, Feb 05, 2018, 9:27 PM UTC

newen wrote: post #167

cup-of-tea wrote: post #161

Earlier quoted context omitted.

Why on earth would you not use the new features?

Tradition? ;) I only use python for deep learning, which is not really that intensive in terms of code. Also most of the code out there for deep learning works on both python 2 and 3. Also, your phrasing invites the question. Why on earth would I use a new feature in a turing complete language? Unless using the new feature results in tangible improvements in my code, I don't see a reason to use it.

I really like this one. “So you already have your turing complete language! What else do you need?”