Python Conference Coming Soon

nnorwitz writes "PyCon 2004 is coming to Washington, DC at the end of March. It's a great place to meet lots of smart people and learn new things. Many interesting discussions go far beyond Python into other programming languages and topics. We should find out more about the Pie-thon, the OSAF since Mitch Kapor is the keynote speaker. There may even be a few surprises. The price is only $175, but early bird registration ends soon. It's not too late to submit a presentation either. I hope to see lots of new faces this year! I want to talk to some Perl and Ruby zealots^Wconverts^Wprogrammers. :-)"

Comments

uhm, I'm not going from Ruby to Python

[Anonymous Coward]

Sorry, Python is a lot better than Perl but then again so's VB, eh?

The Python community is turning into a bizarre mirror-image of the Perl community: full of themselves and a little too eager to show off the latest "trick" you can do in Python.

I read Python books/sites and they say with a straight face "the great thing about Python is there's only one way to do things" .. what they fail to mention is, one way *per Python version*.

I first used Python at 1.5 when it was pushed as a "prototyping language". I'm not coming back until they finish figuring out their object model and scoping rules.

Someday, a bright Pythoner will get hit by lightning and realize, "hey, str(obj) just calls obj.__repr__() .. why the heck don't we all just call obj.__repr__() directly? And do we really need *four* underscores? And do we really need to type 'self' all the time???" At that moment, the Rubification will begin.

Sincerely,
Ruby Zealot

Re:uhm, I'm not going from Ruby to Python

[Slash.ter]

I read Python books/sites and they say with a straight face "the great thing about Python is there's only one way to do things" .. what they fail to mention is, one way *per Python version*. I first used Python at 1.5 when it was pushed as a "prototyping language". I'm not coming back until they finish figuring out their object model and scoping rules.

So you're saying Python evolves. Doesn't C, C++, Java, and ... Ruby do the same? It is easy to have many Python versions installed and usable at the same time. It is as easy to add packages to any of the installed versions. Is it easier to manage change in Ruby?

Someday, a bright Pythoner will get hit by lightning and realize, "hey, str(obj) just calls obj.__repr__() .. why the heck don't we all just call obj.__repr__() directly? And do we really need *four* underscores? And do we really need to type 'self' all the time???" At that moment, the Rubification will begin.

You're confusing 'str(obj)' with 'repr(obj)' but that's OK - you're Ruby Zealot. I think you're to picky and if I was as picky about Ruby, here's what I'm reading here : 'obj.__id__' is the same as 'obj#id' and 'obj.__send__' is the same as 'obj#send'. So not only that I see four underscores (was it borrowed from Python by any chance?) and two ways of doing the same (there are more examples on the web page) but there is another peculiarity: '#' has two meanings: you can use it as in 'obj#id' and you can use it to start comments!

Now about 'self'. It comes from Smalltalk and Matz (creator of Ruby) claims that Ruby borrows ideas from Smalltalk. So I don't see your point. On top of that, you don't have to use 'self'. You can use 'this', 'that', and 'other' or even 'S' if you aim at brevity.

Re:uhm, I'm not going from Ruby to Python

[Slash.ter]

Thats not correct. The parent poster is reffering to the fact that methods in Python have a argument called self, which you sometimes have to type, sometimes to declare, sometimes not.
I'm well aware of that. But 'self' is not a keyword. If you don't like to type it, use something shorter, say: 's'.
I have no clue what you mean by "declaring" and "sometimes not". It is always there, it can be called differently. And you never declare things in Python.

For the C++/Java folks, self is the equivalent of this. No one likes code like that: self.doThis(); self.doThat();
Except when you have class member 'thing', method argument 'thing', and a local argument 'thing'. In C++ you can also have a global variable called 'thing'. You might argue that it's a bad style, but I've seen codes that do that and play tricks with undescores to sort out the mess. In short, in C++/Java you're allowed to be incosistent: 'thing' and 'this.thing' mean the same, sometimes. Python doesn't have to save keystrokes because it's relatively succinct. I like the 'self' idea because it defines the context for me without looking it up in other places. You don't like it and that's fine with me - that's life.

But how should a class of PYthon 3.0 load a class from Python 1.0 over installatino boundaries?
You just start Python 1.0 as a subbrocess of Python 3.0 process and have a proxy class in Python 3.0 to look like Python 1.0 class that communicates with the subprocess. A page or two of coding.
And why does Python evolve that uncoordinated?
I don't think it can be called uncoordinated - at best you may call the changes too big. The changes go through a well defined process - PEPs. And there is a vote. So in a sense you should blame the majority. Guido only breaks the ties. With Ruby it's Matz's opinion that matters read his opinions in an interview. He hinder Ruby's support for international encondings (see this post).

IMHO it would make sense to define now a Python 7.0, or something. And put everything into it you want, and then let the implementations evolve from the current point towards 7.0. So everyone knows what the final language will look like and kows that the current state is only an interims state.
You've just described what's called Python 3k. The idea has been entertained for a while on Python lists. The problem I have is that I cannot code for something that doesn't exist so I prefer to code for what's out there today. I guess it works for me and it doesn't for you - that's life.

Why would I want to convert from Ruby to Python?

[Colonel Panic]

Sure there are a lot of similarities, but I prefer Ruby's purer OO model and I don't prefer Python's whitespace as syntax requirements and the need to type self everywhere (not to mention all those underscores). And where's the fun in there's only one way to write it?

Python definately has some advantages over Perl, but as a Rubyist, it doesn't offer me any advantages that would convince me to switch.

'Different strokes for different folks' as they say down at the retirement center

Re:Why would I want to convert from Ruby to Python

[GCP]

I like a *lot* of what I see in Ruby, and I strongly agree with your criticisms of Python (though I'm still undecided about the whitepace issue.)

Even so, I think Matz's attitude about Unicode and internationalization rules Ruby out as a serious candidate for me.

All Windows and Macs machines being sold today already use Unicode. The Unix world is in last place but the conversion is happening almost everywhere. The very last holdout against Unicode will probably be the Unix-style OSes in Japan. While all other platforms are Unicode and most of the Unix world is converted, they will be the last of the legacy holdouts.

Japanese *nix is also the center of Matz's focus, and it shows. He has made it clear that the principal driving force behind Ruby's design is to help him do his own Japanese work in an encoding (EUC-JP) that he says is "good enough for me [him]". Since EUC-JP doesn't support anything well except for Japanese, he clearly doesn't internationalize his own work, and his comments make it pretty clear that anyone who does want to follow modern internationalization practices had better look elsewhere for a language.

Also, the libraries in Ruby are far less developed than in Python, and I don't see them getting "good enough" anytime soon. Matz's Japanese Unix-centric community just hasn't produced the libraries that the rest of us are beginning to demand from our production languages.

If I were just tinkering around with personal utilities and if legacy subset charsets were good enough for my text needs, then it might be all right. But I need lots of big, solid, production quality libraries for Unicode-based commercial systems, and Ruby isn't close. (Even Python is a stretch.)