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

About Python 3

alexgaynor.net

Post reply on HN
Print view View original

121–130 of 358 posts

Re: About Python 3

#121

Post by dekhn »

freyrs3 wrote: post #76
dekhn wrote: post #6

I used Python 3 for the first time a few days ago (I've been programming in Python for 18 years). When I used python heavily (I've switched back to C++ and now Go) I depended a lot on a small number of really good libraries- ElementTree, NumPy, SciPy, etc. Unless/until all of those get ported to Python 3 (along with hundreds of other programs), and those ports are considered Correct (in the QA validation sense), it's…

Just out of curiosity, have you actually tried getting NumPy/SciPy working on Python 3? Because they've been fully supported for quite a while now. I don't understand how this myth keep perpetuating itself.

I'm not interested in even playing any more. Like I said, I haven't used Python 3 before today (after 18 years of programming Python). I would have cared, for example if Python 3 had any impact in the real world. Anyway, it took years for numpy support; it wasn't available until recently for python3. That's the problem: it took years before these common tools were proted.

Re: About Python 3

#122

Post by dragonwriter »

ak217 wrote: post #41
antrod wrote: post #16

There is no meaningful performance increase to go to a backwards incompatible version? Three letters: DOA. if not performance then at least we'd need some crazy new feature like good multi threading or perhaps running on a new relevant platform (say ios or android). Otherwise we will be 2.X forever.

Actually, there are some minor performance increases, but there are tons of minor improvements, and the new async framework landing in 3.4 is very exciting.

> Actually, there are some minor performance increases

And apparently some fairly major ones (e.g., decimal in Python 3.3.)

Re: About Python 3

#124

Post by SEMW »

revskill wrote: post #52

I wonder why Django doesn't have the same strength (both technically and community) as Rails ? I think the philosophy "Everything is an object" makes sense actually, and in combination with functional programming built-in really makes Ruby is perfect choice for non-professional programmer (even woman) to love coding.

> perfect choice for non-professional programmer (even woman)

It's 2013. Could we please leave 'so easy even a woman could use it' levels of sexism behind us?

