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

91–100 of 358 posts

Re: About Python 3

#91

Post by mixmastamyk »

I was downvoted before for remarking that Py 3 needed a killer feature or two to drive adoption, similar to this post. Perhaps I was not charitable enough.

I'd personally like to see pypy bundled and a complete package manager solution, as well as usability features like bpython. I don't think it is necessary to dump it. It just needs a little excitement.

Still, after many years I am finally planning to move my stuff to Py 3.4 when it comes out next year. No particular reason, it just feels like it is time. Shame that it doesn't look like it will get into 14.04.

Re: About Python 3

#92

Post by steveklabnik »

greenlakejake wrote: post #90
wiremine wrote: post #58

Earlier quoted context omitted.

> Perl 6 is vaporware Perl 6 is not vaporware, you can run it today: http://perl6.org/compilers/features Is it 100% feature complete or fast? No. But there working code and new, stable releases on a monthly basis.

> Is it 100% feature complete or fast? No. If it's not feature complete it's vaporware.

By that definition, basically all software is vaporware.

Re: About Python 3

#93

Post by Ixiaus »

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.

Re: About Python 3

#94

Post by martincho »

What is needed is a very high quality Python 2.x to 3.x migration or conversion tool to make library conversions trivial. If developers knew they could convert any 2.x code to 3.x code with no effort at all and with absolute certainty of proper operation they would probably migrate to the latest 3.x release en-masse.

How difficult would something like this be?

This might be really naive on my part. I haven't really taken the time to study the differences between 2 and 3. I have avoided 3.x out of entirely selfish reasons: I simply don't have the clock cycles to run into roadblocks.

These days languages are only as valuable as the breath and quality of the libraries around them. The issue with 3.x is that it created fear of not having access to small and large libraries developers leverage every day to be able to focus on their problem and not the problem addressed by the library. In that regard it is easy to be inclined to criticize Python leadership for approaching the transition with what might be perceived as a lack of consideration and understanding of the factors that might hinder it.

EDIT:

Just learned about 2to3:

http://docs.python.org/2/library/2to3.html

Not sure how good it is. A quick look at the page gave me the sense that it might be somewhat involved. A true converter would be something that is as easy to use as the the import statement. Something like:

    import2to3 ,
It should not require any more thought than that and it should be 100% reliable.

Re: About Python 3

#95

Post by steveklabnik »

pron wrote: post #75
evmar wrote: post #23

I like to think of engineering as "solving problems within a system of constraints". In the physical world, engineering constraints are things like the amount of load a beam will bear. One of the primary easily-overlooked constraints in the software world is backwards compatibility or migration paths. There are many examples of systems where many look at them today and say: "This is terrible, I could design a better/…

Exactly. This is why something like Java 8 is admirable. They've been able to introduce two major new features from newer "productive" languages – lambdas and traits – without breaking anything; not only that, old libraries will actually enjoy better APIs thanks to the new features without recompilation. Sure, there might be better ways to implement these features, but introducing them in a way that feels natural to…

See also ECMAScript, as much as people like to bash on it.

Re: About Python 3

#96

Post by tbatterii »

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.

> new async framework landing in 3.4 is very exciting

this is the killer feature that would move me to python 3. alas, not released yet. And I took a rails job :(

Re: About Python 3

#97

Post by dragonwriter »

steveklabnik wrote: post #47
ak217 wrote: post #28

Earlier quoted context omitted.

Perl 6 is vaporware. Python 3 is here, it's widely supported, it's faster than Python 2.7, and while Guido didn't do us any favors with his migration strategy, I don't see what the big deal is. Python 3.3 makes writing code that is compatible with both almost trivial. People aren't using Python 3 enough because it's not the default in Debian/Ubuntu. That's about to change with Ubuntu 14.04. I expect that to tip the s…

I have Ruby and Perl tattoos and now work at a Python (2.7) shop, so I have all of the horses in this race, but is there a significant difference between a language that's vaporware[1] and one that nobody uses? The previous things I've seen also indicated that Python 3 _isn't_ widely supported, though I guess Django finally got support recently, and that it _wasn't_ faster than 2.7. Is this just old information on my…

> but is there a significant difference between a language that's vaporware[1] and one that nobody uses?

There's a significant difference between a language for which a complete implementation does not exist such that you cannot use it, and one for which an implementation exists but few people currently choose to use it because there is a closely-related predecessor language that still has a stronger ecosystem.

As an stage in the development of a language out of an existing, widely-used predecessor, the "vaporware" stage tends to precede the "available but not popular due to predecessors ecosystem advantage" stage, which tends to precede the "displaces predecessor" stage.

Its obviously possible for a language to stop progressing at any of the earlier stages before reaching the last stage.

Re: About Python 3

#99

Post by eropple »

wyuenho wrote: post #55
TylerE wrote: post #25

Earlier quoted context omitted.

Scala releases are usually not BINARY backwards compatible. Very different from SOURCE backwards compatible.

Scala also was often not source compatible during 2.7 -> 2.8 because of the huge changes in the standard library.

I'm pretty sure they'll never be doing that again though due to the mess it caused.

Re: About Python 3

#100

Post by dded »

wiremine wrote: post #53

Python 3 is a different language from Python 2. Yes, they are _almost_ the same language, but they are far enough apart to keep people from making the switch. It feels closer to Perl 5 => 6 vs. Ruby 1.x => Ruby 2.x. That's a gross over simplification, but it is closer to the truth than the Python 3 community likes to think. I wonder: have there ever been a successful language rewrite, post critical pass, in the histo…

> have there ever been a successful language rewrite, post critical pass, in the history of computer languages?

Does K&R C to C89 count?

> If so, what lessons can be brought to the current Python 2/3 situation?

C89 programs could use K&R libraries [1], and C89 compilers could compile K&R code.

[1] Well, so could Pascal or Fortran programs for that matter. Where K&R-->C89 fails as an analogy to py2-->py3 may be important aspects of what's so difficult with py2-->py3. (EDIT: added this footnote.)

Post reply on HN