THE FORCED BACKWARD INCOMPATIBILITY

Do you see FIOC 3000 ever taking off as the de-facto FIOC standard, or we'll have around 2.x forever? I know that there's code that won't be updated, it's a shame having to maintain the older branch for ages to come. Shame on you, Guido.

It also worries me that not much stuff is getting updated at all, and even now stuff popping out right now is written for 2.x.

Unlikely.

>>1
Much of what was removed/added to 2.x was so obvious that I knew that it was wrong before I even got myself to learn Python properly, just by looking at Python programs.
Guido may be a good VM engineer, but he is verily a shitty language designer.  And a retard.

>>3
Guido may be a good VM engineer
Aren't there several better implementations?

what's the point of 3.0?  OCD?  Harder for beginners?

>>5
Maybe better Unicode supoort, dunno.

>>4
ruby

>>4
Name them

>>8
stackless python, ironpython, etc.

Some people, when confronted with a problem, think, "I know, I'll break backwards compatibility." Now they have two problems.

>>9
No, I mean, not other implementations, but better implementations.

>>11
stackless and iron are better.
unless you think portability and speed are bad things, that is.

>>11
pypy will be, eventually

>>13
Let's be honest, here: unladen-swallow is much more likely to produce something that's actually less shit than cpython. pypy is a pipe dream and everyone knows it.

>>14
Which brings us to our next discussion point; LLVM: awesome or awesome?

>>14
pypy
Pronounced pay-pay

>>15
Ladies Love Virtual Machines

Don't think anyone will migrate to Python9000 any time soon. Especially Linux platforms often have a shitload of Python applications/libraries/dependencies. While some will probably upgrade in time (i.e. next millenium), some won't, so we are stuck with the old applications or have to move to something new... which obviously won't happen, since NEW THINGS TEND TO BREAK SHIT THAT WAS PREVIOUSLY WORKING.

Besides, print() is just fucking gay.

>>1-18
+2 (Pleasured)

>>3
I always thought that Python's strength was its design, not its implementation. By that, you can conclude that Guido sucks at it all.

>>18
Buy why the fuck was it necessary to fork? It's going to be a maintenance nightmare. Was there any actual reason for it? The good way to do it is to have a single implementation, and pass a parameter to activate the new mode. Maybe have also a compile-time parameter to trim down the interpreter if you aren't going to use the legacy mode.

>>20
Python was arguably evolved rather than designed. Which is why the fork is necessary to fix some of the warts.

>>21
Do you mean it's necessary to fork the implementation (CPython) to support both dialects of the language?

I don't think my browser has two separate rendering engines¹. Likewise, my C and C++ supporting compiler doesn't have a large number of frontends.
________________
¹ ^{I do not use Microsoft Internet Explorer 8}

>>22
The two are substantially different in some areas and I don't think having a separate mode would have been feasible(which is not to say I wouldn't have preferred it). I don't see it as nearly as big of a deal as you seem to

>>20
It's not a fork, it's a branch. They already have a maintainance branch for each released version anyway.

2.7 got a lot of the new features, they can be enabled with the import statement. Changes who should to go to all active versions are done to the trunk and then merged (This gets easier with the migration to a DVCS.) There'll often be a few necessary changes, but it's not like it's a complete rewrite, a lot of patches will apply just fine to both.

There's currently no plans to have /usr/bin/python go to python3, so it shouldn't be a problem for a distribution to ship both at the same time.

If you're maintaining an old project, or starting a new one that needs a library that isn't available for python 3 yet, it's perfectly fine to continue to use 2.x.
If you are doing something new without many dependencies, or are using Python in a teaching environment (Hi, Hal!), please consider taking advantage of Python 3.x's cleaner syntax and standard library API, that avoids some surprises caused by unfortunate decisions that came about during the evolution of the Python language.

If you are the author of a Python library that needs to be compatible with 2.x., it is recommended that you keep it in 2.x, but do the necessary changes to get a good conversion with the automatic 2to3 code converter. This should let you to do releases for both versions while keeping a single code base.

Did Python3000 fix the undecidable NP-complete scoping?

>>24
Did you just copypasta this from some Python9000 propaganda sheet?

>>25
Don't talk like that, you sound like a GCC developer.

>>26
We can see your bland and uninspired application of a tired old meme just fine, thank you, you don't have to bold it for us.

>>24
please consider taking advantage of Python 3.x's cleaner syntax and standard library API

I fail to see any change other then turning print 'hello','world',1,2,3 to print('hello '+'world '+str(1)+str(2)+str(3))

>>29
Then you never looked, or you'd have noticed the new abstract base class system, the new IO module, the forced unicodification of strings, making map, range, dict.keys etc. iterators or views, fixing the exception syntax (the old one tripped up just about everyone), / not truncating the result based on type, etc., etc.
You can read more at http://docs.python.org/3.0/whatsnew/3.0.html

(print('hello', 'world', 1, 2, 3), btw. You'd make a much more effective troll if you didn't just go with whatever you heard from reddit.)

>>29
Enjoy!!

This is the Python language designer.
http://img38.imageshack.us/img38/2341/guido.gif

Don't change these.

Name:		Email:
Entire Thread Thread List