×

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 2.6 to Smooth the Way for 3.0, Coming Next Month

ScuttleMonkey posted more than 5 years ago | from the my-tab-key-still-hates-you dept.

Programming 184

darthcamaro writes "Some programming languages just move on to major version numbers, leaving older legacy versions (and users) behind, but that's not the plan for Python. Python 2.6 has the key goal of trying to ensure compatibility between Python 2.x and Python 3.0, which is due out in a month's time. From the article: 'Once you have your code running on 2.6, you can start getting ready for 3.0 in a number of ways,' Guido Van Rossum said. 'In particular, you can turn on "Py3k warnings," which will warn you about obsolete usage patterns for which alternatives already exist in 2.6. You can then change your code to use the modern alternative, and this will make you more ready for 3.0.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

184 comments

frosty (-1, Troll)

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

piss? goat.

The Case Against Barack Hussein Obama (-1, Troll)

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

Obama will castrate our military and destroy our nuclear deterrent.
http://www.youtube.com/watch?v=cxL8NcNACBY [youtube.com]

He will tax corporations and high income earners that employ the population of the US, which will force them to cut jobs and send the unemployment rate skyrocketing.
http://obama.3cdn.net/b7be3b7cd08e587dca_v852mv8ja.pdf [3cdn.net]

He sees dead people.
http://www.youtube.com/watch?v=galtZF0nKYc [youtube.com]

He wants to take the guns out of the hands of law abiding citizens, leaving us at the mercy of criminals.
http://www.ontheissues.org/2008/barack_obama_gun_control.htm [ontheissues.org]

He'll cut and run from Iraq, knocking the legs out from under the Iraqi government as they are finally finding their footing.
http://www.barackobama.com/issues/iraq/ [barackobama.com]

He believes homosexuals are entitled to more rights than straight people.
http://www.cnn.com/2007/POLITICS/07/23/debate.transcript/index.html [cnn.com]

He believes in mob rule concerning criminal punishment.
The Audacity of Hope, by Barack Obama, p. 58

He refuses to call terrorists "terrorists" even when presented with evidence.
http://www.npr.org/templates/story/story.php?storyId=15251928 [npr.org]

He will prevent us from keeping sensitive materials confidential, which will place national security at risk.
http://www.cfr.org/publication/14356/ [cfr.org]

He would talk with terrorist countries without demanding that they cease their efforts to murder innocent people and abide by the rule of law.
http://www.youtube.com/watch?v=e3Oj7Jn9rv4 [youtube.com]

He believes we should reward people who ignore the existence of a country's sovereignty and illegally enter the country instead of forcing them to abide by the law.
http://obama.senate.gov/news/060923-sen_obama_at_to/index.php [senate.gov]

He believes the government should regulate the internet.
http://obama.senate.gov/podcast/060608-network_neutral/index.php [senate.gov]

He believes in making those who have money pay for the healthcare of those who do not have money.
http://www.barackobama.com/issues/healthcare/ [barackobama.com]

He believes we should take corn, a staple food for the US, and use it for ethanol production, which will cause shortages in food supply and produce car exhaust that is more dangerous to humans than gasoline burning cars.
http://www.boston.com/news/nation/washington/articles/2007/01/05/new_us_congress_looks_to_boost_alternate_fuels/?p1=MEWell_Pos5 [boston.com]

He believes that parents should have no choice but to send their children to government run schools to be indoctrinated by sub-standard teachers.
http://www-news.uchicago.edu/citations/04/041027.obama-ct.html [uchicago.edu]

