Beta

Slashdot: News for Nerds

×

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

CmdrTaco posted more than 3 years ago | from the watch-out-for-teeth dept.

Programming 164

digitalderbs writes "Python 3.2 was released on Feb 20th 2011 with many new improvements. New features include many useful updates to the unittest module, a stable ABI for extensions, pyc repository directories, improvements to the email and ssl modules and many others. This also marks the first release in the 3000-series that is no longer backported to the 2.0-series."

cancel ×

164 comments

great. (0)

Adolf Hitroll (562418) | more than 3 years ago | (#35267312)

so, does that mean that /. editors finally stopped sucking steve jobs' dick?

Re:great. (2)

Ginger Unicorn (952287) | more than 3 years ago | (#35268768)

brings a different context to the the phrase "blow jobs"

woo (-1)

Anonymous Coward | more than 3 years ago | (#35267360)

first post!

Another great Python 3.x series release (4, Insightful)

Anonymous Coward | more than 3 years ago | (#35267374)

That no one will use because there is no compelling reason to port all that cool stuff developed for the 2.x series.

Re:Another great Python 3.x series release (3, Informative)

MetalliQaZ (539913) | more than 3 years ago | (#35267458)

You don't even have to click through to the article...you can find this right in the summary:

"This also marks the first release in the 3000-series that is no longer backported to the 2.0-series."

Python 3.x has grown up and moved out of the house, so to speak. As the language develops, 2.x will be left behind and all your favorite packages will be ported to the new language using one of the excellent automated conversion "helpers" such as 2to3. Twisted, Django, PIL, etc will eventually concentrate on 3.x, and the community will be healthier overall, having been able to shed the stuff that didn't quite make sense with Python.

So stop complaining, sheesh!

-d

Re:Another great Python 3.x series release (4, Insightful)

Anrego (830717) | more than 3 years ago | (#35267630)

This is my biggest complaint with python (I have others, I'll admit I have little love for python). This is not the way to develop a language.

I'll admit I've never developed a programming language, but I have worked on large, long term libraries, and I think the same principle applies. All those stupid design decisions and approaches that are now obsolete and make no sense.. you have to make them still work anyway. You can spew lots of warnings.. but to me breaking backwards compatibility in a _programming language_ is sloppy and completely unacceptable.

So that's why! (0)

Anonymous Coward | more than 3 years ago | (#35267670)

You can spew lots of warnings.. but to me breaking backwards compatibility in a _programming language_ is sloppy and completely unacceptable.

So that's there are so many goddamn programming languages with similar syntax!

Re:So that's why! (1)

Anonymous Coward | more than 3 years ago | (#35267958)

I think you just accidentally a word

Re:Another great Python 3.x series release (5, Insightful)

bjourne (1034822) | more than 3 years ago | (#35267706)

That's exactly what Python did and does, where appropriate. Where it isn't, such as the changed meaning of string literals (they are all unicode now) or the division operator, the breakage is hard. There is no way around that if you want to modernize the language. C# did it too, Java did not. Which is why generics in Java are half-assed and why there are a lot of quirks in the language that traces their roots back to version 1.1 or earlier.

Re:Another great Python 3.x series release (2)

Anrego (830717) | more than 3 years ago | (#35267954)

Java did not

Probably one of the reasons it's so popular in the "serious business"[tm] crowd. I write something in Java, I know it's gonna work in 5 years without me needing to keep some legacy version of the JVM around. Stuff can be gradually migrated over to the replacements for deprecated functionality, without essentially having to fix everything before being able to migrate. See portage and many others for issues associated with the python approach.

Re:Another great Python 3.x series release (1)

Desler (1608317) | more than 3 years ago | (#35267974)

I write something in Java, I know it's gonna work in 5 years without me needing to keep some legacy version of the JVM around.

There are plenty of examples of apps written in Java to break in forth coming versions without any need for the underlying JVM to change. So basically what you claim you don't need to do, many people DO have to do.

Re:Another great Python 3.x series release (0)

Anonymous Coward | more than 3 years ago | (#35268396)

You obviously weren't around when they renamed various libraries and broke everything. Typical newb!

Re:Another great Python 3.x series release (1)

JackieBrown (987087) | more than 3 years ago | (#35268422)

At work, I currently need Jinitiator 1.3.1_02, 1.3.1.28, and 1.3.1.29 in order for all my work related java applications to work properly. I tried just using the new one and most of my apps won't even launch.

Re:Another great Python 3.x series release (1)

GooberToo (74388) | more than 3 years ago | (#35268720)

That's the classic red herring argument.

In five or ten years from now, the python VM of the particular python on which you've built your application is extremely likely to still function and at worst can be compiled. Furthermore, python specifically allows for multiple concurrent python installations. Furthermore, by in large, python is forward compatible between major releases. So the hand waving you're doing is just that...not an issue in the least.

It may surprising many people who think along the same lines as you, but just because python 3.2 has been released doesn't suddenly mean python 2.5, 2.6, or 2.7 has disappeared from the face of the earth. Nor does it mean releases in the 2.x series are suddenly unsupported. Furthermore, python 2.7 specifically exists to creating a VM for migrations. It allows you to play with some of 3.x's features while maintaining 2.x compatibility. This means if staying at or nearly at current python VM development, an easy (or at least a much easier) migration path exists.

Lastly, lets not forget that compatibility is not broken on a daily basis. Which means, if you want compatibility with 2.x you're going to stay on 2.x. If 3.x features are important to you, a minor port is likely. And that completely ignores that automated tools have been created which performs much if not most of the work for you. Plus, once you're o 3.x, chances are extremely high compatibility won't be an issue throughout the 3.x series.

So really, there isn't the least bit validity to you complaint - despite it being a common misconception.

Re:Another great Python 3.x series release (1)

tepples (727027) | more than 3 years ago | (#35269130)

In five or ten years from now, the python VM of the particular python on which you've built your application is extremely likely to still function and at worst can be compiled.

But good luck finding a hosting provider that offers a particular version of Python without having to pay an order of magnitude more to rent your own dedicated server.

Re:Another great Python 3.x series release (1)

GooberToo (74388) | more than 3 years ago | (#35269238)

Yes, $10.00/month is horribly expensive and common and is becoming more and more common every day.

You do realize its trivially easy to find hosting which allows you to install your own languages?

Python does not require root access to install. Not to mention, python's virtualenv [python.org] makes installing, configuring, and carrying your custom python environment and dependencies to other hosts trivial.

Re:Another great Python 3.x series release (1)

maxume (22995) | more than 3 years ago | (#35269280)

Order of magnitude? What's your price point for managed hosting? A cheap VM on something like Slicehost is $20 a month, and the situations where a managed server works and that doesn't are pretty limited.

Nevermind that lots of hosts won't pay much attention if you want to roll your own binaries.

Re:Another great Python 3.x series release (4, Insightful)

luis_a_espinal (1810296) | more than 3 years ago | (#35267768)

This is my biggest complaint with python (I have others, I'll admit I have little love for python). This is not the way to develop a language.

I'll admit I've never developed a programming language, but I have worked on large, long term libraries, and I think the same principle applies. All those stupid design decisions and approaches that are now obsolete and make no sense.. you have to make them still work anyway. You can spew lots of warnings.. but to me breaking backwards compatibility in a _programming language_ is sloppy and completely unacceptable.

Well, you don't have to migrate to Python 3.x. There are a lot of Java 1.2 code out there that will never be migrated, code that sooner or later will not run as intended with new JVMs and JDKs. Code written in COBOL still runs and will never be re-writen (not in our lifetimes).

If it works for you on the 2.x series, most likely it will work fine in years to come. Coming from a Java world, I can tell you I wish the JCP had done the same with many Java crap. Hashtables and vectors should have been deprecated long ago; the '+=' operator in Strings should also have been deprecated; we should have created a damned new collections library so that we could have true generics without type erasure; the JVM should have implemented support for tail recursion; and we should have gotten rid of this one-class-def-per-class-file non-sense.

True, it would have broken a lot of stuff, but only for those that want/need to migrate - many do not. But it would have been a way to get things right and undo a lot of past design wrongs. At some point, it is time to cut backwards compatibility. For those who can't go to the 3.x series, they should simply stay with the 2.x series and work as usual.

Re:Another great Python 3.x series release (1)

Anrego (830717) | more than 3 years ago | (#35267880)

should have gotten rid of this one-class-def-per-class-file non-sense.

I'm actually a fan of this! I do it in my c++ coding as well.

If a class is specialized enough to only really be useful to one class.. it can be defined as part of that class, but I generally avoid that for all but the most trivial stuff (specialized action listeners that need to take parameters being my most common reason for this).

Re:Another great Python 3.x series release (1)

luis_a_espinal (1810296) | more than 3 years ago | (#35269434)

should have gotten rid of this one-class-def-per-class-file non-sense.

I'm actually a fan of this! I do it in my c++ coding as well.

If a class is specialized enough to only really be useful to one class.. it can be defined as part of that class, but I generally avoid that for all but the most trivial stuff (specialized action listeners that need to take parameters being my most common reason for this).

I'm sorry but you don't seem to know what I'm talking about.

I'm not talking about Java source code (where you can have multiple classes defined in one .java file). I'm talking about the output of the compiler, which generates one .class file (bytecode) per class definition, and the JVM inability to operate otherwise. This has serious implications at runtime when it comes to allocating permanent VM memory and can put the brakes on people designing programs with JVM-based functional languages.

Re:Another great Python 3.x series release (1)

Desler (1608317) | more than 3 years ago | (#35267994)

and we should have gotten rid of this one-class-def-per-class-file non-sense.

Why? Doing this is almost always a sign of poor design and is usually equivalent to the god code C/C++ source files that are a major pain in the ass to work with. Sure, sometimes the line can be a bit blurry, but is it really THAT hard to split things into distinct pieces? To not be able to do so reeks of either laziness or someone poorly designing their software.

Re:Another great Python 3.x series release (1)

firewrought (36952) | more than 3 years ago | (#35268886)

and we should have gotten rid of this one-class-def-per-class-file non-sense.

Why? Doing this is almost always a sign of poor design

You may fear that this leads novice developers to a god-class scenario, but my experience was just the opposite: when I moved from Java (which features the one-class-per-file-restriction) to C# (which doesn't), I ended up being more aggressive in describing real world concepts via classes instead of trying to cram little pieces of data or functionality into look-aside collections and flow logic. The overhead of file management, while small, adds a touch of bureaucracy to creating a class. In turn, this make classes seem big and ponderous whereas the real world wants them to be small and lightweight... the mental resistance to creating a new class should not be that much greater than the mental resistance to creating a new method.

Less subjectively, I'd say that there are several places where the one-(public)-class-per-file restriction becomes rather onerous. Example and test code, for instance, benefits from being able to define multiple small classes in the same file without the overhead of file management. Similarly, auto-generated code is best delivered in a single physical unit that is easily segregated and managed separately from one's real code. I think it also makes sense for a group of small, related classes, such as hierarchy of exceptions or token classes in a compiler. Finally, (for the subjective reasons mentioned previously), I think it benefits the scenario where you have to design one large class with a small number of support classes, although it may be a good idea to split these classes across files once their design is stable.

Re:Another great Python 3.x series release (1)

luis_a_espinal (1810296) | more than 3 years ago | (#35269488)

and we should have gotten rid of this one-class-def-per-class-file non-sense.

Why? Doing this is almost always a sign of poor design and is usually equivalent to the god code C/C++ source files that are a major pain in the ass to work with. Sure, sometimes the line can be a bit blurry, but is it really THAT hard to split things into distinct pieces? To not be able to do so reeks of either laziness or someone poorly designing their software.

Jesus Christ, et tu? What the hell is wrong with you people?

I did not say one-class-per-java-source-code-file. I said one-class-per-class-file. Here, I highlighted the part for you.

I'm not talking about Java source code for * sakes. I'm not talking about the number of classes within one single java source file (and btw, you can have multiple classes defined in one .java file). I'm talking about the output of the compiler, which generates one .class file (bytecode) per class definition, and the JVM inability to operate otherwise. This has serious implications at runtime when it comes to allocating permanent VM memory and can put the brakes on people designing programs with JVM-based functional languages. There is a reason why the Dalvik's platform does not have this constrain. Forcing one class definition per compiled bytecode .class file is one thing that we should cut the f* off the JVM independently of whether that is backwards compatible or not.

Not to deviate from the Python-oriented topic of this discussion, but this is a good example of when it is a good time to break backwards compatibility (which is what is being discussed.)

Re:Another great Python 3.x series release (1)

rubycodez (864176) | more than 3 years ago | (#35268234)

Code written in COBOL still runs and will never be re-writen (not in our lifetimes).

not true at all, I've re-architected major COBOL systems (and their ISAM / VSAM databases) several times in my career, to SQL DBMS with J2EE and scripting languages.

Re:Another great Python 3.x series release (1)

luis_a_espinal (1810296) | more than 3 years ago | (#35269544)

Code written in COBOL still runs and will never be re-writen (not in our lifetimes). not true at all, I've re-architected major COBOL systems (and their ISAM / VSAM databases) several times in my career, to SQL DBMS with J2EE and scripting languages.

Reading comprehension dude. I didn't say all existing COBOL code, I simply said Code written in COBOL as in "the general case" or as in "on average" (which is the only way to properly interpret such a sentence.) Yes, you can make a living porting COBOL code to other platforms, yes, it does occur. And yes, it can still occur against the backdrop of the obscenely immense COBOL code base that won't be rewritten anytime soon (if ever.) Your statement - while true - does not contradict the later.

Re:Another great Python 3.x series release (0)

Anonymous Coward | more than 3 years ago | (#35268478)

Well, you don't have to migrate to Python 3.x.

So in other words, hope that you can find a compatible version years down the road that you can give to your clients.

Re:Another great Python 3.x series release (0)

GooberToo (74388) | more than 3 years ago | (#35268966)

So in other words, hope that you can find a compatible version years down the road that you can give to your clients.

Yes, its known as downloading and/or compiling. Dumbass.

If this were commercially driven software you *might* have an inkling of a legitimate point. But since this is community software where the source snapshots, the entire development source tree, and binaries for a variety of platforms, is available to all, such comments are flat out stupid.

Oh no! I might have trouble obtaining what is readily available from any computer with an Internet connection. Oh no!

Shared web hosting (1)

tepples (727027) | more than 3 years ago | (#35269182)

hope that you can find a compatible version years down the road that you can give to your clients.

Yes, its known as downloading and/or compiling. Dumbass.

Unless your clients are trying to use your product on shared hosting, where they don't have the privilege to compile their own software. A dedicated server would cost far more per month.

Re:Shared web hosting (1)

GooberToo (74388) | more than 3 years ago | (#35269308)

If only you had any clue whatsoever about the topic at hand - then you might have a legitimate point. Finding such shared hosts today is trivially easy and is becoming easier every day. And that's presumes one must compile, which is an extremely iffy assumption. Furthermore, installation does not require root privileges.

Re:Another great Python 3.x series release (1)

return 42 (459012) | more than 3 years ago | (#35267816)

Well, it's free software. If enough people don't want to move to Python 3, they can always fork their own project from 2.7. GvR and his followers, however, have decided to focus their efforts on Python 3, leaving the Python 2 cruft behind, and I don't think they're going to change their minds at this point.

Re:Another great Python 3.x series release (0)

Chapter80 (926879) | more than 3 years ago | (#35267910)

I think you are way off on this complaint.

There is NO breaking of backwards compatibility in the Python 2 Language.
And there is NO breaking of backwards compatibility in the Python 3 Language.

If it helps you wrap your pea brain around it, think of it as two separate languages with a lot of similarities: one with a future, built on a lot of learnings, that has been modernized. And one that will run forever as is, unchanged, working like a champ, but with little future development in it.

Re:Another great Python 3.x series release (2)

Anrego (830717) | more than 3 years ago | (#35267992)

That's exactly the approach my little "pea brain" was complaining about. Developing anything in streams forces people to pick one... or in most cases keep both of them around (which is usually a huge pain and involves all manner of hacks.. see using python 3 on gentoo).

And there is NO... (1)

tepples (727027) | more than 3 years ago | (#35269258)

There is NO breaking of backwards compatibility in the Python 2 Language.
And there is NO breaking of backwards compatibility in the Python 3 Language.

And there is NO shared web host offering the Python 3 Language that I could find in a few minutes of Googling (e.g. python 3 shared web hosting).
And there is NO easy way to keep both .py files in the Python 2 Language and .py files in the Python 3 Language associated with respective programs in the Windows Operating System on end users' computers, unlike *n?x which has #!/usr/bin/env python2.7.

Re:Another great Python 3.x series release (1)

maxume (22995) | more than 3 years ago | (#35267922)

If they had named it Bathiola, would you be complaining that the made it too similar to Python?

If Python 3 is a success in 2015 and Python 2 is largely dead, it will provide some amount of evidence that backwards compatibility does not need to be inviolate.

Bathiola (1)

tepples (727027) | more than 3 years ago | (#35269288)

If they had named it Bathiola, would you be complaining that the made it too similar to Python?

No. If Python 3 were called Bathiola, it wouldn't have had the .py extension, and the file manager would successfully choose to run double-clicked .py programs in Python and double-clicked .bath programs in Bathiola. And it'd be easier to separate out web hosts offering Bathiola from web hosts offering only Python (e.g. Google bathiola web hosting in this alternate universe).

Re:Bathiola (1)

maxume (22995) | more than 3 years ago | (#35269702)

The windows file extension thing is a little bit irritating, but I can't say I care that much about it. It is mostly a limitation of Windows that the Python developers chose not to work around (and it is easy to deal with for a few scripts running on one interpreter or the other, just creates shortcuts that explicitly launch the correct interpreter).

As far as the hosting thing, I doubt a new name would help on your search to find a host supporting a new language, outside of PHP, they don't work very hard at keeping stuff current, especially bargain hosts.

Re:Another great Python 3.x series release (2)

Sloppy (14984) | more than 3 years ago | (#35268148)

I feel the pain, but if they had called the language by a new name, wouldn't that nullify the objection? Ruby isn't compatible with Python 2.x libraries either, but no one flames it for that, any more than they blame Python 2 for not being able to run awk scripts. If you can't break compatibility, then nobody can do anything new.

Think of Python3 as a new (though not particularly ground-breaking) language which happens to be very Python2-like, rather than as an update to Python. If you look at it that way, Python 3 is totally forgivable. Is it the right way to look at it? That depends. But it's sure the most useful way to look at the situation, and I think there's something to be said for that causing it to become the correct viewpoint.

Confusingly similar name (1)

tepples (727027) | more than 3 years ago | (#35269324)

if they had called the language by a new name, wouldn't that nullify the objection?

In fact it would; see my reply to maxume [slashdot.org] .

Think of Python3 as a new (though not particularly ground-breaking) language which happens to be very Python2-like

And which has a name confusingly similar to that of Python 2. And which uses the same file name extension as Python 2. And which takes web hosting services that currently offer Python 2 far longer to adopt. Many of the same arguments were tossed around when someone proposed calling the successor to Visual Basic 6 by the name Visual Fred [google.com] .

Re:Confusingly similar name (1)

Korin43 (881732) | more than 3 years ago | (#35269622)

... And which takes web hosting services that currently offer Python 2 far longer to adopt....

Most components of Python-based websites still haven't been ported to Python3. It's not surprising that shared hosting providers don't offer something that doesn't exist.

Re:Another great Python 3.x series release (2)

costas (38724) | more than 3 years ago | (#35268236)

Why not? isn't a programming language a big library of sorts anyway? should you keep supporting every bad design decision for ever and ever?

Python has been extremely conservative about both introducing and deprecating features (the __future__ import is genius). Python 3 had to stay within the rational side of the Perl-6 line, and I believe they pulled it off.

Back-Porting is Half-Baked (1)

Frosty Piss (770223) | more than 3 years ago | (#35268244)

This is my biggest complaint with python (I have others, I'll admit I have little love for python). This is not the way to develop a language.

The problem with endless back-porting is that it stagnates any âoerevolutionaryâ development of the language. There are certain âoemilestonesâ where it makes sense to completely walk away from the old ways of doing something and move on. At a certain point, back-porting makes everything âoehalf-bakedâ.

Re:Another great Python 3.x series release (1)

Gandalf_the_Beardy (894476) | more than 3 years ago | (#35268276)

Imagine if when developing the jet engine, Whittle had to make it backwards compatible with the piston engine. You know - it still needed to use the same fuel, it still only had the same bearings specifications, same exhaust temperatures, couldn't use different lube oil, and so forth... Yes it's a pain but if you want to advance sometimes you have to toss something that has reached the end of it's life and take a large jump forwards. Python 2 will probably go for a lot longer, just like prop-engines do now, but most people have switched to jet for a good reason.

Re:Another great Python 3.x series release (1)

smellotron (1039250) | more than 3 years ago | (#35269620)

Physical manufacturing can't be compared fairly. Every widget created has a cost, which reduces the relative cost of designing a new type of widget (and gets amortized over time). With software, the cost of designing a new type of widget (porting software across OSes or language revisions) is pretty much the entire thing.

Plus, your analogy is off. Comparing jet and piston engines is akin to comparing different programming languages, not different versions of a programming language. The Python folks decided to make their version so incompatible that some people in this thread are arguing that they should be treated as different languages entirely. That's like a piston engine manufacturer upgrading its piston engine production in a way that requires new parts, fuels, etc. and still calling it a piston engine. It's bound to confuse and upset the expectations of some consumers and suppliers.

Re:Another great Python 3.x series release (1)

SpinyNorman (33776) | more than 3 years ago | (#35268392)

So consider Python 2.0 as a legacy language then, and Python 3.0 as a new one.

It'd be nice if all library, language developers had super-human powers of future-prediction, but guess what... they don't. When designing a piece of software, there's only so far you can accurately predict potential future requirements and design to accommodate those. At some point your requirements change beyond the scope of what you were able to anticipate and you've got two choices:

1) Hack the new features in - thereby dooming the software to end-of-life ugliness and eventual replacement by something more suited to the now current requirements, OR

2) Refactor/redesign to reflect the new requirements and as much of the future you can predict from this new position. Maybe you can do this while keeping backwards compatability, and maybe you can't. If you can't keep backwards compatibility while keeping the (refactored, reconsidered) design clean, then you're back at case 1 - a hack.

Re:Another great Python 3.x series release (1)

smellotron (1039250) | more than 3 years ago | (#35269656)

2) Refactor/redesign to reflect the new requirements and as much of the future you can predict from this new position. Maybe you can do this while keeping backwards compatability, and maybe you can't.

If you can't keep backwards compatibility, then you're not actually refactoring. In the context of this discussion, the changes being discussed are most definitely not refactoring. Please don't dilute the term, or it'll have less power when we need to argue it to our managers.

Re:Another great Python 3.x series release (5, Insightful)

dkleinsc (563838) | more than 3 years ago | (#35268822)

Counterargument A: The stupid design decisions and approaches that are now obsolete and make no sense should be forced out of code. Otherwise, the Bad and Wrong version persists a lot longer than it should: some mediocre developer will Google how to solve a Python problem, get something that explains the Bad and Wrong version, puts it into their code, may get a bunch of deprecation warnings, but figures "hey it works, good enough". And if you need an example of how badly out of hand that can get, look at PHP, which still has to support really really stupid things from PHP2 or so because of backwards-compatability, and thus leaving behind a legacy of horrific PHP code.

Counterargument B: Ensuring backwards-compatibility always forever and ever ensures that the language complexity can only grow, never shrink. And thus you grow and grow and grow until eventually the language cannot even be completely defined using BNF or anything similar. Case in point: C++.

Re:Another great Python 3.x series release (1)

arth1 (260657) | more than 3 years ago | (#35267898)

Unfortunately, converting isn't always an option, like with packages that auto-update or write python code, not to mention those that depend on a 1:1 character/string length (i.e. assumes iso-8859-1 or similar).
So the reality is that if you want to use 3.x, you'll quite likely have a system with both 2.x and 3.x, with python defaulting to 2.x

I.e. much the same situation as with java, where you quickly end up with a whole boatload of incompatible virtual machines, one for each app you run.

And this is one of the reasons why I try to avoid both python and java.

Re:Another great Python 3.x series release (1)

Anonymous Coward | more than 3 years ago | (#35268420)

"Whole boatload"? The latest Python 2.x is fully backwards-compatible with all 2.x releases. The same will be true of Python3. Two interpreters (well, four, if your distro ships something older than you need in each category) is hardly a "boatload".

Anyhow, I've been working with Ruby lately, and Python looks like a saint by comparison. I have software that only works with 1.8.6, software that only works with 1.8.7, and software that only works with 1.9 -- and all three of these are within the same major release. ${DEITY} forbid that 2.0 come out...

(Posting AC on account of OpenID authentication going away. *sigh*)

Unnecessary complexity (2, Interesting)

mangu (126918) | more than 3 years ago | (#35268140)

I don't understand how this Py3k praising always gets such good moderation on /.

Python 3 has left the original focus of the language as something simple and easy to use. All the changes are towards a MORE COMPLEX language, I see no change that makes it simpler to use, no change that requires less code than the former version.

Py3k is moving in the direction of Java, where nothing can be done without typing a hundred lines of code. An example from the Python documentation:

17.1.3.1. Replacing /bin/sh shell backquote
output=`mycmd myarg`
==>
output = Popen(["mycmd", "myarg"], stdout=PIPE).communicate()[0]

I cannot see how would anyone call this an "improvement"... Oh, sure, it gives me more options, more control, but if I had wanted to finely tune the innards of the program I would have used C++.

Re:Unnecessary complexity (2)

maxume (22995) | more than 3 years ago | (#35268228)

Removing backtick support actually makes the language simpler.

(I realize that it does make simple shell access more complicated, by requiring that it be done with a library function (but removing syntax still simplifies the language))

Re:Unnecessary complexity (4, Informative)

nneonneo (911150) | more than 3 years ago | (#35268444)

Python never had shell backquotes. The code snippet is highlighting one way that shell backquotes from other languages can be handled. (The "backquote" operator in Python 2.x is equivalent to "repr", e.g. `3+4` yields '7'; it is now gone in Py3K for obvious reasons).

In Python 2.7 and 3.1, there's now a convenience function for capturing program output:

subprocess.check_output('ls -l')

I doubt your claim that Py3K has made things more complicated. If anything, it has made things simpler: less language "burrs" (e.g. / now does float division, eliminating the need to stick float() on one argument or use weird constructs like 1./3), a cleaner standard library ("io" is a great idea), and proper Unicode/8-bit distinction.

Re:Unnecessary complexity (1)

smellotron (1039250) | more than 3 years ago | (#35269906)

If anything, it has made things simpler: less language "burrs" (e.g. / now does float division...)

That particular "burr" I think is something that divides people. While it does make certain generic functions simpler, it's arguably less intuitive for some large user-bases:

  • whole-number math (i.e. kids and certain branches of mathematics): 5/4 == 1 remainder 1, or 1 + 1/4.
  • programmers who have ever used integers before: 5/4 == 1 due to truncation. Also—and this is very important in a culture of abstractions—this is how hardware works.

...eliminating the need to stick float() on one argument...

That was always wrong. IIRC the correct way to get generic floating-point division pre-Python3 is "x * 1.0 / y". It up-converts native integer types without down-converting complex or user-defined numeric types. Still ugly, but workable.

So with Python3, one use-case was made simpler (remainder-free division: x*1.0/y) and the other use-case was made harder (integer division: x//y). It didn't make the language "simpler" as a whole.

Re:Unnecessary complexity (2, Informative)

GooberToo (74388) | more than 3 years ago | (#35269060)

I don't understand how this Py3k praising always gets such good moderation on /.

Well, that's because you just don't understand. Period.

Python 3 has left the original focus of the language as something simple and easy to use. All the changes are towards a MORE COMPLEX language, I see no change that makes it simpler to use, no change that requires less code than the former version.

That's a mouth full but only shows you not only don't understand, but haven't bothered to even look. In what way are things more complex? You mean by adding more language features with easier syntax (example, comprehensions), things are harder? You mean by creating more explicit and less confusing exception handling, things are harder? You mean by adding additional features to support threading concurrently things are harder? You mean by improving threading concurrency, things are harder? You mean by cleaning up, simplifying, and making consistent name spaces and packages, things are harder?

Its pretty clear you're trolling and not made any effort whatsoever to actually learn whats in the 3.x series, let alone the 3.2 release.

Re:Another great Python 3.x series release (2)

maxume (22995) | more than 3 years ago | (#35267474)

The goal of Python 3 was never to have everyone using it in 2012, it was to have a nicer Python language available at some point a little further into the future. For things like the str->unicode conversion, a big break is one of the better ways to transition.

And lots of people are unhappy that things didn't get painted their favorite color, but the process used, where people willing to do the work to make changes were the ones that made changes, was fairly democratic.

Re:Another great Python 3.x series release (0)

Anonymous Coward | more than 3 years ago | (#35267500)

Yep. 2.x is'nt dead! 3.x may improve python, there are still so many apps that has not been ported :/

Re:Another great Python 3.x series release (1)

luis_a_espinal (1810296) | more than 3 years ago | (#35267708)

That no one will use because there is no compelling reason to port all that cool stuff developed for the 2.x series.

Yeah, because everything that needed to be developed has already been done so under the 2.x series. No one will ever need or think to develop something new on the 3.x series. That's why all we have is COBOL because nothing new has ever been needed after all those apps were written with it, oh wait, never mind.

What the fuck are you talking about? (0)

Anonymous Coward | more than 3 years ago | (#35267820)

The only libraries or frameworks that don't support Python 3 yet are those that are dead, and some web frameworks.

Those web frameworks get a lot of hype on the web, but they represent an extremely small segment of the Python-using community. Like most things web-related, they're still far behind the times. Meanwhile, the rest of us have been happily using Python 3 since it was released a few years ago.

Re:What the fuck are you talking about? (0)

Anonymous Coward | more than 3 years ago | (#35268350)

The only libraries or frameworks that don't support Python 3 yet are those that are dead, and some web frameworks.

Those web frameworks get a lot of hype on the web, but they represent an extremely small segment of the Python-using community. Like most things web-related, they're still far behind the times. Meanwhile, the rest of us have been happily using Python 3 since it was released a few years ago.

the numpy,scipy,pylab combo has not been ported to python 3 yet.

Re:What the fuck are you talking about? (3, Informative)

Fnkmaster (89084) | more than 3 years ago | (#35268922)

I extensively use Numpy at work, and that was the primary reason Python 3 was useless to me. However, I should mention that as of Numpy 1.5 release some months ago, Python 3 is now supported. The FAQ page on the Numpy website just hasn't been updated properly.

And Scipy 0.9.0 *does* support Python 3.1. It's currently at release candidate 5, i.e. within a few weeks of an official release. See the release notes [sourceforge.net] from yesterday.

PyLab, I'm not certain about. Matplotlib has an initial port but I think it's not really working yet.

I think now that Numpy and Scipy are running on Python 3.x you'll see a lot more interest in people running it who do real stuff with Python.

Re:Another great Python 3.x series release (2)

jabjoe (1042100) | more than 3 years ago | (#35268426)

EXACTLY. If the Python devs leave 2.x too long and keep saying 3.x only, they will find someone will just fork 2.x and continue it. In free software you only get to make the rules while the community thinks they are good, or it's "fork you!" and the community goes elsewhere.

To me, all the supporting both 2.x and 3.x looks really messy, and why support 3.x if no one else does? Python 3 doesn't seam to be making any progress is taking over and I think it is because it's 2.x with the critical mass. In things as sprawling as languages backward compatibility is really really important. C++ was so successful because it piggy backed on C. Backwards compatibility means why not take it, you start with what you already have.

Re:Another great Python 3.x series release (2)

JackieBrown (987087) | more than 3 years ago | (#35269380)

EXACTLY. If the Python devs leave 2.x too long and keep saying 3.x only, they will find someone will just fork 2.x and continue it. In free software you only get to make the rules while the community thinks they are good, or it's "fork you!" and the community goes elsewhere.

This was the arguement against KDE 4. It took some time, but I am glad that the KDE group went in the direction they did.

Also, if python 2.x is their past, I doubt they care if it gets forked. If it breaks compatibly with the version they finished, then it is self defeating. If it doesn't, then it doesn't affect them other than someone else will be responsible for any bug/security fixes

News for nerds? (5, Funny)

Anonymous Coward | more than 3 years ago | (#35267408)

Come on, guys. How does this help us keep up to date on political events, popular music, or funny videos?

Re:News for nerds? (0)

Anonymous Coward | more than 3 years ago | (#35267478)

Hurrrrr

Re:News for nerds? (2)

kangsterizer (1698322) | more than 3 years ago | (#35267758)

#!/usr/bin/python3
import urllib2

stuff = ['news.google.com', 'grooveshark.com', 'youtube.com/failblog']

for i in stuff:
    print urllib2.urlopen(i).read()

Thats how!

Re:News for nerds? (5, Funny)

blai (1380673) | more than 3 years ago | (#35267830)

print requires brackets now.

Re:News for nerds? (1)

kangsterizer (1698322) | more than 3 years ago | (#35267902)

oh crap lol.

Re:News for nerds? (0)

Anonymous Coward | more than 3 years ago | (#35269564)

And urllib2 is now just urllib, I believe.

Re:News for nerds? (3, Funny)

GooberToo (74388) | more than 3 years ago | (#35269946)

# This works with any python installation rather than only the system installation.
# Using explicit path to system's python install is bad practice. Requiring a source change to run your application with a different VM is silly. Now we need only change our path.
#!/usr/bin/env python3
import urllib

stuff = ['news.google.com', 'grooveshark.com', 'youtube.com/failblog']

for i in stuff:
        print( urllib.urlopen(i).read() )

Is the GIL removed from the interpreter (2, Informative)

JonySuede (1908576) | more than 3 years ago | (#35267456)

Is the GIL [mirocommunity.org] removed from the interpreter ?

Re:Is the GIL removed from the interpreter (1)

maxume (22995) | more than 3 years ago | (#35267490)

No.

Re:Is the GIL removed from the interpreter (0)

lysdexia (897) | more than 3 years ago | (#35267518)

Yes! Python now rides atop an erlang/mach core that, to quote Guido VanRossum "feels like floating on a cloud of titties". It also now has a CickinInABiscuit module that imports a savory cracker right into your interpreter! (Did I mention the interpreter now has sharper ">"'s and is fully compatible with STFU?

Re:Is the GIL removed from the interpreter (0)

Anonymous Coward | more than 3 years ago | (#35268172)

erlang doesn't have problems with global locks. None of that space instead of brackets shit either.

Re:Is the GIL removed from the interpreter (1)

lysdexia (897) | more than 3 years ago | (#35268432)

Sorry, was trying to make a point about apples and oranges, not heap stink on Erlang (a language I found to be just beautiful after a week or so of deep unlearning). :-)

Re:Is the GIL removed from the interpreter (1)

greg1104 (461138) | more than 3 years ago | (#35269684)

It is unfortunate your post has not been moderated upward to where it deserves to be, "+5 titties".

Re:Is the GIL removed from the interpreter (1)

Anonymous Coward | more than 3 years ago | (#35267538)

The GIL isn't, but some of the issues brought up by that talk were fixed somewhere along the 3.x line

Re:Is the GIL removed from the interpreter (0)

JonySuede (1908576) | more than 3 years ago | (#35267562)

ha, at least a nice reply. You are not a butt-hurt loud mouth like one of the above poster.
Thank yuo

Re:Is the GIL removed from the interpreter (1)

lysdexia (897) | more than 3 years ago | (#35268220)

ha, at least a nice reply. You are not a butt-hurt loud mouth like one of the above poster. Thank yuo

Oh, you wanted an answer [python.org] . Honestly, it never crossed my mind that you were doing anything but trolling about a difficult problem [stackless.com] lots of smart folks are dilligently working [codespeak.net] on that have been discussed for years [stackless.com] .

My apologies, I thought this was yet another insouciant probe along the lines of "Oh, is Perl object-orented?" or "Gosh, do people use OpenBSD?". Sorry to prompt that wounded tone from you there.

Oh, and for reference, your (indirect) response requires "neckbeard" or a veiled reference to the autism spectrum to be canon. Just as mine requires a "My fault for feeding the trolls"

Re:Is the GIL removed from the interpreter (0)

Anonymous Coward | more than 3 years ago | (#35268400)

Inkhorn.

Re:Is the GIL removed from the interpreter (1)

JonySuede (1908576) | more than 3 years ago | (#35269492)

, your (indirect) response requires "neckbeard" or a veiled reference to the autism spectrum to be canon

I got both, so no offence taken !

Re:Is the GIL removed from the interpreter (3, Informative)

greg1104 (461138) | more than 3 years ago | (#35268204)

Yes, it would be great if an update to this were covered in the article, like if they put notes on changes to the GIL right here [python.org] or something.

Re:Is the GIL removed from the interpreter (1)

JonySuede (1908576) | more than 3 years ago | (#35269466)

thank you

Re:Is the GIL removed from the interpreter (0)

Anonymous Coward | more than 3 years ago | (#35269820)

So, the answer is "No, they didn't actually do anything useful to the GIL", and the GIL is a big wart in python these days when a cheap laptop comes with 2 processors.

There were a few other bad design decisions in python 3, like the extreme emphasis on generators. Generators! One of the main arguments for generators is that they let you save memory. Sheesh! That's such a 1980s idea. I remember PDP-11s with 64k, and now that I have 4 gig, I need to save memory? That would be OK (but useless) if it had no side effects, but unfortunately generators break the idea of Duck typing. The trouble is that a generator behaves almost like a list, except that it will silently give you a different answer sometimes. For instance:

def foo(x):
        for i in x:
                do_something(i)
        for i in x:
                do_whatever(i)

That function behaves dramatically differently if you pass it a list or a generator, but no exceptions are raised. The whole beauty of Python was the idea of Duck typing, that if you pass the wrong type into a function, sooner or later, python will complain and make your mistake obvious.

Further Improvements to Python... (-1)

Anonymous Coward | more than 3 years ago | (#35267460)

...require switching to Java.

Goodbye, Python 2 (2, Interesting)

ArcRiley (737114) | more than 3 years ago | (#35267572)

I don't know of a major Python library that isn't upgrading to Py3 - and this release marks the tipping point where we wave goodbye to the aging 2.x codebase.

PEP-3003 [python.org] , the moratorium to changes to the language to allow alternative Python implementations to catch up, only applies up to the 3.2 series so we're going to continue moving forward from here. Nobody's forcing Python 2 users to upgrade their code, but there's many advantages and ever decreases hurdles to doing so.

Don't fear change, this change is good and necessary for the advancement of the language.

Re:Goodbye, Python 2 (1)

sourcerror (1718066) | more than 3 years ago | (#35268322)

Panda 3d?

Re:Goodbye, Python 2 (1)

GooberToo (74388) | more than 3 years ago | (#35269384)

I don't know its status, but at best panda is a niche package.

Besides, as things finally reach critical mass with the python 3.x series, as is just now starting to happen, its momentum will naturally pick up other packages along the way. The feature set in the 3.x series is already become very attractive, over that of the 2.x series. Its gravitational pull from new features is only going to build over time.

Re:Goodbye, Python 2 (1)

Permutation Citizen (1306083) | more than 3 years ago | (#35268680)

PIL

Python 3 packages (2)

ArcRiley (737114) | more than 3 years ago | (#35269038)

PIL is working on Python 3; "The current free version is PIL 1.1.7. This release supports Python 1.5.2 and newer, including 2.5 and 2.6. A version for 3.X will be released later" (source [pythonware.com] ). So is Django, Turbogears, wxpython, pygtk, etc. You can vote [python.org] on which major 3rd party packages you'd like to see ported.

PyQT, CherryPy, Genshi, and many others [python.org] are already ported to Python 3.

Re:Goodbye, Python 2 (1)

GooberToo (74388) | more than 3 years ago | (#35269142)

They also recently created a PEP which formalizes gateway interfaces for byte and unicode support which means all of the larger python web frameworks are finally lifting anchor and heading toward 3.x waters.

In the next few years, we'll definitely see a huge uptake in the 3.x series.

Really the question is, how much with pypy be able to absorb from the current cpython 2.x community and when will it take on a 3.x persona.

Re:Goodbye, Python 2 - NOT (3, Insightful)

Animats (122034) | more than 3 years ago | (#35269636)

I don't know of a major Python library that isn't upgrading to Py3 - and this release marks the tipping point where we wave goodbye to the aging 2.x codebase.

Ah, denial. Some major modules that aren't making the transition:

  • BeautifulSoup (HTML/XML parser - replaced by HTML5parser, which is much bigger and slower and has a completely different output tree.)
  • MySQLdb (MySQL database interface. The developer says it's too hard to convert it to Python 3.)
  • M2Crypto (interface to OpenSSL - replaced by new, incompatible SSL module.)
  • SGMLparser (Used by some other modules)
  • FeedParser (Reads RSS feeds. No replacement.)

And those are just ones I happen to have used.

Because the Python community is so tiny, there are major modules that are maintained by only one person. In many cases, they've moved on to other things, and no one is maintaining the modules. The major changes required to move to Python 3.x are non-trivial and aren't being done, because someone would have to take responsibility for a big module they didn't write to do the conversion. In some cases, there are newer, completely different modules with different APIs that perform the old functions. So end users have to do a major rewrite on production programs just to stay in the same place. It's a huge transition. Guido has this smoke-and-mirrors pitch claiming that it's "done". That's because the Python organization, such as it is, disclaims all responsibility for getting modules ported. So it's not his problem that it sucks.

None of the non-CPython implementations are making the transition. Not IronPython (abandoned by Microsoft). Not Shed Skin (only one developer). Not PyPy (defunded by the European Union). Not even Google's own Unladen Swallow [google.com] is moving to Python 2.6, (Google seems to have abandoned Unladen Swallow after discovering that Guido's insistence on excessively dynamic features meant a JIT compiler didn't speed it up much.) The transition to Python 3 has thus killed all other Python projects.

CPython is a naive interpreter, roughly 60x slower than C. It's been stuck at that speed for a decade. And now, that's all we have left.

If you're using Python for anything important, start working on your exit strategy.

Anti-Gravity (2, Funny)

Rik Sweeney (471717) | more than 3 years ago | (#35267582)

Have they added Anti-Gravity [xkcd.com] yet?

Re:Anti-Gravity (3, Informative)

ArcRiley (737114) | more than 3 years ago | (#35267636)

Yep, "import antigravity" is an easter egg. It also contains geohash code, but the core functionality of the module demonstrates how easy Python is;

import webbrowser
webbrowser.open("http://xkcd.com/353/")

Works with every major web browser, no muss, no fuss.

Re:Anti-Gravity (0)

Anonymous Coward | more than 3 years ago | (#35268272)

Waaauunnnggghhh! Say no MORE!

Python? (0)

Anonymous Coward | more than 3 years ago | (#35267628)

Python? People are still using that? Perl is the past, present and future.

Re:Python? (1)

rubycodez (864176) | more than 3 years ago | (#35268260)

hah, Perl 6 is stillborn and it isn't even done being pushed out of Larry's pussy yet.

Re:Python? (2)

Qzukk (229616) | more than 3 years ago | (#35269522)

But... but... I just bought a special unicode keyboard just so I could write code that could never be posted on slashdot!

A stable ABI is a "new feature?" (1)

pclminion (145572) | more than 3 years ago | (#35268844)

How can a stable ABI be described as "new?" Hey guys, it's stable! And it has been stable for 24 hours!

In other news, I quit smoking! I haven't had one since last night right before I went to bed.

Re:A stable ABI is a "new feature?" (1)

maxume (22995) | more than 3 years ago | (#35269100)

Stable across point releases. So C libraries compiled against the stable ABI should work with Python 3.2 or 3.3 or 3.4.

At the moment, libraries need to be compiled for each point release of Python (so 2.4, 2.5, 2.6, 2.7, etc).

Re:A stable ABI is a "new feature?" (0)

Anonymous Coward | more than 3 years ago | (#35269578)

Don't be a pedantic douche. They mention this as a promis to keep it stable. The summary just shortened it.

@cmdrtaco released his 3.2" python (0)

Anonymous Coward | more than 3 years ago | (#35269412)

#smalldick
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>
Create a Slashdot Account

Loading...