Please create an account to participate in the Slashdot moderation system


Forgot your password?
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×
Python Programming Upgrades

Python Family Gets a Triplet Of Updates 196

The Python developers have been busy this weekend, releasing three new versions at different points on the Python continuum: 2.7.4 (a 2.7 series bugfix release), 3.2.4 (what's new), and production releases 3.3.1. Here's what's new in 3.3.1.
This discussion has been archived. No new comments can be posted.

Python Family Gets a Triplet Of Updates

Comments Filter:
  • The Python Launcher (Score:2, Informative)

    by Anonymous Coward

    So, say i want to make myself a python 3 program in the form of an exe file.

    How could i use the "PEP 397: Python Launcher for Windows" in an easy way then?
    i would need to make sure python+ the python launcher were installed as well as my program files.

    or would it be easier to go with the py2exe solution?

    • by Anonymous Coward on Sunday April 07, 2013 @03:30AM (#43383019)

      PEP 397 doesn't do what you think it does. It's a program that gets installed when you install Python. It parses a .py file's shebang line and uses that to determine which installed version of Python gets called. It's not designed to bundle Python programs into standalone executables. For that, you'll want to download something like (which works on Python 3, unlike Py2EXE)

    • by Foresto ( 127767 )

      Here's a list of tools that will help with that []:


  • by PhamNguyen ( 2695929 ) on Sunday April 07, 2013 @02:31AM (#43382931)
    Python needs to support larger dongles.
  • 2.7.4 (Score:5, Interesting)

    by JanneM ( 7445 ) on Sunday April 07, 2013 @02:38AM (#43382943) Homepage

    Happy to see another bugfix release for 2.7. Like it or not, 2.7 is going to remain the main or only version of Python for years to come at many installations. Which means tools that depend on Python at such places also only or mostly support the 2.7 series.

    The developers for the tool I use have just only begun discussing the possibility of perhaps beginning support for Python 3 in addition to the 2.5-2.7 versions for unspecified later versions; but only if it is possible to do without too much code duplication and maintenance efort.

    • Re: (Score:3, Interesting)

      by guacamole ( 24270 )

      The slow speed of Python 3 adoption is surprising. I just started learning python last year, and it seems like some porting effort between Python 2 and 3 may be necessary but the changes between 2 and 3 are pretty small.

      • Re:2.7.4 (Score:4, Informative)

        by mrvan ( 973822 ) on Sunday April 07, 2013 @04:22AM (#43383149)

        I think the current trend in the community is to write a single codebase that support both 2.7 and 3.x. In python 2.x you can "from __future__ import" a lot of the 3.x syntax changes, making it possible to have a shared codebase. For example, this is how django (a major python project) is handling 3.x compatability in its latest version.

        (I guess this could be used as an argument that breaking backwards compatability was not really needed and the transition could have been more gradual, but I don't know enough of the specifics on this case...)

        • On the other hand, some of us supported Python 2.5 pretty much as long as Debian Lenny was supported (until a year ago), and hence __future__ didn't contain the majority of what is needed. Quite a few major projects are only just now moving to requiring 2.6/2.7, and hence only just now making this plausible.

        • by JanneM ( 7445 )

          At least one installation I know about still has only 2.5 and will likely never get updated to anything newer. This is not an uncommon situation, so to the tools I use have to support 2.5 upwards too (2.4 support just disappeared last year). Which means any solution for supporting Python 3 would need to allow for that.

      • The changes may be small but they're significant, potentially breaking a LOT of old code. This was a foolish decision on the part of Guido IMO. Sure, deprecate some features but don't remove them or change the syntax so old code won't run! Even Larry Wall understood that much and you'd never accuse Perl of being a well designed language.

        • by lattyware ( 934246 ) <> on Sunday April 07, 2013 @06:18AM (#43383369) Homepage Journal
          That's how you end up being PHP. Python 3 fixes core mistakes made in earlier versions of the language, and makes it harder to write bad code. That's a good thing, and the last thing you want is a language full of 20 ways to do something, 18 of which are deprecated. Removing backwards compatibility for the 3.x line was a good idea.
          • by jgrahn ( 181062 )

            That's how you end up being PHP. Python 3 fixes core mistakes made in earlier versions of the language, and makes it harder to write bad code.

            I now nothing about PHP, but almost *all* languages try to stay backwards-compatible, because their designers know how surprisingly hard it is in practice to migrate everyone.

            • That doesn't make it a good idea. Go and look at PHP, and you'll see why. PHP is a horrific mess of deprecated stuff, and it's insanely hard to find the right way to do something in the cruft of hacked in features and old ways of doing things. As with all things, we make mistakes when we design languages. Sometimes, we can fix those without breaking backwards compatibility, sometimes we can't. It's worth making the break to make the language better - it's just not wise to do it more than very rarely.
          • by olau ( 314197 )

            I disagree. Python 3 uptake has been really slow. The result is that a lot of the good stuff in the Python 3.x series isn't in wide-spread use yet, and if you're writing reusable library code, you can't really assume the majority of your users will have access to it yet.

            Guido should have said: we'll break these things we have to break, and for the rest add shim layers with deprecation warnings instead of just opening the gates. That would probably have seen much faster adoption rates.

            The gradual approach ha

      • Re: (Score:2, Interesting)

        by abe ferlman ( 205607 )

        Wake me up when they bring 2.x style print back. Taking away convenience features is not the way to encourage adoption, if anything they should add more.

        • by gd2shoe ( 747932 )


          I can understand taking away statements in favor of built-in functions, but that was just too darned handy to yank out from beneath us.

          (Now making parenthesis optional on some function calls might be cool... if it doesn't cause Python to become as unreadable/ambiguous as Perl! Great care would need to be taken, and I doubt they'd ever consider it.)

          • by spitzak ( 4019 )

            It seems to me that a simple handling of a space after the first word is all that is needed. The following statement:

            a b

            is treated exactly the same as


            Then old print would be supported since it would turn into the new print() function. It would also let "help foo" work, which is something I keep typing wrong for some reason.

            I'm sure there is some odd interactions with the parsing of some obscure syntax that need to be figured out, but since all the obvious tests I can

            • by gd2shoe ( 747932 )

              That's exactly what I was driving at. It's simple. It's clear, and it's far easier to type.

              The problem is avoiding garbage like this:
              dir asdf qwer, wert poiu, gfds bvcx

              Do you parse this as:
              dir( asdf(qwer) ), wert(poiu), gfds(bvcx)

              Or as:
              dir(asdf( qwer, wert( poiu,gfds(bvcx) ) ))

              It's not immediately obvious or clear. Thus, great care would need to be taken in designing the change. First word only (first alnum token) would avoid problems like this, but wouldn't be real elegant.

      • by spitzak ( 4019 )

        A killer with Python 3 is the stupid handling of strings.

        A string should be a sequence of byte values. If they *happen* to be UTF-8 then it "is unicode" but I should not be prevented from using my string just because it does not match a complex pattern called "valid UTF-8". Nobody in the history of computer science would ever have made a scheme where the simple act of *looking* at data that has been sucessfully read from an outside source can throw an exception, but for some reason Unicode and UTF-8 turns o

        • by JanneM ( 7445 )

          So, out of curiosity, how do you handle strings in other encodings, such as Shift-JS or EUC-JP?

          • by spitzak ( 4019 )

            You need to know that strings in other encodings are in those encodings, however allowing the string to contain an arbitrary sequence of bytes, rather than limiting it to valid UTF-8, will allow you to defer the decision about handling the alternative encoding until usage of the string, rather than having to do it during storage and copying. This is usually a lot easier and failures are more predictable and understandable.

            It is also extremely easy to distinguish UTF-8 from another encoding, because a huge m

        • If you want to work with byte arrays, then use byte arrays. Python API gives you that ability.

          Strings are more than byte arrays. By definition, they are meaningful sequences of human characters, not bytes, and they provide operations that are only sensible on such sequences (like, say, length in characters). If you're using them to store random data which may or may not be a valid string, you're doing it wrong. It's like complaining that you can't store random bit patterns in a double - well duh, that's not

          • by spitzak ( 4019 )

            Yes, you can use byte arrays everywhere in every api. But that kind of defeats the purpose of Python strings, since you are no longer using them!

            And a 1000-byte UTF-8 string with a single error in is 99.9% UTF-8 characters. In fact I may not be able to figure out it is this magical "not UTF-8" without a very expensive scan! That is incredibly stupid.

            You know your precious UTF-16 can have errors, too? Did you notice that nothing throws exceptions on them? Think hard about why this is, rather than spouting id

    • by fnj ( 64210 )

      Happy to see another bugfix release for 2.7. Like it or not, 2.7 is going to remain the main or only version of Python for years to come at many installations.

      Python 2.7! Python 2.7? Users of all those RHEL 6 installations out there only WISH. They have Python 2.6, and they were damn glad to get that, too, since they were saddled with 2.4 for all those dreary RHEL 5 years.

  • by Urkki ( 668283 )

    A very important feature of any language still seems to be missing: a sane reference documentation.

    In a duck-typed language this is even more important, because compiler/IDE can't really help programmer there. Below is a sample from core library docs, links included. To fully appreciate this, there's no link to this "read()" method, and whole BytesIO class documentation does not contain such method, so you're going be manually searching the page to find documentation for read(). Fortunately it is on the sam

    • The documentation is great in general, you seem to have found one missing link in a relatively obscure class. As a whole, Python's docs are great. They generally explain well and give full examples.
      • Re: (Score:2, Insightful)

        by Urkki ( 668283 )

        The documentation is great in general, you seem to have found one missing link in a relatively obscure class. As a whole, Python's docs are great. They generally explain well and give full examples.

        Just compare (not, these are not exactly same thing, just pretty close):

        Of these, Python's is least clear and useful in my eyes, by quite a margin. YMMV.

  • I guess I am firmly in the realm of knowing enough to get myself into trouble. I use Mac OS X 10.7 and have Macports installed. I just installed python 2.7.4 to stay current. When I start up python, it was still v2.7.1. Trying to figure out why, it seems that python is installed in too many places!

    The original Apple installs are in /System/Library/Frameworks/Python and include versions 2.3 , 2.5.6, 2.6.7 and 2.7.1.
    The python foundation installs into /Library/Frameworks/Python. Furthermore, macports has take

I don't want to be young again, I just don't want to get any older.