Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we rolled out one of the largest Python 3 migrations

blogs.dropbox.com

Post reply on HN
Print view View original

71–80 of 141 posts

Re: How we rolled out one of the largest Python 3 migrations

#71

Post by travbrack »

fermienrico wrote: post #12
thijsvandien wrote: post #2

Interesting write-up, though it leaves me terrified how a relatively small, more or less single purpose application like the Dropbox client has over 1 million lines of code in Python alone.

I found the Dropbox lecture [1] at Stanford one of the most riveting things ever. There is just so much technology behind Dropbox, it is staggering. There is a reason why it is so much better than iCloud sync, Google Drive, Box or OneDrive. [1] https://www.youtube.com/watch?v=PE4gwstWhmc

This led me to find another loosely related but very entertaining piece of dropbox history. The original "Show HN" post: [1]. It's funny to see so much skepticism knowing now what the company became.

[1] https://news.ycombinator.com/item?id=8863

Re: How we rolled out one of the largest Python 3 migrations

#72

Post by rtpg »

cjhanks wrote: post #55
mr_toad wrote: post #48

> However, rather than use the native toolchains directly, such as Xcode for macOS, we delegated the creation of platform-compliant binaries to py2exe for Windows, py2app for macOS, and bbfreeze for Linux. I wish the authors of more Python tools would deploy standalone applications. I do not like having to maintain various sets of Python installers/package managers (because every Python tool seems to use a different…

This is possible and actually pretty trivial. You install all 3rd party dependencies into some directory. The command line entry point is then a simple BASH script which sets the PYTHONPATH to the appropriate installation location and then does the appropriate exec call. You then have a functionally portable python installation.

in the ideal, those making the tools would provide this packaging, instead of asking all users to have `pip` properly set up. Similar issues exist w/r/t npm in my opinion.

Re: How we rolled out one of the largest Python 3 migrations

#73

Post by _ZeD_ »

thijsvandien wrote: post #2

Interesting write-up, though it leaves me terrified how a relatively small, more or less single purpose application like the Dropbox client has over 1 million lines of code in Python alone.

You have no idea how web development is different from desktop one

Re: How we rolled out one of the largest Python 3 migrations

#74

Post by billforsternz »

travbrack wrote: post #71
fermienrico wrote: post #12

Earlier quoted context omitted.

I found the Dropbox lecture [1] at Stanford one of the most riveting things ever. There is just so much technology behind Dropbox, it is staggering. There is a reason why it is so much better than iCloud sync, Google Drive, Box or OneDrive. [1] https://www.youtube.com/watch?v=PE4gwstWhmc

This led me to find another loosely related but very entertaining piece of dropbox history. The original "Show HN" post: [1]. It's funny to see so much skepticism knowing now what the company became. [1] https://news.ycombinator.com/item?id=8863

Yes, this is one of the classics - right up there with the "less space than a Nomad, no wireless, lame" comment (which wasn't on HN I don't think - but we all know it could have been :)

Edit: I see the motherlode is in place earlier in the thread "Especially when you could build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem"

Re: How we rolled out one of the largest Python 3 migrations

#75

Post by throwawaymath »

lugg wrote: post #67
cjhanks wrote: post #55

Earlier quoted context omitted.

This is possible and actually pretty trivial. You install all 3rd party dependencies into some directory. The command line entry point is then a simple BASH script which sets the PYTHONPATH to the appropriate installation location and then does the appropriate exec call. You then have a functionally portable python installation.

Pretty trivial? Really? I think as soon as you start writing all caps trivial has gone right out the window. Trivial would be application dependencies managed by the system package manager. I'm at the point where I won't touch a python app or library that can't be installed via Pacman. It's just not worth my time. And... python is still the only thing on arch that gives me the shits everytime it upgrades.

This exchange is a good demonstration that the word "trivial" has lost its meaning in the same way "literal" has. Much like I usually hear someone use term "literally" for figurative emphasis, these days I mostly hear the word "trivial" used to describe something which is clearly nontrivial.

Math textbooks have been doing this for decades, but it's leaked into common parlance with online discussion.

Re: How we rolled out one of the largest Python 3 migrations

#76

Post by kccqzy »

mr_toad wrote: post #48

> However, rather than use the native toolchains directly, such as Xcode for macOS, we delegated the creation of platform-compliant binaries to py2exe for Windows, py2app for macOS, and bbfreeze for Linux. I wish the authors of more Python tools would deploy standalone applications. I do not like having to maintain various sets of Python installers/package managers (because every Python tool seems to use a different…

Even when I am a python developer, there is still a difference between (a) this dependency that I explicitly rely on and that I need to sort out packaging issues for, and (b) code I treat as a black box and simply expect to work.

More often than not, a typical developer's python environment tends towards https://xkcd.com/1987/

Re: How we rolled out one of the largest Python 3 migrations

#77

Post by phonon »

jsmeaton wrote: post #49
chrisseaton wrote: post #22

Earlier quoted context omitted.

I'm surprised 10% wasn't enough - 10% bottom-line improvement in programming language implementation is normally massive. Twitter is singing from the roof-tops about 10% improvement in Java performance from the new Graal JIT compiler.

Maybe because 10% on a server is much more valuable than 10% on a client. On a server, you’re paying for that 10%. On a client, you’re not. If it was 10% for nearly free then sure - but maintaining a separate implementation of a language is costly.

No, Pyston said of their last version "On Dropbox’s server, we are 10% faster."

PS Thanks for all your Django contributions!

Re: How we rolled out one of the largest Python 3 migrations

#78

Post by mixmastamyk »

billforsternz wrote: post #74
travbrack wrote: post #71

Earlier quoted context omitted.

This led me to find another loosely related but very entertaining piece of dropbox history. The original "Show HN" post: [1]. It's funny to see so much skepticism knowing now what the company became. [1] https://news.ycombinator.com/item?id=8863

Yes, this is one of the classics - right up there with the "less space than a Nomad, no wireless, lame" comment (which wasn't on HN I don't think - but we all know it could have been :) Edit: I see the motherlode is in place earlier in the thread "Especially when you could build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mount…

The iPod comment was from slashdot, if memory serves.

Re: How we rolled out one of the largest Python 3 migrations

#79

Post by bdr »

rawoke083600 wrote: post #3

I would have thought that Go would be perfect for this sort of system-level-like programming ?

Why are people downvoting this? It’s a fine question to ask. I think people have been downvoting questions more lately, and it’s unfortunate.

Re: How we rolled out one of the largest Python 3 migrations

#80

Post by BuckRogers »

melling wrote: post #24
crdoconnor wrote: post #11

Earlier quoted context omitted.

Go code is about ~30% more verbose than equivalent python.

How much faster is Go? Memory usage? It has to be less demanding on your laptop battery, for example.

Go performance would be next tier from Python but memory usage a little less so. The Go team has made great strides in that regard from what it was. The runtime is always getting better, and it's fun to watch.

Rust or native platform (Swift/C# .Net Native, depending) are going to be even more ideal for battery usage.

Proper algorithmic choices are even more important and paramount no matter what is used. It goes without saying that poorly implemented Rust can be bested by well implemented Python.

Post reply on HN