jessenoller.com

If it’s any con­so­la­tion, there are those of us who are gen­uinely excited about Python 3 as well as mul­ti­pro­cess­ing. I appre­ci­ate the hard work that has gone into it and think that it’s bet­ter for the lan­guage to evolve than to stagnate.

There will always be peo­ple who don’t like change. The decid­ing bit in the suc­cess of Python 3 will be who adapts and who does not. I will be adapting.

Ah, don’t bother. Real pro­gram­mers are always eager to learn new things, and if the changes in 3.0 were an unpleas­ant sur­prise, then frankly he’s not been a part of the Python com­mu­nity any­way and I’d say for­feits his right to complain.

“Waaah. I have to learn some­thing new.” That’s all.

Per­haps it is :)

1) mul­ti­pro­cess­ing rocks
2) ruby 1.9 is only a *very* slightly smaller change than python 3, it changes some fun­da­men­tals of the lan­guage as well.

There are two oppos­ing forces here, and you can see them just as well in dis­cus­sions about the GIL.

The first one is the pro­gres­sive and more open-source ori­ented men­tal­ity that pro­mote bet­ter fea­tures and cleaner code. These are the peo­ple that hang out on IRC, write really cool exten­sions, and gen­er­ally have a very aca­d­e­mic and inti­mate knowl­edge of the python api.

The sec­ond one is a more prac­ti­cally goal and busi­ness ori­ented men­tal­ity, that pro­motes sta­bil­ity and pro­lif­er­a­tion. These peo­ple are more often than not get­ting paid to write the spe­cific chunk of code in which they choose to dis­cuss, and are blessed with not hav­ing to worry about the imper­fec­tions of the code as long as they make their deadlines.

There will always be a com­pro­mise between these two forces. I like to fall into the first cat­e­gory, pre­fer­ring to take my time with unit tests and a detailed under­stand­ing of my code, because I do not enjoy going back and fix­ing con­cepts that should have been com­pleted the first time. But, I don’t get paid for my clean con­cepts, I get paid to meet dead­lines and to be able to main­tain the code I’ve written.

Your code doesn’t need to be per­fect to have fun AND make money, and your lan­guage doesn’t either. You also need to have that bleed­ing edge branch to keep the spirit of the craft alive. I’ve never used ruby, and I’ll never write java again, but one thing I can say about the python com­mu­nity is that there is a very large num­ber of peo­ple that are involved in dis­cus­sions across the spec­trum, and this is noth­ing but healthy for the lan­guage, just like bleed­ing edge 3.0 releases are and eas­ily main­tain­able 2.5.1 OSX releases are.

Here’s one instal­ment of my contribution:

http://mikewatkins.ca/2008/12/05/why-python-3/

Regard­ing Patrick’s insight­ful com­ment on the dynam­ics of the more aca­d­e­mic vs more com­mer­cial users, I agree that the vari­ety of users and groups bring much to the over­all Python community.

I won­der if the bet­ter sup­port for work­ing with Uni­code might be one aspect of Python 3 which may be, par­don the pun, some­thing of a *Uni*fying force. Its such a plea­sure in comparison.

This is just the nat­ural wave of stop-energy, mostly concern-trolling. It will go away. I posted my take here: http://blog.pythonaro.com/2008/12/if-only-we-co…

Paul — My ego wasn’t bruised, and frankly — if you have prob­lems with peo­ple on python-dev, bring it up with them. I saw a post, from some­one who has some amount of read­er­ship, which came up on sev­eral feeds I track that dis­ap­pointed me given that I did not feel that many of the points were cor­rect, or warranted.

Also, the com­ments also attached onto the blog post both­ered me. That’s it. If he’s allowed to air his “fairly legit­i­mate stuff”, I’m allowed to say that I don’t like it, or point it out to others.

I don’t think any­one involved in the python com­mu­nity was “incensed” at some­one not uncon­di­tion­ally lik­ing python 3k, hell, there’s some stuff I don’t like about it, and and some things I don’t like about python in gen­eral. If I aired those things here, I would expect responses, and not all of them softballs.

The fact is, Python3k is a sen­si­tive issue for any­one knee deep in the com­mu­nity and lan­guage as it could become a “make or break” thing, there’s been enough talks of schisms and splits and forks and how peo­ple in python-dev hate library devel­op­ers or any­one “with a real job”, that I do think that peo­ple in the com­mu­nity are allowed to respond, as long as those responses are of a civil tone.

I wouldn’t call me bal­anced — any­one with a dog and a 19th month old doesn’t qual­ify as balanced :)

I was actu­ally talk­ing to some­one about this ear­lier — both “sides” need to be civil. As long as there aren’t bla­tant fac­tual errors, religiously-loaded state­ments (“if you don’t love py3k, you hate free­dom”) or out­right flame­bait, there’s no rea­son to not keep it civil.

I agree, neg­a­tive tones — on both sides of any dis­cus­sion can cause peo­ple to not want to explore things further.

That being said: The FUD I cited in my post was less in the post — but the ensu­ing com­ments. There was a lot of con­fu­sion and mis­con­cep­tions in a lot of it, and some in the orig­i­nal post.

I don’t think you’re a “hater” — as for zooko, he isn’t either. But you, me, and oth­ers are going to have to agree to dis­agree. Python 3000 wasn’t sup­posed to be a new species: it is designed to be a jump in the evo­lu­tion of the language.

