×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Python 3.0 Released

samzenpus posted more than 5 years ago | from the break-out-the-cigars dept.

Programming 357

licorna writes "The 3.0 version of Python (also known as Python3k and Python3000) just got released few hours ago. It's the first ever intentionally backwards-incompatible Python release."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

357 comments

fp (-1, Troll)

Anonymous Coward | more than 5 years ago | (#25987623)

i just released my trouser python.

Re:fp (-1, Troll)

Anonymous Coward | more than 5 years ago | (#25988897)

Please send me your cum. I'm trying to cook dinner [lulu.com] for my friends and I've run short.

Thanks!

Libraries (5, Interesting)

explodymatt (1408163) | more than 5 years ago | (#25987653)

Python 3 being out is great, they've fixed a few things that allow bad programming, but does anyone know how long it will take for the libs to start getting ported? Especially numpy and scipy

Re:Libraries (5, Informative)

Yvanhoe (564877) | more than 5 years ago | (#25987681)

Last time I checked (several months ago) it was not thought that backward compatibility would be broken very hard. Most of the modification to do should be automatic so I think that a lot of packets that are still maintained will quickly be made compatible for python 3

Re:Libraries (5, Insightful)

Alomex (148003) | more than 5 years ago | (#25988293)

Backward compatibility is (i) over-rated and (ii) misunderstood.

It is over-rated in the sense that the number of current users which are inconvenienced is a very small percentage of the total number of users of the language (unless the language is in the tail end of its life, like Fortran and Cobol).

It is misunderstood in that with the use of a simple header or import declaration it is possible to have two different versions co-exist while the transition happens. This is done in HTTP where the first thing that clients exchange is the version of the protocol they'll use. It is also done in LaTeX, where the first declaration informs the compiler which major version is being used (pre-2e or 2e).

Kudos for Python for not being afraid to rock the backwards compatibility boat.

Re:Libraries (2, Funny)

gardyloo (512791) | more than 5 years ago | (#25989129)

unless the language is in the tail end of its life, like Fortran and Cobol

Thus the phrases "The looooooooooong tail" and "You're ALL tail, baby".

Re:Libraries (1)

Bob54321 (911744) | more than 5 years ago | (#25987737)

I don't think these even work with python2.6...

Re:Libraries (0)

Anonymous Coward | more than 5 years ago | (#25987753)

Numpy works just fine, though last time I tried to install SciPy on 2.6 (just after 2.6 was released) I had trouble -- and I don't think all of the tests passed. Seemed to work pretty well otherwise, though.

Re:Libraries (1)

explodymatt (1408163) | more than 5 years ago | (#25987809)

I had a lot of trouble (and didn't succeed) when trying to install numpy on 3.0rc3, any hints on how you went about it would be appreciated.

Re:Libraries (1)

maxume (22995) | more than 5 years ago | (#25987835)

It's mostly Windows compiler issues. The python.org 2.6 binary is compiled with VS 2008 and there are a bunch of changes to make to the libraries that numpy includes to get them to compile with VS 2008.

I'm not clear on the Linux situation, but I believe it at least compiles (whether it works 100% is the issue, and I think it is quite close).

Re:Libraries (1)

morgan_greywolf (835522) | more than 5 years ago | (#25987931)

So why don't they just compile it with mingw?

Re:Libraries (1)

maxume (22995) | more than 5 years ago | (#25988013)

You'd have to ask them.

I think part of it is that the 'recommended' version of gcc in mingw is still version 3.4, which is missing out on 4 years of updates (from a code generation point of view, not a bug fix point of view).

Re:Libraries (1)

Tatsh (893946) | more than 5 years ago | (#25988283)

Agreed. It is very unfortunate GCC in Mingw is still using such old utilities. It generally works for all the code I write but I would like to have 4.x on Mingw (it is possible to have but it does not work well).

Re:Libraries (3, Interesting)

gzipped_tar (1151931) | more than 5 years ago | (#25987789)

IIRC numpy and scipy have dependencies on other libraries that are not 2.6-clean. They also have a lot of issue themselves. Currently it's not a priority for them to migrate.

Can't remember when did I read about that... and I'm too lazy to dig it out from their Trac :-P

Re:Libraries (1)

explodymatt (1408163) | more than 5 years ago | (#25988041)

more information on this would be greatly appreciated, do you have a url for me to start searching and maybe some keywords?

Re:Libraries (4, Informative)

gzipped_tar (1151931) | more than 5 years ago | (#25988167)

I just did a Google search site:scipy.org ("2.6" OR "3.0") -"ipython" -"nipy" and there are a lot of results turning up (and of course lots of bogus ones).

It seemed things are much better that I thought of. Those guys are making progress every day and my news were old news...

The difficulty with numpy/scipy is they need a great amount of C-level coding. There's 2to3 for Python code but tweaking C code is not that easy...

Re:Libraries (0)

Anonymous Coward | more than 5 years ago | (#25989117)

numpy 1.3 trunk builds well with Python 2.6 on OSX and Linux, but there are some issues with Windows left. Scipy 0.7.rc1 is out, but I am not sure what the plan there is. I am unaware of any dependencies that are not Python 2.6 clean.

Re:Libraries (0, Troll)

Anonymous Coward | more than 5 years ago | (#25987831)

Numpy? Scipy? wtfy?

Are we talking about a professional scripting language here, or Snow White with a bloody lip calling to one of her little bitches for help?

Re:Libraries (0)

Anonymous Coward | more than 5 years ago | (#25988825)

The main developer of numpy was an active contributor to the design process of Py3K, if I recall correctly he championed the inclusion of a certain type of C interface for arrays, I always figured that was to facilitate the porting of numpy to Py3K.

good (4, Funny)

Anonymous Coward | more than 5 years ago | (#25987665)

previous releases were incompatibilie with earlier ones unintentinally.

Release notes (4, Informative)

Max Romantschuk (132276) | more than 5 years ago | (#25987671)

The release notes might interest people:
http://docs.python.org/dev/3.0/whatsnew/3.0.html [python.org]

Also note that in the end of the release notes are info on the migration path from Python 2 to 3. I'll leave the rest to people who bother to RTFA... ;)

Re:Release notes (1)

neoform (551705) | more than 5 years ago | (#25988659)

Ohhhhh, python.ORG.. for a second there I thought we were talking about backwards incompatible porn.. whatever that means.

Changes (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25987687)

... no dead parrot sketch?

Almost missed this! (-1, Offtopic)

Adam Jorgensen (1302989) | more than 5 years ago | (#25987691)

Damn SlashDot editors, why so slow on the posting? Anyways, I'm looking forward to playing with this one...

You got time machine! (5, Informative)

gzipped_tar (1151931) | more than 5 years ago | (#25987731)

The cool thing about Python is it's "time machine". In Python 2.x you can "from __future__ import " to use features scheduled for future releases. With the release of Python 2.6 there's also a "2to3" tool that will point out revisions needed for 2.x code to be 3.0-compatible, and generate patches for you.

The Python developers have been aware of the difficult road of migration long before the release of Python 3, and they did a lot of careful planning and hard work for it. One of them being the __future__ module that has been there for quite long time just for this reason.

As a Python user, my hat off for them. I wish them success heartily.

BTW: In case you don't know, there's an Easter egg in the time machine: "from __future__ import braces" ;)

Re:You got time machine! (4, Informative)

makapuf (412290) | more than 5 years ago | (#25987815)

You can also use the python 2.6 "-3" option to have warnings about non future-proof constructs (ie things that can't be handled by 2to3)

in fact there are others python easter eggs :

import this
import __hello__

and ... a new one in 3.0, related to xkcd.

Re:You got time machine! (2, Informative)

Yvanhoe (564877) | more than 5 years ago | (#25987895)

Ironically, the XKCD referring to python is now false : Hello world is not

print "Hello world"

anymore but in 3.0 :

print("Hello world")

But I guess the point is still valid.

Re:You got time machine! (1)

thornomad (1095985) | more than 5 years ago | (#25988831)

So I was just thinking of starting to learn Python (been meaning to pickup a language here) and Google's new app engine thing piqued my interest -- but now that 3.0 is out (app engine is 2.x) what's the best way to go about learning Python without having to re-learn everything as things migrate? Or do I just have to suck it up?

Re:You got time machine! (0)

Anonymous Coward | more than 5 years ago | (#25989019)

It is really not that different. They just fixed some things that turned out to be not so great design decisions like making strings not Unicode except when you used a special Unicode type. Anyway, you will probably end up seeing 2.x code at some point and should be at least somewhat aware of the differences.

Re:You got time machine! (1)

TheLink (130905) | more than 5 years ago | (#25989179)

I think the print in python is a bit of a mess.

I like the sprintf style % part. But I don't like the weird rules- e.g. "A space is written before each object is (converted and) written, unless the output system believes it is positioned at the beginning of a line."

And now they change the syntax of print a lot.

Couldn't they just call it something else and keep the old weird print the way it is and thus not break so much?

For instance I think Perl 6 uses "say".

Re:You got time machine! (1)

SilentGhost (964190) | more than 5 years ago | (#25988111)

import __hello__ doesn't work any more. that's backward-incompatibility for you.
doesn't work the way it used to in python2, that is

Re:You got time machine! (1, Offtopic)

gzipped_tar (1151931) | more than 5 years ago | (#25987853)

Oops. Slashdot ate my sentences.

It's "from __future__ import FEATURE_NAME"

I shouldn't have put it in angle brackets.

Re:You got time machine! (0)

Anonymous Coward | more than 5 years ago | (#25988239)

I always knew that Python wasn't all that efficient, but I never realized that it needed 1.21 jiggawatts!

Re:You got time machine! (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25988253)

Watch out for the "its vs. it's" crowd. They are on to you. :)

Re:You got time machine! (0, Offtopic)

gzipped_tar (1151931) | more than 5 years ago | (#25988405)

Ummm. I should have piped my post to my grammar checker written in Python 3000 before I hit the "Submit" button :-P

And now to wait (2, Interesting)

Anonymous Coward | more than 5 years ago | (#25987745)

Sounds great! Now to wait a few weeks while smart people find and fix all the security holes, so I can go and safely get version 3.1.

It's the first ever intentionally... (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#25987747)

...backwards-incompatible Python release. So far!

Language fragmentation... (-1, Flamebait)

Colin Smith (2679) | more than 5 years ago | (#25987751)

Perl,
tcl
python
python3000
ruby
lua
etc etc add your pet language here

And updating scripts and applications to new, incompatible versions?... It's busy work.
 

Re:Language fragmentation... (0)

Anonymous Coward | more than 5 years ago | (#25988309)

Damned straight! I can't stand all those kids and their silly computer "languages". That's why I write only UNIVAC 1100 machine code. By writing for a dead platform, I know that I will NEVER have to waste time patching my work with updates.

No mac version yet? (2, Funny)

neoform (551705) | more than 5 years ago | (#25987763)

Where's the mac version..?

Re:No mac version yet? (1)

Pope Raymond Lama (57277) | more than 5 years ago | (#25988015)

Just there alogn with all the other versions

You download the .tart.gz or .tar.bz2 source packages and build it. Took less than 15 minutes on my machinne

Re:No mac version yet? (0)

Anonymous Coward | more than 5 years ago | (#25989189)

Mmmmmmm...tart.

Unfair headline there, Bubba (3, Interesting)

Ancient_Hacker (751168) | more than 5 years ago | (#25987767)

Yes, Python 3.0 is a break.

But in the past and forseeable future, Python has been exceedingly helpful, much more than most languages, during upgrades.

Usually one has several months to try out new features-- they're in the current version but turned off until you ask for them with "future_builtins".

Plus there's often a backwards feature in the next version to revert back to old behavior.

Not to mention a -3 option to point out the lines in your old program that will need changing for version 3.

But sometimes the changes are so big they can't be encompassed by a compiler switch. Such it is with 3.0.

 

Re:Unfair headline there, Bubba (2, Interesting)

makapuf (412290) | more than 5 years ago | (#25987885)

But sometimes the changes are so big they can't be encompassed by a compiler switch. Such it is with 3.0.

While I agree with your post, here it's not a problem with implementation but with syntax and backward compatibility within a given python version.
The idea is that some needed changes cannot be made backward-compatible (new keywords, ...). So you group them and call that a new version of the language. I doubt you couldn't implement most of it with compiler switches.

Re:Unfair headline there, Bubba (0)

Anonymous Coward | more than 5 years ago | (#25988099)

No, this is not slashdot sensationalism.
The summary is straight from the release page.

Still waiting.... (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#25987805)

I'm still wating for Perl 6 and Duke Nuke =(

let the flame begins and the troll rolls!

That marks my end of use for Python (-1, Troll)

Anonymous Coward | more than 5 years ago | (#25987847)

Too many changes. I like languages that help me build applications, not add significant amount of work to maintain existing functionality with new language version. Adios, Py - it's been a fun 10 years but now we must part.

Re:That marks my end of use for Python (4, Informative)

neoform (551705) | more than 5 years ago | (#25987893)

I'm fairly certain they got all these non-backward compatibility issues out of the way with this release so they don't have to do this kind of thing again for a long while. My guess is, they wont ever put out a non-backwards compatible release, since those changes were mostly to fix poor coding practices like being able to run certain functions without braces (e.g print "hi").

Re:That marks my end of use for Python (5, Informative)

shutdown -p now (807394) | more than 5 years ago | (#25988145)

It's also cleanup of some stupid syntax that was there for ages. For example, exception handling. Old style:

try:
...
except (TypeError, ValueError): # catch both types of exceptions
...
except os.error, e: # catch exception and store into variable 'e'
...

New style:

try:
...
except (TypeError, ValueError): # catch both types of exceptions
...
except os.error as e: # catch exception and store into variable 'e'
...

It's fairly obvious that the latter is much clearer.

Re:That marks my end of use for Python (4, Funny)

lahvak (69490) | more than 5 years ago | (#25988033)

So what are you going to do, take all your existing Python applications and rewrite them in a different language, in order to avoid the "significant amount of work to maintain existing functionality with new language version"?

Re:That marks my end of use for Python (1)

shutdown -p now (807394) | more than 5 years ago | (#25988349)

I'd suggest rewriting in COBOL. This would make sure that one's precious code is not going to be broken by a new incompatible release.

And if OOP is strongly desired, try Simula-67.

Re:That marks my end of use for Python (2, Insightful)

Pope Raymond Lama (57277) | more than 5 years ago | (#25988059)

Besides teh above remark of well thoguth migration paths - it is importante to remakr that support for python 2.x has not ended in any way.

As far as Iam aware, the recomendation is to keep working with python 2.6 - and use the py2to3 script to regularly to make 3.0 releases if you you can (i.e. if your dependencies have 3.0 versions already).

No need to worry about anything, this will be a smooth, years long, transition. Chances are we will even see a python 2.7 before 2.x is officially deprecated.

Hey! (1)

blackjackshellac (849713) | more than 5 years ago | (#25987887)

Well that's nice, any braces for blocks yet? Just kidding.

BTW, whatever happened to Ruby? It just seemed to have dropped off the map in the past 6 months or so.

Re:Hey! (4, Funny)

drewness (85694) | more than 5 years ago | (#25988039)

As someone mentioned above, try


from __future__ import braces

and see what happens. ;)

As for Ruby, I don't really follow its development or use it, but I was reading just the other day that they're really focused on finishing 1.9, which does byte-compiling and some optimization. The current version (like JS before spidermonkey, V8, and squirrelfish) walks and executes the AST (as I understand it), which is slooow.

Re:Hey! (4, Informative)

Constantine XVI (880691) | more than 5 years ago | (#25988119)

For the lazy (or those who don't have python installed at work):

>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Re:Hey! (0)

Anonymous Coward | more than 5 years ago | (#25988799)

Work? What work?

Oh right ...

Re:Hey! (0, Troll)

metamatic (202216) | more than 5 years ago | (#25988687)

I was wondering if Python 3000 would end the whitespace problem by (say) adding an "end" keyword like Ruby, but apparently not.

Given that Guido von Rossum allegedly said he now viewed the whitespace thing as a big mistake that has crippled Python adoption, it's a pity religion prevented it from being fixed in Py3K.

(So I'll stick with Ruby.)

Re:Hey! (3, Insightful)

caldodge (1152) | more than 5 years ago | (#25989139)

Care to cite a reference for the Rossum's alleged comment? I think "the whitespace problem" is actually one of Python's big advantages, since it greatly enhances program readability.

Is it possible to do automatic code migration? (1)

jopet (538074) | more than 5 years ago | (#25987901)

If the syntax differences and the differences in the standard library are well-documented, shouldn't it be possible to write a program that migrates 2.x code to 3.x code automatically? Does such a program exist?

Re:Is it possible to do automatic code migration? (1)

maxume (22995) | more than 5 years ago | (#25987943)

There is. Search on 2to3 if you want to read about it.

Re:Is it possible to do automatic code migration? (1)

explodymatt (1408163) | more than 5 years ago | (#25987957)

Yes, there are both the 2to3 and the 3to2 (now somewhat redundant) packages. 2to3 will convert (most) python 2 code to python 3, but there are some limits on its abilities. Large libraries tend not to work very well, especially anything involving other languages (ie. c) 3to2 was for developers going the other way, maintaining python 2 compatibility whilst writing 3.0 code.

Re:Is it possible to do automatic code migration? (1)

gzipped_tar (1151931) | more than 5 years ago | (#25987961)

Yes, there's the official tool "2to3" and an interpreter flag "-3" in the 2.6 release.

They work pretty well. However, you can't leave everything to the machine. They can't replace programmers' insights.

Yay, Unicode! (4, Interesting)

shutdown -p now (807394) | more than 5 years ago | (#25988007)

Reworked Unicode support is a big deal. It was there before, of course (unlike Ruby - meh), but all those Unicode strings vs 8-bit strings, and the associated comparison issues, complicated things overmuch. Not to mention the ugly u"" syntax for Unicode string literals which was too eerily like C++ in that respect. Good to see it move to doing things the Right Way by clearly separating strings and byte arrays, and standardizing on Unicode for the former.

Now, if only we could convince Matz that his idea for Unicode support in Ruby 2.0 - where every string is a sequence of bytes with an associated encoding, so every string in the program can have its own encoding (and two arbitrary objects of type "string" may not even be comparable as a result) - is a recipe for disaster, and take hint from Python 3...

Re:Yay, Unicode! (1)

rubycodez (864176) | more than 5 years ago | (#25988781)

since methods exist to examine what the encoding of a string is, and to change it, how would there be a disaster unless the coder was sloppy?

backwards not needed (1)

BountyX (1227176) | more than 5 years ago | (#25988133)

multiple versions of python can live happily together and will be seperatly maintained, no worries about backwards compatibility. sorry for typos ;)

I'll still avoid it (1, Troll)

doti (966971) | more than 5 years ago | (#25988175)

As they didn't fixed the stupid forced-indentation thing.

Re:I'll still avoid it (1)

upside (574799) | more than 5 years ago | (#25988297)

Ah. Yes. That one. Once I got over it I dropped Perl almost completely. Perl was my big love, once.

Re:I'll still avoid it (1)

Kent Recal (714863) | more than 5 years ago | (#25988737)

Same here, and that was almost 2 years ago now.
Any coder worth his salt is already indenting his code the way python likes it anyways, no matter which language he's using, so this part of the transition is normally a non-issue.

Re:I'll still avoid it (1)

stuntpope (19736) | more than 5 years ago | (#25989173)

I dropped Perl for Python as well, and I never had to "get over" the indentation thing. Never understood why the big gripe. Programmers type braces and semicolons all the time without giving it a thought, someone elsewhere in this story asked why not an End statement in Python... yet somehow indenting code in a standard, readable way is noxious to them.

Re:I'll still avoid it (0, Flamebait)

m50d (797211) | more than 5 years ago | (#25988367)

That's OK. We don't want the kind of programmers who let a superficial difference like that put them off actually trying a language.

Re:I'll still avoid it (0)

Anonymous Coward | more than 5 years ago | (#25988459)

It does make it a pain in the ass to play around and test with because often cut-n-paste (from random sources) completely fucks up the indention which you then have to fix. Which is even harder when you don't know the language well.

Between Python's extremely verbose syntax (not very script-friendly-like), syntactically significant indention, and relatively poor performance... well... meh

Re:I'll still avoid it (2, Interesting)

m50d (797211) | more than 5 years ago | (#25988675)

It does make it a pain in the ass to play around and test with because often cut-n-paste (from random sources) completely fucks up the indention which you then have to fix.

Cut-n-paste is not a good way to learn.

Between Python's extremely verbose syntax (not very script-friendly-like)

It's not extremely verbose; take a look at Java if you want that. If you compare with e.g. perl, yes it's longer, but the difference is because it's using words rather than random characters, which in my book is worth it for the ease of remembering wtf to write. Compare it with Ruby or, *struggles to think of another scripting language* TCL, say, and the verbosity is pretty similar.

and relatively poor performance...

Really? It's not going to win races against C, but performance is very much on a par with say Perl (which yes, has a lot of improvements coming in v6, but that's not here yet), and ahead of other similar languages. Couple with the fact that it's easier to bind from python than any of the alternatives, and you end up with code that in practice is as fast as you could write anywhere (because you use e.g. NumPy, which just binds to the fastest libraries available for doing what it does).

Of course python does sacrifice some things - but the ease of code writing and most of all maintainability are well worth it in most cases, in my experience.

Re:I'll still avoid it (1)

totally bogus dude (1040246) | more than 5 years ago | (#25988957)

Have you considered using a decent editor which can fix the indentation for you?

Just a thought.

I actually prefer Perl to Python, but I'll admit that I'm not actually sure why.

Re:I'll still avoid it (0)

Anonymous Coward | more than 5 years ago | (#25988427)

Forcing you to do what you should be doing anyway. Ill avoid working with you.

Re:I'll still avoid it (3, Insightful)

MightyYar (622222) | more than 5 years ago | (#25988705)

As they didn't fixed the stupid forced-indentation thing.

Same reason I don't use C... that stupid forced-curly-brace thing. Why can't the language just know what I want to do?

</sarcasm>

Re:I'll still avoid it (2, Insightful)

horza (87255) | more than 5 years ago | (#25989123)

It's good thing when you get used to it as it makes source code much clearer. If you find that the forced indentation is bulking up your code too much then you are probably missing a trick... in Python there is always a short-cut and you just have to think more Python-like. For example in C/PHP I would type:
x=1; y=2; z=3;
When you first look at Python you are tempted to write:
x=1
y=2
z=3
Quickly you find you can:
x,y,z = 1,2,3

Phillip.

print function (4, Interesting)

togofspookware (464119) | more than 5 years ago | (#25988181)

First thing mentioned on the 'what's new' page (http://docs.python.org/dev/3.0/whatsnew/3.0.html)is that you'll have to change your code from

    print x, y, z,

to

    print(x, y, z, end="")

I can see the value of making things more consistent, but it seems to me whenever they update things in Python, it's usually to make programming in it a little bit harder.

Why not make print a function, but then change the language to not require parentheses for any function call? You'd still have to use them when calling a function with zero arguments, and in sub-expressions, but to not require parens for top-level function calls would, if nothing else, make playing around in interactive mode or with short scripts a lot more pleasant.

Granted, I come from a Ruby background, so I may not know what I'm talking about. My experience with Python is trying to write some scripts on my OLPC, where the craptacular rubber keyboard made typing parentheses all the more agonizing. I finally caved and installed Ruby so I could get some work done. Maybe people who prefer Python really like typing parens. And underscores.

Re:print function (2, Interesting)

gzipped_tar (1151931) | more than 5 years ago | (#25988315)

The IPython (nothing Apple-related) interactive shell hacked the Python lexer to allow exactly this. You type this at the shell prompt:

foo a, b, c

it will be interpreted as a call foo(a, b, c).

IPython still has some bugs with this feature, though. It can be turned out, but I still prefer it in interactive use just as you've mentioned.

Anyway, I think the current Python syntax is OK.

Re:print function (4, Interesting)

maxume (22995) | more than 5 years ago | (#25988375)

I would say that it makes typing python a little bit harder, but I would also argue that it makes programming python easier, not harder (it eliminates print as a statement, but it also eliminates special syntax that existed only for redirecting print output, and makes it trivial to change the default behavior of print within a module (by defining a local print function)).

I don't know why this story's flagged "endofdays" (4, Funny)

Slartibartfast (3395) | more than 5 years ago | (#25988377)

That'll be when Perl 6.0 ships.

Re:I don't know why this story's flagged "endofday (2, Informative)

Anonymous Coward | more than 5 years ago | (#25988507)

AFAIK Perl 6.0 is already there, in the form of Pugs (which is said to be compatible with all the specs), and it's just the implementation of Perl 6 in perl6 itself what people are waiting for. You can go and write actual Perl 6 code, and run it on Pugs, and it'll work.

Not all it's cracked up to be (1)

Gracenotes (1001843) | more than 5 years ago | (#25988457)

  1. >>> import antigravity [python.org]
  2. Automagic xkcd [xkcd.com] in browser!
  3. >>> print "Hello, world!"
  4. File "", line 2
    print "Hello, world!"
    SyntaxError: invalid syntax

  5. :(
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...