Slashdot Mirror
Guido and Bruce Eckel Discuss Python 3000
Phoe6 writes "Leading author and programmer, Bruce Eckel, posted some of his concerns on Python 3000 stating that the Python community is failing to address some of the important issues with this major, backward incompatible release. Problems he mentions are concurrency support on multi-core CPUs, easy deployment support, and a standardized user interface, amongst others. He expresses his dissatisfaction at the post titled "Python 3K or Python 2.9?. Guido van Rossum addresses the concerns in a very pragmatic way with his response to Bruce Eckel and calls for more developers to contribute to Python to improve it further. Bruce Eckel concludes with his thoughts that he wants his favorite language to be better with his reply to Guido's reply."
I just don't see a reason for this conflict with Guido. Just make a new language, if you want something incompatible, but don't call it Python. Call it Anaconda or something. Or even Garter. Then you can do what you want. If you think you are better than Guido, then get typing, and prove it!
This is my sig.
First link should probably be to http://www.artima.com/forums/flat.jsp?forum=106&thread=214112 .
"Elmo knows where you live!" - The Simpsons
Shouldn't Python 3000 include a giant animated foot and silhouettes of the audience cracking jokes?
Python, meet Haskell and Erlang.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
One thing I don't understand about Eckel's original article is that he says breaking compatibility isn't a big deal, because the programmers who don't want to use the new version will just stay with the old one. How does that work for the users? Do they (a) end up having to pick which version of the language to install on their machine, and lose the ability to run half the world's python software, (b) have to install multiple versions of python on their machine, or (c) ??? Eckel is comparing with Java, but since Java is a compiled language, it's much less of an issue; syntactical changes don't affect the end user who just wants to run the code. How would python handle this? Perl 6, for instance, will automatically detect if the code you're running is perl 5, and will run it correctly in a compatibility mode.
Find free books.
If they really want to help Python, build some online documentation that doesn't suck donkey balls. Seriously, I've never had more trouble learning a language than with Python. I have to go google it, because every site is missing info, so you have to put them all together. Does anyone know of a site with ALL the info, that lists ALL the methods in ALL the classes along with what those methods are expecting? Because I sure as hell could never find anything like that. Learn from PHP guys, the reason PHP took off so fast was because the php.net website kicks royal ass as far as documentation and you can learn it quickly. Just my 2 bits.
My main problem with python 3.0 is the loss of the print statement! I have pestered Guido about it (including booing his talk on python3000 at europython this year) and, he said "well i brought this up last year and nobody seemed to object" and then to me personally "well no other language has a print statement".. I think the dumb simplicity of python's print statement is one of my favourite python things. It makes the language friendly (and I am a pepper-print debugger). As Mr. Hettinger says "you can't break 'hello world!'".
I also think, more generally, that people are in for a world of pain, converting to python 3000. There needs to be tools that are %100 reliable that can convert code from 2.6->3.0. Otherwise, there will just be too much code mass, and it will take a long long time for 3.0 to be accepted. Such a stall is bad news for an OSS project.
Simon.
Why not just call it Python++? Oh, that's right, Python doesn't do that.
You gotta find first gear in your giant robot car
The python mathematics algorithms must have a bug if they're going from version 2.9 to version 3000.
Bruce complained that Python3K is not modular enough. Guido, always the pragmatist, and having just watched Reservoir Dogs, retorted that anyone who wants a modular language should get his head examined.
Some guy on the mailing list proposed a new and better syntax, but Guido declined to merge it; he explained that he doesn't trust the new guy as much as Bob, whose Context-Free Syntax (CFS) is going into the next development version (odd-numbered, of course).
Tsunami -- You can't bring a good wave down!
A lot of what Eckel is saying is basically "Python should be more like other languages" - not because they're better, but because I'm more used to them. Obviously that's totally ridiculous, yet not surprising: If you look at his resume, it seems he's far more familiar with other languages than Python. I seriously doubt his credential - let alone objectiveness - to question Python's design.
Guido is right that Bruce's comments are mostly not core language issues.
But that's also the problem the Python language is fine the way it is; it doesn't need any major overhaul. Before hacking away on P3K, Guido should concentrate on getting things like the UI, the standard libraries, and package management straightened out. Community contributions won't fix those; in fact, community contributions are the source of many of the problems of Python because often, there are multiple, mutually incompatible libraries and tools trying to do the same thing and stepping on each other.
Guido is doing what is fun (hacking the language) instead of what is needed (straightening out the libraries), and that's not the best choice for Python overall.
Probably because the syntactic whitespace "problem" only exists in the heads of people who have never used Python.
Some drink at the fountain of knowledge. Others just gargle.
The right answer is here: http://newlisp.org/
Actually, those aren't the real problems with Python. They're not the ones that keep it from, say, replacing Perl.
Multicore support is a nonissue. CPython is too slow to need it. It's helpful to distinguish between the Python language, which isn't bad, and the CPython implementation, which is a slow, naive intepreter. CPython is about 60x slower than C. Compare Java, which, with modern just-in-time compilers, is about 2-3x slower than C. What's needed is a Python compiler with some smarts. There's Shed Skin, but it doesn't work yet.
One side effect of the speed problem is a tendency to try to write C modules to do things that take significant time. Unfortunately, CPython's interface to C is terrible, bug-prone, and changes with each new release.
The "dynamic language" thing is overdone. CPython is a demonstration of the fact that if you make everything a dictionary, it's easy to implement a dynamic language. It's also a demonstration of "if the only tool you have is a hammer, everything looks like a nail". Too much time is wasted in Python checking to see if something changed that probably didn't change. You can add or change functions or data of a running object or a running function. From outside the object or functionor thread, even! It's cool! It's l33t! It means you can't have an optimizing compiler. (Well, maybe you could, with one that goes to immense lengths to detect when "something funny" is going on and reworks the code on the fly. Won't be easy to implement.) Those features just don't get used that much, except to patch around bugs in the buggy Python libraries. The troubles with the "global interpreter lock" stem from this problem. The "global interpreter lock" is mostly protecting all those dictionaries which define the program. After all, one thread might want to patch the code in another thread.
Years ago, LISP hackers used to talk about how great it was that LISP programs could modify themselves while they were running. Few useful programs ever actually did so. Java has a certain amount of dynamism; you can, if you really have to, create Java code from within a program, compile it, and load it. Few programs need more dynamism than that. The Shed Skin implementation imposes some restrictions on dynamism, and they're on the right track.
Libraries are someone else's problem. Python is better than Perl as a language, but CPAN is better than Python's Cheese Shop. Many key modules aren't part of the main Python distribution and aren't synchronized with it. Examples are the interfaces to databases like MySQL and the interface to SSL. These lag months or years behind the base system. Modules outside the small "core" are not supported in any coherent way. Each is supported by a developer or two, working in isolation. If they lose interest, the module languishes, and nobody else can change it. This sometimes leads to multiple libraries for the same purpose, each with different bugs, and none good enough to obsolete the others.
The overall effect is that if you try to write something complicated in Python, everything goes along just great until you hit some library bug that can't easily be fixed. Or you discover that you need racks of servers to compensate for the painfully slow implementation.
That's why Python hasn't even replaced Perl, over fifteen years into the deployment of Python.
Meanwhile, those of us who use Python in our work will continue to be productive and prosperous, while I guess you can go back to writing your unbelievably boring "blog". What a loser.
Guido is doing what is fun (hacking the language) instead of what is needed (straightening out the libraries), and that's not the best choice for Python overall.
That says, in one line, what I wrote in a much longer post.
For python to be healthy in the future, it needs to cut out all the added syntactic sugar bloating the syntax since 2.2 and substitute it with complex XML support.
Ergonomica Auctorita Illico!
As long as they are going to break things here's my wish list for python. Make it possible for a compiler to compile it. Yes I realize that's essentially impossible for a dynamic language that does not enforce types in the function prototypes.
However, it could be done like this. First recognize that nearly all uses of python do not take any advantage of the dynamic typing, and nearly all calls to functions happen with arguments whose type is not varying. Thus why not have a mechanism, an optional one, that could hint at the expected typing for a function and its args. I realize there are ways with "decorators" to add type checking, but that's not the point. I'm talking about type hinting. The reason for this would be to allow a compiler to examine the code, read the hints, and then compile the code or translate it to C++.
The problem with existing python accelerators is that they bend overbackwards to avoid stepping on the dynamic typing. Why not allow the user to forego that if they want to and have static typing if they want to go to the effort of indicating it.
Some drink at the fountain of knowledge. Others just gargle.
> I like Perl. Is there a tool that converts Python scripts to Perl, or compiles them into the opcodes that Perl's interpreter actually executes? That could let Python scripts run on lots of other machines, possibly avoiding all those architecture limitations that the Perl engine has already solved.
There are plenty of ways to make Python and Perl talk to each other but there is NO tool that compiles either to each others byte code directly. You can embed the interpreters of each other. Inline::Python and PyPerl come to mind, not including cross language communication as in COM, CORBA etc. Of course, this means that you will still need to use the other interpreter but you could distribute that yourself. But all that is often not worth it for some minute advantages that are gained except as an interim solution.
Yeah, I've never understood why some people have such a problem with Python's use of whitespace. I think that it makes Python great as a language for teaching programming to beginners. Anyone who has had to try and read a student's unindented code will surely sypathize.
Regarding the GUI: don't.
This is a language, so keep it as such. I realize it's hard to market a language without a rich set of standardized libraries, but the UI should be an exception. This is an area where the technology is slowly but constantly changing. In addition, GUIs tend to have somewhat "religious" supporters. Also, as Bruce mentioned, all of the toolkits have their advantages and disadvantages. One "disadvantage" they all share is a changing API. Nothing stays the same forever. Tying your language standard to a third party API is problematic.
One language tried to do this (Java), but it's original GUI was universally reviled, and it's current "official" GUI (Swing) is competing with an extremely popular third party solution (SWT), and another third party solution (Jambi) is starting to gain enthusiastic users.
So in my opinion, leave the UI unstandardized.
Don't blame me, I didn't vote for either of them!
He's not that different from Linus. He does things in ways that some people seem to really dislike. When they complain, he doesn't mind. "Tough cookies." I guess when Linus does it, it's a noble independent spirit, when Guido does it he's being an asshole.
I use Python as a test, actually. Hating the language is okay by me, we've all got tastes. Lucky for you, we don't write our code in Python so you won't suffer. But saying you hate it because of enforced whitespace? That fails your interview, right there. Ohhhh boy. You've got a problem with having to make things line up the way their supposed to? Just wait until you hit some actual PROJECT REQUIREMENTS.
He said that 'self == whitespace indentation' whereas for me I see that as exactly the oposite:
- using whitespace for indention remove 'visual noise' at the cost of 'language magic'
- using self adds 'visual noise' with the (dubious IMHO) benefit of language 'simplicity'.
IMHO removing self would be a big plus for Python, sure self makes things more explicit but if developers really wanted to use explicit language, they would stay with C instead of using Python, Ruby..
While python org has documentation, python documentation lacks three critical aspects.
1) searching and finding only relevant results. When I don't know exactly what I'm looking for, say how to parse an input string to numerical variables, and try to search python.org I get all kinds of crap at the top of my search. Discussions, posts, Peps, and deprecated crap. There ought to be a way to search for things relevant to the current python commands.
2) documetnation that teaches. Too often when I find the documentation of a method it's just a terse self-referential explanation and a list of args. No understanding is returned. If you want to see doucmentation that explains how to use a function look at Perl's man pages. There commands are explained.
3) local documentation. Again I point to perl's man pages as the right balance between compactness, richness, and completeness.
Some drink at the fountain of knowledge. Others just gargle.
RIGHT ON THE HEAD. Python is the perfect language for student homework. If they don't indent properly, their code doesn't even WORK.
Or to look at it another way, they're making sure that the problem of people using their own personal messy indentation style stays fixed.
Ergonomica Auctorita Illico!
Yeah, and the GIMP UI "problem" only exists in the heads of people who have never used the GIMP.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
The Python Software Foundation (PSF) needs to realize that there's so much more to a language than the syntax. There needs to be a major effort in making it easier to install, get started with, and deploy Python, and much more advocating and marketing needs to be done. For example, PSF should start campaigning so that web hosting providers support Python out of the box. Why do you think PHP, despite it's obvious drawbacks, is so popular? Because it's ubiquitously supported and requires nil efforts to get started!
It's great that Python is constantly evolving into a cleaner and more competent language, but I fear that the Python 3000 efforts could result in a pyrrhic victory in the war between programming languages because it simply fails to attract enough new people. There's so much that the PSF could do, but there seems to be too much "But that's not our job!"-thinking.
I'm even more perplexed why Guido is removing the "+" sign. HE says he's reserving it for an unnamed future use. In the mean time using two minus signs in a row is how all additions will be done in python 3000. I'm baffled by this.
Give me multiply indexed arrays and array slicing! that would be something.
We at slashdot are scientists, specialists and kernel hackers. Your FUD will be found out.
{
:-)
Yeah,+I+just+hate+it+when+those+folks+think+that+white+on+white+can+be+readable;
}
{
Or+that+positioning+text+properly+is+the+correct+way+to+make+it+parsable+by+humans;
}
Oh wait, this piece of text is a bit more readable.
Isn't it?
That was pretty cool the way you absolutely did not answer the question.
Various BASIC implementations had an intermediary representation. It's nothing to crow about, on its own. Sure the Perl implementation is pretty performant. It's a decent piece of work, but it's nothing desirable as a *target platform* for other code tools. It doesn't have some endless list of hardware it magically works on, it's just a C-implemented runtime you compile in different places. Thus, the idea of specially targetting it as a runtime is kinda loopy, when there *are* very widely deployed runtimes which go far beyond the "compile it you fool" level. The Java VM is the foremost among these.
-josh
In theory, it seems like significant whitespace in syntax would be a problem. In practice, I've never seen any problems with it in the years that I've been using Python. OTOH, I've seen a lot of bugs caused by mishandling the optional C-style "if" blocks in those languages that use them.
I've used Python.
The syntactic whitespace is hard to get used to and causes hard to find bugs.
This has been a public service announcement from the Society for the Preservation of Curly Braces.
You want the truthiness? You can't handle the truthiness!
You do know about Python's block delimiter support, right? You can use the block delimiters from any language you like, just prefix them with '#' and Python will handle them automatically.
Bruce Eckel is looking for Erlang. That's not what Python is for.
StoneCypher is Full of BS
They fixed the whitespace problem in a fork:
http://clisp.cons.org/
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
You're right. Another good poll would be "How many people haven't bothered with Java because of the whole VM thing?" Or, "How many people haven't tried LISP because of the whole 'no side effects' thing?" Or "how many people refuse to use C because of the whole compiler thing?" Or "How many people reject Ruby because of the whole 'ability to pass blocks of code as arguments' thing?"
My point is, these things are kind of central to their respective languages. If you truly despise one of these central features, chances are good that there are a dozen other things about the language you won't like either. The Python people could jettison every feature you didn't like, until they finally wound up with a bastardized knockoff of Your Favorite Language. Then you'd end up ignoring Python in favor of Your Favorite Language anyways.
If the whitespace thing is a big deal to you, then either your editor of choice isn't doing anything to help you, or you're just whining that Python isn't exactly the same as YFL.
You want the truthiness? You can't handle the truthiness!
I've never understood the "whitespace" thing... don't you guys indent your code anyway????
Removing the curly braces was only slightly problematic for me because my "%" key didn't work with python code for Vi(m)..... I'm sure there are plugins for Vim to fix that, but even that wasn't bad enough to make me find a fix.
Don't quote me on this.
Try Pyrex. It speeds up some code a LOT. (For other code it doesn't do much.) And Pyrex is "nearly" compatible with Python.
N.B.: You must compile Pyrex code to run it. Also, Pyrex is most suited to writing "small pieces" for use from Python. But if you were even thinking of Python, and it was the speed that deterred you, look into Pyrex. (Some people use psycho or pypy, but I believe that those are still too beta...and I don't think they generally speed to code as much as Pyrex does.)
I think we've pushed this "anyone can grow up to be president" thing too far.
I meant sys and os, sorry about that.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
Sounds like some tough issues. Good thing they have 993 years to get it right.
Try this, in increasing order of work required (and likely reward).
One: try Psyco. It may give you the bump you needed, or it may do nothing, but since it's so easy you might as well try it.
Two: write faster code. Basically, let Python do the work for you by handing off as much processing as possible to the language. For example, this:
is longer to type and possibly vastly longer to execute than:
since the latter knows how many values it needs to pre-allocate memory for, and can perform the operations in a tight C loop instead of evaluating a much slower Python loop.
Three: profile. Once you're sure that you've written good algorithms are aren't re-implementing large bits of Python in Python, run a profiler to find out where you can direct extra attention. Some people do this before #2, but I don't touch it until I know that everything else is right.
I wrote a "diff" function in native Python that searches two many-gig files for lines that appear in one but not the other. Said function is IO bound on a SCSI-320 RAID-0 system with 4 15K RPM drives, and typically uses about 20% CPU for the duration. You can write slow Python, but that doesn't mean that you have to.
Dewey, what part of this looks like authorities should be involved?
Nope... I like python and use it every day. Losing the syntactic whitespace for a more traditional whitespace-neutral {}-block style would to me only feel as an improvement. Syntactic whitespace makes it harder to automatically reindent code, makes it easier to accidentally break the code structure and generally makes refactoring a pain. Furthermore I suspect the syntactic-whitespace to be the reason pythons lambda-statements are severely limited.
If anyone is interested, my top candidates for improvement or python would be:
* regular {} blocks instead of semantic whitespace
* non-trivial lambda-statements
* explicit scoping of variables like with the "var"-keyword in Javascript
Nice to have but not essential would be:
* ++ and its friends
* ternary statements
* switch statements, preferably supporting strings. I know that you can simulate this with a dict and a try-catch but honestly, why keep a feature out of the language for "simplicity" and then encourage people to use horribly unreadable workarounds?
Yes, I indent my code. Mostly automatically by hitting tab in emacs or doing the equivalent of M-x reindent-region. This does not work in python as there's no explicit end-of-block marker for the editor to use as a cue. Thus, refactoring code is a pain and it's easy to accidentally break code.
Oh, and doing a diff ignoring whitespace-changes is no longer a way to see what's really changed in the code and what's noise left by someone cleaning up the code-style.
I still like and use python but the whitespace thing is no bonus.
And learn LISP.
Deleted
From what I hear, the idea of the new major breaks-backward-compatibility Python version was conceived in 1999, so the release was codenamed Python 3000 to mock Windows 2000 especially. It will actually be named Python 3.0.
don't you guys indent your code anyway?
Well that's kinda the whole point. Programmers indent according to the block structure, so curly braces and begin/end keywords are pretty superfluous. One of the reasons why I dislike Pascal is that it's got at least four different keywords to mark the beginning an end of a block. It's just confusing. C-style languages are better, but the parenthesis are still redundant. Why do those people love repeat themselves so much?
Using self, or something like it, is a requirement for having a dynamic class-based OOP system. C++ can get away with avoiding it most of the time by requiring variable declarations. Python will and should never do that. Ruby uses at-signs which have much of the same purpose as self in Python.
Please, for the good of Humanity, vote Obama.
must we give modpoints to idiots?
It's kind of hard to avoid when the earlier moderators were idiots.
JVM was designed for Java -- and only java. jpython, etc, are suboptimal hacks. the .net CIL is an improvement, but it's still made with VB/C# in mind. For script languages, parrot looks to be a much better fit.
Do you even lift?
These aren't the 'roids you're looking for.
CPAN is better than Python's Cheese Shop.
And the Java API + 3rd party libs knock them all into a cocked hat.
you had me at #!
For a really great and thought provoking talk about concurrency watch this Techtalk about Newsqueak given by Rob Pike of Plan9 fame.
:) No, really.
Build channels as first-class citizens into Python.
Meme of the day: I browse "Disable Sigs: Checked". So should you.
I answered the exact question, directly. I'm not discussing why I lile Perl. I like Perl. I'd like to use some of the existing code in Python to do some things that perhaps Perl doesn't do. But without having to deal with the Python runtime environment, especially given the limitations mentioned in the story we're discussing. And while Perl's extremely wide portability of identical source code isn't "magical", it is indeed one of the reasons why I like Perl. Because I don't have to learn some new language every several years just because Perl is now pretty old.
I'm not looking for "the best VM" or anything else like that. I'm looking for a way to use Python scripts with my Perl engine. Which is exactly what I said, and exactly what I want.
If you want to argue about something else I don't care about, which is known as a "straw man" fallacy, then why don't you reply to that other obnoxious post instead of bugging me with irrelevancies?
--
make install -not war
Use Perl, it has ALL of these.
Whitespace is syntactically significant in almost every language. Try splitting a variable name with whitespace in Java, C++, C, Visual Basic, or virtually any other language. I've worked in dozens of languages and only remember ONE (back in 1975) in which whitespace wasn't syntactically significant - HP Basic/2000. And you were limited to variable names of a single letter or a single letter followed by a single digit. Do you really want to go back to those days? I didn't think so.
Python happens to use whitespace to simplify the good programmers' life - Use whitespace to mean the RIGHT thing - to designate blocks of code (which good programmers do anyway).
To those who suck as programmers, it's a problem. Thanks for identifying yourself.
Think about why you got modded that way.
There are good reasons for the whitespace thing, actually. If that's your biggest complaint, hell, my biggest complaint about other languages is that I'm forced to use these silly brackets when I'm already indenting anyway.
Don't thank God, thank a doctor!
I think you meant Haskell (or, to a lesser extent, some other ML-like language). Lisp has plenty of opportunities for side effects. You can do without them, if you want, but you could do that just as easily in C or Java.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
This language lacks a standard. There is no ISO specification. There is one working implementation, and a few half-done clones that are "broken" because they aren't identical to the primary implementation. Now they talk about incompatible changes!!!
That's less standard than Microsoft OOXML.
I can't take this language seriously, and I'm certainly not going to rely on it for anything that has to last through the years or be deployed out in the wild.
I can rely on C. It was standardized by ANSI in 1989, by the ISO around 1992, and again by the ISO in 1999. There wasn't any crap like "remove puts because people can just use printf", but this is exactly what we see with Python.
I can rely on the Bourne shell, also standardized by the ISO. (joint effort by the Open Group and IEEE) I can sort of rely on C++ and Pascal. I can rely on Ada, FORTRAN, and even COBOL.
The first link points to the same page as the second link. It should point to this
Ok, this is Slashdot, no one clicks those links anyway.
### Why do those people love repeat themselves so much?
Its not repetition, it is the structure of the code. The indention is the thing that serves no purpose and should be completly removed and left to the editor (just like other 'prettifying' such as syntax highlighting). Python does it the wrong way around, it takes the look of the code and interprets it as structure. Look however is very easily destroyed, a simple copy&paste destroys Python code and if you don't have a good editor, it is extremely hard to recover the code after such an operation and even with a good editor its still extremely easy to let an error slip in. Refactoring a pretty tiny piece of Python code belongs to the worst coding experiences I ever had, since what would have taken minutes in a block language with block markers, resulted in hours of try&error in Python.
To make a long story short: Keeping a single '{' and a '}' in the right place is trivial, keeping hundreds of ' ' in the right space and at the right length can get insanely hard, if you miss even a single one of them your code breaks, sometimes without even given any kind of obvious error (beside other reasons, thanks to brain-dead automatic variable declaration on assignment, a problem sadly shared by way to many other scripting languages).
### I've never understood the "whitespace" thing... don't you guys indent your code anyway????
I don't indent code, my editor indents code according to the block markers. If a language doesn't provide block markers, the editor can no longer do the task and its up to me, annoying and error prone.
Your post seems to assume that only students beginning CS 'forget' to indent their code. One of the first things I find myself doing these days when I pick up someone else's code is running a global auto-indent on it (pretty easy in Eclipse). Sometimes they didn't indent at all, other times they apparently came up with their own indentation scheme (in one method I saw it seemed he had done a reverse indentation policy, where inner code blocks get indented less than the outer ones). The latter developers are the ones I really want to strangle...
Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination.
Well I guess it comes down to what tools you usually use. Some coders that move a block of code will manually adjust it to the correct indentation depth, some coders will use the equivalent of M-x reindent-region. If you're the former you're probably happier with python where you wont have to worry about the {}-delimeters. It's not a big problem.
Thanks for the tip about ternary-statements. The syntax will take some getting used to but it will come in handy sometimes.
I agree, if they have that different of a goal, just fork and call it something else. Many will stay with Guido's Python, others will migrate to the new langauge.
Problem solved and no one needs to get killed in the process.
---- Booth was a patriot ----
(Yeah, I know we have indent to fix that, but you'd never bother using it after the pain of seeing such thing.)
I want to run Python scripts in my Perl environment because, among other reasons, Python's runtime has the problems mentioned in this Slashdot story summary. And I don't want to have to install and maintain a Python runtime, or learn its peculiarities. But I do want all its functionality, including the Python scripts embedded in lots of my OS. During my transitions from Ubuntu 6.4 to 6.10 to 7.4, the Python libraries and installs got very corrupted, including some apps using different versions of Python side by side, getting entangled (not to mention the bloated redundancy). So I'd like to just have a wrapper for Perl that can handle all those Python scripts.
Python claims to "run everywhere", but I can't find an actual list. I'd be surprised if it actually runs on the extremely complete range of platforms Perl actually runs on. If Python scripts actually ran on Perl engines, then it would.
--
make install -not war
How on earth did your broken reading comprehension lead you to that conclusion?
What I said (for people capable of reading English) is that it's best to let Python itself do as much as it can, rather than needlessly re-implement parts of the language in native Python. Don't write loops if map() or list comprehensions can replace them. Don't write "c = a; a = b; b = c" to swap two variables when "a, b = b, a" does the same thing but faster and with less memory.
The C equivalent would be saying to use libc instead of hand-rolled knockoffs because the standard version will almost certainly be more efficient and better tested.
Finally, it's "Lua", not "LUA", and even their Wiki doesn't claim as much superiority over Python as you do.
Dewey, what part of this looks like authorities should be involved?
It's also a problem for people who have to share code with others who don't use the same indentation style. Nothing is more fun than trying to figure out just what the hell is going on when some stuff is spaced, some is tabbed, and automatically converting it could screw it all up for you.
Obviously, the braces have become a religious issue for Python people, which is a shame. They clear up any potential ambiguity all on their own, they aren't arduous to type, and they're much more amenable to automated tools. Still, if you'd rather get all holy war and insulting about it, you say a lot more about yourself and your ilk than you do about anyone else.
Slashdot - where whining about luck is the new way to make the world you want.
Well, there's also old-school Fortran. But let's be realistic-- when someone says that whitespace is not syntactically significant, they mean that it is not significant for anything but lexing.
It seems to me that most general purpose programming languages would do best if they did exactly three things in relation to their standard library:
The art, of course, is in defining the right frameworks for each area. This is not easy. In fact, it's very hard, perhaps the single hardest thing about developing a good new platform for programming. However, as demonstrated by the C and C++ worlds where standard libraries are minimalist but there are several popular cross-platform libraries used in practice, it can usually be done. And if you can do it, and produce good frameworks that are both clean enough to use for most things as they stand and extensible in useful ways where platform-specific features or future developments warrant, then you're backing a winner for sure.
The language itself should then, IMHO, provide solid support for library users and developers in terms of clear interfaces and facilities for whatever version checking, dynamic loading, calling conventions, data marshalling, documentation or other common aspects make sense for that language.
This combination basically keeps the overhead for learning and portability low, which is the major advantage of having a standard library in the first place, but without committing to writing and maintaining a large standard library from day one. The latter, IME, usually means having to live eternally with the mistakes when the implementation that was driving the library turns out not to be flexible enough a few years down the line; this has happened to most monolithic standard libraries in mainstream programming languages so far.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Libraries and components are part of the runtime.
And I still like Perl. If I can just suck in the Python scripts, I don't have to bother with Python, however much reason you might have to like it. I'm talking about my reasons. Talk about yours with someone else, who doesn't care that they're strawman arguments.
--
make install -not war
Nobody is going to rewrite compatible implementations of these thousands of library methods in Perl. So even if you could wrap a preexisting script in Perl, you'd actually have to install and maintain most all of a Python runtime, but do it in what would undoubtedly be some kind of poorly supported half-assed Perl extension hack.
Ok,
Python is slower than C, C++ and Java... Guess what? So are PHP, Ruby, Perl, and every other interpreted language.
However, if it takes me 10 programmer hours to create a python program (or PHP, Ruby, Perl) program, and the program takes 10 seconds to process 50,000 records from my database while the C version of this program takes 500 programmer hours and takes 1 second to process 50,000 records.... how long does it take before the C program is faster?
about 9.8 billion records... well, at our current rate of record growth, I'll be there in about year 2500, even assuming 50% growth/yr (completely unsustainable for any enterprise past 10 years) its still 2100 before the time saved by the program equals the time saved on programming time... Not to mention CPU time costs less than 1 cent/hr, and programmers are much more expensive.
And for the record, we have done this. We recently re-wrote a C application in python, the original application took 5 programmers 3 years to create, we recreated it in python with 2 programmers in 6 months, it is feature complete vs the C implementation, it is slower, but not outside of what would be considered reasonable. We also haven't even tried to optimize it at all... which we could do and probably at least get 10-20% improvements in performance.
Now, in saying this am I saying interpreted languages are the answer to every problem? No! Sometimes, you need C, sometimes there are problems that can't be solved well in any specific language. If there was a be all end all language, we'd all be using it. Python, Perl, PHP, and Ruby all have their place, in general I prefer Python because I find it much more intuitive than Perl, I find generally better programmers advertising Python jobs than advertising PHP jobs, and I just like it better than Ruby
What? No. There are no limitations in the C implementation of the Python 2 runtime environment that are not also in the C implementation of the Perl 5 runtime environment. Both of the languages have a lot of similar characteristics. Both were developed at around the same time, with Perl starting a few years earlier. Perl 4 came out in 1991, Perl 5 in 1993, Python 1 came out in 1994.
...
The "Perl engine" only runs Perl code. It does not run any other languages.
You can run Python from within Perl though using both runtimes:
http://search.cpan.org/~neilw/Inline-Python-0.20/Python.pod
And perhaps one day you can run both scripts interchangeably if Parrot achieves is goals:
http://www.parrotcode.org/
In the meantime, if you want to write in a dynamic language you can run Python in the JVM or IronPython in the CLR. Then you can use a single runtime to call into Java or C# or Javascript or Ruby or VisualBasic. You can not do this with Perl 5, it is extremely unlikely that Perl 5 will every be supported outside of it's single C implementation. These limitations in the Perl 5 runtime are why your Perl community has been doing a from-scratch rewrite of Perl these last 7 years or so
Not quite - no switch or case. Unless you're running the prototype version of perl6 written in Haskell.
Seems to me, that what you're saying is that the mix of whitespace and tab is a problem, not the the whitespace == indentation, wouldn't it be better if Python disallowed tab for indentation?
>>It's because Ruby doesn't have ridiculous idiosyncrasies that the original programmer isn't willing to change. Matz seems to have an open mind about improving Ruby.
It depends: see Unicode for example, AFAIK Python's support is still better, it's a point where Ruby should have evolved faster..
I've never personally run across Python code that doesn't use four spaces, so this is much more a problem in theory than in practice. Furthermore, Emacs will automatically pick up the indentation mode of any Python file you open and use that instead of its default for that one file. I doubt that it's the only programming editor that can handle this for you.
Dewey, what part of this looks like authorities should be involved?
Still using Notepad?
Using Emacs, if I type "if foo:", as soon as I press ":", the editor will enter a linefeed and move my cursor down, indented four spaces to the right of the "if" statement.
Now, if I type the command to be executed in the "if" clause and hit enter, I will be positioned immediately under the first non-whitespace character in that line. If I type "else:", as soon as I press ":", it will shift that line to the left four spaces so that it's immediately below "if foo:", insert a linefeed, and position the cursor exactly where it should be to enter the "else" clause.
I never have to think about indentation because Emacs does it for me. I literally have not had to deal this supposedly tricky whitespace in years. If things like this are difficult in your editor, it may be time to upgrade to one more suited for programming (and there are plenty that should fit the bill).
Dewey, what part of this looks like authorities should be involved?
I know about this. And I know about ponie.
And I still haven't heard of anything approaching a release candidate for perl6, or ponie, or pynie. Maybe I just haven't been paying attention...
Another question is whether pynie has a chance of becoming the default Python environment. There's been Jython and IronPython, and probably others, but they suffer from lacking some features and generally being less popular than CPython. I imagine most people would agree that a standard VM is probably a good thing.
Don't thank God, thank a doctor!
If your editor isn't displaying indentation, you should raise a bug report for it. That's a pretty serious problem and would make editing code much more difficult than it ought to be. HTH.
### I literally have not had to deal this supposedly tricky whitespace in years.
You don't do copy paste? You never insert a "if foo:" above a already existing piece of code? As soon as you have to move a already existing piece of code a block deeper the lack of block markers gets a huge annoyance, since its just as easy to mess up.
Beside, you are doing the classic pro-whitespace mistake, the arguments always go like this:
Q: Why whitespace?
A: So people are forced to indent properly and make pretty code.
Q: But whitespace is a pain, causes trouble, etc.?
A: Use a proper editor!
Q: But if I use a proper editor it will indent my code automatically anyway, I don't need the language to force me!
A: Hm..
When you are already using something else like Notepad, it simply doesn't make sense to have whitespace blocks. If everybody would use Notepad I could see a reason behind it, but people just don't.
... implementations are slow/fast. A language based on a specification can have multiple implementations with vastly different performance characteristics. Consider Common Lisp, which has implementations:
* with a classic interpreter, and dynamic native compliation (Allegro CL)
* with a byte-code compiler (CLISP)
* with dynamic native compilation only (SBCL, OpenMCL)
The reason "Python is slow" is that it is defined by an interpreter-based implementation - other implementations with different performance curves are judged on bug-for-bug compatibility with CPython.
To a Lisp hacker, XML is S-expressions in drag.
Your parent poster could be referring to the tab vs space issue. But that problem would disappear if those heretics would just do it like I do, the One True Way.
// Lisp can do everything those languages do and much more. Why Ruby and Python exists is a mystery for me.
(defun test ()
(dolist (truth-value '(t nil 1 (a b c)))
(if truth-value (print 'true) (print 'false))
(prin1 truth-value))) => TEST
(test)
def test():
for truth_value in True, None, 1, ('a', 'b', 'c'):
if truth_value:
print True,
else:
print False,
print truth_value
test()
For many, many people, version 2 is much more readable (mind you, this is very simple LISP code). And since you're going to indent correctly your code (either by hand or with the help of an editor), why not make indentation matter?
Now you come back explaining why LISP code is perfectly readable by you (irrelevant to my reply) and refuting the value of readability in anyone's code (irrelevant to reality).
I speak England very best
Syntactic whitespace reminds me of the rules of "Haiku", the Japanese poetry style.
http://en.wikipedia.org/wiki/Haiku
Aficionados of Haiku say they like it because it frees them to concentrate on meaning rather than form. The form is specified.
Personally, I like the syntactic whitespace for these same reasons.
So much time has been wasted debating coding styles that I am happy to have it pre-specified and dealt with.
We can then move on to more important issues of content.
Or fire the asshole for not following the coding guidelines of the company. Sorry, but if you hire some nitwit who needs the language to force them to write proper, readable code, you deserve what you get.
The vast majority of those are posix platforms, so even if there's no actively maintained port, it wouldn't be hard to get one going. The CPython core is simple, portable C. Of course it also runs on any (recent? - haven't checked) JVM and .Net, giving it another set of platforms. And on Symbian, rather more relevant then the old Psion stuff.
Not sure how your Python versions got entangled - strange things happen during OS upgrades - but I routinely have 2-3 different python versions installed on my systems w/o problems.
no taxation without representation!
Moderation -2
50% Troll
50% Overrated
When Slashdotters can't handle a post that just asks if one popular language can use scripts from another popular language, then the TrollMods have won.
--
make install -not war
* regular {} blocks instead of semantic whitespace
I agree completely. I love Python, but syntactic whitespace is the major problem of the language. It comes from Guido's idiosyncrasy of having Python being a "teaching language", but that is no longer the main use of the language.
However, Python already has a starting 'brace', it's the colon. It would be aesthetically pleasing to use the semicolon as the ending 'brace', it would fit into the general 'look' of Python:
Which would work even if Slashdot's <ecode> environment botches up the indentation and you copy-pasted it directly to your terminal window.
-josh
If you want to be able to call python code from perl and vice versa, then consider things like the foreign function interface, rpc of various sorts, corba, swig, and special-purpose tools like perlpy.
Compiling to python to perl bytecode is not necessary to achieve your aims, nor is it *possible* because the runtime features are different.
-josh
It's a while since I used vi, but a tab and a set of six spaces both show up in WordPad - and they both look the fucking same. Ditto if I print the file. And if you tell me I should be using an IDE that pretty much proves my point - if a language needs anything more than a text editor to write it, then it has serious failings.
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
I'd say people who have programmed in ABC wouldn't have a problem, either, since that appears to be where Guido got the idea.
OTOH, in other languages, you can use whitespace in a few different ways and still have a pretty clean, properly indented syntax. It's just not enforced. Being able to say:
if ( foo ) { bar(); }
or in some languages:
if ( foo ) bar();
instead of
if ( foo )
bar();
-- or however it's exactly written in Python -- is nice if the code to be executed is really that short. Or, in the case of Perl, one can even write:
bar if foo;
How's that for eliminating ugly punctuation?
I don't think the use of whitespace as syntactically significant is necessarily a "problem", since a good text editor handles things like tab conversion and such. It's a preference, and I don't prefer it. Give me Lisp with parentheses everywhere before making whitespace so important.