Python 2.0 beta 1 released 87
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 ."
Re:Seriously, Though... (Score:1)
As to being closer to the language specification I'd say go with 1.6 for the moment. If 1.6 runs your code, 2.0 will too.
Re:the diff (Score:2)
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 ++
Re:the diff (Score:1)
Actually, as far as resources go, I've heard a few nasty tales lately about BeOpen's (PythonLabs's parent) financial and executive problems. I hope it's nothing that will affect Guido and the team, or that if it is, maybe ActiveState can step in and help, as I've always been impressed by their work. (Not that I'm rooting for ActiveState over BeOpen -- I'm happy with anyone that can give the Python team a good home.)
Just to clear up a couple of things from your otherwise good post, the unicode support and the new regular expression parser are already in 1.6. (And yeah, I like the new list comprehensions for 2.0, too. :) )
Cheers,
Nah, just give it some time (Score:1)
Soon, if not already, Guido's planning to start work on Python 3000, which is going to be a complete rewrite of Python, which won't be backwards compatible with the 1.x series. Well, at least this is what the plan was according to a roadmap at python.org which I can no longer find, so I don't know if this is still the plan or when it's supposed to be released.
Then again, they might be reworking the name, because when I did a search for "Python 3000", it turns out that it's also the name of an auto security system [autopreservers.com] from some Ohio outfit named "Auto Preservers." ;)
Cheers,
Re:Why do we see so little of Python? (Score:1)
Unless you work at screwing the pooch.
(PS: Python is also used at ILM, for high-grade rapid development. )
"And they said onto the Lord.. How the hell did you do THAT?!"
Because Python can't do this: (Score:1)
from os import *
direc = '/'g = listdir(direc)
testf = g[14]print g[14]
f=open(testf, 'r')Python can't seem to do this. Unfortunately, that is a major drawback since most other major languages CAN do that. What is "that"? "That" is having a variable as a filename. What I tried to do there was to insert text extracted from a directory listing into a variable which could be opened and read. That's all. But the software doesn't seem to be able to do it. I've read through a lot of the documentation and I can't find anything about the ability to do this. I think more people should be aware of the limitations of Python before they attempt to use it.
Re:Why do we see so little of Python? (Score:3)
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.
Oh.. (Score:1)
Sorry, I didn't realize that only people who developed seriously complex software systems were allowed to use this software.
Re:forget perl vs python (Score:1)
Re:Why do we see so little of Python? (Score:1)
Why? Well, you sit someone familiar with either C or shell script (like me) down in front of two moderately complicated Perl or Python programs, and see which one they figure out first. Is that a fair test? No. Is that a test that goes on every day? Yes.
But I wasn't going to ask you that question, because syntax flamewars are meaningless. Also, judging from the Python code you have on your website, well, it looks a lot like perl code, without some braces and semicolons, and if that isn't a trivial syntax issue, then I don't know what is.
You're right that Scheme's syntax is particularly easy to parse, but it isn't just about linked-lists. Built-in linked-list support is *very* handy, and Perl offers something about as powerful with its arrays; I gather Python does as well. Also, as another poster mentioned, lexically-scoped variables and closures are also potentially very handy, and this can be done in Perl as well. (by passing and returning references to anonymous subroutines and by using 'my' variables; Perl also has dynamic scoping if you need it, but you probably don't want to do that...)
It sounds like you like Python, but it doesn't sound like you've *really* used all three languages. Or rather, you seem to appreciate syntax over language features. If this is the case, then try out BASIC, and you will see my point.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Eh? (Score:2)
Re:Why do we see so little of Python? (Score:2)
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.
Re:Why do we see so little of Python? (Score:1)
I tend to use "my", and parse "@_", but like I said before, you can always pass a single reference as an argument, or use a reference to a hash essentially to pass around a namespace...
Perl does ask for more explicit information about everything, yes, and a friend of mine told me that there is a pretty fast third-party Perl compiler that his company uses internally, (so of course I haven't gotten to see it myself...
Also, the PerlC stuff makes it really easy to just import and use headers and libraries like native Perl stuff, I think that's the real feature there. They do make it harder to implement C extensions, but again most of the time you probably don't need to do that, and CPAN has more than enough modules for doing everything else...
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Because Python can't do this: (Score:1)
There's no bug in the system (if by system you mean Python). There are multiple postings pointing out that
It's worth remembering that on the overwhelming majority of occasions, when you think you've found a bug in the language/compiler/whatever, you just don't understand your program well enough (Kernighan and Pike say this in the chapter on Debugging [bell-labs.com] in The Practice of Programming).
(Now everyone will reply with anecdotes about finding compiler bugs...)
Re:Why do we see so little of Python? (Score:1)
I agree that it's kind of cool that you can do that in Perl. OTOH, I have mixed feelings about being able to add arbitrary syntax like this. I've seen operator overloading abused far more often than I've seen it used at all reasonably, causing no end of headaches for people who have to work with code written using it, and this capability seems like operator overloading on steroids. I know Schemers love the feel of creating a language specific to each problem, but my experience out here in the Real World tells me that's an express ticket to Trouble.
I'm also still curious about whether this facility can be used to create a real exception mechanism - one that has finally and rethrow, that doesn't succumb to creepy scope problems, etc. I'm a little skeptical, actually, and decent exception handling is something I believe should be part of any modern programming language.
That's putting it politely. I've been critical of Perl, but that's nothing compared to how I feel about Tcl. Tk is great, I use it a lot via Python's native Tkinter interface, so I get to read a fair amount of documentation written for Tcl users, and none of it has made me think better of the language. Perl may be a mistake, but Tcl is a true crime against reason.
Being able to compile Perl into C is definitely cool. Python's equivalent is "freeze" which does some magic to collect all of the modules you need plus a runtime and bundle them into an executable. I've never tried it, so I don't know how well it works; from time to time I've wondered how it handles things like eval and exec, and it seems like certain forms of dynamic behavior would be almost impossible to support.
That said, it's just not the same as being able to create a true dynamically loadable extension module which can define its own types etc. and be loaded into a running language-interpreter instance. For example, it can be very handy to choose at runtime which module you load to perform a function, or fall back from one to another if the first isn't found, etc. Being able to unload/reload an extension module on the fly is really cool for debugging, too. It sort of looks like Perl supports a lot of this to some degree, but it's not 100% clear and it certainly doesn't seem to make it anywhere near as easy as Python does.
I guess the long and the short of it is that I don't see any reason whatsoever for anyone ever to switch from Python to Perl. You probably don't see any reason whatsoever to switch from Perl to Python; fair 'nuff. The real question is whether a case has been made for recommending either one over the other to someone who currently knows neither. I'd say the balance still tips toward Python.
Pros for Python:
Pros for Perl:
About even:
The scorecard's far from complete, but the points in Python's favor seem both stronger and more numerous. What else can you suggest to even things up?
Re:Why do we see so little of Python? (Score:1)
I'm not even a huge Perl advocate, but I learned it for my job and thought it was pretty handy, especially for getting the job done quickly. I revamped a script to add accounts, and integrated a domain registration system with a credit card processing system; (the first was written in Perl; the second had a Perl API interface, and I found a credit-card module for another processing system that was also already in Perl...) I'm sure there's a lot of Python code out there too, but Perl is quickly becoming a favored language for CGI interactions. On the server side, there's also PHP and Java now, and PHP also looks a lot like Perl (and probably like Python too...).
I haven't played with Perl's Object system much, but I know it has one, so I can't really compare those two; it seems to work pretty well, though.
I'd argue over the syntax being more familiar to CS types, because I consider myself to be one, and I never learned awk, either, but Python syntax doesn't look incomprehensible. But this is such a matter of taste that I'd fear to mention it, because syntax flamewars really are useless.
I think "my" is a feature, I just wish it was the default. However, Perl defaults to something simple for the novice--making variables global. Many other languages default to something similar. However, there's nothing wrong with telling a programmer to declare all (or almost all) of their variables with 'my' as a good programming practice; if they really want dynamic scope, they can use 'local', but they probably don't. I don't mind when Perl gives me a few options; actually, I like it. If I'm feeling Scheme-ish, I can use lexical scope and recursion; if I'm just quickly hacking, I can use global variables, iteration, and implicit looping (command-line switches for text filters...) and stuff. I'm sure you could hack a version of 'use strict' that enforces whatever particular programming paradigm you like better, (it favors 'my' variables in modules, incidentally) but that's a decision that I'd rather leave up to the programmer.
Perl can also compile to an intermediate byte-code form, and generally a well-written Perl program performs at a minimum as fast as your average interpreted language, and in a best case faster than C, (using nifty built-in data types and whatnot) but generally somewhere in between.
Incidentally, writing a simple C program is generally fastest, although there are a few instances where the C++/STL solution is faster. (the STL is incredibly well implemented on g++) Most interpreted procedural languages are generally about 10x slower, and most shell scripting languages are generally 10x slower than that, (100x slower than C!) but for some problems, certain interpreters pull ahead of the pack.
For instance, Python (and many functional languages) have a built-in arbitrary-precision number capability that is pretty well implemented. Perl has a module for this, but it is pretty slow; I think there's a faster one available, too. I know there are libraries to do this in C (like gmp), but they aren't necessarily there by default.
Not only is Perl extremely portable, and indeed already ported just about everywhere, but since it can generate code for itself in Bytecode and C, it's even more portable and flexible. (assuming you can compile the resultant C code...)
AFAIK, both Perl and Python use reference-counting garbage collectors; I know that there are a lot of great features slated for the *next* versions of Perl, and one of them on the drawing board is a real garbage collector; but that's probably on the TODO for the Python people as well.
Actually, I think the two are pretty even. Although I think Perl supports traditional functional programming better, I doubt many people would do it in Perl. (although I might try my hand at either writing a Scheme interpreter in Perl, or yet another Nth generation language; I'm silently debating to myself over syntax-parsing and data-type handling at the moment.) I agree that Python has a sparse looking syntax, but I'm not convinced that I like it yet, and therefore that's a style issue. Also, Perl is great for speeding up old shell scripts and migrating from sed or awk, and provides wonderful modules for CGI and database integration. I suppose Python has its own modules for this, but I like writing web pages in Perl better than writing them in HTML, and that's saying something, since I'd never use an "HTML Editor", either.
On the other hand, I think Python might make a good stepping-stone for people coming from a more academic, functional-programming background, and ultimately want to learn, say, Java. Although Perl has closer syntax, Python has some of the comforts of home, and has built-in exception handling. But ultimately, I guess it depends on what you want in a language, in the first place.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Why do we see so little of Python? (Score:1)
Well, exceptions encompass a lot more than true errors - resource unavailability, deliberately aborted waits, etc. etc. In a large program, where the function that recognizes a condition may be several calls removed from the topmost function that needs to know about it, propagating status codes all the time gets real old, real fast. Exceptions provide a way to streamline the whole process quite nicely.
IIRC, Java's exception model was fairly reasonable but the common usage of exceptions was somewhat less so. Like anything, exceptions can be abused or used wrongly, so you need to be careful to distinguish the usage from the model.
Well, the simplest scope of all is no local variables at all. Everything's global. You could even do away with function arguments as such; if you want to pass parameters to foo() you just assign to foo_x, foo_y, etc. before you call it and the return value is in foo_result. Or you could use a register-like model.
Obviously, simplest isn't necessarily best here, even though in general simplicity is a virtue. The question is which model provides the best balance between expressiveness, intuition, flexibility, etc. Personally, I think it's safer to have things be local by default to avoid unintended name clashes than to have them be global by default. Those kind of bugs tend to be really nasty to track down, and having too much stuff global makes them all but inevitable.
Historically yes, but that's one of the biggest changes for Python 2.0. Extension writers still have to manipulate refcounts, but Python itself can apparently figure out that if all of the references to objects in a set are satisfied by other objects also in that set then the whole set must be disconnected from anything else and can be GC'ed. That's about as good as you're going to get in such a thoroughly extensible language, I think.
Does Perl have modules specifically geared toward language processing? I'm quite sure Python does.
You bet. Some of the very biggest web players use Python rather than Perl for this kind of stuff, and I've yet to hear of a serious Perl equivalent to Zope. Check out the Vaults of Parnassus sometime; even compared to CPAN, the variety of modules represented there is pretty impressive.
Re:Why do we see so little of Python? (Score:1)
I'm sure Perl has modules geared towards language processing, and I might even look it up; but for some reason, I have a desire to implement that part myself at a lower level, as well. Maybe by learning lex better, for starters...
Another site I found that looks pretty useful for Perl info is "perldoc.com"; it looks like most of the 'new, bolted-on' features of perl started in 1993, with the development of Perl 5; they're debating about what'll go into Perl 6 now...
...And I like the mythology reference.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:forget perl vs python (Score:1)
"Gratuitous guesswork"? There is no gratuitous guesswork in Python's scoping rules. They are perfectly well-defined, simple, and easy to understand.
I agree that it would be better if all variables had to be declared before being assigned to. Not enforcing this causes bugs due to typos that would otherwise be immediately discovered by the interpreter. But Python is far from the only language with this flaw. Most dialects of Lisp (not including Scheme) and Perl also suffer from this problem (although with Perl I suppose there is a way of running in a paranoid mode that will give you warnings about this type of problem).
Regarding functions picking up their enclosing lexical variables, this would certainly also be nice, but is really not much more than a nicety. Almost anytime you would need a closure, you can do the same thing just as easily using object instance variables or default arguments to functions. Sometimes this requires a bit more typing, but that's the only downside. (And, in fact, by using default arguments, you get an explicity list of the variables that a function is importing from an enclosing scope, and this can often increase the clarity of the code.) On this issue, Python made the trade-off of being more efficient and portable. Implementing closures requires having a real garbage collector, and in the ability to copy stack frames to the heap, which has significant portability and efficiency ramifications. Despite this, full lexical scoping and true garbage collection are on the slate for future versions of Python. How this can be done without damaging Python's efficiency and portability remains to be seen.
I'm not saying that I have no complaints with Python -- I, in fact, have many. But I have used a lot of languages and I have many complaints with all of them. I have far fewer complaints with Python that with any other language I have yet used.
Re:forget perl vs python (Score:1)
had to be declared before being assigned to. Not
enforcing this causes bugs due to typos that would
otherwise be immediately discovered by the
interpreter. But Python is far from the only
language with this flaw. Most dialects of Lisp (not
including Scheme) and Perl also suffer from this
problem
Most Lisp compilers tell you about undeclared variables.
? (defun foo (baz) bar)
;Compiler warnings :
; Undeclared free variable BAR, in FOO.
; Unused lexical variable BAZ, in FOO.
Regarding functions picking up their enclosing
lexical variables, this would certainly also
be nice, but is really not much more than a
nicety.
Sure not. It is one of the essences of
Functional Programming.
Despite this, full lexical scoping and true
garbage collection are on the slate for future
versions of Python. How this can be done
without damaging Python's efficiency and
portability remains to be seen.
Funny, Python's efficiency (without native code
compilers
GC literature you see that reference counting
is considered not to be the memory management
algorithm of choice (besides some special uses).
*Real* GCs are considered more efficient. Reference
Counting originally has been developed for Lisp
in 1960. Nowadays almost no Lisp uses reference
counting anymore - go figure. Reference
counting does not deal with cycles, etc.
Well, lexical scoping... I think it helps
to read the original articles on Scheme and
one might understand why all modern Lisps
(ANSI Common Lisp, Dylan, EuLisp, Scheme,
ISLisp,
I guess, after some design iterations Python
will look like a blend between Haskell and Lisp.
;-)
Re:forget perl vs python (Score:1)
> undeclared variables.
Perhaps you are correct -- I haven't programmed professionally in Lisp for 16 years. But back then Lisp certainly did not typically warn against assignment to a variable that had not first been declared.
> Surely not. It is one of the essences of
> Functional Programming.
But Python isn't a functional programming language. Sure, it borrows many nice features from Lisp, but it encourages a somewhat different programming style. In Python, full lexical scoping would only be a nicety. Adding it would not greatly enhance the Python programming experience. For instance, Python lists work differently than Lisp or Haskell lists. They are very good at what they do, but they are not really ideal for functional or recursive programming styles.
> Funny, Python's efficiency (without native code
> compilers
> GC literature you see that reference counting
> is considered not to be the memory management
> algorithm of choice (besides some special uses).
And to some extent, Python has proved the literature wrong. Python's reference-counting GC is one of the reasons that Python is extremely portable and consequently very popular. It is very difficult to make an efficient and portable non-reference-counting garbage collector. Python took the choice of practicality, rather than being theoretically optimal. I mysself was pretty dubious when I heard that Python used a ref-counting GC, but it won me over.
For instance, with a ref-counting GC, the life-time of objects is well-defined, and consequently, object destructors become very useful things. Constrast this with Java where destructors are basically useless. Furthermore, it turns out that cycles are not much of a problem to deal with. They don't occur all that often, and when they do, they can usually be easily and automatically broken in destructors.
I think that Python has shown (since well-defined destructor behavior is so useful) that GC'ed languages should have ref-counted garbage collectors as their main garbage collectors, and then have a full garbage collector as a backup to get rid of objects with cycles. This is, in fact, what Python 2.0 does. It provides a true backup GC that can be optionally turned on, if you need it.
|>oug
P.S. I'm not sure that you are correct about no Lisp using reference-counting. The last time I looked at GC literature, there were some that used a "one, two, many" reference-count for dealing with short-lived objects. Perhaps my knowledge on this, however, is also out of date.
Re:forget perl vs python (Score:1)
Well, 16 years is some time, isn't it?
> It is very difficult to make an efficient and portable non-reference-counting garbage collector.
I'd say, that the performance of Python is so "bad" (it's not native compiled and VM based), that a reference counting memory management can't make it much worse. Still for a lot of tasks the performance may look good enough. This changes if more of the code stops using built-in mechanisms, but instead relies on user code. The built-in code is written in C and usually several times more efficient, than the Python code, which runs on the VM. This can also be seen in VM-based Common Lisp implementations.
Reference counting has advantages. But it also has severe drawbacks. For a discussion of these issues see the book "Garbage Collection, Algorithms for Automatic Dynamic Memory Management" from Richard Jones and Rafael Lins. See also:
http://www.xanalys.com/software_tools/mm/glossa
> that GC'ed languages should have ref-counted garbage collectors as their main garbage collectors
I hope not. Lisp and Smalltalk systems nowadays have much more sophisticated GCs. The Lisp I'm using on the Mac has a Incremental Generational Ephemeral
Re:forget perl vs python (Score:1)
>> non-reference-counting garbage collector.
> I'd say, that the performance of Python is so "bad" (it's not native
> compiled and VM based), that a reference counting memory management
> can't make it much worse.
Before claiming that the performance of Python is "bad", you have to
understand its niche. Its primary niche is as a scripting language.
As such, it has to be very portable and small. It has to start up
quickly. It can't have a separate compilation stage. Lisp failed in
this niche because all of the implementations were either too bloated,
weren't portable, started up too slowly, or didn't have the built-in
facilities to make scripting easy to do. As far as scripting
languages go, Python is faster than any other I've seen in common use,
other than Perl.
Back in the day, all the Lisp folk at MIT decided that to popularize
Lisp they would make special hardware that would run Lisp really
quick. I told them that they would never popularize Lisp using this
strategy -- that if they wanted to spread the word, they had to make a
small, fast, useful Lisp that would run well on typical hardware and
would have built-in facilities to easily get to the OS. Of course
they didn't listen to me. If they had, perhaps Lisp would now be a
mainstream language, and I would be very happy. A bit more recently,
MIT Scheme and the Scheme Shell tried to provide a small portable Lisp
for the masses, but the last time I looked, both started up slowly,
weren't object-oriented, and were still pretty bloated.
Guido, when he invented Python, got all these things right. Part of
getting these things right was in making the appropriate trade-offs.
Python will run on Palm Pilot. It will run on Windows CE palmtops.
It runs on nearly every platform known to man, and is easy to port to
any new platform that might come along. This is one of the reasons
why it has succeeded. Part of accomplishing this was going with a GC
technology that was known to work well, and could satisfy the
requirements for being small and portable. Unfortunately, Lisp
implementations were hobbled in achieving this goal in part by
requiring a more complicated, less portable garbage collector.
Python is not a language that was intended for all programming tasks.
It was designed to fill several niches where ease of programming is
more important than efficiency: scripting, RAD prototyping, GUI
development system, gluing components. In all of these niches,
efficiency is not terribly important, as long as the language doesn't
consume many resources and add annoying pauses. For scripting, GUI,
and glue, most of the time is spent doing other things -- not
executing the user code, so the user code does not need to run
terribly quickly. For RAD prototyping, Python was designed so that
Python modules can be easily replaced with modules implemented in
other languages. In this manner, bottlenecks can be determined
through profiling, and then the bottlenecks can be reimplemented in a
more efficient language. More efficient languages (like C or C++, for
instance) are more difficult and slower to program in, so the
prototyping stage can be very useful. Often, only speed-critical
sections of the code will need to be replaced, since not much time
will be spent in other modules, and the total development time will be
significantly less. Also, in many cases the problem and the solution
is not fully understood until a prototype is developed, and
consequently implementing a prototype in a RAD language is a very
useful and time-saving project.
Python is also perhaps not ideally suited for very large programming
projects, where a statically typed language is very useful in
automatically and quickly detecting certain sorts of common bugs.
> Reference counting has advantages. But it also has severe
> drawbacks. For a discussion of these issues see the book "Garbage
> Collection, Algorithms for Automatic Dynamic Memory Management" from
> Richard Jones and Rafael Lins.
> See also:
> http://www.xanalys.com/software_tools/mm/glossary
Thanks for the pointers.
>> GC'ed languages should have ref-counted garbage collectors as their
>> main garbage collectors
> I hope not. Lisp and Smalltalk systems nowadays have much more
> sophisticated GCs.
Perhaps, but by not using a ref-counted garbage collector, you have
given up the ability to have useful destructors. In my mind,
expressive power is more important than anything else -- especially in
a RAD or scripting language, and destructors are very expressive.
> The Lisp I'm using on the Mac has a Incremental Generational
> Ephemeral
> after short lived objects in RAM (and uses the MMU to find changed
> pages) and runs almost unnoticably.
The Python GC runs completely unnoticably.
|>oug
Re:Because Python can't do this: (Score:2)
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=="/".
Re:Because Python can't do this: (Score:1)
Bzzt. Wrong.
Try prepending the path of the directory you told it to list to the filename you're telling it to open. You're listing / and then trying to open a filename from there in the current directory. Not surprisingly, this fails.
Top tip: don't use from foo import *, it can lead to name collisions.
Re:Why do we see so little of Python? (Score:2)
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 [ncsu.edu].
open requires full path (Score:1)
it would incorrect for "open" to make assumptions about where the file is.
jim
Re:Because Python can't do this: (Score:1)
Well, thanks for the advice, but I don't think you understand what I'm doing. (BTW, please note, I just downloaded this system today, when I read the Slashdot article about Python 1.6 being released)!!
Ok, this is what I'm doing:>>> from os import listdir
>>> direc = '/python20'
Ok....no problem there. Now, the next step:>>> g = listdir(direc)
Seemingly easy! (I thought to myself, hmmmm. Quite a nice language). Next:>>> g[18]
'xyzzy.py'So, now we've got g[18].
>>> testv = g[18]
Aha! Perfect. Next:>>>f=open(testv,'r')
Errrr:/ Darn, this is embarrassing. I was typing in the program as I was writing this post to show you (and the other 2 people that posted) that it didn't work, but it seems to now. But it didn't - a while back. But anyway. Oh well.Re:Why do we see so little of Python? (Score:1)
Secondly, the keywords unless, and until are great. Lastly, if/unless blah, etc. and other natural constructs also make my programming day a lot easier, and improve readability as well.
Re:Because Python can't do this: (Score:2)
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.
Re:Seriously, Though... (Score:1)
Re:Because Python can't do this: (Score:1)
Re:Why do we see so little of Python? (Score:1)
Sanity suggests, in #61 [slashdot.org]:
pb replies, in #107 [slashdot.org]:
I disagree. I think it's a very fair test. Unless you want to argue that there's absolutely no correlation between readability of code to one familiar with a language and one unfamiliar with it - be my guest - readable code is pretty much readable code. Sitting a language-novice in front of typical pieces of code written in the two languages may not be a perfect test, but it's not a totally useless one either.
One particularly interesting form of unreadable code is code which is easily mistaken at first glance for other code which does something either subtly or drastically different. This is a particular kind of unreadability for which Perl is justly notorious, and which Python generally avoids (though it falls down on the job sometimes too). You're right that a lot of what goes on in language wars is just noise, but some aspects of a language's syntax and semantics do have quantifiable effects on the maintenance cost of programs written in that language.
I only found one script on the site, and I think its similarity to Perl code is more related to the problem domain - web page creation - than with the languages. If you want a better example of doing things reasonably well in Python that would get incredibly ugly in Perl, look at the Traveling Salesman Playground on my web site. Alternatively, you could just pick some code at random from CPAN and Parnassus. Only a blind man or a zealot would fail to see that a random Python program can be grokked more readily than a random Perl program, regardless of experience level.
That's a pretty darned rude assumption, especially since Sanity had explicitly stated that "You may not have used all three languages, but I have." in #61 to which you were replying. I don't think you have any right to gainsay him on that.
That's just rudeness for its own sake. I see nothing in Sanity's comments to justify your statement, or your gratuitous mention of BASIC to demean your opponent.
I picked Python over Perl years ago. However, if I were to make the choice today based on the behavior of each's proponents in this discussion I'd make it the same way. Someone else said something about Perl's lower "barriers to entry" resulting in a high percentage of its advocates being inexperienced and immature programmers. I think that's exactly right, except that the inexperience applies to advocacy as well as coding styles.
Re:Perl? Python? Well, maybe.... (Score:1)
The familiar is always easier to understand than the unfamiliar. That's an obvious, well known, and basically meaningless fact. What's more interesting is what happens when that effect is factored out, i.e. when someone is presented with two things that are equally familiar or unfamiliar. In such "apples to apples" comparisons, languages well-grounded in studies of programmer productivity (e.g. Python) will always win out over languages that just kinda grew over time (e.g. Perl).
If you would dispute that characterization of the two language's heritage and origins, just ask Guido and Larry, or read the histories that are available online.
Re:Why do we see so little of Python? (Score:1)
Re:forget perl vs python (Score:1)
Re:Why do we see so little of Python? (Score:1)
No, I did not. I said nothing of the sort. Please learn to read before you post.
Release speed (Score:3)
----
Remove the rocks from my head to send email
Re:Hate-Based Cultures Die Out (Score:1)
In today's news (Score:3)
Silicon Valley has developed a new technique to speed software development. Time travel. According to reports Python 1.7 is still due Mid December
and I just downloaded 1.6 (Score:1)
Founder's Camp [founderscamp.com]
Re:Why do we see so little of Python? (Score:1)
The test I was talking about has a slight difference; anyone with a C or shell script background would surely find Perl a more comfortable language. But I disregard this, because I'd rather hear about language features, and I don't consider Python 'syntax' a feature. It looks like Perl, but the braces and semicolons are gone, and it doesn't allow some other stuff. Ooo. I don't care.
Also, yes, you can write line noise in Perl. But you can also write clean code in Perl. It's your choice. The same is true for C. I don't necessarily *want* a language that ties my hands based on what the *implementors* thought was good and right and just; I might occasionally have a reason for what I want to do. I know someone who would love to have an actual goto statement in Java, for instance; and he has a very sane reason for it. If you don't believe in gotos either, well, I don't want to talk to you, either. My point is, there's nothing wrong with letting the programmer do more. If they don't want to do it, they won't; if they need to, they can. This goes for syntax *and* features, and sometimes the one gets in the way of the other.
My comments were based on his emphasis of syntax over features, even after I explicitly asked him to discuss language features. I think these are an important part of any language, because if a given feature is not supported, no amount of syntax will help you. If, after my request, he told me about the superior features Python had instead of demeaning Perl and Scheme, (with no real facts, just stylistic opinions, I might add!) I might have been kinder as well.
I mentioned BASIC not out of rudeness, but merely because it is a great example of a language with clean syntax and bare functionality.
I'd love to know more about Python, but if this is your idea of Python advocacy, I don't want it. There are friendlier communities of programmers out there, who would be happy to tell me about the language features and think that is important. At least you mentioned an example program that might be easier in Python; that interests me. The syntax flame-wars do not; I saw all that in the big Pascal/C flamewar back in the day. (I was sympathetic to the Pascal side, because Turbo Pascal 7 was dominant at the time, and it really did have all the features you'd want from C, except perhaps the 'unsigned longint' type, and maybe the C-style 'switch' statement; therefore, it was just another stupid syntax flamewar)
Anyone who wants to program in a structured way can; they can learn that discipline by having their compiler/interpreter shout at them, or by doing it themselves. I probably learned a lot of structure by moving from BASIC to Pascal; but I learned a lot more about power and simplicity by moving to C. I'd much rather see the discipline imposed by the programmer and not the language, but yes, that has to be learned somewhere along the way.
...and the advocacy bit was a cheap shot, and you didn't help your case any by calling me rude and quoting me out of context. Read my post again and apologize, or just reply to this one and tell me what features make Python a better language. I don't want to debate style with you. REALLY.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Why do we see so little of Python? (Score:1)
I think that could be interpreted as being against low barriers to entry, but in any case, you can't get my quotes right either, so I wouldn't flame anyone else for it if I were you...
Also, I haven't 'picked' Python or Perl; I just don't know Python. But you haven't been terribly supportive, encouraging, or informative about it, so I think I like the Perl community better, so far. Of course, choosing a Language based on the behavior of its programmers is somewhat silly, but I did that with my Operating System as well.
In my experience, BSD Zealots tend to be rude and insufferable, while Linux Zealots are generally just enthusiastic. From this thread, it looks like Python Zealots are equally obnoxious due to their marginalized presence; perhaps they just feel persecuted.
This is just a generalization; I know there are some very polite and interesting BSD and Python users out there; but they can't seem to find their way to Slashdot, or are drowned out by whoever shouts the loudest.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Eh? (Score:1)
the diff (Score:4)
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
The reason Python is better than Perl and Scheme.. (Score:1)
I mean think about it for a second. If Joe Layman (or Laywoman... I'd like to lay a woman, but wait, I digress...) finds out your a programmer and you say you write in Perl, it doesn't sound manly. Say you code in Scheme, and that just makes you sound like a Schemer (ho ho, how we laughed...). Tell them you program in Python and they can visualize a huge manly snake... Or something.
Erm... What was I saying again?...
---
Re:Why do we see so little of Python? (Score:1)
Google uses python for their crawlers.
Crystal Space uses python for their Crystal Space 3D Engine
RealNetworks uses python.
MCI Worldcom internal frame relay configuratin and provision suite uses python.
Caligari Corporation uses python for truespace. you know the 3d modeling and animiation tool?
IBM east fiskill uses python, they use it to create business practice logic for factory tool control applications. Used at the Micrus semiconductor plant in East Fishkill.
Have you heard of HKS? They guys who created ABAQUS/CAE? all mech engineering have. They have incorporated python into their finite element analysis program.
The freaks at LANL are using python to control large-scale physics codes on massively parallel supercomputers, yada yada yada.
The ISDN BRI OA&M group at Nortel uses python as its offical scripting language for CGI applications.
Yahoo uses pythons.
Redhat uses python for its install procedure.
NASA Johnson space center uses python in its integrated planning system as the standard scripting language. Efforts are underway to develop a modular collection of tools for assisting shuttle pre-mission planning and to replace older tools written in PERL and shell dialects. Python will also be installed in the new Mission Control center.
LLNL uses python.
egroups.com is implemented in PURE python.
Infoseek uses python, most of their program is done in python. 11k lines of python code, and user interface in 17,000 lines of python-scripted html templates.
ILU by Xerox lab, the CORBAish OIS supports python.
There are tons of people using python. We don't see little of it, you are just ignorant!
Re:Why do we see so little of Python? (Score:2)
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.
Re:The reason Python is better than Perl and Schem (Score:1)
That has to be the inimitable groucho. Or perhaps he isn't?
Guido's Time Machine (Score:2)
Re:Why do we see so little of Python? (Score:1)
(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.
(2) Python code *tends* to be far more readable, and hence more maintainable. I concede that it is possible to write readable Perl code, but 99% of it that I've seen is not very readable.
(3) I'm a former user of REXX (mostly on OS/2). This is a language that I *really* liked because it was powerful and simple. Since REXX is not readily available to me on the platforms that I use, I now use Python for the same reasons that I used to use REXX. I find that my productivity with scripting languages like REXX and Python to be unsurpassed with any other language.
(4) Python seems to provide more consistency over Perl (and not just syntax/style). I can't recall the specific cases, but Perl tends to have a philosophy of being able to do the same thing many different ways. Python, on the other hand, tends to not have as many choices. For me, this makes Python code more maintainable.
(5) Writing OO code in Python is more natural and cleaner to me than in Perl.
Re:Because Python can't do this: (Score:1)
Hmm... Python doesn't. The reason is that most of the time, you don't use "from package import *", but simply "import package" and use "package.function(...)".
But it still doesn't allow writing from a variable. But I'm not going to comment on that because it's probably some other dumb thing that I've done :|
What is "not writing from a variable" ? Or maybe try on comp.lang.python.
Perl? Python? Well, maybe.... (Score:1)
Re:Perl? Python? Well, maybe.... (Score:1)
Of course they both grew over time, you idiot. All software does. The difference is whether something ever went through an actual design phase before being "released into the wild" or whether all of its evolution has been guided by momentary expediency. It's a little bit of an oversimplification, but not much, to say that Python was designed while Perl just kind of wandered according to Larry Wall's needs at each particular instant.
Interesting Changes... (Score:2)
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...
forget perl vs python (Score:1)
but if...
- you feel trapped with a proprietary or single platform language.
- you like java's OO and libraries but miss the syntactic expressiveness of functional languages or meta programming.
- you like vb's ease of use (try pythonwin by mark hammond - code completion, integrated interpreter window for tweaking variables and expressions on the fly)
- you like opengl/3D (pyopengl, blender, and truespace all use python)
- you think having one draw api and multiple backends is cool (such as illustrator, pdf, postscript, opengl, various widgets,
- you need software engineering constructs in a rapid application package like: asserts, easy testing at package level (all packages are runnable externally or in a self test mode), full introspection, built in documentation that is also available via introspection, the debugging power of being able to intercept any method call before it happens, or the rapid feedback of transparent bytecode compliation.
then, maybe python is for you.
what you will NOT find in python (that i know of):
- support for a transactional container like mts / EJB. there are libraries for talking to COM and CORBA. you will have to rely on a database or bridge to another system for transactional applications at the object level.
- blazing speed. you can create python objects in 'c' for this.
wishing i had a paying python job,
jim
Re:Perl? Python? Well, maybe.... (Score:1)
Re:Man in the street? (Score:2)
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. ;-)
Re:Python & XML support (Score:1)
Also there's a report from XML.com on an paper presented at XML'99 [xml.com]
There's an active XML SIG, with a page on Python org [python.org].
Re:Why do we see so little of Python? (Score:2)
(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...?
Python is Love, not Hate (Score:1)
Re:Perl is the Windows of programming languages (Score:1)
Re:Why do we see so little of Python? (Score:1)
Being more specific about how Python is superior is exactly equivalent to being more specific about how Perl is inferior, and yet that seems to be what you're whining about. Thanks for the attempted double bind, but I'll pass. Instead, what I'll do, and what I've already done, is try to steer you toward the information that will let you make your own informed choice about which language is better. Here (again) is a link to the Python tutorial [python.org]. It really does a better job of "hitting the highlights" than I can here. Go through as much or as little of it as you feel you need. For your convenience, though, I'd recommend some of the following sections as particularly relevant or potentially indicative of differences between Python and Perl:
There's also a separate document about extending and embedding Python [python.org], which I think is one of the best things about the language.
I hope you enjoy and learn from these sources of information. If you need more, somebody else has already pointed out that comp.lang.python is very newbie-friendly and full of helpful folks. It's true.
Re:Why do we see so little of Python? (Score:1)
Thanks for the links, I might check it out some more, later. However, I don't see anything incredibly new and different as compared to Perl; I guess liking the syntax better *is* the reason to use Python, because the featureset looks relatively similar.
(I like the built-in set support, but the __main__ stuff looks like a nasty hold-over from C; so far, this is all looking like another useless flame-war over two languages of very similar functionality and very different weird syntactical limitations...)
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Why do we see so little of Python? (Score:1)
Or... start debating programming language freatures. Not syntax; not grammar; not debating.
Is that so hard to understand?
If you like, you can read the *entire* series of posts yourself, and make your own conclusions, instead of picking one of them apart, out of context.
For instance:
Whether or not this is true (and I don't suppose you have a shred of proof)
I haven't seen any proof for the syntactic and styliistic "better" claims so far; why should I provide it? I *have* mentioned various different language features, and this has so far gone unnoticed.
That's no excuse for presuming to gainsay him on whether or not he had in fact used the languages in question.
My excuse for that was that he was debating syntax and the usefulness of linked lists, not lexical scope or closures. That is to say, he either managed to use Scheme without even *noticing* the useful features it provides, or didn't mention them in his reply.
You're generalizing from one poster on
Yes. That's how advocacy works. You play nice, and promote your language. Once you start being rude, you lose respect. You can analyze this at your leisure the beginning of this thread.
I don't think it was; I thought it was incredibly stupid, and I think this is too. But if I don't feel that you understood my post, then I will attempt to keep replying until you do.
Now here's the test. All that text before this line, what did it accomplish? Well, not much. So let's try again.
Riddle me this: does Python have lexical scope, closures, useful built-in data-types, familiar syntax, functions, variables, looping constructs, or objects? How does it help you manage a program better than, say, Perl? What does it *not* let you do that you might conceivably want to do, and how ugly are the methods used to get around this?
These are real questions, because I don't know Python. As I've said before, on the surface an average Python program looks like a Perl program without the curly brackets and the semicolons; instead it has labels and indentation and whitespace, which is strange, but still workable. Its arrays look pretty similar on the surface, it has modules and an object system, it appears to have built-in regexps, and it is also an interpreted scripting language.
So PLEASE tell me what I'm missing. To date, this entire flamewar has been completely useless, apparently based on semantics, or perhaps an incomprehensible hatred of the '@' symbol. All the Python code I've seen thus far could be run through a trivial translator to change the notation, and 90% of it would be workable Perl code, requiring little human translation.
So, if you can, tell me what's the big deal, and keep it clean this time. If you can't, well, don't reply again.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
But this has been in the works, right? (Score:1)
(Wow, look, 2.2.17 and 2.4.0-test7; what a jump! NOT!)
The added features are funny, though: C and C++ looking language constructs; tell me when they allow blocks and semicolons instead of whitespace and newlines, and then we'll talk.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Seriously, Though... (Score:2)
I'd love to hear the skinny from an experienced developer.
Re:Why do we see so little of Python? (Score:2)
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.
--
LISP/SCHEME is beautiful... (Score:1)
Re:Why do we see so little of Python? (Score:1)
Welcome to the mudpit. We're all having a good wallow here. ;-)
I guess we need to stop and think about what "knowing the language" means. Is it a Good Thing if "knowing C++" means knowing all sorts of details like constructor/destructor ordering and implicit type conversions, for example? What ever happened to the "principle of least surprise"? IMO, the ideal language would have the characteristic that when you look at a piece of code you either know from a set of very simple rules what it does, or you know immediately that you don't know and you need to find out. A language in which you can often look at a piece of code, think you know what it's doing, and be utterly wrong, is therefore less than ideal. Worse is when even running the code on nine out of ten test cases doesn't reveal that it's working any differently than you thought, but the tenth case takes down your whole application five months after you or anyone else last looked at the code.
If something looks like a function call taking arguments x and y, it should act like a function that takes arguments x and y, even if it is in fact a built-in language feature and not a true function. This precludes acting like a function that takes arguments x, y, and this or $_.
Re:Because Python can't do this: (Score:1)
Well Cedric, thanks for your advice. You've been quite helpful , unlike some of these rude individuals **cough cough** that have posted here today. What they don't realize is that I just downloaded this software earlier today. I first posted about it 30 minutes after installing it and finding the bug in the system.
Re:forget perl vs python (Score:2)
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
Re:Interesting Changes... (Score:2)
Syntactically only (not that syntactic sugar is a bad thing here). If a compiler can't optimize this with at least a refcount elimination, then it's a complete joke. I suspect python's optimizer is able to detect this sort of trivial case.
Re:Hate-Based Cultures Die Out (Score:1)
Many dislike the syntax of Perl. Maybe some of them are forced (by other programmers in the company) to use Perl, who knows ? It's a bit like you are a Java expert and you are forced to code in FORTRAN. And then, some FORTRAN programmers come on Slashdot and keep arguing FORTRAN rules! The unfortunate! It's like putting a bunch of deadly hungry lions in a park with sheeps. Expect terrible massacre.
The perl weenies don't waste their lives hating. You don't see them constantly dissing python.
Well I have the vague impression it works both way.
That really sucks, and is the main reason why I will never switch. I want to live in a culture of support and respect, not one of hate and venting.
Well, too bad you didn't see the Pythonian culture of the experts (Guido, Tim, AMK, and many others....), the Pythonian jokes, and the Monty Python references.
Try it first... (Score:1)
When you import another module, you do have access to that modules variables--they just don't pollute your local namespace unless you explicitly command them to (with "from spam import eggs" version of the import command). All you have to do is refer to them by their proper name: spam.eggs instead of just eggs.
If you really want to use eggs instead you can:
(sucks in all the names from spam)
eggs = spam.eggs
I don't know what you mean by "the writing function doesn't allow you to write strings." You can write pretty much anything you want, including binary.
Python has if/elif/else, for item in sequence, and while expression as forms of flow control. What else do you need? Endif and Wend are superfluous--they just signal the end of the block (Perl and C use }). Python can tell by the level of indentation.
GOTO. Don't need it. Between break, continue, and exception handling all the legitimate uses of GOTO as a flow control are covered (I suppose labelled breaks might be nice, but I haven't really missed them).
I don't understand your complaint about importing other modules as a form of flow control at all. I think you must have just missed the whole idea of functions and classes. What version of BASIC were you using before? Even VB doesn't use simple chaining of source-files for flow control--at least, not anymore.
Re:Interesting Changes... (Score:2)
Re:Why do we see so little of Python? (Score:1)
Before I get started, I invite a Perl advocate to answer the same set of questions for Perl so we can all compare. Any volunteers?
OK, here goes:
Before we go on, I'd also like to touch on two things about Python that you didn't even ask about but that help make it even cooler.
Next question:
I have to admit that it's hard for me to put some of this into words, because it has to do with general philosophy rather than specific features. A lot of what's in Python is there specifically to improve clarity, reduce possibility for error, etc. Sometimes Guido has arguably gone too far, such as with the indentation thing or long-standing (but finally overcome) opposition to augmented assignment, but it's hard to fault him for that. He knows what he's doing, and so do the other decision-makers. Despite quibbles from Perl or Scheme folks who are surprised by anything not Perl or Scheme, Python generally follows the "principle of least surprise" rather well.
The fact that objects are central and not just peripheral to Python is one example of something that has far-reaching but hard to define consequences. The fact that it has had mature module and exception features from the start is similarly helpful, especially in larger programs. Object-persistence stuff like pickle and shelve (yeah, weird names), rudimentary as they may seem, have also proven invaluable to many people. One might say that Perl has caught up in many of these areas, though I personally think it still has a way to go, but catching up is still not the same as doing it right the first time. Legacy code written "before we had X" is a pain.
Damn little. A lot of people have done a lot of very fancy things with Python. There's very little you can't do even if you only use the language in the most straightforward way. If that doesn't work, you can step into meta-object programming and namespace manipulation, which are a little bit tricky but still not "black magic". If that doesn't work you can write an extension module, which again is about as painless as one could reasonably expect it to be. Overall, whatever level you have to go to, it's about as non-ugly as one could hope for. The only time I had to do something really ugly in a Python program was when I had to deal with some issues about default parameters being evaluated at function-definition rather than function-call time.
In a post of this length, I would of course be remiss if I didn't mention some of the things that I think are wrong with Python. Bear in mind, though, that I'm loth to gainsay the language developers' decisions even when I might have done it differently myself. They have done a better job than I would have.
Re:Because Python can't do this: (Score:1)
Basically, Python tries to operate on the principle of least surprise. If you tell it to replace all the local function with the os versions of them, and then invoke the os open function, you shouldn't be too surprised if it behaves the way the native os open function does. You were surprised (this time), but you probably won't run into that again; consider how surprising it would be if it worked the other way around, though: despite explicitly telling the program to always prefer the os versions if available, the program persisted in secretly invoking the builtin version instead?
Re:Why do we see so little of Python? (Score:1)
Its built-in data-types consist of scalars, (which can be numbers, strings, some weird stuff, and references to other stuff...
Perl doesn't have a built-in exception system, but it has prototypes, which basically lets you add syntax to the language; there's a simple example (in Programming In Perl, I think) that adds a try..catch construct to the language.
Objects were definitely added to Perl later; I don't use them very often, and indeed could write it all myself if I had to, (lexical scoping, closures, and tools for adding syntax, right?
Perl does have features for integrating with other languages, and I've compiled Perl programs into C before as well, (it's generally about 30-40% faster, nothing impressive--it compiles too much of the Perl runtime into it still) and it also has a bytecode format, if people want that.
Python might follow the 'principle of least surprise' for someone unfamiliar with programming languages, but Perl looks like a few popular (also ugly?) languages, and might be better for migrating old Unix hackers as needed.
I don't think it'd be too hard to make a pre-processor to do either behavior; actually, I think a language with a flexible front-end tokenizer would be somewhat interesting, provided people always included their modifications in the source, or the program could always convert their code back to "standard" code.
Yeah, the built-in types vs. objects is always interesting; for the record, I don't like how Perl does it. References can be somewhat clumsy, and I'd rather be able to determine which type a scalar *really* is than automatically convert it. At least references know what type they are, though.
Obviously a lot of people don't like Perl syntax, and here are some of my thoughts on the matter:
I didn't like having to use $, @, and % all the time, either; it makes it look like a strict BASIC variant where you'd have to specify $, #, or % for different types. However, once I learned it, I found out two things: Most of the time, you just stick $ in front of a variable, because generally you're just working with scalars. Also, it forces you to think about which types you're using, and that can often be a good thing.
The braces and semicolons are pretty familiar for anyone who has used C and Pascal. With the way I write my code, I don't think I'd want whitespace as a seperator; I'll just use a pretty-printer for that. The other alternative, parentheses... well, a lot of people don't like that either.
There are lots of default arguments to functions in Perl, and they're pretty straightforward, and well-documented. But, that having been said, you don't have to use them. Pass as many useless parameters as you like, it's perfectly legal. But I don't find the way Perl handles default values that confusing, and if I don't know, well, I could always pass a variable to a function like usual, like I probably would if I didn't know that Perl had default values...
Other than that, I think that's about it; the two languages have a lot of similar features. From what I've seen here, it looks like Python has some interesting and powerful ones, but Perl generally has more flexibility, and maybe more of a learning curve, too. (don't ask me, it only took me a couple of days to learn, and a couple of weeks to get pretty comfortable with it...)
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Why do we see so little of Python? (Score:1)
BTW, I should probably point out that this was more my fault than Python's. The default parameters in this particular situation should have been instance variables on a single-method object, and I knew that. I was just being lazy. This actually highlights what I think is one of Python's most endearing features: Python makes it easier to do things the right way than the wrong way. It's eerie sometimes when you realize it, as though GvR is psychic or something, but it's a very real phenomenon noted by many Python programmers. Keep in mind that I still could have kept doing things the ugly and painful way if I had wanted...but why?
I know it will strike many as hyperbole, but I really think that Python makes it possible for below-average programmers to write above-average code. I've seen it happen too often not to believe in this effect, and the best thing is that those skills honed in Python can be transferred to other languages. A Certain Other Language, by contrast, rewards sloppy habits and punishes clean ones, all too often resulting in above-average programmers writing below-average code.
Re:Why do we see so little of Python? (Score:1)
If you have non-local goto (setjmp/longjmp) you can get something pretty close to real exceptions. I've seen many such attempts or approximations, in many languages. They're never quite the same as having exceptions supported directly, but they're usually good enough.
Do you by any chance have a pointer to an API document that describes this?
Au contraire. I'm an old UNIX hacker, and if you think the crap embedded into *sh has anything to do with real programming languages you need your head examined. Bourne, Korn, et al have made many people's lives miserable with their arbitrary and silly quoting, scoping, and argument-passing rules. To anyone familiar with real programming languages, particularly those in the Algol/Pascal/C family, I think Python will seem more familiar than Perl, not less.
I've always found it amazing that Perl users will criticize Python for abusing indentation, then turn around and blithely accept Perl's abuse of variable names.
To built-in functions, you mean. The Perl function-declaration syntax doesn't seem to have a place for default arguments, or in fact for real argument lists at all. In this it is much like *sh and very unlike a real programming language.
Why do we see so little of Python? (Score:1)
Is this flamebait? Oh sorry, I forgot that dissenting thought isn't allowed on Slashdot.
--
Re:Why do we see so little of Python? (Score:1)
Perl supports prototypes [perl.com], which let you control your function argument behavior, and create new syntax. The example I gave with exceptions is actually very clean, with no C-style hackery required.
Otherwise, Perl implicitly takes argument lists; in fact, everything you pass to a non-prototyped function behaves exactly like an array of arguments (sort of like main() in C), and if you don't like that, you can always pass a reference to your own structures. More on all of this in the perlsub documentation [perl.com]. Check it out, it's very flexible as to how it handles function arguments and return values, and prototypes simply extend this further.
I agree that shell looks somewhat backwards compared to Pascal or C, (I never had to use Algol!) but it's a great tool for getting the job done, and that's why Perl is often patterned after it. It's like a shell language with support for everything in C and the standard Unix tools built-in, including the ideas of regexps from grep, the sort from qsort(), and whatnot. However, Perl doesn't have any arbitrary quoting, scoping, and argument-passing rules. It's quite clear on all of these points, and the quoting rules especially are very handy. And from what I've heard here, Python has some interesting scoping rules that aren't lexical or dynamic scope, while Perl supports either one, and more.
As to the variable names, well, I think I covered that point already. It might turn newbies away from Perl, but I think it isn't a bad paradigm to try. It at least makes you think about what type your variable is, which is something you should do anyhow. (In Scheme, you constantly check for it instead, which I also like; in C, well, you'd better remember which one you meant, as well...)
By the way, thanks for the feature debating! You don't have to stop just yet, but I want you to know that I actually find this part of the discussion fascinating, and fun. I was debating to myself just last night about how many details a language should really be allowed to handle, and how much of that a programmer should be able to tweak, and I'm sure there's a compromise in there somewhere. But you can't expect any language to really do the right thing without being too unwieldy to use...
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
They missed their chance... (Score:1)
I don't know what they would have called Python 2.0 if they'd done that, though :-)
Danny- reviews of Programming Python [dannyreviews.com] and Python Essential Reference [dannyreviews.com])
Re:Why do we see so little of Python? (Score:1)
I'm sorry, but...yuk! I mean, really. It doesn't handle finally, or rethrows, or catching some exceptions but not others (except by using an explicit conditional in the catch). The implementation is probably pretty opaque not only to a beginner, but to even a medium-level but casual Perl programmer. The comment alludes to creepy visibility issues regarding $_. That's clean? I'd like to keep this on a positive note, I wish I could say "yeah, that's cool, it's a nifty hack", but I just can't. There's no way I could consider that an adequate substitute for exceptions in Python or most other languages.
The lack of proper argument lists is another thing that bugs me. It probably shouldn't. It's really not so bad if the first line of every function parses the argument list into local variables. Having thought some about how I'd design and implement The Perfect Language, I'm well aware of how much easier that is on the language implementor. Nonetheless, it's something I find hard to stomach. It's one of those "making it easier to write sloppy code than to write neat code" things; people are more likely to use real argument lists than "my" and $_ (ick), and the code will be better for it.
Even though neither is fully compiled or fully interpreted, Perl has more of a compiled-language flavor and Python has more of an interpreted-language flavor. In that context, each language's scope handling makes more sense. Personally I don't much care for "my" and "local" but at least it's better than Tcl's "upvar" (double-plus ugh). As for Python's scope handling, you have to be very careful. The very same things that make it seem a little odd when you allow yourself to forget the rules - lots of Python programmers have bookmarks in Lutz's book where there's a table of what the local and global namespaces will be in various situations - are also critical to meta-programming and a whole grab bag of other nifty tricks. It would be sad to sacrifice those things to make a few CS gradual students happy. Once you grok how scopes and namespaces work, it all makes quite a bit of sense - in some ways more sense than either pure-lexical or pure-dynamic scope.
Re:Why do we see so little of Python? (Score:1)
Oh yeah, I forgot to mention. I looked at some of the stuff on extending Perl using C. It doesn't look anywhere near as clean as doing the same thing in Python, though that may be in part due to the fact that I could only find a reference and not a tutorial. I think that's one area of Python that you should really check out. Adding extension modules in Python is so easy it's almost a bad thing, because you can be tempted into doing things as extension modules that really should be done as plain old Python modules.
Re:Because Python can't do this: (Score:1)
What you want to use is os.chdir.
>>> import os
>>> direct = '/etc'
>>> files = os.listdi>>> os.chdir(direct)
>>> f = open(files[7])
>>> f
So there you have it.