Slashdot Mirror
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. :-)"
This is from the Python page!
Scheme has the following advantages to Python:
* Supports proper closures, with lexical scoping.
* Any function can be defined anonymously, via the lambda keyword.
* Is supported by a standard (R5RS, IEEE)
* Makes it easy to program in a functional style, i.e., without side effects.
* Supports macros.
* Mathematically oriented, rather then processor oriented, numeric model.
* Supports fairly optimized compilation to native code.
There are multiple lisp implementations of varying quality. Common Lisp is a language standard like C++, not an implementation. Modern Lisp supports static type declarations as well as dynamic typing, so a good lisp compiler plays in the C++ space, not the scripting language space - only it's as easy to write in as a scripting language....
Now about 'self'.
... and that is what the parent was talking about.
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.
In SmallTalk self is a reference, like in Python, to the object the current running method belongs to, but you have never to type it except you need it.
For the C++/Java folks, self is the equivalent of this. No one likes code like that: self.doThis(); self.doThat();
Python is in some parts really brain deadly designed, e.g. the __init__(self) methods instead of CTORS like Java or C++. Class methods aka static methods are ugly as well. Prepending every method call with self is ugly
Of course you can ahve several Python versions installed. I'm sure the parent knew that.
But how should a class of PYthon 3.0 load a class from Python 1.0 over installatino boundaries? And why does Python evolve that uncoordinated?
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.
angel'o'phere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
I think you misinterpreted the slide talking about Ruby 1.9.x. The odd numbered Ruby versions are the development track, while the even numbered versions are release caliber. Ruby2 will have Unicode support and Ruby1.9.x is where it will show up first. The lack of multilignual support is actually listed as a reason as to why Ruby currently stucks. This isn't half-assed support of Unicode.