(Not to mention - it's a little silly to single out web frameworks as the One True comparator of two languages. That Rails is more popular than Django does not necessarily imply that Ruby is a better language than Python, any more than the fact that SciPy is more popular than SciRuby implies the reverse).

Re: About Python 3

#125

Post by dekhn »

freyrs3 wrote: post #71
toyg wrote: post #22

Earlier quoted context omitted.

ElementTree has always been in 3.x. I believe NumPy and SciPy are finally making the leap just about now.

A lot of people cite that lack of NumPy support is what's keeping them from moving to Python 3, I've seen this comment more times than I can count. It seems most of them haven't done their research and found that NumPy/SciPy has had complete support for Python 3 for 4 years now.

Please don;t interpret my comments above as ignorance. I am quite aware of what is available (and was available, when I considered switching to python3). I did my research at the time (which was some 5 years ago). It looks like scipy was added about 3-4 years ago... at which point I don't care any more.

Re: About Python 3

#126

Post by rogerbinns »

rom16384 wrote: post #84
dekhn wrote: post #6

I used Python 3 for the first time a few days ago (I've been programming in Python for 18 years). When I used python heavily (I've switched back to C++ and now Go) I depended a lot on a small number of really good libraries- ElementTree, NumPy, SciPy, etc. Unless/until all of those get ported to Python 3 (along with hundreds of other programs), and those ports are considered Correct (in the QA validation sense), it's…

I don't regard the lack of practical multithreading as a problem. We routinely use multiprocessing and IPC via queues for parallelism, and for me the main limitation is Python's excessive memory use: even atomic data types are objects which cause quite a bit of overhead (a memory efficient dictionary with support for a few basic data types would be great). Thankfully everything still fits in the server's memory, othe…

I heartily recommend using concurrent.futures. It is a standard part of Python 3.2+ - http://docs.python.org/dev/library/concurrent.futures.html - and you can get it for other Python versions - https://pypi.python.org/pypi/futures

Behind the scenes it uses multiprocessing and/or threading plus queues etc. I have a function that adds command line arguments (number of workers, use threads or processes, debug mode) and then another that returns an executor given the command line arguments.

The debug mode forces a single thread and is intended for when you want to run pdb as multiple threads/processes make things considerably more complicated.

Re: About Python 3

#127

Post by pudquick »

w1ntermute wrote: post #120
laureny wrote: post #112

Earlier quoted context omitted.

> Mac overall market share is still pretty low. Somewhere in the 10% percent range I believe. That's in the US. In the rest of the world, it's around 5%.

According to this site[0], it's at 7.54%. Out of that, only 32% are running the latest version of OS X (10.9). Another 24.5% are running 10.8. So almost half of OS X users are at least 2 versions behind. Not nearly as up-to-date as you might think. 0: http://www.netmarketshare.com/operating-system-market-share....

So what you're saying is that greater than 56% of Macs are running operating systems at most 1.5 years old ? (10.8 + 10.9).

God I wish the numbers were like that for Windows.

Re: About Python 3

#128

Post by danso »

wycats wrote: post #119
danso wrote: post #104

Earlier quoted context omitted.

But were the changes between 1.8 and 1.9 in Ruby as significant as 2 to 3 to Python? Or even 1.8 to 2.0? I know in Ruby 1.8.x to 1.9, some major changes in my day-to-day coding involved Hash (elimination of hash-rocket, and ordered key-value pairs by default)...but I can't think of anything off hand that required me to rewrite my own libraries. And between 1.9 and 2.0...I've been switching between machines that have…

1.8 to 1.9 was a HUGE release in terms of breaking changes. Probably the most notable change was the introduction of proper unicode support. Unlike Python, which changed syntax at the same time, Ruby tried to maintain compatibility with existing syntax. In practice, this allowed Ruby libraries (including Rails; I did the bulk of the encoding work for Ruby 1.9 in Rails 3) to do runtime introspection to support 1.8 and…

Ah yes, it's fitting that I would forget about the Unicode change...the fact that I did so is just further affirmation of why I still get myself into encoding problems...all the time. But yes, the Unicode support did seem to be a frequent reason for library overhauls.

Re: About Python 3

#129

Post by dekhn »

rom16384 wrote: post #84
dekhn wrote: post #6

I used Python 3 for the first time a few days ago (I've been programming in Python for 18 years). When I used python heavily (I've switched back to C++ and now Go) I depended a lot on a small number of really good libraries- ElementTree, NumPy, SciPy, etc. Unless/until all of those get ported to Python 3 (along with hundreds of other programs), and those ports are considered Correct (in the QA validation sense), it's…

I don't regard the lack of practical multithreading as a problem. We routinely use multiprocessing and IPC via queues for parallelism, and for me the main limitation is Python's excessive memory use: even atomic data types are objects which cause quite a bit of overhead (a memory efficient dictionary with support for a few basic data types would be great). Thankfully everything still fits in the server's memory, othe…

Well I do care. I think multiprocessing is a stupid abomination- it's like a person who never learned how to use threads found the threading library and decided to make a message-passing communication system with a thread-compatible concurrency library.

Message passing is fine (and it's the sort of thing that Go uses) but ultimately, leaving single-address-space multithreading completely on the table when it's the single most obvious and straightforward way to take advantage of modern processors is just dumb.

Re: About Python 3

#130

Post by falcolas »

devicenull wrote: post #107
falcolas wrote: post #82

As a development lead, we recently abandoned our plans to migrate to Python 3. Here's a short summary of why: To begin the migration, we needed to move from Python 2.6 (which is the default on our CentOS6 production boxes) to Python 2.7. This transition is actually rather hard. We can't use the packages provided in CentOS base or EPEL, because they are all complied against Python 2.6. To re-produce all of our package…

Using Python2.7 on CentOS really isn't that hard. Install FPM, and run `fpm --python-bin python2.7 --python-easyinstall easy_install-2.7 -n MySQL-python27 -s python -t rpm -d python27 MySQL-python` . You'll find a MySQL-python27 RPM sitting in the current directory. Repeat for any package you want. You can avoid compiling the core python27 language yourself by using the python27 packages from IUS.

You just described building packages, which we looked into and decided not to do. The cost (which does not stop after the rather easy step of building the packages) was not offset by the benefit of migrating.
Post reply on HN