Python 3k will not reach wide­spread adop­tion for some time — Myself? I won’t be using it pro­duc­tion for at least a year, if not longer: my list of library depen­den­cies is fright­en­ing, not to men­tion while I might hack on it/stuff for fun — I still need to tar­get a 2.x release for work.

I am a fan of python 3, I think it’s cleaner, I think the bytes/unicode fix­ing was needed, and I am always for sac­ri­fic­ing back­wards com­pat­i­bil­ity to grossly adjust the path of things.

Time will tell w/ Py3k. I’m rec­om­mend­ing to peo­ple I know they learn 2.6, 2.6 will be around for awhile, and I’d put money on the table that 2.7 is in the pipe too. This means that Py3k will have time to mature, and per­haps the migra­tion path will be smoother.

No one, at least, no one I pay atten­tion to, in the python core group has any mis­taken impres­sions about the real-world effects and con­se­quences of py3k. If they didn’t, they would not have con­strained them­selves as much as they did, and we’d have a perl 6 on our hands.

I don’t know if you’ve read my other posts on the con­cur­rency sub­ject, but I fun­da­men­tally agree with you, ergo the inclu­sion of the mul­ti­pro­cess­ing library as a start.

Not to men­tion, the inclu­sion of a fiber-based thread­ing sys­tem (which is what erlang uses) should in no way break back­wards com­pat­i­bil­ity if it is done in addi­tion to the cur­rent thread­ing imple­men­ta­tion. Twisted is not the one true answer in the python com­mu­nity any­ways. Take a look at Kamaelia, mul­ti­pro­cess­ing, Drama­tis, etc.

Not to men­tion: No, it doesn’t need this to “really take off” — con­cur­rency is not the pri­mary goal or design cen­ter for Python. How­ever, the design cen­ter does not exclude the pos­si­bil­ity of a well done con­cur­rency system.

“”“
As it is, I’ve read so many neg­a­tive things about py3 and mul­ti­pro­cess­ing in the last few days I’ve burned out my abil­ity to be rea­son­able.
”””

Well, what called your name to my atten­tion, and what brought me to this blog, was the won­der­ful new mul­ti­pro­cess­ing mod­ule, and a desire to thank the peo­ple who made it pos­si­ble. I’ve been work­ing with it the last few days. Get­ting to know it. Com­par­ing its per­for­mance with the thread­ing mod­ule on code I have con­verted. And I am exceed­ingly impressed. The per­for­mance sparkles. The ease of con­ver­sion from thread­ing to mul­ti­pro­cess­ing is amaz­ing. The addi­tional mem­ory over­head, com­pared to threads, seems to be sur­pris­ingly small in my tests (under Linux). The per­for­mance of Queue par­tic­u­larly sur­prises me. I had known *of* this mod­ule for a cou­ple of months. But this is the first time I’ve picked it up and *used* it. Color me excited. And I’m not just say­ing that to cheer you up. Like I say, I sought out this blog with the express pur­pose of say­ing it.

Mes­sage pass­ing, FTW!

–Steve Bergman

“”“
It seems to me that when­ever any­one brings up incon­ve­nient issues like the pro­mo­tion of the lan­guage,
”””

What about pro­mo­tion of the lan­guage? We’re not going to have to live with all those bits of “unbeauty” for­ever. Just for a few more years.

“”“
which ver­sion new­com­ers should use,
”””

Use “python 2.6 –3 –tt” for now. I think that’s clear enough to those in the know. This will no doubt have to be stated an restated fre­quently. Yes, new folks will have a ten­dency to want to start with the “lat­est and great­est”. In a cou­ple of years, 3.0 will prob­a­bly be the nat­ural choice.

“”“
avail­abil­ity of books or learn­ing mate­ri­als,
”””

There is *already* at least one book avail­able with 3.0 cov­er­age. The next iter­a­tion of books with duly have that lit­tle “Cov­ers 3.0!” tri­an­gle in the bot­tom right cor­ner or wher­ever, just like they’ve said “Cov­ers 2.4!”, etc. in the past.

“”“
the gulf between the objec­tives of the core devel­op­ers and the users, or just the plain con­fu­sion that you get when some­one puts some­thing dif­fer­ent out under the same name, that’s sup­pos­edly FUD and the critic a “hater”.
”””

Yes, that last quoted seg­ment is unsub­stan­ti­ated FUD.

“”“
A really good crit­i­cal sum­mary of Python 3.0 is the fol­low­ing ref­er­enced com­ment. Note its brevity (in con­trast to para­graphs upon para­graphs about mon­keys
from one com­men­ta­tor):
”””

Triv­i­al­iz­ing James’ post in that way is, in my opin­ion, in poor taste, and an appli­ca­tion of exactly what it is that you claim peo­ple are doing to you.

Frankly, I’ve noted more “Chicken Lit­tles” than haters in the com­mu­nity. The sky is not falling. 3.x is not that dif­fer­ent from 2.x from a programmer’s per­spec­tive. More so from a code maintainer’s per­spec­tive. But over the next cou­ple of years the con­ver­sion tools should evolve, and 2.6+ code will make up an increas­ing por­tion extant Python code base, and ear­lier ver­sions will be less rel­e­vant. Yes there will be pain for main­tain­ers of older code bases. But some­what less than what I’ve read some fear-mongers predicting.

Python 3.x is and has always been about about the long term. And I wish more peo­ple under­stood that.

Just a point of clar­i­fi­ca­tion. When I speak of “unbeauty”, above, I am refer­ring to all of 2.x’s lit­tle warts that are going away. I don’t think that my word­ing there was really clear.