Guido and Bruce Eckel Discuss Python 3000 305
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."
Bruce, Just a Make a New Language Then (Score:2, Interesting)
Re:Bruce, Just a Make a New Language Then (Score:4, Insightful)
While I agree, if he wants something that's fundamentally incompatible, but wants to still call it Python, that's silly.
On the other hand, they're saying 'We need more devs to work on Python' and pushing people away that -care- is exactly the opposite of that. If they want new devs, they'd better be resigned to the fact that the newcomers WILL have a different vision, just as this guy does. Finding code-slaves that will do everything you want exactly as it always has been is nearly impossible. You have to pay people to make them go through pain like that. (Coding in someone else's style is just as hard as painting in someone else's... Initially it's almost impossibly hard, and it gets easier with time... And there's always the alternative of working on something else without all that pain.)
Re:Bruce, Just a Make a New Language Then (Score:4, Insightful)
Good point! Managing developers is hard enough in a company where the devs are paid. Managing volunteers is much, much harder. I strongly believe that half of the success of many open source projects is not the brilliant ideas or the super cool code, but the personality of the lead developer. Linus and Guido have proven to be such personalities that managed to galvanize hoards of developers around them. That is quite impressive. How many managers out there would be able retain employees without any pay?
One distinctive feature of these open source project leaders is that they have to act like assholes sometimes. I proves that they are tough, have a vision and won't budge. At first it seems counter-intuitive that being disagreeable will accomplish more but it works because even if it pushes one developer way, it might attract others or make the ones who are left work harder. It's like a medieval army. Decimating 1% of the army is worth it because it will make the other %99 percent work harder.
Re:Bruce, Just a Make a New Language Then (Score:4, Funny)
Re: (Score:3, Insightful)
You know, I said something similar to this about Larry Wall, Perl, and Perl 6.
Re: (Score:2)
Anaconda is already in use.
I was thinking SAP, "Simply another Python". Oops, that is taken too.
Re:Bruce, Just a Make a New Language Then (Score:5, Funny)
Of course, since Python was named after Monty Python's Flying Circus, maybe it should be one of these:
Something along those lines anyway
Re:Bruce, Just a Make a New Language Then (Score:4, Funny)
So, Bruce's Python derived language could be called SNL (Selfless Notation Language). Libraries could have names like "Bassomatic" (XML processing) or "Cowbell" (Multimedia types).
Re: (Score:2)
Surely we should first rename what we've already got to ExParrot, implying that has passed on, is no more, has ceased to be, has gone to meet its maker, etc. Then we'll be free to call its replacement whatever we like. :-)
Re: (Score:3, Insightful)
Also, his main goal, changing the language to be more productive on multi-processor systems, is an extermely valid one in a "design for the future" sense. Right now it makes marginal sense, but multi-core & multi-processor systems are becoming more common...and the predictions is the trend will not on
Sometimes I think we should just all give up (Score:2)
Bad link? (Score:5, Informative)
With a song and a dance (Score:4, Funny)
Solved problems (Score:2)
Re:Solved problems (Score:5, Interesting)
Personally, I like some of the ideas of Python better than Haskell and Erlang. There have been some very good ways of doing multithreading, even massive multithreading (see Stackless, some of which is now back in the main Python), and making it natural, even with an imperative style of programming. Some implementations (again, see Stackless) make threads so lightweight that you can spawn thousands without being concerned about performance, and the structures used make it natural to do that without any kind of locking issues -- sometimes, without explicit locks at all.
The problem is not with python, the language. It's with python, the interpreter, and all the associated C modules, embedded versions, etc, not to mention Python programs that might assume the same behavior.
Specifically, it's the Global Interpreter Lock. The GIL is the most retarded move I've ever seen in a language. Basically, Python said "We don't want to make the Python interpreter too complicated, so we're going to deliberately remove multicore support." They even support real OS threads, but only one Python instruction may be executed at a time. Which is fucking stupid.
There are a lot of really good things in Python. I'd like to be able to write a good, modern game with Python, but if you figure it may be half as fast as C already, I'm not going to lose another 50% speed because it can't use both cores. (Yes, psyco can make it MUCH faster, close to C. But, psyco doesn't work on 64-bit, which is another kick in the balls for performance.)
Re: (Score:2)
Python has multicore support; it's called "spawn a process".
Down the road when you have, say, 200 cores, do you really want to be
Re: (Score:3, Informative)
Er. Image rendering is typically one of the most obvious places where separate processes with no shared state yield huge benefits. In fact, image/graphics rendering applications are among the few categories of software which are able to take full advantage of multi-core systems right now, and it's largely because this is such a good solution for them.
Re: (Score:2)
It is worth pointing out that the situation isn't as bad as you imply as multi-core support most definitely has not been removed. Threading works great when python is I/O bound. Anytime python is outside of the interpretor handling an I/O operation, the GIL is released and allows another thread to execute. Threads which are executing inside the interpretor, continue to run regardless of the GIL's state. CPU bound tasks, o
Re: (Score:2)
One thing I like about Python is that it's not ashamed to steal good features from other languages. Even better, it usually makes them easier to use or gives them nicer syntax. So I'm OK with this. But I feel it's necessary to point out a couple problems with your thesis here:
Erlang is cool and all, but libraries are basically a dead end at this point. There are too many things missing that you have to go implement on your own, and if they don't catch up soon they're
staying with an old version -- how? (Score:5, Interesting)
Re:staying with an old version -- how? (Score:5, Informative)
You'd typically install multiple versions of python on the same machine. On Unix-like systems each Python version's executable will be named in the manner of python2.4, python2.5, and so on, with a symbolic link from /path/python to (usually) the newest version. Scripts can call for a specific version of Python by starting with a hash-bang line like #!/usr/bin/env python2.5.
Many operating systems facilitate this scheme by offering independent packages for different versions of Python. In particular, on Debian Etch the user can choose to install any of the python2.3, python2.4, and python2.5 packages, then use update-alternatives(8) to switch the system default between the three.
Re: (Score:2)
Re: (Score:2)
What? You thought you could just write software and then it would work forever?
It'd be great if the world worked like that, but it never does. People are always making incompatible changes somewhere (even if they're just obvious bug fixes), and so software always needs to be maintained to keep up with the platform it's written for. This is one of the key practical advantages o
Re: (Score:2)
Compiled type-safe python (Score:4, Interesting)
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.
Re: (Score:2)
documentation (Score:2, Insightful)
Re: (Score:2)
Re:documentation (Score:5, Interesting)
Huh. One of the things that really attracted me to Python was the (perceived) quality of the Web documentation. The Python Tutorial [python.org] and Python Reference Manual [python.org] are very complete and provide an excellent high-level overview of the language, something which can be rather difficult to come across in, for example, the land of Perl. Granted, the Library Reference [python.org] could be stronger, but I can still usually find what I need in there; and if not, it's easy enough to invoke dir() and view the __doc__ string on any objects of interest from Python's command line.
I guess it's just a matter of personal taste. But for what it's worth, I found it much easer to pick up Python without resorting to any third-party books or reference materials than to start fresh with either Ruby or Perl.
Re: (Score:2)
http://docs.python.org/lib/module-SocketServer.html [python.org]
I had to google a lot of missing info to be really able to use SocketServer.
Re: (Score:2)
The syntax and "Computer Science/Academic style description" of a language are not usually the most difficult bits (there are some exceptions of course
I mean, after reading "formal/academic" docs I'd know how to do "Hello World", "fibonacci", etc
Re: (Score:3, Insightful)
i dunno, every piece of documentation is just a starting point. I only use docs.python.org to find a suitable module and then just look around it in IPython shell (import module; module. etc.).
As for PHP.net, it's full of buggy, halfassed examples written by morons and more often push you wrong way than not.
Re:documentation (Score:5, Informative)
searching the online docs (Score:2)
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 do
Re: (Score:2)
I am surprised that none of your searches took you to docs.python.org. But perhaps you were using lots of third party e
Re: (Score:3, Insightful)
There are a few under-documented libraries that I've run into before, but largely I've been happy with the python docs.
I could swear you were talking about Ruby, because that's exactly the way I feel about Ruby (a language I love, but the docs are disorganized, decentralized, and generally poor).
Re: (Score:2)
losing the print statement (Score:4, Interesting)
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.
even odder. (Score:3, Funny)
Re: (Score:2)
I hope this will not be included in v3.0.
Re: (Score:2)
Re:losing the print statement (Score:4, Insightful)
Interesting. Where other languages have print statements that do exactly what you tell them, Python's print statement has at least two ways of adding unexpected characters. Not what I'd call "dumb simplicity".
While most experienced programmers can predict what a print statement will output, they won't be able to do this with Python's
print "Hello, World!" # One extra character is added here.
print "Hello", "world" # Two extra characters are added here.
print "Hello", # Guess how many extra characters are added here? Hint: not zero.
Quiz:
* How can you use Python's print statement to print some text without a newline? No fair firing up the interpreter!
* Name three languages whose print statement only prints characters that the programmer explicitly passes to it.
Re: (Score:2)
Py: print "Hello World"
QB: PRINT "Hello World"
Py: print "Hello",
QB: PRINT "Hello";
"It's the same syntax as BASIC!" should never be a selling point of your language.
Re: (Score:2, Insightful)
Instead of:
>>> print "Hello World!"
you now have to do
>>> print("Hello World!")
just two extra paretheses, and no more of this >> stuff.
Re: (Score:2)
Why? I was a Python programmer for 3 years, and the print statement was one of the most obvious warts.
Amen to that. Because it's a command and not an expression, you can't do things like use it in a lambda command or pass it as a parameter. This means that if you want to print every value in a list, you can't just type "map(print, listname)" or anything else as compact and "clean". I'll be more than happy to drop yet another pointless command when the alternative is every bit as convenient and provides much more functionality.
Python++? (Score:4, Funny)
Re: (Score:2)
You want to add something to Python, but only wind up with what you had before anyway? :-/
Re: (Score:3, Informative)
Decimal point is wrong... (Score:3, Funny)
Sounds familiar. (Score:3, Funny)
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).
Re:Sounds familiar. (Score:5, Interesting)
So why does Python scatter its standard libraries across half a dozen packages? Probably one of the biggest problems beginners have with Python is that they can never remember whether something is in os, os.path, sys, string, re, or whether it's maybe just a method on an object, or maybe it changed in some recent release. And you can't just safely import everything from those packages either.
Re: (Score:2)
Sys and OS. (Score:2)
BS argument (Score:5, Insightful)
both are right, sort of (Score:5, Insightful)
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.
Mod parent up. (Score:2)
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.
Re: (Score:2)
Guido should concentrate on getting things like the UI, the standard libraries, and package management straightened out
Commenting on these as someone who isn't a Python person at all...
They are both wrong! (Score:2, Interesting)
Those aren't the real problems with Python (Score:5, Insightful)
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.
Re: (Score:2)
I don't believe that's commonly done, instead many Java programs that require "dynamic" stuff reimplement Lisp in XML (with various degrees of completeness/bugginess).
AFAIK python is faster than perl. I don't know what the perl6/parrot people are doing, but I'd rather a faster perl5 first than a perl6 with lots of stuff thrown in.
I suppose doing stuff like that is hard a
Re: (Score:2)
Re: (Score:2)
Well if memory serves, researchers managed to build 'good' performance (half the C performance in some benchmarks) for Self which was quite dynamic language (a prototype based language in fact), thought I don't know if it supported threads..
Re: (Score:3, Interesting)
* Multicore support is a nonissue. CPython is too slow to need it.
Agreed, but CPython isn't the only implementation that has problems with multicore support. The psyco JIT compiler also has a global lock, and is fast enough for many compute intensive applications. But still doesn't benefit from multicores. The issue is that dictionaries and lists are expected to
Re:Those aren't the real problems with Python (Score:4, Interesting)
It is actually two issues.
First is Psyco, and any similar efforts in the future. Psyco, aside from not supporting anything but 32-bit x86, also is limited to a single core, despite being very, very fast -- in some cases, supposedly faster than C. In any case, that is the goal.
And if CPython is that slow, I'll take any performance boost I can get.
Second, it means that any other implementation that doesn't have a GIL is likely going to expose obscure bugs in existing python programs. Well, not bugs, but assumptions that only one Python instruction can run at a time. Not to mention the C extensions...
Well, first, no compiler is "easy". If it is, write me a C compiler that's half as good as gcc.
Second, it's been done. You mention LISP:
And yet today, there are very fast and useful LISP compilers, which do just what you said an "optimizing compiler" can't do -- they make LISP fast enough that it could probably be used as a replacement for C or Java (for most things), if it weren't for all those damned parentheses...
Well, CPAN is better than just about any language. Also, you were expecting to find cheese in the Cheese Shop? They're all out of that!
In any case, CPAN doesn't seem to be much better supported -- often, yes, a developer or two, working in isolation, maybe a bit of peer review.
Also, this is like the argument of Windows being better than Linux, due to number of apps. It's a sad reality that it limits options, but in my experience, Linux is better enough that I'd often rather do a little extra work to make Linux do what I want than buy a Windows program to do the same thing.
I don't think Python is quite there yet, though. Notice how pretty much every one of your Python complaints holds for Perl, except CPAN. But, if Python were fast enough, and had threading that worked, I'd be using it instead of Perl, no question. (For that matter, if Perl6 ever gets released, and if Python gets ported to Parrot -- not very likely, I know, but if it happened -- CPAN would suddenly become available to Python people.)
Which would be great, if it weren't for the fucking GIL. I hate that thing.
Then again, people are willing to deploy Ruby, so at a certain point, CPU is cheaper than programmers. Although I still wish I didn't have to choose.
Well, Perl hasn't replaced Java, and Java hasn't replaced C.
Frankly, I think one of these languages needs to step up and offer something compelling -- or I need to find the one that already has, and still isn't dominating. But I've been looking for years, and still haven't found something that's as dynamic and easy as perl/python/ruby, as portable as Java (even CORA, please), and as fast as C, even though I'm convinced it's possible.
Python needs to go on a diet (Score:2)
Re: (Score:2)
If you *must* use XML, ElementTree is built into Python 2.5.
Regarding GUI (Score:4, Interesting)
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.
Why do people pile on Guido (Score:3, Insightful)
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.
Re: (Score:2)
Re: (Score:3, Insightful)
Not if you tell the language what size tabs you're using, it can't. Or just stick to the standard of 8 spaces. Or use an editor which has whitespace normalization, or whitespace character display. Sure, it's a problem if you're trying to use the tools wrong. But if you stop trying to fight it and go with the flo
Strange Guido's reply (Score:4, Insightful)
- 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..
Re:Strange Guido's reply (Score:5, Interesting)
The problem is that Python does not distinguish between creating a variable and assigning a new value to an existing variable. This means that scoping doesn't work as well as it should. In particular, you can't do this: because Python cannot tell that the second v is the same as the first. You can access v from the Child() function, but you can't update it. There are ways around this problem, but they are ugly. That's why Python really uses self: so it knows which scope each variable belongs to. And it's a pain. There should be a way to explicitly specify the scope of variables without having to resort to ugly hacks. I am a big fan of Python, but it could be so much better...
Re: (Score:2)
Granted, its use should be pretty rare so that's not a big deal.
Myself I would have used Limbo's notation for declaration:
def Parent():
v
v = 5 #assignment
def Child():
v += 1
Child()
But I know that Pythoners don't like variable declaration..
Re: (Score:2)
I am interested to hear about nonlocal. That's almost the feature I was looking for. So thanks. Most informative.
I don't think it's a completely orthogonal issue, though, because if the scoping rules did work as in C++/Java, then there would be no need for either "self" or "nonlocal". But that would be a really major change to the language.
It's not the langauge, stupid (Score:3, Informative)
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.
Re: (Score:2)
Blow my mind. (Score:2)
Re: (Score:2, Informative)
Yeah, well (Score:3, Informative)
Plenty of time (Score:4, Funny)
Performance... CPU vs Programmers (Score:3, Insightful)
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
Re:Syntactic whitespace (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
The syntactic whitespace is hard to get used to and causes hard to find bugs.
Re:Syntactic whitespace (Score:5, Funny)
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.
Re:Syntactic whitespace (Score:4, Interesting)
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?
Re: (Score:2)
* regular {} blocks instead of semantic whitespace
I don't think this fits particularly well into Python's philosophy. {} are largely redundant, and whilst whitespace seems to cause you some issue, I've never had a problem with it. Lamdba's might benefit from this, but any multi-line lambda should be indented anyway, so you might as well use whitespace for that, too.
* non-trivial lambda-statements
This would be on my personal wishlist. Maybe some syntactic sugar that would turn this:
Into this:
Re: (Score:2)
RIGHT ON THE HEAD. Python is the perfect language for student homework. If they don't indent properly, their code doesn't even WORK.
Re: (Score:2)
Re: (Score:2)
http://clisp.cons.org/ [cons.org]
PArrot (Score:2)
Re: (Score:3, Funny)
Re: (Score:2)
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
Invisible+Control+Structures (Score:2)
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?
Re: (Score:3, Funny)
Re: (Score:2)
My point is, these things are kind of central to their respective languages. If you truly despise one of these central feat
Re: (Score:2)
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.
Re: (Score:2)
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.)
Re: (Score:3, Informative)
I love Python, but it's often just too slow!
Try this, in increasing order of work required (and likely reward).
One: try Psyco [sourceforge.net]. 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 [python.org]. 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: