Slashdot Mirror
Python 2.0 beta 1 released
jhylton writes "How's this for a rapid release schedule?
Python 2.0 beta 1 is now available from BeOpen PythonLabs. There is a long list of
new features since Python 1.6, released earlier today. We don't plan on any new releases in the next 24 hours ."
I was under the impression 1.6 required the recompilation of third party extensions anyway. Although I suppose thats not truly 'breakng' them (although isn't there an explicitly-deprecated syntax thats no longer supported?)
Pax,
White Rabbit +++ Divide by Cucumber Error ++
free experimental electronic music netlabel at www.viablehybrid.com
It's refreshing to hear the "syntax is not an issue" perspective. With that attitude you can approach Python as a dialect of Lisp - albeit with very different syntax. ("Traditional" infix operators, minimal use of parentheses etc).
For a comparison of Python and Scheme, see:
http://www.python.org/doc/pythonVSscheme.html
For a comparison of Python and Common Lisp, see:
http://www.norvig.com/python-lisp.html
Can't comment on Perl. I don't use it.
Python makes it easy to express very complex ideas in simple and readable code. Definitely worth a try. Everyone who tries it seems to love it, from beginners to the AI cognoscenti.
---- Ends are ape-chosen; only the means are man's.
No, the beta period for 2.0 should be fairly short (knock on wood), with a 2.0final release within a month or two. 1.6 is a release born of legal quibbling, not of technical reasons.
The simple rule for perl is that a sub without an argument operates on $_ unless otherwise specified. Therefore, as given in the example, "chomp" operates on $_, while "chomp $thing" operates on $thing. Some subs do not operate on scalars, and others require more than one argument, so these subs must be called with the appropriate paramaters, however is is very natural in programming. You know that 'rename' requires two paramaters, so you have to supply them both.
At least, if you don't like this behaviour, you can get C like required paramters by simply adding in the parameter on each sub call, "chomp $_" is identical to "chomp". My least favourite disfeature of python, it's syntaxly important indentation is impossible to avoid.
Nice way to get your program corrected :-)
"testf" doesn't include the full path name, so of course it can't work unless direc="." (as in any language). Try 'FILE* f=fopen("dev/null", "r")' in C while being on your home directory, it won't work too well, will it ? The fix is:
f=open(direc+"/"+testf,"r")
with the "/" being unnessecary if direc=="/".
Yes, that is flamebait, and I'll tell you why.
;) then you haven't won any points with me; actually, you've lost a few.
1) Perl is a pretty cool language; I've used it. Cryptic, yet powerful, much like C. Also, I like being able to write some simple, powerful text processing, without being bogged down by the details.
2) Scheme is a pretty cool language; I've used it. Simple, with interesting choices for primitives and control structures. I like being able to make and extend a program with an amazing amount of flexibility, and easily implement new features.
3) Python might very well be a cool language as well. However, I haven't used it; I'd have to try it out and find a use for it, and it looks pretty weird. However, since you've offered no actual facts for your argument, and bashed two other languages that I consider to be pretty good, (even if they are generally slower than C
4) Therefore, from (3), that's flamebait, not advocacy. Please reply with reasons that make Python a better choice than Perl or Scheme for a given problem domain, instead of "Python is so much better, and Perl and Scheme just suck". Syntax issues are irrelevant; I could probably write a tokenizer to get rid of the syntax issues involved, if I had to. Language support for features is relevant; (i.e. Scheme's choice of first-class types vs. Perl's references) also, implementation decisions are relevant (Perl and Scheme can be interpreted *or* compiled depending on the implementation, but generally are still slower than a truly compiled language because of their feature-sets, like "eval").
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Bzzt. wrong.
By importing os with "from os import *',
you're overwriting plain open (ANSI fopen (3)) with unix open(2), which takes an integer argument as flag.
Han-Wen Nienhuys -- LilyPond
Wow, more releases per hour then M$ IE gets security advisories!
----
Remove the rocks from my head to send email
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
Silicon Valley has developed a new technique to speed software development. Time travel. According to reports Python 1.7 is still due Mid December
python.org is owned and run by CRNI. guido and the core developers left CRNI because they were reducing resources for python development. thus, the team found a new sponsor in beopen.com.
it boils down to python having the resources to evolve, which is a good thing.
from a developers standpoint. python 2.0 is still based off the same code base. the big rewrite will probably not come to fruition for another 1-2 years. i believe 2.0 has a duel license, both gpl and the old python style CRNI license.
2.0 has some cool features including full support for unicode, list comprehensions (very cool), more xml tools, and a rewrite and speedup of the regular expression parser. *but*, 2.0 also breaks many of 3rd party extension packages, so you may want to keep 1.52 or 1.6 around until 2.0 support matures.
as far as a 'language spec' goes... python is an evolving language with many contributors. python has pep's which are basically a new feature request proposal. most peps include a patch to demonstrate the new feature, as well as supporting arguements for the feature. the group of core developers then fights among themselves about the merits until a steady state is reached. votes are taken, and i think guido has the final say.
jherber
Mind you, I've not used perl, but I do have some experience in the two other languages.
Every time I want to change python, it is to make it more like scheme; orthogonal, consistent, predictable.
Mostly it boils down to lexical scoping, declaring variables, and closures. syntax is a doddle, love it or hate it, you can pretty easily learn to live with any given syntax. Language features do play a role.
All of which can be hacked around without too much hassle, but the do limit my use of python to a super-scripting language. Filesystem chores, typically in a pipeline with sed and awk preprocessing the input. Anything larger and python's scoping rules tend to start nipping, and then biting.
On the other hand, due to the powerful modules it comes with, python can do quite a lot in a short program.
Actually, it's a long standing joke in comp.lang.python that Guido van Rossum, the creator of Python, has a time machine. It usually come up in the context of someone saying, "Boy, I really wish Python would add feature X." Then someone (usually Python guru Tim Peters) would respond to the effect that Guido likes the idea of adding feature X so much that he will use his time machine to retroactively add it to the language as of three releases ago....
This isn't a big deal for a += 1 , but certainly is for a more complex assignment like a[index].attribute += 1
Definitely a good thing...
If you're not part of the solution, you're part of the precipitate.
Even in languages that have it, "endif" doesn't do anything. It's just a marker, to show where a block ends. C doesn't have endif either; it has braces. Either would be redundant in Python, because the end of the block is already known from the indentation (yeah, lots of people can't get over that, but we had that flamewar yesterday).
That's a good thing. Read Edsger Dijkstra's paper on "Goto Considered Harmful" from thirty years ago for an explanation. Python has a rich enough set of control structures - most notably exceptions - that make goto unnecessary.
Another good thing. It helps prevent the experience, familiar to C and C++ programmers, of scrabbling around trying to find out where something was defined and which definition is operative. Like many experienced Python programmers, I don't even use "from foo import *". That forces me to use "foo.func(x)" later, which is a little more verbose but makes it blindingly obvious to everyone which definition of "func" I'm using.
Like Perl is easy for the man in the street to understand? Or Scheme? Or any possible programming language? Be careful not to use the "man in the street who happened to learn Perl/VB first" too much in your examples. ;-)
Slashdot - News for Herds. Stuff that Splatters.
Ok...I promised myself I'd stay out of the Perl/Python flamewars...but...
(1) Python code is more obvious about what's happening. Perl has implied arguments that can make it difficult for someone else to maintain. Example: "chomp;". I look at this and wonder: "chomp what?" After reading in Perl docs, I find out that $_ is implied. Not nice.
Well, anyone who knows Perl knows that chomp operates on $_ by default. So, your argument is that Perl is hard to program in unless you know the language...?
For the new python user, what are the pros and cons of using the python.org version versus the pythonlabs.com version? Which is more current, and which is closer to the language specification? Is python.org's hosting The Python Consortium a real sign, or the equivalent of "People For Fair Play in Elections", ie semi-bogus.
I'd love to hear the skinny from an experienced developer.
As for Scheme, that is largely a syntax issue too. Scheme, and Lisp, were great when they were first invented - "hey, look at these cool new linked-lists, let's build a language around them", but we have moved on from there. Scheme's syntax is designed for computers, not people.
You may not have used all three languages, but I have. Try out Python, you will see my point.
--
first off - moderator, kiss my informative ass ;>
python is not a functional language, but it does offer lambda, filter, reduce, list comprehensions, and python's functions are first class objects. there is also a good chance that it will offer continuations in a future version as well. python can also construct and execute code on the fly, as well as offering support for "deep lexicals" at the syntactic level.
as far as metaprogramming goes, it offers better support than OO language i know of that has a modern grammer. http://www.python.org/doc/essays/metaclasses/
python is great mix of OO with a dash of functional programming and metaprogramming power.
who wants macros. have you ever worked with MFC - gag!
the only part of python that is similar to perl is the excellent regexp library. and since perl got it right, why not adopt it?
jim