Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Python 3.0 Released 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."
This discussion has been archived. No new comments can be posted.

Python 3.0 Released

Comments Filter:
  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Thursday December 04, 2008 @08:02AM (#25987639)
    Comment removed based on user account deletion
  • Libraries (Score:5, Interesting)

    by explodymatt ( 1408163 ) on Thursday December 04, 2008 @08:03AM (#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 (Score:5, Informative)

      by Yvanhoe ( 564877 ) on Thursday December 04, 2008 @08:06AM (#25987681) Journal
      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 (Score:5, Insightful)

        by Alomex ( 148003 ) on Thursday December 04, 2008 @09:16AM (#25988293) Homepage

        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: (Score:3, Funny)

          by gardyloo ( 512791 )

          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".

        • Yeah, exactly like IPV6.

          wait....

        • Re:Libraries (Score:5, Informative)

          by Rostin ( 691447 ) on Thursday December 04, 2008 @11:13AM (#25989807)

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

          Fortran will continue to thrive for many years. I don't know numbers, but based on my personal experience, it's the preferred language of most computational scientists and engineers. The most recent revision occured in 2003. According to this [acm.org], a new one is being worked on.

          • Re:Libraries (Score:5, Insightful)

            by Alomex ( 148003 ) on Thursday December 04, 2008 @11:32AM (#25990097) Homepage

            Fortran will continue to thrive for many years.

            I agree. The point is that the number of current users is a non-negligible percentage of the universe of future users. It is in that sense that it is "near the tail end".

            For languages which are very early in their life cycle, such as Python, the number of users inconvenienced today are negligible compared to the total number of users that it will have and benefit from the changes.

          • Re: (Score:3, Interesting)

            by steveha ( 103154 )

            I wonder if Fortran may eventually be replaced by Python.

            A few years ago, when I was first getting into Python, I read an article where a guy from a science research lab talked about his lab's transition from Fortran to Python. Python has some nifty heavy-duty math modules, written in C; and everyone at the lab who tried out the Python stuff strongly preferred it to Fortran.

            Since C code is doing all the heavy lifting, it's nice and fast. Since Python is interactive, scientists can use it as a really-power

            • Re:Libraries (Score:4, Informative)

              by 644bd346996 ( 1012333 ) on Thursday December 04, 2008 @02:34PM (#25993085)

              Python can't replace Fortran, but C can (and to a large extent, is). For most serious scientific computation, the initial software is written in a language like MATLAB or Python, which make use of number crunching libraries written in C or Fortran. When that code needs to be modified to run on a supercomputer instead of a workstation, it is usually converted to pure C or Fortran.

              Interpreted and interactive languages like MATLAB and Python make it easy to prototype and test a new algorithm, but C and Fortran are still necessary to make an efficient implementation.

              (Disclosure: I am a mathematician, currently using all the above languages for ongoing research, though I am studiously avoiding having to write any Fortran myself.)

            • Re:Libraries (Score:5, Insightful)

              by Vornzog ( 409419 ) on Thursday December 04, 2008 @02:40PM (#25993173)

              I wonder if Fortran may eventually be replaced by Python.

              Already has been, in my world. I know plenty of people around the chem department who still use Fortran because 'it is the language of scientific computing, dammit!'

              Here is the thing. Most of the time, they were so panicked about how long the program would take to run, they lost sight of how long it took them to write it.

              I replaced many Fortran programs with Python in my time, because I could write the data IO so much faster, and then just use the C-level numerical libraries to do the analysis. The program would end up running just as fast, and the code could be written in an hour instead of a week.

              Some people will die before they change languages. The rest of us just want our results. Hopefully, the switch to py3k goes easy and the community continues to grow.

    • I don't think these even work with python2.6...
    • Re:Libraries (Score:4, Interesting)

      by gzipped_tar ( 1151931 ) on Thursday December 04, 2008 @08:21AM (#25987789) Journal

      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

    • I heard they're going to use Python 3.0 for the impending from-scratch rewrite of DNF.

    • Re: (Score:3, Insightful)

      by gfxguy ( 98788 )

      Python 3 being out is great, they've fixed a few things that allow bad programming

      Really? So if I write code in Python 3, it's guaranteed to be "good" programming?

      Honestly, I didn't look at the article... have they actually made things MORE rigid?

      I use python... I like python... but I can't help but think it was designed by someone who was pissed off that people didn't format their code the way he formatted his code. Since his way was obviously the "right" way, why not write a language that forces you to

      • Re: (Score:3, Interesting)

        by blincoln ( 592401 )

        I can't help but think it was designed by someone who was pissed off that people didn't format their code the way he formatted his code. Since his way was obviously the "right" way, why not write a language that forces you to do it that way? Problem solved!

        This is actually the main reason I haven't worked with Python beyond tweaking a few existing scripts. The funny thing is that (unless I'm misremembering the syntax) I already code using that style in other languages. But the idea of forcing that style on

        • Re:Libraries (Score:5, Insightful)

          by Anonymous Coward on Thursday December 04, 2008 @01:54PM (#25992479)

          I can't help but think it was designed by someone who was pissed off that people didn't format their code the way he formatted his code. Since his way was obviously the "right" way, why not write a language that forces you to do it that way? Problem solved!

          This is actually the main reason I haven't worked with Python beyond tweaking a few existing scripts. The funny thing is that (unless I'm misremembering the syntax) I already code using that style in other languages. But the idea of forcing that style on everyone annoys me enough to put me off of the language as a whole.

          I was really hoping that 3.0 would remove that petty stupidity. Doing so would even retain backwards compatibility with prior versions!

          I just don't get it when people say that, its sorta like saying you don't use language X because you have to store numbers as floats or integers instead of char variables.

          I honestly like the fact that Python forces a coding format, I hate opening someone else's source and spending the first minutes trying to understand how they layout things if at all. And yes if people were smart it would be easy to pickup anyones code, sadly that world doesn't exist.

          No its not petty stupidity, not using Python because of your reasons is sadly what I would call petty stupidity.

        • Re:Libraries (Score:5, Informative)

          by bnenning ( 58349 ) on Thursday December 04, 2008 @02:05PM (#25992665)

          But the idea of forcing that style on everyone annoys me enough to put me off of the language as a whole.

          I had that exact reaction when I first came across Python. But after giving it a chance (many years later), I realized that it doesn't force a style any more than C forces the "style" of putting braces around blocks. Indentation levels are just syntax elements that happen to correspond to what most developers naturally do. Really, having to indicate blocks to the compiler in one way and to humans in another way is a DRY violation, which Python eliminates.

  • good (Score:4, Funny)

    by Anonymous Coward on Thursday December 04, 2008 @08:04AM (#25987665)

    previous releases were incompatibilie with earlier ones unintentinally.

  • Release notes (Score:4, Informative)

    by Max Romantschuk ( 132276 ) <max@romantschuk.fi> on Thursday December 04, 2008 @08:05AM (#25987671) Homepage

    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... ;)

    • by neoform ( 551705 )

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

  • by gzipped_tar ( 1151931 ) on Thursday December 04, 2008 @08:13AM (#25987731) Journal

    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" ;)

    • by makapuf ( 412290 ) on Thursday December 04, 2008 @08:23AM (#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: (Score:3, Informative)

        by Yvanhoe ( 564877 )
        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.
        • by TheLink ( 130905 )
          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: (Score:2, Offtopic)

      Oops. Slashdot ate my sentences.

      It's "from __future__ import FEATURE_NAME"

      I shouldn't have put it in angle brackets.

  • And now to wait (Score:2, Interesting)

    by Anonymous Coward

    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.

  • by neoform ( 551705 ) <djneoform@gmail.com> on Thursday December 04, 2008 @08:18AM (#25987763) Homepage

    Where's the mac version..?

    • 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: (Score:3, Funny)

        by hawk ( 1151 )

        >You download the .tart.gz or .tar.bz2 source packages and build it. \

        At last, what the world has been waiting for: a language for bimbos and airheads! :)

        hawk

  • by Ancient_Hacker ( 751168 ) on Thursday December 04, 2008 @08:18AM (#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: (Score:3, Interesting)

      by makapuf ( 412290 )

      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.

  • 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?

  • by slumberheart ( 1423685 ) on Thursday December 04, 2008 @08:39AM (#25987947)
    SyntaxError: maybe in 3.5
  • Yay, Unicode! (Score:5, Interesting)

    by shutdown -p now ( 807394 ) on Thursday December 04, 2008 @08:44AM (#25988007) Journal

    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...

    • 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?

      • Re: (Score:3, Interesting)

        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?

        Assume a simple case: a function taking two strings as arguments. In Ruby 2.0, you cannot safely concatenate those two strings, or even compare them (because encodings may be incompatible). You cannot properly interpret it, because the set of possible encodings is not closed (the client may pass you a string with an encoding he defined himself). You cannot convert it t

  • multiple versions of python can live happily together and will be seperatly maintained, no worries about backwards compatibility. sorry for typos ;)
  • print function (Score:4, Interesting)

    by togofspookware ( 464119 ) on Thursday December 04, 2008 @09:03AM (#25988181) Homepage

    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: (Score:3, Interesting)

      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 (Score:4, Interesting)

      by maxume ( 22995 ) on Thursday December 04, 2008 @09:23AM (#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)).

    • Re: (Score:3, Funny)

      by moranar ( 632206 )

      You seem to want Perl. You can find it at http://www.perl.org/ [perl.org]

    • Re: (Score:3, Insightful)

      Why not make print a function, but then change the language to not require parentheses for any function call?

      A good argument is that it would make the grammar ambiguous.

      What's the parse tree of "f x, g y"? I think it can be both (tuple (f x) (g y)) and (f x (g y)).

      One could of course detect and disallow ambiguous strings, at the expense of the parser having to do a little more work. It may be a little, or it may be a lot. ...

  • That'll be when Perl 6.0 ships.

    • Re: (Score:2, Informative)

      by Anonymous Coward
      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.
    • Which will also be the point of singularity
    • by Abreu ( 173023 ) on Thursday December 04, 2008 @11:27AM (#25990027)

      Signs of the apocalypse:

      * A black man was elected President of the US - November 4, 2008
      * Chinese Democracy was released - November 23, 2008
      * Python 3000 is released - December 4, 2008
      * ?
      * ?
      * Large Hadron Collider starts operations - ?
      * Duke Nukem Forever is released - ?

Dennis Ritchie is twice as bright as Steve Jobs, and only half wrong. -- Jim Gettys

Working...