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

131–140 of 358 posts

Re: About Python 3

#131

Post by dekhn »

rogerbinns wrote: post #126
rom16384 wrote: post #84

Earlier quoted context omitted.

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…

I've been programming with import Queue, import threading, for years now (probably 8 or 9). I don't want to drop all my completely fine multithreading code for Yet Another Threading API.

Personally I think multiprocessing is just dopey. Why force me to program around two different address spaces when I can just have one?

Re: About Python 3

#132

Post by TylerE »

claudius wrote: post #103
plorkyeran wrote: post #48

Earlier quoted context omitted.

In that case (and all of the other GNU stuff) it ships with the final GPLv2 version, since Apple is unwilling to ship GPLv3 code.

Is there a particular reason for that? I can understand not wanting to ship GPLv3 code if it is embedded sufficiently deeply into the hardware, but it shouldn’t be a problem to ship GPLv3 Bash, as the user can change the binary delivered on the harddrive at any time?

GPL has all kinds of non-corporate friendly clauses. I wouldn't touch GPLv3 code in anything I ship either.

Likewise Torvalds refuses to let GPLv3 touch the kernel.

Re: About Python 3

#133

Post by ausjke »

For web backend I feel the new PHP and its frameworks are good enough. JS/HTML5/CSS are doing well for web frontend at least, and they evolve fast. Java did well on Android and enterprise software stack. There are also Object-C, .NET for their market segments... Nothing can replace C/C++ for system programming at this point. Additionally, many 'minor' languages are here for different goals(Go, Erlang, etc).

Now the question, why do I need Python at all nowadays? I spent two years trying Python and ended up with PHP/C/C++/JS/Java for nearly all my needs.

Re: About Python 3

#134

Post by dekhn »

kylemaxwell wrote: post #123
dekhn wrote: post #30

Earlier quoted context omitted.

That's nice. I don't care.

accidentally upvoted. but why did you even bother posting that?

To demonstrate the vehemence which long-term experience programmers view the lack of ability with which Guido is running the python3 project.

If he had actually addressed the important questions in Python3 (first being getting the majority of people on 3 quickly by getting the major libraries ported quickly, second being addressing the GIl in either 2 or 3 (if the GIL had been removed in 3, I would have much more strongly considered it).

If either of those had been addressed, some of us (who are influential in the area) would have adopted 3 and prosetlyized it. However, I lost so much confidence in Python after the 2 to 3 transition that I've decided to actively non-prosetylize it.

Re: About Python 3

#135

Post by malkia »

Almost all Autodesk products come bundled with 2.x version of python. Could it be that Python 2.x is the Windows 7 of the Python world :) - just good enough for everyone.

(I'm not a python user, had to write few items for Maya/MotionBuilder and few other scripts).

Re: About Python 3

#136

Post by int_19h »

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…

With Python, one must take a conscious effort to write code that is both 2.x and 3.x, but it is entirely possible (also with some detection/shimming at runtime). Some of that is easier if you stick to 2.7 and 3.3+ only, because then you can do things like "from future import print_function", use b"..." and u"..." literals etc.

Re: About Python 3

#137

Post by falcolas »

marcosdumay wrote: post #108
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…

Even Debian is using Pyhon 2.7 for a while already, looks like CentOS is being quite slow.

When you consider what it is, it makes sense. It's designed for big companies that want stability, at the cost of being a few OS generations behind the bleeding edge.

Fedora is moving to Python 3, so RHEL (and thus CentOS) will follow, but not for several years.

Re: About Python 3

#138

Post by ak217 »

Ixiaus wrote: post #93
thezilch wrote: post #31

It wasn't until 3.3 that py3 was really palatable. Easier to support unicode running the same codebase in py2 and py3. yield from -- look, a py3 feature worth porting for! 3.3 was released in late 2012, and so, we can probably shift this "5 year" expectation to start from there. In fact, it's 3.4 that really starts to wet the beak with asyncio and enum. I'm not sure 2.8 needs to happen, if 3.x simply, and finally, ha…

This. While there are many wonderful features in Py3 (I use it 100% in production at work) it still needs a killer feature to really inspire people to move over. Python's lack of solid asynchronous I/O is definitely one of those features I think.

That's coming in 3.4.

Re: About Python 3

#139

Post by pnathan »

agentultra wrote: post #39

I like Python 3. I prefer it. It is better to program in than 2.x. Iterators everywhere, no more unicode/encoding vagueness, sub-generators and more. It is a much better language and it's hard to see how it could have evolved without a clean break from its roots. However it has been interesting to follow over the last five years. It has been a sort of, "what if p5 broke the CPAN," scenario played out in real-life. Br…

Had a discussion at work a few weeks ago about this. Roughly, it came down to this - if you need any backwards compatibility whatsoever (Do you ever expect your code to ever run on machines with operating system releases younger than 2013ish OR do you ever plan to interop with code older than 2013ish), Python 2 is the way to go. Otherwise, feel free to use Python 3.

This effectively means that only for purely greenfield projects for machines under your team's control and possibly even new teams can Py3 be used confidently. It's a shame - there are a number of nifty cleanups in Py3, but I simply don't see a compelling reason to use Py3 over Py2. This is particularly true given PyPy being fast and Py2. Given the triple of Python/Perl/Ruby for a greenfield project, I'd probably explore Ruby; I haven't been jaded by it yet, unlike Perl or Python.

Re: About Python 3

#140

Post by rmc »

w1ntermute wrote: post #51
themgt wrote: post #33

It's fascinating to compare this with ruby 1.9, released around the same time, but seemingly with a slightly better cost/benefit ratio, having nice new features and also significantly improved performance, and with ruby 1.8 being deprecated with a lot more speed and force. It got everyone to actually make the switch, and then ruby 2.0 came along, largely compatible and with a more improvements, and now ruby 2.1 seems…

> You could analogize it to Apple with OS 9 -> OS 10.9, versus Microsoft with people still running XP No, you couldn't. The difference in upgrade rates between Windows and OS X is primarily due to their differing customer bases. Windows is very popular in enterprise, which avoids unnecessary upgrades in order to ensure compatibility with in-house software. OS X, however, has almost no presence in enterprise, and cons…

As well as the enterprise, don't forget the non-technical home market, and non-technical small businesses. Windows is much more common there, and they also don't have a short upgrade cycle.
Post reply on HN