In short, he's an anti-American, anti-military Marxist who will destroy the US before he can be voted out of office. I don't like McCain and I have problems with many of his positions, but he will, at the very least, keep the US from crashing and burning within the next 4 years (provided the Dems don't win Congress).

And no, he's not a Muslim (as far as we know). He's not black (he's bi-racial). He's not a Christian (against everything Christians believe in). He's not a foreign-born Manchurian candidate (born in Hawaii and he's telling everyone how he'll kill the country).

Terrorists regimes around the world have said that they want Obama to be president. Would you take advice from people who want to kill you and elect the person they want elected?

Re:The Case Against Barack Hussein Obama (-1, Offtopic)

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

(against everything Christians believe in)

Not everything. He does believe in socialism, just like Jesus.

Re:The Case Against Barack Hussein Obama (-1, Offtopic)

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

Not everything. He does believe in socialism, just like Richard Marx Stalin (RMS)

Re:The Case Against Barack Hussein Obama (0, Offtopic)

vtcodger (957785) | more than 5 years ago | (#25252057)

*** Obama will castrate our military and destroy our nuclear deterrent. ... etc,etc,etc for thousands of tiresome words. ***

Sounds good to me. I reckon I'll vote for him.

Re:The Case Against Barack Hussein Obama (-1, Offtopic)

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

(provided the Dems don't win Congress)

For what it's worth, the Dems have already won Congress.

Point-by-point refutation of connotative bias to come when I feel like it.

Guess what, cone. I feel like it already. (-1, Offtopic)

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

> Obama will castrate our military and destroy our nuclear deterrent.
I don't mind. As far as spending and numbers are concerned, we already outnumber the rest of the world. And anyone crazy enough to use nukes is crazy enough to not care about US deterrent.

> He will tax corporations and high income earners that employ the population of the US, which will force them to cut jobs and send the unemployment rate skyrocketing.
Several prominent economists disagree with this assessment. And even if it's true, New-Deal style job creation is in the pipe too.

> He sees dead people.
Who the fuck cares.

> He wants to take the guns out of the hands of law abiding citizens, leaving us at the mercy of criminals.
If you read the linked article, you'd know this is a misrepresentation.

> He'll cut and run from Iraq, knocking the legs out from under the Iraqi government as they are finally finding their footing.
Likewise an oversimplification. The 16 months are tied to a timetable of phasing in Iraqi control of Iraq. This is no more cutting and running than a road trip is reckless driving.

> He believes homosexuals are entitled to more rights than straight people.
This claim is not supported by the transcript.

> He refuses to call terrorists "terrorists" even when presented with evidence.
No, he refuses to call a losing battle a winning battle, even if doing so keeps certain terrorists from being classified as such. The bill in question covered an omnibus of opinions, and disagreeing with one does not mean he disagreed with the whole bill.

> He will prevent us from keeping sensitive materials confidential, which will place national security at risk.
The stated plan is to go through classified materials and determine what can be declassified without threatening national security; the hypothesis is that there are many such documents kept classified for political reasons. If all of those materials really do need classified status, the department will do nothing. I fail to see the issue here.

> He would talk with terrorist countries without demanding that they cease their efforts to murder innocent people and abide by the rule of law.
Why would a country that is convinced you are the enemy do anything you tell it to do? Why would a country with whom you will not communicate listen to your demands?

> He believes the government should regulate the internet.
The government is already giving the people who run the internet an exception from antitrust law, on the basis of the "natural monopoly" created by the wires. In fact, the government helped pay for those wires. Shouldn't it have a say in how those wires are used?

> He believes in making those who have money pay for the healthcare of those who do not have money.
The alternative is for those with no money to have no healthcare either. Most of the country considers that unacceptable.

> He believes we should take corn, a staple food for the US, and use it for ethanol production, which will cause shortages in food supply and produce car exhaust that is more dangerous to humans than gasoline burning cars.
He believes we should use corn ethanol as one of many replacements for oil. Corn production has already skyrocketed on speculation for this alternative fuel. Meanwhile, your comments on the dangerous nature of ethanol exhaust are supported neither by the article nor a cursory Google search on the matter.

> He believes that parents should have no choice but to send their children to government run schools to be indoctrinated by sub-standard teachers.
How do you know? The linked article only mentions that he happens to send his kids to a private school where he gets a discount. Not supporting vouchers does not mean wanting to destroy private schools. They seem to be getting by well enough without government hand-outs.

> In short, he's an anti-American,
What the fuck does that mean.
> anti-military
And why not?
> Marxist
Not even close.
> who will destroy the US before he can be voted out of office.
Assuming that Congress rolls over to every fucking thing he suggests, and assuming he was lying about bipartisanship and dialogue as being fundamentally necessary for democracy to work.

> Terrorists regimes around the world have said that they want Obama to be president. Would you take advice from people who want to kill you and elect the person they want elected?
The devil said Goody Proctor was working for him. Why should we believe the devil? Why should we believe the terrorists? If they really wanted Obama to win, would they be spilling their guts about it so everyone in earshot could hear?

I'm done with this. I don't care if you're a troll. This kind of nonsense shouldn't be sitting around waiting to convince those too lazy to investigate.

GOOD NIGHT.

More ready? (0, Offtopic)

RichiH (749257) | more than 5 years ago | (#25251907)

English is not my first language, but isn't "more ready" wrong?

Re:More ready? (0)

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

It's not eloquent but I don't think its wrong.

Re:More ready? (1)

cpicon92 (1157705) | more than 5 years ago | (#25251967)

Technically the correct term would be readier, but that sounds a little awkward to some people. Generally the rule is: One Syllable=[adjective]er More than one Syllable=more [adjective] Unfortunately very few people tend to adhere to this. They usually randomly pick one method or the other, or worse, they use both. (more readier).

Re:More ready? (2, Interesting)

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

Technically the correct term would be readier, but that sounds a little awkward to some people. Generally the rule is: One Syllable=[adjective]er More than one Syllable=more [adjective] Unfortunately very few people tend to adhere to this. They usually randomly pick one method or the other, or worse, they use both. (more readier).

Ready has two syllables.

Re:More ready? (1)

Shin-LaC (1333529) | more than 5 years ago | (#25252503)

GP missed an important part of the general rule: adjectives that end with "y" form the comparative with "ier" even if they are two syllables. Uglier, happier, prettier, etc.

Not sure about this one (2)

the eric conspiracy (20178) | more than 5 years ago | (#25251947)

Why not just wait for 3.0 to make the changes? That way you'll only have to test everything once.

And if it's like some other languages you might have a long time to wait before 3.0.

Re:Not sure about this one (5, Insightful)

jeremiahstanley (473105) | more than 5 years ago | (#25252021)

Because the development cycle is longer than that for derivative projects. Imagine if you could have a cycled and tested app that was ready from day 0...

Re:Not sure about this one (4, Informative)

arevos (659374) | more than 5 years ago | (#25252305)

And if it's like some other languages you might have a long time to wait before 3.0.

Given that the first release candidate [python.org] of Python 3.0 is already out, I doubt we'll be in for a very long wait.

Re:Not sure about this one (0)

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

It's around 2 weeks till final is out. They're planning on doing 1 more RC I think, then it's over and done with. Code base is long since locked except for critical bugs.

Re:Not sure about this one (3, Informative)

AM088 (1170945) | more than 5 years ago | (#25252399)

I think the point is that with 2.6, your old code will work but will tell you what to change. If you move to 3.0, unless you have those changes already, it just won't work.

Re:Not sure about this one (2, Insightful)

fyngyrz (762201) | more than 5 years ago | (#25252471)

If you move to 3.0, unless you have those changes already, it just won't work.

...which is why some heavy python users, myself included, aren't going to use 2.6 or 3.0. I have huge amounts of python in operation, and the very last thing I'm going to do is break any of it with an incompatible language that happens to slightly resemble python (no matter who wrote it, and no matter what they call it, it isn't python if it can't run mundane python code.)

Every once in a while we see one of these "brainstorms"; for example, Microsoft pulled VB from the office suite... only to put it back. Because the idea was stupid; there was a ton of production code / applications they flat out broke. Python's doing exactly the same thing, and it's not going to work out for the same reason(s.)

If you're going to modify a language, you *must* do it in a compatible manner, otherwise what you're doing is making a new language that will require an entirely new community. Names notwithstanding, and resemblance beyond incompatibilities notwithstanding.

Re:Not sure about this one (5, Informative)

tazzzzz (203300) | more than 5 years ago | (#25252751)

...which is why some heavy python users, myself included, aren't going to use 2.6 or 3.0. I have huge amounts of python in operation, and the very last thing I'm going to do is break any of it with an incompatible language that happens to slightly resemble python (no matter who wrote it, and no matter what they call it, it isn't python if it can't run mundane python code.)

"slightly resemble python"? Python 3.0 code looks just like the Python that's been around for years. Maybe there's some handy new syntax (with), but it's still Python.

This is not about fundamentally changing Python. This is about cleaning up warts, some of which have been around since Python 1.x.

If you're going to modify a language, you *must* do it in a compatible manner, otherwise what you're doing is making a new language that will require an entirely new community. Names notwithstanding, and resemblance beyond incompatibilities notwithstanding.

From what I've seen, the Python devs have put together about the best possible migration path while still actually making the changes that need to be made.

Here's the picture, in case it's not clear: Python 2.6 is just as backwards compatible as the other 2.x releases. Which is to say that porting from 2.5 to 2.6 is pretty trivial. I'd expect any actively used and maintained library to be 2.6 compatible within weeks (and a great many probably didn't break at all).

2.6 lets you use many of 3.0's features that don't break compatibility (and there are many). It also has a warnings mode to help you spot 3.0 incompatible code. And it lets you selectively turn on 3.0 features within a module.

Want to start using the new print function?

from __future__ import print_fiunction

Voila! The print keyword goes away and you have the new print function. Certainly bits of new Python 3.0 syntax work now as well:

try:
        1/0
except ZeroDivisionError as e:
        pass

The "as e" bit is new.

Finally, there's actually a "2to3" tool that makes many of the changes in an automated fashion.

The single biggest change from a compatibility standpoint is that "foo" is a unicode object in 3.0 and a string (set of bytes) in 2.x. You can even prepare for that switch:

from __future__ import unicode_literals

foo = "foo" # this will be unicode
bar = b"bar" # this is a set of bytes
unibar = bar.decode("utf-8") # get a unicode from the bytes

They have put *a lot* of thought into how to make this transition. People will gradually shift to 2.6, just as they did with 2.5. And, over time, they will change to using the new features. They'll probably upgrade to 2.7 (yes, there will be one), and use the new features even more. And eventually their code will just be 3.0 code and the switch will be a no brainer.

Re:Not sure about this one (0)

the eric conspiracy (20178) | more than 5 years ago | (#25252933)

I think the point is that with 2.6, your old code will work but will tell you what to change. If you move to 3.0, unless you have those changes already, it just won't work.

So you are saying that if I fix all the warnings in 2.6, my code will work 100% unchanged in 3.0? If not, why wouldn't I just wait for 3.0 and then just fix everything ONCE?

And now there is a 2.7? Sounds like death by a thousand cuts.

Re:Not sure about this one (2, Informative)

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

If not, why wouldn't I just wait for 3.0 and then just fix everything ONCE?

Well, first of all, 2.6 and 3.0 come out at the same time and share many of the same new features... so there's no "just wait for 3.0" possible, it's either/or right now.

The advantage is that if you have a big pile of 2.5 code right now, you can slowly turn on the "use 3.0 style" switches in 2.6 and migrate your code one little switch at a time over a long period of time.

That way, a few years from now when they decide to stop supporting new features in the 2.x path and you really "must have" some new feature in the 3.x path, it will be significantly easier for you to switch if you've turned on the "use 3.0" switches previously.

Not really (4, Interesting)

widman (1107617) | more than 5 years ago | (#25252419)

You can keep your code compatible with both at the same time. Deprecated features are trivial to rewrite in most cases. There are even tools for this.

Not really (-1, Troll)

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

A few years ago, while browsing around the library downtown, I had to take a piss. As I entered the john a big beautiful all-american football hero type, about twenty-five, came out of one of the booths. I stood at the urinal looking at him out of the corner of my eye as he washed his hands. He didn't once look at me. He was "straight" and married -- and in any case I was sure I wouldn't have a chance with him. As soon as he left I darted into the booth he'd vacated, hoping there might be a lingering smell of shit and even a seat still warm from his sturdy young ass. I found not only the smell but the shit itself. He'd forgotten to flush. And what a treasure he had left behind. Three or four beautiful specimens floated in the bowl. It apparently had been a fairly dry, constipated shit, for all were fat, stiff, and ruggedly textured. The real prize was a great feast of turd -- a nine inch gastrointestinal triumph as thick as a man's wrist. I knelt before the bowl, inhaling the rich brown fragrance and wondered if I should obey the impulse building up inside me. I'd always been a heavy rimmer and had lapped up more than one little clump of shit, but that had been just an inevitable part of eating ass and not an end in itself. Of course I'd had jerk-off fantasies of devouring great loads of it (what rimmer hasn't), but I had never done it. Now, here I was, confronted with the most beautiful five-pound turd I'd ever feasted my eyes on, a sausage fit to star in any fantasy and one I knew to have been hatched from the asshole of the world's handsomest young stud. Why not? I plucked it from the bowl, holding it with both hands to keep it from breaking. I lifted it to my nose. It smelled like rich, ripe limburger (horrid, but thrilling), yet had the consistency of cheddar. What is cheese anyway but milk turning to shit without the benefit of a digestive tract? I gave it a lick and found that it tasted better then it smelled. I've found since then that shit nearly almost does. I hesitated no longer. I shoved the fucking thing as far into my mouth as I could get it and sucked on it like a big brown cock, beating my meat like a madman. I wanted to completely engulf it and bit off a large chunk, flooding my mouth with the intense, bittersweet flavor. To my delight I found that while the water in the bowl had chilled the outside of the turd, it was still warm inside. As I chewed I discovered that it was filled with hard little bits of something I soon identified as peanuts. He hadn't chewed them carefully and they'd passed through his body virtually unchanged. I ate it greedily, sending lump after peanutty lump sliding scratchily down my throat. My only regret was the donor of this feast wasn't there to wash it down with his piss. I soon reached a terrific climax. I caught my cum in the cupped palm of my hand and drank it down. Believe me, there is no more delightful combination of flavors than the hot sweetness of cum with the rich bitterness of shit. Afterwards I was sorry that I hadn't made it last longer. But then I realized that I still had a lot of fun in store for me. There was still a clutch of virile turds left in the bowl. I tenderly fished them out, rolled them into my hankerchief, and stashed them in my briefcase. In the week to come I found all kinds of ways to eat the shit without bolting it right down. Once eaten it's gone forever unless you want to filch it third hand out of your own asshole. Not an unreasonable recourse in moments of desperation or simple boredom. I stored the turds in the refrigerator when I was not using them but within a week they were all gone. The last one I held in my mouth without chewing, letting it slowly dissolve. I had liquid shit trickling down my throat for nearly four hours. I must have had six orgasms in the process. I often think of that lovely young guy dropping solid gold out of his sweet, pink asshole every day, never knowing what joy it could, and at least once did, bring to a grateful shiteater.

Re:Not really (0)

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

nice one!

Re:Not really (0)

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

Thanks!

I always aim to please.

tough transitions (4, Interesting)

AceJohnny (253840) | more than 5 years ago | (#25251991)

These kind of compatibility switches are make-or-break. I'm glad there's Python 2.6 to try to ease the problem, but Py3k means that everybody who publishes python software will all of a sudden have to maintain 2 branches, for Python 2.X line and Python 3.X line.

This isn't the same as one software package having "legacy" and "bleeding edge" branches, because that's their own choice. In this case the underlying language is forcing them to choose.

Honestly, I'm not confident in the economics of such transitions, and believe Py3k will die out.

Re:tough transitions (1)

demmer (623592) | more than 5 years ago | (#25252013)

depends on how fast ubunto & co include 3.x when the target group of an appication already has 3.x there is no need to maintain the 2.x branch

Exactly why... (-1, Troll)

Junta (36770) | more than 5 years ago | (#25252119)

I've been sticking with perl. One of their significant criticisms to me is a strength: their development is relatively stagnant.

Perl6 has been an ever-present worry, but transitions from perl5.6 or so to perl5.10 has been fairly rock solid. I was a python user, but too many changes between even relatively minor updates had me revisiting scripts time and time again. I converted to perl in search of a capable scripting language that wasn't screwing around so much, even if the syntax at times is peculiar.

I will say the same thing that plagues python has plagued Java and probably hosts of other platforms. Platform developers often do more than 'extend' new features, they trample on existing things along the way 'improving' them. Generally, I can see arguments why it happened, but the fact of the matter is a language doing that is pretty crappy..

Really? (5, Insightful)

Peaker (72084) | more than 5 years ago | (#25252183)

What Python features broke for you between minor releases?

I find it pretty hard to believe any Python user would actually switch to Perl, and stick to it.

You sir, are probably making this story up :-)

DB access.. (0)

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

Between 2.x series I saw DB access strategies change, for example. That's the prominent one that pushed me over the edge to try perl.

Re:Really? (1)

pongo000 (97357) | more than 5 years ago | (#25253323)

What Python features broke for you between minor releases?

I can assure you that the one Python application I use regularly (trac) cannot be upgraded between minor versions without large-scale upgrades to dependent modules. It was an absolute nightmare upgrading from a machine with 2.2. to 2.3...many hours spent tracking down modules that simply didn't work with 2.3.

Coming from the perl world, having to deal with just one dependency nightmare with Python was enough to entice me to stay in the perl world...

trac, however, is excellent software, so I put up with it being a Python app. I find it rather shameful that minor Python releases render so many modules as doorstops...

Re:tough transitions (2, Interesting)

imbaczek (690596) | more than 5 years ago | (#25252121)

it'll take several years, but a critical mass will switch eventually IMHO.

Re:tough transitions (0)

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

Everybody who publishes python software will all of a sudden have to maintain 2 branches, for Python 2.X line and Python 3.X line.

Is there any reason for people not just to upgrade their Python? If they are using a Linux distro, it will most likely happen automatically anyway..
That is said as a python software publisher, who mostly feels like just upgrading the code.

Re:tough transitions (3, Insightful)

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

Honestly, I'm not confident in the economics of such transitions, and believe Py3k will die out.

Why would Python 3.0 'die out'? Even if you don't believe existing projects will make the switch there's no reason why new projects won't want to have the considerable benefits of using Python 3.0.

Re:tough transitions (2, Funny)

GooberToo (74388) | more than 5 years ago | (#25252461)

Why would Python 3.0 'die out'?

Its widely believed a large asteroid fell from the sky and wiped the mighty python 3.0 out. ;)
 

Re:tough transitions (3, Insightful)

DragonWriter (970822) | more than 5 years ago | (#25252309)

These kind of compatibility switches are make-or-break. I'm glad there's Python 2.6 to try to ease the problem, but Py3k means that everybody who publishes python software will all of a sudden have to maintain 2 branches, for Python 2.X line and Python 3.X line.

No, they don't "have to" maintain two branches. They can choose to, or they can maintain one (which depends on their particular circumstance); if necessary (if it is an app and not a library) they can just distribute the right interpreter with the app.

This isn't the same as one software package having "legacy" and "bleeding edge" branches, because that's their own choice.

Yeah, actually, it is exactly the same as that, at least as long as bug-fixes and maintenance continues on Python 2.x: the "one software package" being the Python interpreter.

And, yeah, if those maintaining python-based projects choose to maintain Python-2.x and Python-3.x based versions, that will also be an instance of exactly what you say it wouldn't be, as it will still be their own choice.

Re:tough transitions (5, Insightful)

GooberToo (74388) | more than 5 years ago | (#25252505)

For whatever reason, people fail to understand python natively supports parallel installs. Furthermore, since python's preferred script magic is "#!/bin/env python", rather than, "#!/bin/python", the executing script will use the python that it finds in your path. Additionally, you can also tie python to a specific version as "python2.5". Want a different python? Change your path. A script requires a specific version of python? Change the script to require it. It's one line and trivial. It's at the top of the file, so there's no hunting even.

New python releases only pose problems for the uninitiated, the ignorant, or the dumb.

Re:tough transitions (0)

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

I was going to add 'or the Perl programmer' but realized you already had.

Re:tough transitions (0)

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

Why bother with Python? Between Perl, Ruby, and Haskell, I have enough dynamism to make Python ashamed.

Re:tough transitions (3, Insightful)

jgrahn (181062) | more than 5 years ago | (#25254545)

For whatever reason, people fail to understand python natively supports parallel installs. Furthermore, since python's preferred script magic is "#!/bin/env python", rather than, "#!/bin/python", the executing script will use the python that it finds in your path. Additionally, you can also tie python to a specific version as "python2.5". Want a different python? Change your path. A script requires a specific version of python? Change the script to require it. It's one line and trivial. It's at the top of the file, so there's no hunting even.

Changing my path is not practical. It's too broad. I'd have to write a shell script wrapper for the application which did 'env PATH=new_python:$PATH the_real_application "$*"' or something. And it's not just me; I'd have to communicate this to all other users of the system somehow. And changing one line of a script is not trivial, if I'm not root.

All this may seem like minor things, but it adds up. And no other good language puts me in situations like that.

New python releases only pose problems for the uninitiated, the ignorant, or the dumb.

Or those of us who have been around for a while, and seen innocent backwards-incompatible changes become maintenance nightmares ... Ok, maybe not a nightmare in this case, but an inconvenience and annoyance which will keep being inconvenient and annoying for years, until the last Python 2.x dependency goes away.

The best way to judge this would probably be to look at what Linux distributions like Debian want to do about Python 3.0. They ship one Python as the default (2.4 currently, for Debian) but provide others too. I bet even a change from 2.4 to 2.5 is a major migration for them.

Doesn't matter (2, Interesting)

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

Most distros already include the current and previous versions of Python. So Ubuntu, for instance, will include 2.6 and 3.0, and possibly 2.5 as well.

Furthermore, you can check to see what version of Python you're running under and make your code so that it accomodates both. This is all accessible via sys.version or sys.version_info


>>> sys.version
'2.5.1 (r251:54863, Jul 31 2008, 22:53:39) \n[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)]
>>> sys.version_info
(2, 5, 1, 'final', 0)

With that knowledge, you just put all your version specific stuff in modules.

So you can do a:

import sys
major,minor,micro,release,release_num = sys.version
if (major > 3):
        import module_for_python_3.0
else:
        import module_for_python_2.x

Re:Doesn't matter (1)

TheVoice900 (467327) | more than 5 years ago | (#25252603)

Another common pattern to use for this, as well as for libraries, is the following:


try:
        import one_way_to_do_it
except:
        import more_common_way_to_do_it

Re:Doesn't matter (1)

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

That can hide subtle problems, especially in your own modules. A module can fail to load and you'll be left scratching your head as to why, because your method will cause the interpreter to abort with an exception on the second module, even if the 'one_way_to_do_it' module is supposed to work.

The better way would be to trap individual exceptions with something like this:


try:
        import one_way_to_do_do_it
except SomeException:
        handle_SomeException()
except SomeOtherException:
      handle_some_other_exception()

and so forth, so you get a better idea of what's going on. But I like my first way better because it tells the knowledgeable script user what's going on ;)

Re:tough transitions (2, Funny)

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

Honestly, I'm not confident in the economics of such transitions, and believe Py3k will die out.

No wireless. Less space than a nomad. Lame.

Re:tough transitions (2, Insightful)

xant (99438) | more than 5 years ago | (#25253475)

Uh, it's almost exactly the opposite of what you're saying. You don't have to have a Python 3.x line; you can just deploy your code on Python 2.6, keep your working application working, and do all your new development and testing with Python 3.x warnings turned on. Then your next release is Python 3.0 compatible; or if you somehow fail to do finish the Python 3.x upgrades in time for your next release, you don't have to release on Python 3.x, you can just keep using Python 2.6 even though your code is partially upgraded.

Partially upgraded codelines are always the problem with major version upgrades, and the Python 2.6/3.0 future compatibility is designed precisely so that this problem is not a problem.

Python has bent over backwards to make the upgrade as easy as possible for people with serious Python applications in production.

Re:tough transitions (1)

thogard (43403) | more than 5 years ago | (#25253915)

Funny thing is that none of my production code base even runs under 2.6. I'm moving stuff from a very old server to new hardware and so far I've had to move 2.1,2.2,.2.3 and 2.4 over and some stuff broke when using the newest version of some of the old version. The result is now I have to spend lots of time maintaining programs that should not have to be maintained. I have never seen a project written in Python that meets its time or financial budget and stuff like this makes me want to ban the language from our systems completely. That also seems to be a tend with major open source projects that also never seem to get finished. There is a perpetual tweaking that must be done to keep things working and that is so wrong. Throw in the security issues and the maintenance costs of python code and there is no positive return on investment management point of view. Remember stability is good. Loading thousands of unauditable packages is bad.

What's new (5, Informative)

ChienAndalu (1293930) | more than 5 years ago | (#25252031)

Here are the changes [python.org].
I really have to check out the multiprocessing package. Too bad that I have to wait for the print function and the new division handling.

Re:What's new (2, Informative)

yuriyg (926419) | more than 5 years ago | (#25252281)

Too bad that I have to wait for the print function and the new division handling.

Huh?
from __future__ import print_function
from __future__ import division

Braces (-1, Flamebait)

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

The inbetween release is because they're adding braces to version 3 and they want to give people time to prepare for the transition.

Re:Braces (0)

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

Yeah, it's true. You can actually start using it right now with "from __future__ import braces".

haha..Python,....do you get it ?? (0)

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

haha! Python ! Do you get it ? Guido named it after MPFC, this is very amusing. Do you get it ? haha Python....it's MPFC! Haha, do you see ?

Cut the crap. (5, Interesting)

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

These changes are NOT earth-shattering. 2.6 is mostly just going to add a few new features, most important being the with statement. Most code written using Python idioms will be fine under 2.6 and 3.0. Now, if you tried to write Java-esque or C-esque code under Python, you might run into issues. Even then, I doubt it. They've been deprecating features for awhile, and 3.0 is probably the point at which they'll be yanked...you've only had a year or two of DeprecationWarnings.

I'm not sure why people whine about a language evolving. Retain backwards compatibility to a fault and you end up with C++, which is crippled by C-isms. You either know your code well enough that you could make the small incremental changes along the way, or you simply don't upgrade.

Python most needs sane standard libraries. It is far too much of a "let's throw this in there" with three different naming conventions and no package organization. It is a shame, because the language itself is pretty powerful in the right hands.

Re:Cut the crap. (2, Insightful)

jimdread (1089853) | more than 5 years ago | (#25252207)

I'm not sure why people whine about a language evolving.

It's because all their old code breaks. And that hurts.

Re:Cut the crap. (0)

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

He just explained why it won't. In the cases where it does break, it's usually trivial to make the changes to get it working. Really, I haven't seen a single case where it would force massive rewrites of code.

Re:Cut the crap. (0, Interesting)

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

Well I'd guess you'd be in for a fair amount of digging if you want it to run on 3.X and you aren't using unicode for your text strings yet.

Re:Cut the crap. (0)

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

Why would that be? Text strings will act the same way as they always did, they'll just be unicode. It solves a lot of Python 2.x headaches. I really can't see how it could cause any big problems.

Re:Cut the crap. (3, Insightful)

slimjim8094 (941042) | more than 5 years ago | (#25252409)

So don't use Python 3.0. If it's critical, you're not upgrading from a known working base anyways, right? And if it's not, this will hold your hand.

Re:Cut the crap. (1)

RAMMS+EIN (578166) | more than 5 years ago | (#25252815)

Isn't there a simple solution to that? I mean, someone or some group could take it upon themselves to maintain the old incarnation of the language, and then old code would continue to run fine.

Re:Cut the crap. (0)

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

Because if we really wanted to rewrite the same program every year or so, we'd be using Microsoft languages and SDKs.

String f**k up (3, Interesting)

spitzak (4019) | more than 5 years ago | (#25252261)

Reading the release, they have decided to really push 16-bit strings (they call this "Unicode" but it really is what is called UTF-16). I think this is a serious mistake.

The proper solution is to use 8-bit strings, but any functions that care (such as I/O) should treat them as being UTF-8. Most functions do not care and thus the treatment of "Unicode" and "bytes" are the same.

The problem with UTF-16 is you cannot losslessly convert a string that *might* be UTF-8 to UTF-16 and then back again. This is because any illegal UTF-8 byte sequences will be lost or altered. This is a MAJOR problem for code that wants to process data that is likely to be text but must not be altered under any circumstances, in effect such programs are forced to be ASCII-only, even though UTF-8 is purposly designed so that such programs could display all the Unicode characters. Note that bad UTF-16 (ie with mismatched surrogate pairs) can be losslessly converted to UTF-8 and back.

This has been a real pain so far in our use of Python, and I am quite alarmed to see that they are changing the meaning of plain quotes in 3.0 to "Unicode". This is really a serious step backwards, as we will be forced to tell anybody using our system to put 'b' before all their string constants and I suspect there will be a lot less automatic conversion of these strings to unicode when we want to display them. Note that Qt is also causing a lot of trouble here too.

Re:String f**k up (4, Informative)

Animats (122034) | more than 5 years ago | (#25252429)

The problem is that there are three kinds of string-like objects in Python: UTF-16 strings, ASCII strings, and uninterpreted arrays of 8-bit bytes. Python 2.5 sort of supports all 3, with "array of bytes" the least well supported. Since this is a language without declarations, the semantics of this gets messy.

The most common problem was that functions like ".read()" yielded strings, not arrays of bytes. This follows C standard library semantics, but is a bad fit to Python. In 3.0, ".read()" yields an array of bytes, not a string. If the data read is to be converted to a string, "decode" is required. That's the right answer.

This is consistent with modern thinking about data representation. Consider SQL, which makes a similar distinction between "TEXT" and "BLOB".

Re:String f**k up (1)

spitzak (4019) | more than 5 years ago | (#25252919)

Interesting. I was afraid they were making all these functions return strings. If they are returning bytes as well it would certainly make things a lot better. However I would expect them to have the same trouble I am having.

Let's assume read returns a string of bytes. What I am worried is that the following example text will not work as expected:

    if file.read()=="utf8 string" ...

I expect this will automatically convert the result of file.read() to UTF-16 and then do the comparison. This will not produce the correct test if in fact the UTF-8 is an invalid encoding. Even if it turns the result into a string with error characters, it will still match the other string if it had error characters in the same place resulting from a different wrong utf-8 string.

From your description it sounds like the following will do the correct thing, which is better than I thought from my reading:

    if file.read()==b"utf8 string" ...

So at least this can be achieved. However I am worried that users will be tempted to type the incorrect code because it is easier.

It's possible that the == test will not work unless the compared string is a bytes string, but I would think that would break far too many Python programs. The other possibility is that failures to convert the utf8 to Unicode will throw an error, but then you have just introduced a million DOS flaws into everybody's programs.

Re:String f**k up (2, Informative)

Animats (122034) | more than 5 years ago | (#25253145)

From What's new in Python 3.0 [python.org]: The str and bytes types cannot be mixed; you must always explicitly convert between them, using the str.encode() (str -> bytes) or bytes.decode() (bytes -> str) methods.

That's the right way to do it, but I agree that as a retrofit to existing code, it's a headache.

Worse, it's a problem that's detected at run time, not compile time, at least with the CPython implementation.

Re:String f**k up (1)

spitzak (4019) | more than 5 years ago | (#25253467)

Well in a lot of ways that (not doing any automatic conversion) is the only correct solution if they really want plain quotes to be Unicode and not bytes/utf-8. It will be such a pain to fix existing code, though, that I would not have thought they would do that.

Re:String f**k up (0)

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

So your customers are putting illegal UTF-8 in their string constants, and you're passing them around to functions that expect unicode input, and then Python and Qt are "causing trouble" when they won't accept it?
Use bytes, do your own damn encoding/decoding after you've meditated long and hard on what the fuck kind of data you're really dealing with here, and stop being so damn half-assed. The API contracts are not to be broken.

Re:String f**k up (2, Interesting)

spitzak (4019) | more than 5 years ago | (#25252861)

No, think a little harder.

Imagine a file system that names the files with strings of bytes.

It is absolutely vital that if I ask for a list of files and then try to open them, that this all work, no matter what byte sequence has managed to get in there as a filename.

It is also *nice* but nowhere near as vital that I be able to show these names to users and they read them as Unicode strings.

Re:String f**k up (4, Informative)

John Millikin (1083757) | more than 5 years ago | (#25252591)

Spoken like somebody that's never had to deal with encoding issues. Using UTF-8 internally is fine, but exposing it to the programmer is insane and error-prone. And if the programmer then proceeds to manipulate that raw byte buffer as a string, he's an idiot.

The proper solution is to use 8-bit strings, but any functions that care (such as I/O) should treat them as being UTF-8. Most functions do not care and thus the treatment of "Unicode" and "bytes" are the same.

You might not be aware of this, but computers are used for more than just transmitting text. I don't want my binary streams being rewritten to gibberish because some I/O routine was written to be too clever. Furthermore, not every system uses UTF-8. Some may even need to send data over a *gasp* network! Good luck getting every other computer in the world to start using UTF-8 immediately.

The problem with UTF-16 is you cannot losslessly convert a string that *might* be UTF-8 to UTF-16 and then back again. This is because any illegal UTF-8 byte sequences will be lost or altered.

If you try to convert bytes that aren't in UTF-8 using a UTF-8 codec, an error will be raised. This behavior is proper -- if you don't know what format your input is in, there's no way to perform text-based operations on it.

This has been a real pain so far in our use of Python, and I am quite alarmed to see that they are changing the meaning of plain quotes in 3.0 to "Unicode".

Every developer I know uses Unicode strings already. The new behavior is just one less character to type in front of literals.

This is really a serious step backwards, as we will be forced to tell anybody using our system to put 'b' before all their string constants

Otherwise said as: "We're too stupid to fix the glaring encoding errors in our product, so we'll just use bytes everywhere and pretend it's all working". Also, Unicode strings in Python are implemented with either UTF-16 or UCS-4 depending on platform.

Re:String f**k up (2, Interesting)

spitzak (4019) | more than 5 years ago | (#25253001)

You might not be aware of this, but computers are used for more than just transmitting text. I don't want my binary streams being rewritten to gibberish because some I/O routine was written to be too clever

Thank you for explaining exactly why I want UTF-8 to be used, while thinking you were arguing against it.

Data is NOT just text. Therefore we should not be mangling it because we think it is text. We have enough trouble with MSDOS inserting \r characters. This crap is a million times worse.

Re:String f**k up (2, Interesting)

spitzak (4019) | more than 5 years ago | (#25253081)

Spoken like somebody that's never had to deal with encoding issues. Using UTF-8 internally is fine, but exposing it to the programmer is insane and error-prone. And if the programmer then proceeds to manipulate that raw byte buffer as a string, he's an idiot.

The compiler will turn "unicode" into the utf-8 encoding. The programmer does not see \xnn sequences of the utf-8 bytes. Try some modern compilers with utf-8 support some day before you say anything stupid again.

Any programmer that modifies UTF-16 as a raw array of words is an idiot. Besides surrogate pairs, there are combining characters and bidirectional indicators and lots of other trouble. In fact I prefer UTF-8 exactly because it discourages such misuse of strings, which are really made of words, sentences, etc.

If you try to convert bytes that aren't in UTF-8 using a UTF-8 codec, an error will be raised. This behavior is proper -- if you don't know what format your input is in, there's no way to perform text-based operations on it.

You have just introduced a massive DOS hole into your programs. Or do you really think you should run a "is this correct UTF-8" call before any attempt to convert? Sorry, it is not going to raise an error, it will instead convert to error UTF-16 characters.

Every developer I know uses Unicode strings already. The new behavior is just one less character to type in front of literals.

You know that Python will convert your bytes from UTF-8 to "Unicode" automatically when needed? No you didn't? Might want to study up on that...

Otherwise said as: "We're too stupid to fix the glaring encoding errors in our product

The encoding errors are not in our product. They are in the files we are attempting to read (metadata attached to images, mostly). Dumbass

Re:String f**k up (1, Informative)

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

I was on your side right up until you said:

Dumbass

Re:String f**k up (0)

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

I'm a bit confused here. It sounds like your data is a sequence of bytes, and not necessarily a sequence of valid characters. People expect a string to be a sequence of characters, and many many programs would break if strings could contain non-character garbage. Sometimes you need to work with raw byte sequences, and so python 3k provides the bytes type.

Though using UTF-16 is no doubt a source of great pain for your project, it seems like a very niche issue you are having. However, I don't really understand what exactly what your project is trying to do, so I could be missing a greater issue here. Could you clarify what your input data is, how you manipulate it, how you output it, and at what points string conversions screw everything up?

Re:String f**k up (2, Insightful)

spitzak (4019) | more than 5 years ago | (#25253029)

People expect a string to be a sequence of characters. Please notice the first word in that sentence.

"People" are not computers. "people" LOOK at the display. People are not trying to copy the data literally from one place to another or do comparisons of strings or read files that might (horrors) not contain correct UTF-8 data. There is no reason to mangle the data until the very last moment before it is put on the display.

I can quite confirm that if you have more than one way to represent the same sequence (such as different ways of producing the same UTF-8 error) you will produce a MAJOR screw up, quite likely an exploitable security hole. It also is not nice if "copy" mangles data just because it had a sequence that could not be coinverted correctly to glyphs.

Re:String f**k up (4, Informative)

belmolis (702863) | more than 5 years ago | (#25252683)

Python does not use UTF-16 strings; it uses UCS-2 strings. The difference is that in UCS-2, every character is represented by exactly two bytes, while in UTF-16, some characters, those outside Plane 0, are represented by two "surrogate" pairs, totaling four bytes. UCS-2 does not provide any representation for characters outside the BMP. In other words, UCS-2 is a straightforward fixed length encoding, while UTF-16 is a more complex variable-length encoding.

Python can in fact use either of two internal representations for text: UCS-2 or UTF-32 = UCS-4. If you give the option --enable-unicode=ucs4 to configure when building Python, you will get a Python that supports all of Unicode rather than just the BMP.

Re:String f**k up (0, Troll)

spitzak (4019) | more than 5 years ago | (#25253033)

No, Python is using UTF-16 nowadays. At least be somewhat informed before trying to argue with me about this.

Re:String f**k up (4, Informative)

belmolis (702863) | more than 5 years ago | (#25253177)

In fact I am better informed than you are. When not compiled to use UCS-4, Python uses what is properly called UCS-2, with half-baked extensions for treating it as UTF-16. Certain functions know about surrogate pairs, such as those that convert between UTF-8 and the internal representation. However, such basic functions as len do not know about surrogate pairs. Try giving a character outside the BMP as the argument to len. It will return 2, not 1.

Re:String f**k up (1)

spitzak (4019) | more than 5 years ago | (#25253493)

The fact that len returns 2 for a non-BMP character indicates that UTF-16 *is* being used. len is returning the number of words that the string occupies. This is a useful number (it indicates how much memory is needed to copy the string). The number of "characters" is completely useless, it causes crashes if you think it has something to do with memory usage, and it is useless for analyzing text unless you believe all the letters in Unicode are like fixed-pitch Latin letters.

x.len() when x is a UTF-8 string should return the number of bytes as well, and in fact this is how Python works.

Re:String f**k up (0)

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

x.len() when x is a UTF-8 string should return the number of bytes as well, and in fact this is how Python works.

That would be len(x), not x.len(). Congrats, you've just demonstrated that you don't know jack about how Python works.

Re:String f**k up (1, Interesting)

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

The number of "characters" is completely useless.

Whawhawhaaaat? It is useless to know how many characters are in a string, but usefully to know the size the string takes in memory in a completely memory-managed language?

Either you are exaggerating excessively (to prove your point, I posit charitably?), have an extraordinarily insular view of the programming world, are a troll, or, I think most likely, are an intelligent and thoughtful programmer the midst of temporarily insanity brought about by becoming entrenched fallacy defending a losing argument.

Take a deep breath...No, really. Do it. Breath in....wait a moment....and out.

All of Slashdot has pounced on your message, is arguing against you, and insulting you. It's because we're jerks. Also there's a technical problem in a few of your comments, but mostly we're just jerks. Take a night off, cool off, remember that we are jerks and the insults are not really directed at you, admit to yourself that there were mistakes in your argument, learn from them, and move on.

Ahh, and I just realized why you care about the size a string takes in memory. You are doing IO and are trying to use a string to store non-text data. Don't use a string. Use the bytes type instead.

Re:String f**k up (1)

earthbound kid (859282) | more than 5 years ago | (#25253345)

UCS-2 does not provide any representation for characters outside the BMP

That's not quite correct. You can use characters outside the BMP, they just have messed up len and slices, since they're actually made of two pseudo-characters.

>>> pb
u'\U00010000'
>>> len(pb)
2
>>> pb[0]
u'\ud800'
>>> pb[1]
u'\udc00'
>>> pb
u'\U00010000'

I would show that I was able to print it, but Slashdot hates Unicode.

Re:String f**k up (1)

spitzak (4019) | more than 5 years ago | (#25253501)

You are describing UTF-16. The characters outside the BMP take 2 words and thus len is 2.

Re:String f**k up (1)

RAMMS+EIN (578166) | more than 5 years ago | (#25252791)

I think the real lesson here is that byte sequences and character sequences are not the same. Every character sequence can be encoded to a byte sequence (by using an appropriate encoding), and every byte sequence can be converted to a character sequence (by means of some decoding), but they are fundamentally different things. I wonder if we wouldn't be better off making this explicit, and providing distinct string (character sequence) and blob (byte sequence) types.

Re:String f**k up (3, Insightful)

spitzak (4019) | more than 5 years ago | (#25253129)

I think the lesson is that there is ONLY byte sequences.

The fact that some code can interpret that byte sequence and draw something on the screen that the user thinks of as "text" is completely irrelevant and should not be a fundemental datatype of a programming language. This should be part of the code that draws the text. Imagine if every other type of data, such as image pixels, or sound samples, had a different IO routine and you could never read a file with the wrong routine because the conversion was lossy.

The real problem is that everybody's mind has been polluted by decades of ASCII where there was no difference between characters and bytes. All I can suggest is to try to think of text as words or sentences. Nobody would suggest that it would be good to make all words use the same amount of storage, or that it is important that you be unable to split a string except at word boundaries. But there has been so much use of ASCII that people think this is important for "characters".

I also believe there is a serious politically-correctness problem. Otherwise logical programmers are consumed with guilt because Americans get the "better" short encodings, and therefore feel they have to punish themselves by making the conversion to i18n as painful as possible so that Americans have just as much trouble as anybody else. The fact that they have actually made I18N far harder for everybody and thus actually discouraged it is the ironic result of this guilt.

Re:String f**k up (1)

tazzzzz (203300) | more than 5 years ago | (#25253309)

I think the lesson is that there is ONLY byte sequences.

The fact that some code can interpret that byte sequence and draw something on the screen that the user thinks of as "text" is completely irrelevant and should not be a fundemental datatype of a programming language.

No, text is important and there certainly are more than byte sequences. Yes, byte sequences are important and they certainly still exist in Python 3.0 (and, in fact, you now get a mutable byte sequence type as a bonus).

Let's say I have a webapp and there's a form with a state/province field. The user selects "California" from the list. The browser converts that set of characters to UTF-8 (because that's what's specified on the page) and then sends those bytes to the server. The web framework on the server properly spots the UTF-8 encoding, decodes it back into a bunch of characters.

This sequence of steps allows me to validate that the characters "California" represent a valid state.

If all I had was a series of bytes and not actual characters, I'd be SOL.

>>> u"California".encode("rot-13")
'Pnyvsbeavn'

Pnyvsbeavn is a perfectly legit series of bytes to represent "California", but I clearly couldn't do any useful validation there unless I decode it.

So, in many instances, the code does care about more than a sequence of bytes and "strings" containing "characters" are a very useful construct.

Re:String f**k up (0)

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

Character sequences are an extremely useful abstraction. 'q' is a roman letter, '2' is a digit, '&lambda' is a Greek letter who's capital is '&Lambda'. This is easy to think about with characters, but much harder with bytes (particularly with variable length encoding). Perhaps in your particular case you can get away with thinking of strings as sequences of bytes, but many times (I really think most times) it is extremely useful to abstract and think of strings as character sequences, and that's what the string type does. strings not be used to represent arbitrary binary data -- that's what bytes is for.

From another comment of yours:

There is no reason to mangle the data until the very last moment before it is put on the display.

If you don't want python abstract your data into a string of characters, then don't use string. If you are using the Greek and Cyrillic alphabet, changing capitalization, correcting spelling, or need to ensure that all characters are actual letters and not random garbage, don't use bytes.

Re:String f**k up (3, Informative)

tazzzzz (203300) | more than 5 years ago | (#25253239)

Actually, this has been explicit in Python for some time. In Python 2.x, "string" objects are byte sequences and "unicode" objects are character sequences.

What changes in Python 3.0 is that "unicode" objects have been renamed "string" and "string" objects have been renamed "bytes". So, not only is it explicit, but the naming makes more sense.

The other related change is that string literals in your code are interpreted as Python 3.0 "string" objects ("unicode" in Python 2.x terminology), whereas previously you had to stick a 'u' in front of the string to get that behavior. And you can indeed specify the encoding of your source files, which is nothing new.

All of this to say, you're right on the money and Python is already in the spot you describe as "better off".

Re:String f**k up (4, Informative)

tazzzzz (203300) | more than 5 years ago | (#25253215)

Reading the release, they have decided to really push 16-bit strings (they call this "Unicode" but it really is what is called UTF-16). I think this is a serious mistake.

The proper solution is to use 8-bit strings, but any functions that care (such as I/O) should treat them as being UTF-8. Most functions do not care and thus the treatment of "Unicode" and "bytes" are the same.

I'm going to try once more, slightly differently. Two other people apparently have tried and failed.

Python 3.0's handling of strings is basically the same as Java's, because it has proven to work quite well there.

For webapps, and the rules may be a little different on the desktop, "best practices" in Python for some time have been that you use unicode objects everywhere internally when you are representing text. When you hit a boundary (a file on disk, the net), you encode that unicode string into whatever encoding makes sense (often UTF-8). So far, so good, I hope?

Python's internal representation of unicode objects is only relevant in that you need it to support whatever code points you care about. I don't think there are any code points that you can represent in UTF-8 that Python will screw up after decoding/encoding. I'm sure there are many people who would be interested to see such a test case.

If you have a bunch of bytes that *might* be UTF-8, you're screwed. "process data that is likely to be text but must not be altered"? What do you mean by text? 7-bit ASCII? UTF-8? And where is the text coming from? Unless you tell Python the encoding of the file, you're going to get bytes out, not unicode objects.

The whole point is that Python unicode objects know how to represent code points. If you have get a set of bytes from somewhere you *have* to know what encoding it is in order to be able to treat it as a bunch of text characters. Python unicode objects will not be "bad UTF-16". How they're stored is not generally important. What's important is that Python internally keeps track of the code points and will either successfully convert to whatever encoded sequence of bytes you want or it will raise an exception because the encoding you've chosen doesn't have one of the characters in your string.

Python 3.0 makes this all clearer. When you talk about a "string", you're talking about a bunch of unicode characters. Anything else is a collection of bytes.

By the way, you can specify what encoding a Python source file is in so that your string literals are all properly decoded.

For further reading...
http://www.joelonsoftware.com/articles/Unicode.html [joelonsoftware.com]

Re:String f**k up (2, Insightful)

earthbound kid (859282) | more than 5 years ago | (#25253381)

The proper solution is to do what they did: hide from the programmer what internal format is used for strings. The only time programmers should know about the encoding is when they themselves explicitly select an encoding so that they can turn a bunch of bytes into a string or when they're sending the string out into the world as a bunch of bytes. Encode and decode explicitly at the edges. Internally, hide the implementation details. It's just basic OO.

Module support for 3.0 is a long way off (3, Insightful)

Animats (122034) | more than 5 years ago | (#25252493)

Many essential third party libraries need to be converted for Python 3.0. I need M2Crypto (SSL support) and MySQLdb (MySQL support), neither of which is ready for Python 3.0, and neither of which has been updated in the last year or so.

My guess is that it will be three years before stock mainstream Linux distros come with Python 3.0 and a set of libraries that work with it.

Re:Module support for 3.0 is a long way off (2, Informative)

Ixokai (443555) | more than 5 years ago | (#25254617)

This is quite true: but sort of irrelevant. Even the core developers on Python-dev have been seen to state on more then one occasion that they don't expect Python 3.0 to be the "standard" for a period of time that will stretch to years: one? three? The specifics don't exactly matter.

That's why they've done the releasing of Python 2.6 and Python 3.0 in parallel (although 3.0 was recently delayed a little, the development of each have been hand in hand); they fully expect to maintain the 2.x line for awhile, and are already talking of 2.7.

Each new iteration of 2.x will bring it closer to 3.0, and the third party modules will steadily become more and more available. Right now the IMHO biggest hurdle in the development of the modules for 3.0 is a lack of a serious conversion document from the point of view of the C internals. But they're even working on that.

3.0 seems to be, more then anything else, a work yet in progress. Even when it's released, its not fully expected to everyone will be converting their code over to be 3.0. They don't expect people to *really* start using it in a standard way until 3.1, 3.2 or so -- and whatever version of 2.x that will accompany it that people willll be converting from at that time, complete with additional features to help ease the transition.

Personally, I find the strategy for migrating Python to 3.0 ... comforting. I don't necessarily agree with *all* of the changes done to 3.0, but most I quite like. Since I have a massive codebase at work that's currently running on 2.x, a major/incompatible change to "fix" the language is something that alarmed me early on.

However, now I know that 2.x will be supported for quite awhile, and new releases will be made upon it to ease the way, I have a roadmap to follow that makes the burden significantly easier. Once we update our codebase to 2.6., I'll probably start slowly modifying things to activate more optional 3.x-isms, and by that time the myriad third party libraries will probably be supported.

2.6 brings a number of interesting features to us; and allows us to start working slowly towards migrating to the 3.0 world. This is a -very- well thought out migration plan, IMHO.

Old news... (4, Interesting)

pdxp (1213906) | more than 5 years ago | (#25252711)

3.0rc1 (beta) [python.org] is already available and has been for some time now. The advantage of 2.6 is not as much its backward-compatibility but its ability to tell you exactly what needs to change (via runtime warnings) for 3.0 without actually breaking your code. I've been using both for months now, so this article isn't exactly hot news.

Hahahahahaha! (-1, Troll)

Jane Q. Public (1010737) | more than 5 years ago | (#25253347)

This is pretty much a given in both Ruby and Rails! In every case I know of, users had advance warning from their interpreters when anything was deprecated and would become obsolete within a few versions.

Sounds like Python is bragging about something their chief competitor has been doing better for a long time.

Re:Hahahahahaha! (0)

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

This is pretty much a given in both Ruby and Rails! In every case I know of, users had advance warning from their interpreters when anything was deprecated and would become obsolete within a few versions.

Sounds like Python is bragging about something their chief competitor has been doing better for a long time.

Umm no... Python has had DeprecationWarnings for longer than Ruby has existed.

Re:Hahahahahaha! (0, Troll)

Jane Q. Public (1010737) | more than 5 years ago | (#25253829)

Okay, that's cool, but Ruby and Rails have also had "upgrades in preparation for", similar to this. This is hardly news. It is like they are bragging about something that everybody else does.
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...