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."

Comments

Bruce, Just a Make a New Language Then

[tjstork]

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!

Re:Bruce, Just a Make a New Language Then

[Aladrin]

There's 2 sides to that, though.

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

[canuck57]

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

[DigitalSorceress]

Of course, since Python was named after Monty Python's Flying Circus, maybe it should be one of these:

• Gumby
• Nudge
• Ni
• Creosote
• UnladenSwallow
• Albatros
• DeadParrot
• CheeseShop
• LiverDonor
• CrimsonPermanentAssurance
• AndNowForSomethingCompletelyDifferent
• Spamalot
• WhatsAllThisThen
• NudgeNudge
• Monty
• KillerRabbit
• Tim
• Lumberjack
• JudeanPeoplesFront
• Gourd
• Herring
• Shrubbery
• HungarianPhrasebook
• Jabberwocky

Something along those lines anyway

Re:Bruce, Just a Make a New Language Then

[Anonymous Coward]

Python 3000 is fundamentally incompatible with the current Python, retard.

Re:Bruce, Just a Make a New Language Then

[drgonzo59]

Finding code-slaves that will do everything you want exactly as it always has been is nearly impossible.

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

[hey!]

That's not right; you need to name the language after a comedy troupe or show. Then famous bits from that can be used to name features or releases.

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:Bruce, Just a Make a New Language Then

[Anonymous Brave Guy]

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:Bruce, Just a Make a New Language Then

[DohnJoe]

please, don't be such a troll. There's no conflict here, simply someone voicing his opinions about the new python version. It's his favorite language and he'd like to see it become even better.

Just make a new language, if you want something incompatible His point is that, since Python 3000 will be incompatible with the previous versions, this is the time to make some big changes which are currently not planned.

Re:Bruce, Just a Make a New Language Then

[HiThere]

Nah, he's already said he likes Ruby, so if Python won't go where he wants he could choose dRuby (distributed Ruby). He wants Python to do it because he's more productive in Python. That's a good reason.

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 only continue but intensify.

OTOH, I've seen arguments that a data-flow architecture is inherently better suited for that environment, and I've seen at least one decent language to program in that was data-flow. (Prograf. It showed up for the Apple][ lc, which only had one processor and not threading capability to speak of. It died attempting to transition to MSWind95. It had problems as well as a lot of promise.)

Perhaps Python could add a dataFlow library? The library would need to be coded in C or some such (C is traditional for Python libraries). Perhaps it would need to be an "along side" langauge, like Pyrex. That would tend to have the problem of never having the syntax match that of Python...quite, but there might be compensatory advantages.

At all events, I'm not sure HOW the problem should be solved, merely that it NEEDS to be solved. And this is the reasonable time to address any necessary changes.

P.S.: I also agree that threads, and processes that are handled like threads, are an inappropriate solution. This doesn't mean that I know what the best solution is, merely what it isn't.

N.B.: This is a more than trivial problem, because of all the different levels of parallelism that are out there. Some of them don't HAVE any shared ram. (Think computer clusters.) Some of them have LOTS of shared RAM (think multi-core machines). Some don't share cache ram, but share system ram (multi-processor). And a good solution will need to handle these cases transparently. When you write on one system, you can't be expected to know the environment in which you'll be running. (Perhaps clustered computers could be split out to be handled separately. Those who are running computer clusters are still expected to be knowledgeable at the hardware level.)

Re:Bruce, Just a Make a New Language Then

[jasquigl]

Personally, I think you missed the perfect name: HolyHandGrenade

Re:Bruce, Just a Make a New Language Then

[The One and Only]

Pedantry: By definition, you decimate your army by killing 10%. If you select 1% of your army and decimate that, then you only kill 0.1%. And it's really not like decimation at all--if someone doesn't fit into the project, their departing the project just improves cohesion. Decimation was intended to terrorize the troops.

Re:Bruce, Just a Make a New Language Then

[VGPowerlord]

While I agree, if he wants something that's fundamentally incompatible, but wants to still call it Python, that's silly.

You know, I said something similar to this about Larry Wall, Perl, and Perl 6.

Re:Bruce, Just a Make a New Language Then

[Anonymous Coward]

You don't just fork a language, for all sorts of mostly political reasons. Using a different language is certainly an option -- these days it's not even unreasonable to bundle the entire language interpreter along with your program. Perhaps if Ruby 2.0 ever happens, there will be some additional pressure on python to improve, but right now the competition isn't there. Sure as hell ain't Perl 6.

Guido has himself said that he'll accept patches that remove the Global Interpreter Lock, IF they don't hurt performance AND they don't overly complicate the C API. I don't think that's too unreasonable.

Re:Bruce, Just a Make a New Language Then

[nwbvt]

Yeah, thats just what the world needs, yet another scripting language influenced by Python.

I think 'conflict' is a bit strong, Bruce merely wished there were more changes in Python 3000. And his biggest problem (the GIL) Guido is actually open to changing, assuming the change wouldn't be murder on performance like the last attempt to remove it.

Its sort of sad that we assume by default what they are engaged in is some sort of flame war...

Re:Bruce, Just a Make a New Language Then

[Anonymous Coward]

> Perhaps Python could add a dataFlow library?

Already done in PyPy (it's actually an "object space", which is more like a global behavior switch). Not going to happen in CPython, since dataflow variables require some pretty radical rethinking of the underpinnings. Maybe if someone ported Python to Alice.

Re:Bruce, Just a Make a New Language Then

[Bodhammer]

What about "Every Sperm is Sacred"? It doesn't exactly flow off the the tongue (so to speak) but it is reverent to Monty Python...

Re:Bruce, Just a Make a New Language Then

[chromatic]

Doesn't the creator of a work have the moral right to name that work?

Re:Bruce, Just a Make a New Language Then

[cibyr]

Stackless Python, anybody?

Re:Bruce, Just a Make a New Language Then

[drgonzo59]

terrorize the troops.... terrorize the developers -- eh, what the big difference? ;-)

And by decimation I meant the practice of eliminating/killing/firing in general, not specifically the Roman practice of killing every 10th, from which the term originated, of course.

Bad link?

[albalbo]

First link should probably be to http://www.artima.com/forums/flat.jsp?forum=106&thread=214112 .

Python

[Bastard of Subhumani]

That's the one where the control structures are all invisible, right? I'll give it a miss, thanks all the same.

Re:Python

[An Onerous Coward]

This has been a public service announcement from the Society for the Preservation of Curly Braces.

Re:Python

[totally bogus dude]

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.

Re:Python

[Anonymous Coward]

Maybe it's displaying it, but as invisible spaces (with a pinkish tint)?

With a song and a dance

[SEWilco]

Shouldn't Python 3000 include a giant animated foot and silhouettes of the audience cracking jokes?

Re:With a song and a dance

[Anonymous Coward]

I think that's called GNOME.

Solved problems

[Watson Ladd]

Python, meet Haskell and Erlang.

Re:Solved problems

[SanityInAnarchy]

It's not even an issue of better support for concurrency in the language itself.

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:Solved problems

[ubernostrum]

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.

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 dealing with sharing data in memory between tens or hundreds of thousands of threads spread out over them? Having a program run as a single process with huge numbers of threads -- as practiced by the Java world and egged on by people who don't know any better -- is largely a hack designed to deal with running on operating systems which, at the time, didn't have true multitasking. Seeing as that's not so much of a problem these days, and seeing as how there are very good concurrency models based around lightweight IPC, do we really want languages to be chaining themselves to it?

Re:Solved problems

[ubernostrum]

Python, meet Haskell and Erlang.

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 going to realize that other languages which already have great libraries available have nicked all the cool features.

Haskell.... is a mess. When you can write non-trivial programs in Haskell without needing a post-graduate degree in category theory, I'll take another look, but right now I read Haskell tutorials and I keep expecting Geordi to call up from Engineering and tell me I need to reconfigure the phase emitters for an inverse tachyon pulse; all of the Haskell documentation beyond extremely basic things basically consists of technobabble right now.

Re:Solved problems

[GooberToo]

I agree, in this day and age, not having a plug to remove the GIL is beyond stupid.

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, on the other hand, essentially means python is single threaded unless your work is being done outside of the interpretor, which likely means there is no point in writing it in python.

To add insult to injury, python's process model sucks so if you want to go the fork model, things which should be easy in a high level language like python are as much a pain as they are in C, or almost so. Thus ultimately means if I have a need to take advantage of multiple cores and CPU bound, you're probably better off writing it in C/C++ than python. If on the other hand, I'm IO bound, and threading is desired, python is still attractive. In fact, python is very attractive for network servers.

So yes, the GIL is brain dead in this day and age, and will continue to become even dumber as days roll by, but threading + multi-core is not completely without merit in python.

Re:Solved problems

[Anonymous Coward]

"Spawn a process" is a 50% answer because it only works for situations where you're not sharing memory. What about all those people who need concurrency AND shared memory? What about those who don't want to spend the time to rewrite their programs?

For example, an image processing algorithm is often trivial to make multithreaded, usually by dividing up the scan lines in the image among the processors. Instead of a single loop over each scan line, create N threads that process 1/Nth of the scan lines. If you have to do this with separate processes, each process has to copy its results back to the parent. If the algorithm is iterative, each process may need the previous iteration's results from each of the other processes. This copying overhead is probably enough to make concurrency not worthwhile.

Can you imagine a rendering pipeline where all the geometry and textures have to go from one process to the next?

In another situation, I have a server written in C. At some point it was decided that users should be able to add Python scripting to do custom processing, so this server now hosts CPython. It is trivial to make each script a separate thread so they can all run at once, but due to the GIL only one can run at a time. If I tried to make each script a separate process, not only would there be an explosion of processes, but they would be unable to access the server's state. This means that I either have to rewrite the server (not likely) or move to a scripting language that properly supports threading.

dom

Re:Solved problems

[ubernostrum]

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:Solved problems

[Anonymous Coward]

On the other hand, most people don't write the inner loops of cpu heavy graphics processing in Python. If you're using Python as 'Fortran with nicer syntax', you're doing something very, very wrong...
For image processing, consider using a C extension for the intensive bits. IIRC, they can spawn threads that are independant of the GIL.

Re:Solved problems

[Anonymous Brave Guy]

Down the road when you have, say, 200 cores, do you really want to be dealing with sharing data in memory between tens or hundreds of thousands of threads spread out over them?

I don't know, and I'm pretty sure you don't either. Both shared state and non-shared state concurrency have potential given the right language/environment tools to support them. No-one really knows yet whether shared state will ever scale to many interactions rather than the small numbers typically used in today's research on transactions etc. Nor does anyone really know yet whether unshared state models will ever be viable for general high performance applications where the overheads matter. If I were a betting man, I would wager that non-shared state concurrency will come to dominate "high level concurrency" wherever it's viable, but for the nitty gritty stuff that needs to be fast, shared state will be the only credible choice, though based on a more powerful, more compositional and less error-prone formal model than the manual locking and such we often see in industrial languages today. The one thing that seems pretty certain, though, is that handicapping your entire runtime environment in such a way that one major approach to concurrency is effectively impossible isn't a smart move in the long term.

Re:Solved problems

[ezdude]

I agree with you. Eckel's point that concurrency can make Python "slowness" irrelevant is a good one, but it's even better if we substitute Haskell for Python, or maybe functional programming, in general. Haskell is a hard language to learn, no doubt. But I am trying, for exactly the same reason Eckel thinks Python can be improved. With Haskell there is already a path to "simple concurrency", or at least, simpler than will be the case for dynamic languages like Python.

Re:Solved problems

[try_anything]

Concurrency is hard. Processes can't change that. The putative safety difference between threads and processes is mostly based on a comparison of very simple multiprocess designs with very complex multithreaded designs that use fine-grained locking. If you can use a "very good concurrency model" that's already implemented for your platform then you will be much better off in the long run, of course, no matter whether it's implemented on top of threads or processes. If you use a complex design based on intricate locking patterns, then you may never get it completely right. Ah, but it's rather impractical to do intricate fine-grained locking with processes, so nobody makes the mistake of tackling hopelessly complex locking problems when they're using processes.

In other words, the standard argument for processes over threads is pretty much the same as the (primary) one Linus uses for C over C++: If you use threads/C++ then you're going to do all kinds of stupid complicated things and doom yourself. If you use processes/C then you'll magically see all the simple designs that you overlooked when you were using threads/C++, because you have no choice. That isn't universally true; not everybody is frothing at the mouth to do all the nasty complicated things their tools allow.

do we really want languages to be chaining themselves to it?

It isn't crack. Making it available isn't the same as chaining people to it.

Re:Solved problems

[SanityInAnarchy]

Python has multicore support; it's called "spawn a process".

Hey, why didn't I think of that?

Yeah, I'll file that right along with having my program invoke gcc as a way to add dynamism. Yes, it can be done, but it's ugly and slow compared to the right way.

I'll give you this much, though: Processes are a lot easier to scale across machines. However, I'd much rather see the distinction start to disappear -- there are cases where, even if you're OK with the semantics of copying data back and forth, you simply can't deal with the performance implications.

Oh, and by the way, one other thing Java did right: You can run untrusted code in the same process as trusted code. An operating system written in Java would not need traditional processes, except for legacy apps that don't run on the JVM. (I'm not advocating either Java or the JVM for this purpose, though; there are better ways of doing the same thing.)

Re:Solved problems

[SanityInAnarchy]

I agree, in this day and age, not having a plug to remove the GIL is beyond stupid.

Well... Not so much stupid as lazy. Stupid that they don't think it's worth spending the effort, but also, they do claim it'd be hard to do -- and, for some things, it would be.

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.

Yeah, at which point, it doesn't matter, because when your process is I/O bound, you can write it in Ruby, PHP, JavaScript, whatever you want. It has nothing to do with multiple cores, then.

The only way it could possibly involve the second core is if it's reading from / writing to a CPU intensive process, in which case, it really doesn't matter whether Python uses OS threads or green threads, the result is the same.

CPU bound tasks, on the other hand, essentially means python is single threaded unless your work is being done outside of the interpretor, which likely means there is no point in writing it in python.

Well, there is one: If you are very careful, you can use external libraries to do the heavy lifting -- stuff like crypto, compression, image processing, whatever -- stuff that's all been done many times over in C. Modules that are written properly can release the GIL, do some CPU crunching with stuff that doesn't touch Python internals, then acquire the GIL again to pass the results back to the script. The point of Python here is to be a high-level scripting language, to tie all these pieces together.

However, this attitude annoys the hell out of me. It's pervasive -- Perl, Python, Ruby, PHP, pretty much all so-called general-purpose high-level "scripting" languages use the cop-out of C-based extensions as an excuse for poor performance. To me, this says that these are not general-purpose languages. They're more architectural languages -- more powerful than Bash, maybe, but basically doing the same job Bash does with init scripts.

So, yes, there's still a point in writing in Python -- it's one of the best we've got. But what does that say about us?

To add insult to injury, python's process model sucks so if you want to go the fork model, things which should be easy in a high level language like python are as much a pain as they are in C, or almost so.

This was discussed awhile ago -- it may be possible to take one of the various micro-thread models, or even just a threading model, and port it to processes. Not a lot of them, just one per core, maybe. Python does have ways to access shared memory (as a method of IPC), and it's possible that other models could be used -- pipes would suck for performance, but would be cool for transparently porting a program to the cluster.

But at this point, we'd basically be building a scheduler / process model on top of another scheduler / process model, because they're too lazy to remove the GIL.

Re:Solved problems

[vrmlguy]

"Can you imagine a rendering pipeline where all the geometry and textures have to go from one process to the next?"

Yes, several. X11 involves, at a minimum, both server and client processes, while graphics accelerator cards use at least one entire other processor that you have to coordinate with. Finally, the PS3 uses its cell processors quite well for rendering. The trick to getting good performance in all of these cases is to use shared memory. You just need a good system of communicating between the processes to keep them from stepping on each other's toes.

Re:Solved problems

[GooberToo]

Sounds like we're on the same page. Death to Python. Long live Python. ;)

Re:Solved problems

[Just Some Guy]

Down the road when you have, say, 200 cores, do you really want to be dealing with sharing data in memory between tens or hundreds of thousands of threads spread out over them?

Do I want that as an option? Oh, yeah. Consider a multi-processing map() replacement that I'd been playing around with. The fork()ing version is much more complicated than a threaded version would need to be because you have to serialize return values, and is less capable because it's unable to return any values that aren't serializable (such as sockets or file handles).

Yes, all that complexity can be a nightmare, but sometimes that nightmare is actually preferable to the alternatives. As it stands today that's not a choice that I get to make.

Re:Solved problems

[Sloppy]

Consider a multi-processing map() replacement that I'd been playing around with.

Wow, very cool. Yeah, this is the kind of stuff we need. I understand and partially agree when some people complain about the "difficulties" that go with shared memory, but sometimes, multiple threads really just don't conflict, and map() is often such a case. We need ways to be able to take advantage of massive multithreading when it's appropriate, because sometimes it really is. Darn GIL. Kudos on looking into a parallel map(). You the man!

Re:Solved problems

[Just Some Guy]

Thanks man. It's nice to feel appreciated. :-)

You hit it right on the head, though. It's a shame that a massively multithreaded version is more or less impossible right now. I'd love to benchmark a threaded clone of that function on a big SMP system without any of the inherent penalties of fork.

Python2Perl?

[Doc Ruby]

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.

Re:Python2Perl?

[afd8856]

What crack are you on? Where's Perl on JVM, or on DLR, btw?

Re:Python2Perl?

[Doc Ruby]

I'll do the stupid thing first

Perl has been compiling scripts to intermediary interpreted code since the beginning. You know nothing. Just how to do the stupid thing.
Shut the fuck up, asshole.

Re:Python2Perl?

[jma05]

> 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.

Re:Python2Perl?

[k8to]

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.

Re:Python2Perl?

[larry bagina]

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.

Re:Python2Perl?

[Doc Ruby]

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?

Re:Python2Perl?

[Anonymous Coward]

Is there a tool that converts Python scripts to Perl I am not sure why anybody would want this.

compiles them into the opcodes that Perl's interpreter actually executes It has already been done for .NET and JVM. You are more than welcome to write one.

possibly avoiding all those architecture limitations that the Perl engine has already solved. What architecture limitations are you talking about? Python runs on the same operating systems as Perl.

Re:Python2Perl?

[Anonymous Coward]

But without having to deal with the Python runtime environment, especially given the limitations mentioned in the story we're discussing.

Did you READ the article? Most complaints had ABSOLUTELY NOTHING to do with the runtime environment. Those that do aren't improved much in perl (have you tried concurrency in either language?). The complaints dealt with libraries and components.

You can still maintain that the perl runtime is somehow better, but you certainly haven't given any evidence of it.

Re:Python2Perl?

[Doc Ruby]

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.

Re:Python2Perl?

[Doc Ruby]

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.

Re:Python2Perl?

[Waffle Iron]

A significant portion of Python library calls are actually implemented in native C code. Almost any python script is going to make use of a lot of these native libraries, which actually comprise the vast majority of the size of a python distribution. If you've ever seen C python extensions, you'd see that this C code is intimately coupled deep into the Python VM, including direct access into of various publicly defined Python VM C structures.

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.

Re:Python2Perl?

[Wheat]

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 ...

Re:Python2Perl?

[Anonymous Coward]

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.

Isn't that what Perl6 promises to be able to do?

Oh and as someone who migrated from Perl to Python, my advice would be not be quite so close minded about learning a new syntax ;) (Yeah, I know, that's exactly what you wanted to hear!)

Re:Python2Perl?

[kraut]

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.

Re:Python2Perl?

[Doc Ruby]

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.

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.

Re:Python2Perl?

[k8to]

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. This is essentially true, which is why the idea of compiling one to run on the other is ridiculous. Thank you for agreeing.

Re:Python2Perl?

[k8to]

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.

staying with an old version -- how?

[bcrowell]

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.

Re:staying with an old version -- how?

[Niten]

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:staying with an old version -- how?

[__aaclcg7560]

It'll be like the current situation with PHP. PHP4 and PHP5 been out for ages, but only recently has the death knell for PHP4 been announced. The fun comes when your development system has the latest version but your target server has the previous version. You quickly become expert in compromising hacks.

Re:staying with an old version -- how?

[afd8856]

Even more, on Ubuntu (but I think also on Debian), there's the pycentral folder in /usr/share, where folders (software) can be installed that provide python packages for several python versions.

Re:staying with an old version -- how?

[Anonymous Coward]

Yes, and I understand Perl 7 will automatically correct syntax errors!
Don't get me started on Perl 8. Sweet, sweet stuff.

Re:staying with an old version -- how?

[bcrowell]

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.

Wow, they break compatibility with every dot release? That sounds crazy to me. It means you have to have a ton of versions of the languages installed (I checked, and I have 3 versions of python installed on my ubuntu box), and I would think it would produce huge problems with libraries. What if you write an open-source library using python 2.4, it's done, it's solid and debugged -- then python 2.5 comes out, and programmers start complaining because they can't use it with their python 2.5 projects. Are you just expected to keep on fiddling with your code for the rest of your life, whenever a new dot-release of python comes out? And you also presumably end up maintaining the old versions of your library as well, since some people are depending on those...? Ouch.

Re:staying with an old version -- how?

[Chandon Seldon]

Are you just expected to keep on fiddling with your code for the rest of your life, whenever a new dot-release of python comes out?

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 of "open source" software - the person who keeps a program up to date can be different from the person who initially wrote it.

Re:staying with an old version -- how?

[Poromenos1]

According to Guido the language differences aren't going to be so huge that code can't be ported, I think he said that something like 90% is going to already run, and there will be tools to help you locate and convert the other 10%.

Re:staying with an old version -- how?

[VGPowerlord]

What? You thought you could just write software and then it would work forever?

Believe it or not, yes. That's how it works in languages like C, C++, and Java.

This actually causes people to complain about the size of Java's standard library because deprecated features are never removed.

Re:staying with an old version -- how?

[Niten]

You misread my post. Point releases of Python are generally backwards compatible, aside from a few minor differences which aren't an issue for most programs. All I was saying is that, should you find yourself in one of those edge cases where it is necessary to run your program under a specific older version of Python, it's generally easy to do so.

Re:staying with an old version -- how?

[Anonymous Coward]

Actually, Python is generally pretty careful about backwards compability. That's why 3.0 is such a big deal in python-land, it's pretty much their only chance to remove old cruft and fix broken stuff.

Re:staying with an old version -- how?

[Anonymous Coward]

Yeah, because problems with moving Java applications between different VM version and platforms are simply unheard of.

Re:staying with an old version -- how?

[turbidostato]

"The fun comes when your development system has the latest version but your target server has the previous version. You quickly become expert in compromising hacks."

You mean... like never do such an idiotic thing as having a development environment that doesn't match your production one?

Re:staying with an old version -- how?

[Chandon Seldon]

Believe it or not, yes. That's how it works in languages like C, C++, and Java.

Sure, "Hello World" still works. But not any application that has to interface with anything interesting.

There are probably some examples of C applications for Solaris or AIX from the early 90's that still work perfectly, but that's an exceptional case. Hardware platforms change. New interfaces are introduced, and even if the old interfaces aren't dropped they're still susceptible to code rot.

At best, a very stable language based on a custom runtime system (say Java or Erlang) might be able to run a program that's 15 years old (Java isn't actually that old yet, but there might be Erlang programs or maybe some odd LISP dialect). Even then it's wildly unlikely because the environment the program has to interact with has changed so radically.

Not that any of this really matters - any non-trivial program that gets used for anything relevant will have to be constantly maintained to fix bugs anyway.

Re:staying with an old version -- how?

[pavera]

You obviously have very little experience with java programs.

All java programs require some version or other of java, and if java has made incompatible changes (they have) between releases, you need 2 versions of the JVM to run 2 different programs (if those programs require says 1.4 and 5 respectively). This can be extremely fun, especially since each JVM is going to take up 2-300MB of ram...

I have seen this problem deploying enterprise java apps hundreds of times, it is pretty much constant "Oh, I want to run App1 version 3.2 which requires Java 1.3, I also want to run App2 version 6.4 which requires Java 6" Have Fun!

Re:staying with an old version -- how?

[Wheat]

> Wow, they break compatibility with every dot release? That sounds crazy to me

That would indeed be crazy. Python has not had any significant breaks in backwards compatability since I started using it in 1999. You can run a Python 1.5 or Python 2.0 program just fine in a Python 2.5 program. Of course, if you are taking advantage of a language feature introduced in Python 2.5 of course you can't run it in a earlier release.

There are a few exceptions, such as code that interfaces with C has had changes. But Python developers have put a lot of time and effort into maintaining backwards compatability. This is the point of breaking backwards compatability in Python 3, and the current Python 2.5 implementation has a lot of verbose, length code that deals with a lot of corner cases that almost no one uses. Python 3 is about fixing all those small things that you can't fix without breaking backwards compatability, and about ditching all that backwards compatablity that is in Python 2 that makes maintainence and optimization that much harder.

Re:staying with an old version -- how?

[__aaclcg7560]

It's not my fault that the ISP is not using the latest and greatest in web technologies. That's the problem with being on the bleeding edge. :P

Re:staying with an old version -- how?

[Nevyn]

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.

Many? Debian (and "inherited" distros. like Ubuntu) does. Fedora doesn't (and "inherited" distros. like CentOS) doesn't. Is that common on win32, on FreeBSD? I didn't think so. Also saying "just use update-alternatives" to change your system Python is insanity IMNSHO, either you are using it and doing the above will almost certainly break something ... or you aren't and should just stick with the default. Note that I'm not saying having a /usr/bin/python-2.3 isn't useful, just that changing what /usr/bin/python points to is a very bad idea.

And before this turns into a flamewar against Fedora, my bet is that the major reason Fedora don't allow different version of Python and Debian do is that Fedora has a huge amount of "core" code written in Python while Debian have almost none.

Re:staying with an old version -- how?

[Chrisq]

between releases, you need 2 versions of the JVM to run 2 different programs (if those programs require says 1.4 and 5 respectively).
I believe this is wrong. JVMs (though not always javac bytecode compilers) are backwards compatible. You could run a 1.4 program on a 1.5 JVM. You could probably compile it, unless you happened to have used one of the new keywords as a variable name or something similar.

Re:staying with an old version -- how?

[turbidostato]

"It's not my fault that the ISP is not using the latest and greatest in web technologies. "

Maybe. But it is certainly your problem if you develop on a platform different from the one you know it's going to be your production one. You can choose *your* environment, right?

Re:staying with an old version -- how?

[petermgreen]

Java is supposed to be backwards compatible and much of the time it is but you still get the odd app that fails to run on a new version of java due to either bugs in the new version, relying on non public classes, or relying on behavioural subtuleties that aren't fixed by the spec.

Re:staying with an old version -- how?

[bcrowell]

any non-trivial program that gets used for anything relevant will have to be constantly maintained to fix bugs anyway.
A counterexample: TeX.

documentation

[Anonymous Coward]

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.

Re:documentation

[afd8856]

I used to think something along these lines as well, when I moved from php to python, long time ago. But now it's really not an issue if you download the Python CHM help file and either use its index or navigate the Library Modules section. Also, I used to like that the php help section on the site has comments with code and everything, but looking back, these just really promote stupid recipes, with stupid tricks, full of bugs and insecurities. My 2 (euro)cents.

Re:documentation

[Niten]

Huh. One of the things that really attracted me to Python was the (perceived) quality of the Web documentation. The Python Tutorial and Python Reference Manual 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 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:documentation

[psavo]

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

[Waffle Iron]

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?

/usr/share/doc/python/html/lib/lib.html

Re:documentation

[Cheesey]

That's a very unusual complaint about Python, which has great documentation. http://docs.python.org/ has info about everything bundled with Python (this is big -- "batteries included"). You can also get help from the Python interpreter by calling the built-in help() function, which takes a module, class or method name as a parameter. help() also works for many third party Python extensions.

I am surprised that none of your searches took you to docs.python.org. But perhaps you were using lots of third party extensions with their own documentation.

Re:documentation

[ardor]

One example says more than enough:

http://docs.python.org/lib/module-SocketServer.html

I had to google a lot of missing info to be really able to use SocketServer.

Re:documentation

[jadavis]

If they really want to help Python, build some online documentation that [isn't bad]

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:documentation

[rg3]

It is insulting that you say that, and you deserve being modded down. I started learning Python with the official tutorial, which is completely clear and exposes you all the language features in an afternoon. There is also a module index that contains the documentation for the different modules, exposing the objects, functions and constants from every module, as well as a list of modules. There's the library reference, that exposes all the modules (again, grouped by topic), all the built-in functions, data types and operations, etc. There is also a document describing the syntax in detail. There is also a document explaining how to embed and extend Python. Complain about its syntax, the way it does some things. Whatever you like to whine about. However, the Python documentation is excellent. No discussion allowed, coward.

http://www.python.org/doc/

Re:documentation

[TheLink]

I personally found the perlfaq(s) and the various other perl manpages (e.g. perlipc) a lot more useful than docs for practically any other programming language I've encountered.

The syntax and "Computer Science/Academic style description" of a language are not usually the most difficult bits (there are some exceptions of course ;) ). It's the nitty gritty details in the perlfaqs and similar that I find more useful.

I mean, after reading "formal/academic" docs I'd know how to do "Hello World", "fibonacci", etc in the language but how about stuff that doesn't look like someone's CS homework ;)?

e.g.
Signal handling: "Handling the SIGHUP Signal in Daemons", "How do I avoid zombies on a Unix system?"
Or making diagnostics easier (esp for others):
"How do I tell the difference between errors from the shell and perl?"
Or:
"How do I do fancy stuff with the keyboard/screen/mouse"
"How do I use an SQL database?"

man perltoc for more. A lot of stuff covered and probably already included on the system if you're running a typical Linux distro or FreeBSD.

Some of the stuff covered is not so easy to find/figure out for other languages.

Re:documentation

[rhadc]

Exactly. Python has tons of documentation, and none of it is easy to use. Even O'Reilly blew it by using the "Programming Python" title for what should have been the Python Cookbook. Sometimes you just want a straightforward language reference. Why is this so hard?

Re:documentation

[voidy]

The IDE that comes with python, IDLE, lists arguments for a method as you type it (after typing the leading parentheses). The way the documentation is actually integrated in to the language itself is also fantastic, and the python quick reference is brilliant too, as well as the tutorials and other documentation available. If you use an IDE like Pida, then you have documentation available just a tap away too. I don't think the argument about the documentation being lacking really stands up to muc, and the fact is, that once you know about the language, it's so intuitive that you really can just learn new classes/libraries without too much effort. In fact, with ipython, or with a few lines of startup script for the python interpreter, you can have tab completion of classes, methods and variables. This is just fantastic for finding your way around the language and various modules.

Something to note about PHP, and the learning to use it element is that a lot of naming conventions and the like are totally inconsistent, which reflects the roots of PHP really. It never started as a large and comprehensive language, the name says it all 'Personal HomePage tools'. Python however was created to be elegant and consistent. it really does succeed in that goal. Where pyton really doesn't stand up to PHP is in the way it weaves in with HTML, but python is a general purpose programming language, not really a web language.

I don't want to say that PHP sucks, and perl and python are fantastic... but I just said it, so there!

losing the print statement

[mathgenius]

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.

Re:losing the print statement

[Anonymous Coward]

My main problem with python 3.0 is the loss of the print statement!

Why? I was a Python programmer for 3 years, and the print statement was one of the most obvious warts.

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).

Is print("hello, world") unfriendly? I don't see why. Plus, if you're new to the language, it'll save a lot of explaining later when you ask "Why do I not need parens for print?".

There needs to be tools that are %100 reliable that can convert code from 2.6->3.0.

In general, it's impossible to convert code from one language to another 100% reliably, unless the differences are truly trivial. And if the differences between 2.6 and 3.0 were truly trivial, there'd be no reason to break compatibility and call it "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.

Oh darn? It's happened before, and they lived. I'm sure Guido would be interested in your ideas on how to run a successful open-source language implementation, 'mathgenius'.

Re:losing the print statement

[Yath]

I think the dumb simplicity of python's print statement is one of my favourite python things.

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 ... unless they're experienced with Python.

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:losing the print statement

[blank axolotl]

boo hoo

Instead of:
>>> print "Hello World!"

you now have to do
>>> print("Hello World!")

just two extra paretheses, and no more of this >> stuff.

Re:losing the print statement

[Bob of Dole]

It maps almost perfectly onto QBASIC:
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:losing the print statement

[Just Some Guy]

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.

Re:losing the print statement

[WilliamSChips]

Interestingly, the syntax it uses was something I liked about it. It felt a lot less kludgy than having print/println, and it has the most common use as the simplest.

Re:losing the print statement

[a.d.trick]

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.

Oh darn? It's happened before, and they lived. I'm sure Guido would be interested in your ideas on how to run a successful open-source language implementation, 'mathgenius'.

Well python is much larger now, so the effects of a new version will be more profound. However, I don't think it's as bad as the GP makes it out to be and we're not in a hurry anyways. Python 2 is pretty good.

Re:losing the print statement

[massysett]

Agreed. I cheered when I saw that Python 3 won't have a print statement. I once looked at the Python reference manual on print, and it was so dense that I found it to be less trouble to simply ditch the statement entirely. For all tasks except those most trivial I use sys.stdout.write(). At least then I know what the interpreter is going to do, without the funny "print" business of "softspace" and such.

For a language that says "explicit is better than implicit", there is a lot of funky stuff going on with the print statement. Good riddance to it.

Re:losing the print statement

[Nevyn]

While I agree that having to do print("Hello world") instead of print "Hello world" is going to be painful (tm), I can't help but feel that it might be worth it if only so that print won't have the horribly ugly warts on the language it does now.

"print >>os.stderr, 'foo'" has to be the ugliest thing in the language, and "print 'foo'," is probably second.

Of course I don't think they needed to sacrifice backwards compat. to add the new syntax, but given an either or choice I'd probably go for breaking everything ... but then I'd also choose brackets, so I'm probably given a minus vote for making Python decisions :)

Re:losing the print statement

[kiso]

that's what i hate about python - when you do a major upgrade, most of the older python scripts cease to work. that creates a bigger problem in redhat linux es, where most of the system administration tools are written in python. the language itself might be great, but the administration/maintenance is a pain in the neck.

Re:losing the print statement

[Phoe6]

You are right. This is as per design in python2.6 (and below) and I dont know if addition of () is removing this feature in py3k, in which case, it is a welcome move.
The 2.6 (and below) language reference says that print is designed to output a space before any object. And some search goes to find and that is controlled by softspace attribute of sys.stdout.
Way to print without leading space is using sys.stdout.write()

I have kept a note for myselfhere.

Re:losing the print statement

[Nosklo]

you can't just type "map(print, listname)" or anything else as compact and "clean". And in Python 3k you won't be able to do that either, because Map now returns an iterator object and that would result in no function actually being called unless the iterator is used. One good solution would be to:

[print(line) for line in listname]

Re:losing the print statement

[crucini]

In general, it's impossible to convert code from one language to another 100% reliably, unless the differences are truly trivial

And yet I know of a program that converts C into x86 machine language quite reliably. I'd say the differences are more than trivial.

If you can stomach a long, discursive essay, please read Rich Programmer Food.

Re:losing the print statement

[Anonymous Coward]

Granted, it may be difficult to get the print statement to output the exact whitespace characters you wanted, but this is not important for the bulk of its use. The print statement most valuable as a gentle introduction to the language and for quick debugging output. In neither case is it particularly important to have the correct whitespace, and in both cases it's much easier to type "print" than "sys.stdout.write('___\n')".

It's nice to be able to write "Hello, world" in a single line, so that the Python student can immediately start to learn about variables and operators rather than having to first learn about minutia like importing packages, object dot notation, method invocation, and whitespace escaping in strings... and without invoking the standard Java refrain: "Trust us, you really need all this boilerplate just to output two words; just ignore it for now, but don't screw up while typing it all in."

in mother russia

[Anonymous Coward]

python codes you!

version number or marketing?

[Anonymous Coward]

Usually such a big jump in version number is done in two steps. For example you'd go from 3.1 to 95, and then from 98 to 2000.

Re:version number or marketing?

[wootest]

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.

Compiled Python 3000?

[Anonymous Coward]

I love Python, but it's often just too slow! Based on the profiling I did, it is the interpreted nature of Python that is at fault. What I think would be great is if Python 3000 were to also include a native code compiler. Maybe it could be built off of GCC or LLVM to make the work go faster? In college I had to use OCaml, and it had both a bytecode and a native code compiler, and they were both well supported. OCaml is a lot like Python in many ways, so I think maybe it could be possible to do the same with Python. I would do it, but I just don't have the skills necessary. :( If I wasn't so busy as a nurse, I'd try to learn more about compiler design.

Re:Compiled Python 3000?

[HiThere]

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.)

Re:Compiled Python 3000?

[Just Some Guy]

I love Python, but it's often just too slow!

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:

output = []
for value in input: output.append(transformfunc(value))

is longer to type and possibly vastly longer to execute than:

output = [transformfunc(value) for value in input]

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.

Re:Compiled Python 3000?

[Anonymous Coward]

This is the thing that makes me laugh my ass off : people saying Python is not slow if you use Python libraries implemented in C. Yeah, of course. But then why should i need Python ? there's already a much, much better language, and with a much faster implementation, LUA. LUA is a simple, clean, fat-free language made to script existing C and C++ libraries and to be embedded in middlewares.
Saying python is not slow when you are not writing pure python code is ridiculous. Python is reinventing the wheel, then, by having a large standard lib no better than what C and C++ already had. Just bind already existing ones to LUA and script them as you wish, it's the same as using Python.

Java proved itself as a language and implementation. Everything, except the JVM itself is written in Java. All the libs are in pure Java.
Lisp even more proved itself. There are multiple implementations of lisp written in lisp, and some lisp are even faster than Java (SBCL for example).
Lisp is more powerful than Python. You can extend the language with macros in any way you see fit. Lisp is as much dynamic as Ruby and Python are. Lisp is as much object oriented as any language can be if you want it so. (it spawned multiple object orientation implementations, including the most popular one, CLOS)
Lisp is functional, much more so than Python or Ruby. And it has optional static type declaration that can help the compiler make faster code. It has the best of all the worlds. It's imperative ? check. It's functional ? check. It's object oriented ? check. It's dynamically typed ? check. IT CAN ALSO DECLARE STATIC TYPES ? CHECK!!!

Lisp can do everything those languages do and much more. Why Ruby and Python exists is a mystery for me.

Re:Compiled Python 3000?

[Just Some Guy]

This is the thing that makes me laugh my ass off : people saying Python is not slow if you use Python libraries implemented in C.

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.

Re:Compiled Python 3000?

[tzot]

// 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).

Python++?

[Zackbass]

Why not just call it Python++? Oh, that's right, Python doesn't do that.

Re:Python++?

[Anonymous Brave Guy]

You want to add something to Python, but only wind up with what you had before anyway? :-/

Re:Python++?

[julesh]

Python = Python + 1 just doesn't have right ring to it, does it?

Re:Python++?

[StarfishOne]

I'd say there's nothing wrong with Python += 1

Re:Python++?

[kalleh]

Python += 1

Re:Python++?

[Anonymous Coward]

It's certainly a long way ahead of ADD 1 TO COBOL GIVING COBOL.

Decimal point is wrong...

[__aaclcg7560]

The python mathematics algorithms must have a bug if they're going from version 2.9 to version 3000.

Re:Decimal point is wrong...

[Anonymous Coward]

I think they learned from Windows: Windows 1.0, 2.0, 3.0, 3.1, 3.11, what's next?
95, NT, 2000, XP ?

Re:Decimal point is wrong...

[__aaclcg7560]

Python Classic vs. New Python

Re:Decimal point is wrong...

[jc42]

Well, my immediate thought when I read "Python 3000" was that they are switching to using the release date as the version number.

My second thought was that they've realized and are being honest with us about how long it'll take to release a version that works right.

They're smart guys.

Just rename interpreter to phyton3

[Anonymous Coward]

... I have the following symlinks:
java13 => /opt/jre13/bin/java
java14 => /opt/jre14/bin/java
java15 => /opt/jre15/bin/java
java16 => /opt/jre16/bin/java
java => java16
Guess what - it is simply perfect.

Syntactic whitespace

[metamatic]

To anyone else who was curious and potentially interested:

No, they're not fixing the syntactic whitespace problem.

Move along, nothing to see.

Re:Syntactic whitespace

[Waffle Iron]

Probably because the syntactic whitespace "problem" only exists in the heads of people who have never used Python.

Re:Syntactic whitespace

[Anonymous Coward]

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.

Re:Syntactic whitespace

[Ostsol]

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.

Re:Syntactic whitespace

[pclminion]

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:Syntactic whitespace

[Ilan Volow]

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.

Re:Syntactic whitespace

[metamatic]

Yeah, and the GIMP UI "problem" only exists in the heads of people who have never used the GIMP.

Re:Syntactic whitespace

[Waffle Iron]

Nope, I've used the GIMP a good bit, and its UI problems are real.

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:Syntactic whitespace

[bperkins]

I've used Python.

The syntactic whitespace is hard to get used to and causes hard to find bugs.

Re:Syntactic whitespace

[ubernostrum]

The syntactic whitespace is hard to get used to and causes hard to find bugs.

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

[marcello_dl]

They fixed the whitespace problem in a fork:

http://clisp.cons.org/

Re:Syntactic whitespace

[zigamorph]

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?

Re:Syntactic whitespace

[arevos]

* 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:

on_connect do(self):
  self.connected = True

Into this:

def on_connect_block(self):
  self.connected = True
on_connect(on_connect_block)

* explicit scoping of variables like with the "var"-keyword in Javascript The nonlocal keyword in Python 3000 goes some way to rectifying this. It's not as neat as "var" in my opinion, but I can see why they shied away from explicit declarations.

* ++ and its friends x += 1 is more explicit, and I don't think that many Pythonists would welcome an increment operator.

* ternary statements Already in Python 2.5:

x = a if b else c

* switch statements, preferably supporting strings. I tend to agree with you. A "switch" or "case" statement would be nice, especially if it was like the one in Ruby.

Re:Syntactic whitespace

[GnuVince]

Use Perl, it has ALL of these.

Re:Syntactic whitespace

[Chapter80]

Nice Troll.

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.

Re:Syntactic whitespace

[Reality Master 201]

Yeah, but then you have to use Perl, and then you're just an asshole.

Re:Syntactic whitespace

[nwbvt]

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...

Re:Syntactic whitespace

[zigamorph]

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.

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.

Re:Syntactic whitespace

[BRSloth]

Losing the syntactic whitespace for a more traditional whitespace-neutral {}-block style would to me only feel as an improvement. Till the day you have to read someone else code, written in C++, with all lines starting on column 0.

(Yeah, I know we have indent to fix that, but you'd never bother using it after the pain of seeing such thing.)

Re:Syntactic whitespace

[Anonymous Coward]

* non-trivial lambda-statements

GvR has already said that you are correct. The significant whitespace issue means that the parser has a problem with a multiline lambda.

However, all functions are first-class objects, and names are highly disposable, so you can trivially do what you want:


foo(lambda x: x + 3) # call foo() passing a function that adds 3

def fun(x):
    return x + 3

foo(fun) # call foo() passing a function that adds 3
del(fun) # optional: explicitly discard the name "fun"


You can do this trivial example with lambda, but you can do an arbitrarily complex function with def as shown in the second part of this example.

GvR feels that giving a function a name for a little while is not a big deal. There have been proposals to allow the "def" statement to take a '*' as the name, or something like that, to make it clear that you really want an anonymous function; but standardizing on using the same name (in my example "fun") every time you want an anonymous function seems like an easy way to do things, and doesn't need any change to the language spec.

And as I showed, you can even discard the name "fun" if you like. (If foo() held a reference to the function, it will still have that reference after you unbind the name "fun".)

Note that you can define a function at any scoping level, so you can be in the middle of some function, and define a function and pass a reference to the function. If you are inside a local scope, you don't even need to worry about discarding the name, since the local scope will be cleaned up once you exit that scope.

* switch statements

I for one am quite content to do a switch like so:


if x == 0:
    func0()
elif x == 1:
    func1()
else:
    func_default_case()


What does "switch" really buy you? I guess a clever optimizing compiler might be able to take advantage of the knowledge that the switch is always on a single expression. But in practical use, the if/elif structure gets the job done.

This could be an example of "there should be one, and preferably only one, obvious way to do something".

Re:Syntactic whitespace

[heinousjay]

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.

Re:Syntactic whitespace

[Grant_Watson]

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.

Re:Syntactic whitespace

[Wdomburg]

Not quite - no switch or case. Unless you're running the prototype version of perl6 written in Haskell.

Re:Syntactic whitespace

[Just Some Guy]

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.

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.

Re:Syntactic whitespace

[Anonymous Coward]

There's a workaround for this.. it's not pretty buuut. You can always end your blocks with pass, then you can re-indent it and paste it around without breaking it.

def fish (x):
    if foo:
        bar
        pass
    pass

Re:Syntactic whitespace

[Abcd1234]

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.

Re:Syntactic whitespace

[mok000]

If anyone is interested, my top candidates for improvement or python would be:
* 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:

a = 1
while > 10:
a += 1
b = a + 2
;
print a

Which would work even if Slashdot's <ecode> environment botches up the indentation and you copy-pasted it directly to your terminal window.

Re:Syntactic whitespace

[mr_mischief]

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.

Sounds familiar.

[markov_chain]

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).

Re:Sounds familiar.

[m2943]

Guido, always the pragmatist, and having just watched Reservoir Dogs, retorted that anyone who wants a modular language should get his head examined.

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:Sounds familiar.

[k8to]

The problem here is that you are insisting on thinking of these tools by the wrong names. If you remember that python has a stdin file object and then have to hunt around for it, you've done yourself a disservice. The name of this object is sys.stdin.

Just call things by their full names. They're short, they're unambiguous, and they say what they are.

Re:Sounds familiar.

[Anonymous Coward]

So why does Python scatter its standard libraries across half a dozen packages?

The Python standard library is actually many dozens of packages. If you have a suggestion for a way to improve library design, I'm sure we'd all be happy to hear it.

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.

os / sys: OK, this one is a bit weird (similar to Java's System/Runtime weirdness)
os.path: dealing with paths
re: dealing with regular expressions
string: you basically never need this; it's a holdover from Python 1.something, and string instances now have most of the interesting functionality themselves

And you can't just safely import everything from those packages either.

Sure you can. It'll cause a lot of extra files to be loaded when your program starts, but it won't break anything. Later you can run pylint on your program, to get a list of packages you're not using, and remove those imports.

Re:Sounds familiar.

[Poromenos1]

If it has to do with paths, it's in os.path. If it has to do with the OS in general, it's in OS. If it has to do with strings it's in string, and with regular expressions in re. What's so hard? The only two libraries in the whole of python that one might confuse are sys and path, and besides, why would you confuse two libraries? What are the docs for?

Re:Sounds familiar.

[Gen.Anti]

After a brief discussion about why pluggable syntaxes won't be allowed, Bob, in real life a professional vet, becomes disgusted with coding and decides to devote his evenings to learning Chinese (to the dismal of the users who want better performance in games, and don't run their games on servers). A few days later a minor turmoil with another guy Henrik who offers his Reverse Forth Syntax (RFS) results in a Slashdot story.

Re:Sounds familiar.

[m2943]

The name of this object is [framfeesl]

No, the name of the object is "stdin" because that's what UNIX and C programmers know it as. If Python renames the object to [framfeesl], then that decreases its usability.

The problem here is that you are insisting on thinking of these tools by the wrong names

No, the problem is that Python is referring to well-known objects by new, made-up names for no particularly good reason.

Re:Sounds familiar.

[m2943]

If it has to do with paths, it's in os.path. If it has to do with the OS in general, it's in OS. If it has to do with strings it's in string, and with regular expressions in re. What's so hard?

Except that that's not true. The natural thing would be for os.path.exists to be in os, not os.path, because it's an OS call, not a function that operates on paths. And why is sys.argv in sys when the argument vector is a pretty universal concept and a generic operating system service? And why is Python exception handling in sys? Or sys.exit? And why is sys.getfilesystemencoding in sys, when it is a function whose purpose is to provide a non-system-specific way of finding out system specific information?

The definitions in the Python documentation of what the modules are for are simply not helpful for deciding where to look for functions. After many years of using Python, I still feel that the functions in the libraries are often simply in the wrong modules, something I don't experience in any other language. Furthermore, whether you notice or not, it's simply a fact that beginners do have problems with this.

Re:Sounds familiar.

[Anonymous Coward]

os.path: dealing with paths

Well, except that it contains system calls, like os.path.exists.

Sure you can

No, I can't, because the documentation doesn't guarantee that I can.

I'm sure we'd all be happy to hear it.

Existing Python users would scream bloody murder if things started moving around between os, sys, and os.path, no matter how illogical the current setup may be. Ever single change would take weeks of debate, and it's simply not worth it. OTOH, this sort of legacy issue is also what allows other languages to come in and nibble at Python's market share (like Ruby, for example).

Re:Sounds familiar.

[smellotron]

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...

I don't think I've ever heard of anyone confusing re with string. Though I've never met anyone who approached Python without first knowing what a regular expression is. I can see my girlfriend (who knows neither Python nor regular expressions) being confused about why basic substring and replacement functionality is in string, but more "sensible" substring and replacement functionality is anywhere else. But really, for anyone adept at using Linux from the command line, figuring out Python modules is usually a walk in the part, eating a piece of cake. pydoc and the plethora of good online resources should be more than enough for someone who learned ps from the man pages.

Ok... I'll give you os and sys. I have a tendency to forget some of the obscure parts; I blame naming. It's somewhat misleading to have "system" and "operating system". Maybe runtime.argv and runtime.stdin would be more obvious than sys, but I'm sure 50% of the Python-using population would vehemently oppose that (for whatever reason).

For that matter, maybe /etc would be better named /config, but backwards-compatibility rules all (including being backwards-compatible with the ideas in the developers' heads, regardless of how correct or good those ideas are). So just think of sys as secretly being runtime or whatever else tickles your pickle, and the module division should make more sense.

BS argument

[henrypijames]

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.

Re:BS argument

[Anonymous Coward]

I guess he's just Thinking in Java/C++.

Re:BS argument

[Anonymous Coward]

If you look at his resume, it seems he's far more familiar with other languages than Python.

Either you are not paying attention to detail or you are an ageist troll. Bruce Eckel adapted in past to many "paradigm shifts" (and he already was an old guy), there is no reason to assign his criticism to some alleged rigidness of his mind.

both are right, sort of

[m2943]

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.

Re:both are right, sort of

[dkf]

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...

• For UI, people should be aware that Tk has just had a large injection of new widgets that support theming/styling schemes that make them look just like native widgets. (Actually, they are real native widgets on some platforms...) Now if only the python interface to Tk didn't set the TK_LIBRARY environment variable, things would work even better.
• One man's essential standard library component is another man's useless bloat. Really. So suit yourself as to what you put in. It helps though if you try to keep the style of the API consistent, and the number of API patterns small. After all, the big problem with Win32 was always that the API was too often inconsistent with itself, whereas the POSIX API is mostly much cleaner that way.
• Package management is hard. Good areas to examine first are "package versioning rules" and "single file packages".

Re:both are right, sort of

[cyberkahn]

After reading this it is quite clear to me that Guido has no idea what he is talking about when it comes to Python 3000.

Re:both are right, sort of

[Anonymous Coward]

Boy, if GvR has no idea what he's talking about, then who the heck does? GvR invented the language and has been completely involved in its evolution all along.

I've attended a talk where he explained Python 3K and I have also watched a video from the Google Tech Talk series where he explained it. Everything he is planning makes sense to me.

So, please either explain what you meant, or else I am likely to think that it is you who have no idea what you are talking about.

Re:both are right, sort of

[smellotron]

It helps though if you try to keep the style of the API consistent, and the number of API patterns small.

The wonderful thing is that Python's typing system allows APIs to become standardized simply through function naming, syntax, and a little bit of semantics. People complain that database modules like psycopg and pypgsql (both database access layers) aren't well-documented. But since they both more-or-less follow the DB-API 2.0 spec, they can more-or-less be interchanged without screwing things up. Plus, the developers don't have to document everything; just the parts that differ from the spec.

If only GUI toolkits were the same way.

PArrot

[goombah99]

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. Isn't that exactly what Parrot was supposed to be about? Even the name was chosen to hint at monty python.

Re:PArrot

[zerblat]

Ah, you mean the Norwegian Blue? I don't know. Looks dead to me. Of course, 'e might just be resting. Beautiful plumage, though.

They are both wrong!

[pigiron]

The right answer is here: http://newlisp.org/

Re:They are both wrong!

[Anonymous Coward]

newLISP is a great little scripting language, though it could be better. I hope that in one of the upcoming releases it gets implicit fixnum->bignum conversion, without the bullshit of using the gmp.lsp library. I also hope (but this time I'm more certain) that the 64-bit builds will use 'long double' instead of 'double' to support larger numbers without the need to use bignums.

Those aren't the real problems with Python

[Animats]

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:Those aren't the real problems with Python

[slashnot007]

Wow. You nailed it. Those are my feelings exactly. Espeically about Dynamic typing being too much of a good thing since it screwes with optimization.

Re:Those aren't the real problems with Python

[TheLink]

"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"

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 and boring for most people. So they'd rather do stuff like come out with python3k or perl6 instead of a fast python2.x/perl5.

Re:Those aren't the real problems with Python

[atrus]

Java dynamic code tends to be pretty well behaved, and is actually heavily used. For instance, EJB 3.0 makes very heavy use of the reflection API to auto generate RMI wrappers, maintain object pools, etc, with no heavy lifting from the developer.

Re:Those aren't the real problems with Python

[renoX]

>>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!

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:Those aren't the real problems with Python

[FlashBuster3000]

You better compare python to other dynamic scriptlanguages instead of C or Java. One should probably take the languageshootout on alioth.debian.org with a grain of salt (as i didn't look into the implementation of the benchmarks), but supposed that the benchmarks are equally well written, you'll see that python compares very well against php or perl. Java is a lot faster, but eats a lot more memory. Then again, Java is a lot different to Python. Let alone C.

Re:Those aren't the real problems with Python

[WilliamSChips]

Yeah, Self was quite fast due to heavy, heavy optimization. I'd say that Python doesn't do enough dynamism and that is what is making those sorts of optimizations hard. Too many special cases.

Re:Those aren't the real problems with Python

[julesh]

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.

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 have atomic operations, which is rather slow in most cases without the global lock. This needs changing at a language definition level, perhaps by introducing a way to declare that this isn't necessary.

Re:Those aren't the real problems with Python

[RAMMS EIN]

``Espeically about Dynamic typing being too much of a good thing since it screwes with optimization.''

That actually isn't the real problem with dynamic typing. The real problem is that type checking can help catch many errors. Static typing catches these errors before your program is run. Dynamic typing does so at run time. So, where static typing will force you to delay shipping your program until the bugs (that type checking can catch, and there are many of those) are fixed, dynamic typing will let you ship your buggy program and wait for your customer to call you after it ate 3 months of their work.

Re:Those aren't the real problems with Python

[RAMMS EIN]

``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.''

Well, yes and no, but that wasn't the point I was going to make here. I did want to add that Lisp designers and implementers have gone to great lengths to make everything possible, and the cases that can be efficient efficient. So if you have a good Lisp implementation, you can do all the wonderful dynamic stuff...but you can also write your program in a fashion that makes it more amenable to optimization, and expect it to run fast.

The new dynamic languages have shown people the power of the first part. Now, they are struggling to get the last part right.

Re:Those aren't the real problems with Python

[SanityInAnarchy]

Multicore support is a nonissue. CPython is too slow to need it.

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...

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.)

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:

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.

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...

Libraries are someone else's problem. Python is better than Perl as a language, but CPAN is better than Python's Cheese Shop.

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.)

Or you discover that you need racks of servers to compensate for the painfully slow implementation.

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.

That's why Python hasn't even replaced Perl, over fifteen years into the deployment of Python.

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.

Re:Those aren't the real problems with Python

[plasticsquirrel]

CPython is about 60x slower than C. Compare Java, which, with modern just-in-time compilers, is about 2-3x slower than C.

What exactly is being measured, and which benchmarks do these numbers come from?

Re:Those aren't the real problems with Python

[Sartak]

Python is better than Perl as a language

While Python certainly looks prettier, it's not as expressive as Perl. Consider lexical closures, which Perl has had for over a decade.

def make_counter(initial): ctr = initial def nonclosure(): ctr = ctr + 1 return ctr return bar

This will throw an "local variable 'ctr' referenced before assignment" error when you try to invoke the function returned by make_counter. The following Perl just works:

sub make_counter { my $ctr = shift; return sub { return ++$ctr; }; }

Re:Those aren't the real problems with Python

[Wheat]

> I suppose doing stuff like that is hard and boring for most people. So they'd rather do stuff like come out with python3k or perl6 instead of a fast python2.x/perl5.

No. Please read the article(s), it is inaccurate to compare Python 3 development with Perl 6 development. Bruce Eckel was whinging about Python 3 not doing enough "fun stuff" as Python 3 is really only concerned with removing warts that resulted from early design decisions in Python. Perl 6 is about doing "fun stuff". As for performance, the cPython implementation in Python 2 has had a lot of optimization work done to it. Much optimization work done to Python 3 will be available to Python 2 in the form of the Python 2.6 release.

Re:Those aren't the real problems with Python

[Wheat]

> 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.

You mean something complicated like a feature-rich Content Management System such as Plone?

http://plone.org/

Plone has been known to replace racks of servers of commercial CMSes with a single server. And those commercial CMSes are written in things like Java and C++. Python has very little competition from Perl in the feature-rich CMS space.

Personally, I've known a lot of developers who switched from Python to Perl (myself included). I've never met a single person who has made the transition in the other direction.

Re:Those aren't the real problems with Python

[Wheat]

Oops, I meant to say Perl to Python. I've never met anyone who switched from Python to Perl though.

Re:Those aren't the real problems with Python

[chromatic]

For that matter, if [Perl 6] ever gets released, and if Python gets ported to Parrot -- not very likely, I know...

Actually, people are working on it. It's Pynie; Patrick Michaud wrote a basic compiler for it in about eight hours.

Re:Those aren't the real problems with Python

[Anonymous Coward]

"If you really have to, create Java code from within a program, compile it, and load it. Few programs need more dynamism than that."

Actually many, many of Java programs modify existing code on the fly. For example, every program that uses object-relational mapping: the ORM will modify the class files before they are linked to transparently implement lazy loading of related objects, dirtiness tracking, etc.

Re:Those aren't the real problems with Python

[haystor]

No heavy lifting for the developer...Java. (+1 Funny)

Java has no sense of dynamic code, in particular when compared to Lisp as mentioned in this thread.

Re:Those aren't the real problems with Python

[smellotron]

Java has no sense of dynamic code

Java's still better off than C++ in that regard. Every C++ unit-testing framework I've seen either jumps through template-metaprogramming-hell hoops to get compile-time reflection, or uses some sort of preprocessor to do out-of-band reflection (e.g. perl/python script that roughly parses the unit tests and generates a skeleton). So while Java's reflection mechanisms may be weak (I don't know the extent of it), it's certainly not the weakest of the lot.

Mod parent up.

[Animats]

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:Mod parent up.

[sigzero]

I thought straightening up the libraries was one of the goals of PY3K?

Python needs to go on a diet

[Ilan Volow]

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.

Re:Python needs to go on a diet

[Anonymous Coward]

XML support would be a library issue. Syntactic sugar bloat? What, you mean descriptors. Woah! All that bloat. Yeah it's amazing how Python can still do anything with one whole character taking on a new meaning.

Re:Python needs to go on a diet

[Llywelyn]

XML is not the answer with Python. Almost never. The only reasons I've ever found for XML are compatibility with other apps that use XML--otherwise there's generally a more elegant solution that doesn't use it.

If you *must* use XML, ElementTree is built into Python 2.5.

Re:Python needs to go on a diet

[Ashcrow]

Python has fantastic support for XML ... but unlike some other languages (*cough*Java*cough*) it's much simpler to write your application than script your whole system with lots of XML files. Most apps needs configs (where XML can be nice) but code should be done in code :-).

Compiled type-safe python

[goombah99]

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.

Re:Compiled type-safe python

[Anonymous Coward]

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.

I see someone's never heard of Lisp.

Re:Compiled type-safe python

[Anonymous Coward]

1. Python is type safe. I think you mean you wish it were statically typed.
2. I do take advantage of it and I do vary the argument types. I think those that don't are trying to treat Python like another language (e.g. Java).
3. Adding static typing to make runtime acceleration easy is a cop-out. If I wanted the things you're wanting I'd use Java. I think better runtime performance will come from PyPy or some similar approach, but compromising language design for performance is a bad idea. Python is dynamic on purpose, so just go use Java or C# and you'll be happy.

Randall

Re:Compiled type-safe python

[Chrisq]

I am not sure why this is marked funny, it is a good point. Lisp can be compiled http://www.cons.org/cmucl/ and does not enforce types in function prototypes. The downside is that types are either atoms or lists, but it shows that this is not impossible.

Re:Compiled type-safe python

[Anonymous Coward]

You might want to take a look at http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/ and/or http://www.cython.org/

Re:Compiled type-safe python

[Anonymous Coward]

I really like boo. It's a statically typed language targeting .NET, with Python-like syntax and conventions. It manages to do away with most of the type declarations through (semi-)implicit typing, and it supports "duck" typing, which is something similar to Python's object model (although, as you observe, most Python code doesn't take full advantage of its dynamic nature). Boo has access to .NET's huge object library, and of course it runs much faster than Python.

It's a pity there isn't a non-.NET version available, as it's really quite a nice language. I think it's better-suited to large-scale programming than Python, since it will catch errors like type mismatches and uninitialized variables, and it's more amenable to other kinds of static program analysis. Apart from the common library differences, Python and Boo code is very similar, so it's a short step between writing Python code and porting to Boo to make it fast (which is something like how Pyrex is typically used).

Regarding GUI

[Brandybuck]

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.

Why do people pile on Guido

[pclminion]

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:Why do people pile on Guido

[Anonymous Coward]

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.

I hate tabs and anything other than 2 space indentation. My usual response when pushed to adopt stupid indents is to use a single space out of pure malice. I've never been unemployed for longer than 2 days in 15 years, so you can frankly take your precious PROJECT REQUIREMENTS and shove 'em. How's that sound, would I pass your interview process?

Re:Why do people pile on Guido

[Anonymous Coward]

You must have been working alone in your basement. I can't imagine anybody would want you on their team. (PS: I'm not the GP)

Re:Why do people pile on Guido

[Anonymous Coward]

> That fails your interview, right there.

And thank god for that. Failing your interview OF me for that fails my interview of you, too. I'm glad we'll both be glad not to have each other.

Re:Why do people pile on Guido

[imbaczek]

You wouldn't pass mine and you'd have a big fat ASSHOLE scribbled on your resume.

Re:Why do people pile on Guido

[Anonymous Coward]

You've got a problem with having to make things line up the way their supposed to?

You're being obtuse. The problem with syntactic whitespace is that it can introduce errors that you can't find without doing a hexdump of the source code, which is about the stupidest thing ever.

Indentation standards can be enforced by post processing, anyway. It's a non-issue.

Re:Why do people pile on Guido

[WilliamSChips]

Python will support indentions of any length as long as they're there and they're consistent. (Tabs are 8 spaces, as god indented. Er, as God intended.) And if you don't indent at all you're a fucking idiot, I don't care who you are.

Re:Why do people pile on Guido

[julesh]

You're being obtuse. The problem with syntactic whitespace is that it can introduce errors that you can't find without doing a hexdump of the source code, which is about the stupidest thing ever.

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 flow you'll be fine.

Re:Why do people pile on Guido

[SanityInAnarchy]

Not only can you use 2 spaces for indentation if you like, but you can also use hard tabs and set your tabstop to two spaces.

Next you'll be telling me that you hate any language that defines subroutines with anything other than a "function" keyword... Deal with it.

Re:Why do people pile on Guido

[SanityInAnarchy]

I guess when Linus does it, it's a noble independent spirit, when Guido does it he's being an asshole.

More like, Linus actually bothers to listen to and understand the opposing viewpoint. He also tends to not make unilateral decisions that everyone is going to hate.

Saying he's "not that different than Linus" is like saying Linus is not that different than Stalin. Just because they're dictators doesn't make them even remotely comparable.

Re:Why do people pile on Guido

[VGPowerlord]

Or just stick to the standard of 8 spaces.

That's not a very "standard" standard. I've seen quite a few programming style guides that recommend 4 spaces. Or tabs.

Re:Why do people pile on Guido

[Anonymous Coward]

Linus actually bothers to listen to and understand the opposing viewpoint. That is funny. I had a good laugh. Thank you.

Re:Why do people pile on Guido

[pclminion]

so you can frankly take your precious PROJECT REQUIREMENTS and shove 'em. How's that sound, would I pass your interview process?

No, you wouldn't. With an attitude like "shove the PROJECT REQUIREMENTS" I've got to assume that you've spent your life working for morons who will take whatever crap you care to throw at them.

Re:Why do people pile on Guido

[Anonymous Brave Guy]

The problem with syntactic whitespace is that it can introduce errors that you can't find without doing a hexdump of the source code,

What's wrong with just mandating that only tab characters may be used for indentation? Or having a smart editor that deals with this problem?

The reality is that in any block-scoped language, people reading and maintaining the code usually only see the indentation anyway. Sure, you can have {} or begin...end or whatever your language calls it. However, if you screw up the indentation so it looks like your inner and outer if...else blocks match up but according to the punctuation they don't, you'll have just as much a bug as the syntactic whitespace guys, because most programmers won't notice and will trust the indentation. The only difference is that in one case, your language rules can force the code to look like exactly what it represents, while in the other, they can't and the best you're likely to find is an editor that is language-aware and forces the indentation to match the block delimiters.

Re:Why do people pile on Guido

[brantondaveperson]

PROJECT REQUIREMENTS != Indentation Style

Indentation style is personal choice, and I have never understood why on earth people get so wound up about the way in which code that they might have to read one day is indented.

I mean really, what's the big deal? And the magnificent thing about using curly braces, or whatever, is that it makes that particular personal choice matter not one whit. Just re-indent and the problem goes away! It's almost as if a computer can understand your code!

But not in Python, of course. Python's use of whitespace as actual syntax is just nutty, and that's the end of the matter.

And since you seem in such a grumpy mood, I though I'd cheer you up by pointing out that you probably wanted to use the word "they're" not "their" in your second to last sentence there.

Re:Why do people pile on Guido

[Chrisq]

I've never been unemployed for longer than 2 days in 15 years

You have good long term prospects as a Guantanamo interrogator.

Re:Why do people pile on Guido

[dodobh]

My problem with enforced whitespace is that tabs and spaces are treated differently. I use 8 space tabs, someone elses uses 4 space tabs, and someone else uses 2 spaces, but all our code can still work properly, even when we edit the same file. Differentiating between tabs and space characters is the big reason why I dislike Python.

Re:Why do people pile on Guido

[Anonymous Coward]

You have worked on a project where in the same file you have a mixture of 2-space, 4-space and 8-space indentation? Jesus Christ, that must be disgusting! The reason that python's whitespace is a non-issue is because in any project how to indent becomes a matter of project policy. You don't accept code that does not meet your coding standards. Name me a widely-used project that doesn't have coding standards. They all do, because without them the project would be an unmaintainable, ugly mess. Indentation style is an important part of this.

Re:Why do people pile on Guido

[Anonymous Coward]

Lots of real-world uses of text do not preserve whitespace. I've seen people share code on Web forums that was word wrapped, yet could be repaired because it contained real delimiters. Python source instantly becomes unusable unless you correctly guess what belongs in or after each loop and branch. It's very aesthetic but around today's systems it's just not practical enough.

Strange Guido's reply

[renoX]

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..

Re:Strange Guido's reply

[Simias]

Or make it optional like "this" in C++, you could fully qualify the name (self.content) or just make it implicit (content).

Re:Strange Guido's reply

[Cheesey]

You have touched on a problem with Python that has always annoyed me. It's not "self", but it is one of the reasons why "self" has to be explicitly specified.

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:

def Parent():
  v = 0
  def Child():
    v += 1
  Child()

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:Strange Guido's reply

[Anonymous Coward]

Actually, no. That's an orthogonal issue altogether, and is being addressed in Python 3000 with the new "nonlocal" keyword. Thus your code would be written as:

def Parent():
    v = 0
    def Child():
        nonlocal v
        v += 1
    Child()

self being explicit is actually pretty amazingly powerful, if slightly rough on the fingers. For example, you can invoke a method from a class on a different object by providing self:

class Foo(object):
    def bar(self):
        print self.x

Foo().bar() automatically supplies self, but let's say you wanted to call Foo.bar on an object of class Jimmy. This is easy:

myjimmy = Jimmy()
Foo.bar(jimmy)

Now inside Foo.bar(), self == myjimmy. Neat!

Re:Strange Guido's reply

[renoX]

Am-I the only one to find that nonlocal is ugly?
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 := 0 #declaration
        v = 5 #assignment
        def Child():
                v += 1
        Child()

But I know that Pythoners don't like variable declaration..

Re:Strange Guido's reply

[Anonymous Coward]

I agree that it's ugly, but I also see the reasoning -- a new scope shouldn't implicitly clobber names from the outside scope (a common source of bugs). That said, I would have preferred it be done exactly as in the example you gave.

Re:Strange Guido's reply

[Cheesey]

Don't get me wrong! I like self being explicit... in fact, I have begun to use "this->" when I write C++ code.

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.

Re:Strange Guido's reply

[Eli_Courtwright]

Python 3000 is fixing that issue with PEP 3104: http://www.python.org/dev/peps/pep-3104/

searching the online docs

[goombah99]

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.

Re:searching the online docs

[Anonymous Coward]

Thank you for clarifying my for mentioned frustrations :)
You put it much better than I did.

Re:searching the online docs

[British]

I understand the original poster's complaint about the documentation, I just right now cannot find the exact set of pages he was talking about.

I've done frequent google searches on docs.python.org to find out how to use a method,etc. Sometimes you get results that lead you to a way too low-level page about the method or library that is absolutely useless(to me, at least).Maybe it is the "language reference" that probably shows up a lot in google search results? That and several-years-old single discussions from the mailing list.

It's not the langauge, stupid

[Aminion]

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.

Re:It's not the langauge, stupid

[Aminion]

"langauge"? I spell checked everything besides the subject, so obviously it got misspelled.

Re:It's not the langauge, stupid

[Anonymous Coward]

> For example, PSF should start campaigning so that web hosting providers support Python out of the box
Take your poison: mod_python, django, turbogears (and probably a few others that I haven't heard of).

Considering that the former hasn't really gained much steam, and the latter two are relatively new players (see http://www.djangoproject.com/weblog/2006/aug/07/guidointerview/ , was only a little more than a year ago), fragmented into two (or more) communities, I can't see web hosting providers would have scrambled to add support for python.

Having more hosting support for Python would be nice, but actually doing it would be much more fuss than simply installing PHP with a single command on the hosting server. I've written non-trivial things on django, I love its simplicity, but if I were to make decisions for a hosting company I wouldn't be hosting python for those There needs to be a major effort in making it easier to install, get started with, and deploy Python
I can't imagine how it could be made significantly easier. And considering, say, Java's success (in the corporate world), I think ease of installation/deployment is not a really deciding factor...

> Why do you think PHP, despite it's obvious drawbacks, is so popular?
Because it's "easy to learn", and allows you to add a XSS/SQL code injection hole to your site within 5 minutes. Makes the kiddies feel 1337.

Re:It's not the langauge, stupid

[SanityInAnarchy]

Because it's ubiquitously supported and requires nil efforts to get started!

Both Python and PHP required about the same amount of effort to get started, at least for me:

sudo apt-get install python
sudo apt-get install php5

In fact, PHP is harder, because you need the version number.

If you look at hello world programs, it's pretty similar.

The only difference I see is that PHP, early on, was very easy to embed into existing web pages, so it was sort of the logical next step to learn, once you know HTML. So, among the newbie web developers, PHP is synonymous with server-side scripting. Fortunately, no one is stupid enough to try to use it for anything other than the web.

Unfortunately, PHP is also ubiquitous among the newbie web dev crowd that when they get ambitious enough to try something really big, even innovative, they do it in PHP. Example: Drupal. But really, once you start designing your app properly, separating content and presentation, there's no advantage that PHP has over Python, except that you already know it.

even odder.

[slashnot007]

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.

Re:even odder.

[josephdrivein]

If this is true and there is no easy workaround, I'll switch to another language.
I hope this will not be included in v3.0.

Re:even odder.

[Just Some Guy]

You missed the tag, methinks.

Re:even odder.

[josephdrivein]

I thought the same just after I clicked "Submit".
It was even a good joke. :)

Re:even odder.

[Phoe6]

I doubt this claim is true. Please mod the above post down, its just a FUD.

Re:even odder.

[Anonymous Coward]

Please mod the above post down, its just a MORON.

Blow my mind.

[Verte]

Give me multiply indexed arrays and array slicing! that would be something.

Re:Blow my mind.

[slashnot007]

Your wish is granted already. import numpy

Invisible+Control+Structures

[Peaker]

{
        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? :-)

Significant whitespace

[tylersoze]

Well if one of the incompatibilities is getting rid of the goddamn significant whitespace I'm all behind it. It might even encourage me to give the language a chance. If it weren't for Civ IV I would have never used it for anything. A good slashdot poll would be how many people haven't even bothered with the language because of "the whitespace thing".

Re:Significant whitespace

[An Onerous Coward]

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.

Re:Significant whitespace

[sydneyfong]

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.

Re:Significant whitespace

[zigamorph]

I've never understood the "whitespace" thing... don't you guys indent your code anyway?

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.

Re:Significant whitespace

[Uerige]

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?

Re:Significant whitespace

[JesseMcDonald]

"How many people haven't tried LISP because of the whole 'no side effects' thing?"

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.

Re:Significant whitespace

[grumbel]

### 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).

Re:Significant whitespace

[grumbel]

### 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.

Re:Significant whitespace

[Just Some Guy]

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.

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).

Re:Significant whitespace

[grumbel]

### 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.

Flamewars

[Anonymous Coward]

I understand that it is inevitable for the same old flamewars to start on slashdot.

But must we give modpoints to idiots?

Re:Flamewars

[julesh]

must we give modpoints to idiots?

It's kind of hard to avoid when the earlier moderators were idiots.

Yeah, well

[stonecypher]

Bruce Eckel is looking for Erlang. That's not what Python is for.

Sys and OS.

[Poromenos1]

I meant sys and os, sorry about that.

Plenty of time

[SiliconEntity]

Sounds like some tough issues. Good thing they have 993 years to get it right.

Sometimes I think we should just all give up

[Colin Smith]

And learn LISP.

Re:Sometimes I think we should just all give up

[chthon]

You got lucky, last time I mentioned Lisp I was downmodded flame-bait. However, I share your sentiment. I have been busy in the past year programming Common Lisp, and the more you learn it, the more you can conclude that all other languages just run behind.

Except in libraries and GUIs. My main application is now written in Lisp, but I am developing its GUI in Python, because of the cross-platform possibilities (best cross platform Lisp = CLISP (Win + Linux), Python GUI (TkInter, Win + Linux)).

self can't be removed from Python

[WilliamSChips]

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.

Re:self can't be removed from Python

[renoX]

Nobody said that self can be removed, just that it could be hidden (mostly), as Ruby or the other language do..

In the same way space based indentation doesn't remove indentation but it 'hides' it mostly.

a language is only as good as its libraries :-)

[toby]

CPAN is better than Python's Cheese Shop.

And the Java API + 3rd party libs knock them all into a cocked hat.

Re:a language is only as good as its libraries :-)

[Anonymous Coward]

The Java API and most third party Java libraries are terrible. They provide an incredibly poor level of abstraction, and because of this you end up writing ten times the amount of code that you would in a language that doesn't suck.

Re:a language is only as good as its libraries :-)

[smellotron]

And the Java API + 3rd party libs knock them all into a cocked hat.

Ah, yes, the standard library the redefines data structures (ArrayList vs. Vector) but can never remove them due to backwards compatibility. But since Vector is so ubiquitous in other languages, and ArrayList is... erm... two similar words put together... most beginners use the wrong tool to begin with. Same issue with Hashtable vs HashMap. Or the decision that Properties "is-a" Hashtable instead of "has-a", which again can never ever be replaced with the proper relationship (a private member instead of inheritance) because somewhere, someone depends on that dynamic typing, for no good reason, and we don't want it to break. Yeah the Java API is awesome. At least they added autoboxing so basic data types aren't incredibly annoying to use with basic data structures.

Me, I'll take x = dict(foo=[1, 2, 3]) and the Python file metaphor (if it has fileno(), you can stream to/from it) any day over Java's megalomaniac collections API.

Concurrency / Message passing

[LuckyStarr]

For a really great and thought provoking talk about concurrency watch this Techtalk about Newsqueak given by Rob Pike of Plan9 fame.

Build channels as first-class citizens into Python. :) No, really.

Flamebait.

[SanityInAnarchy]

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.

building programs on quicksand

[r00t]

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.

Am I the only one that noted this?

[Anonymous Coward]

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.

Fork it

[nurb432]

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.

Python is not Javascript

[Anonymous Coward]

Syntactic whitespace makes it harder to automatically reindent code

This is a nonsensical statement. The only reasons to "reindent" code are because you're doing something like a refactoring that added/removed a level of scope. But in that case, Python removes the need for this entirely. Instead of "Add {, add }, select region, reindent", it's simply "select region, push right" (or left).

I've programmed Python for years, and I still can't figure out why anybody would need to "reindent" Python. It comes correctly indented! You may as well complain that it's hard to automatically add {}'s in C.

makes it easier to accidentally break the code structure

I don't know what you mean here, either, unless you go around randomly adding whitespace for fun.

If anyone is interested, my top candidates for improvement or python would be: ...

All of these things are in Javascript. If you want Javascript, you know where to find it. Go for it. Nobody's stopping you. I hear it's a pretty nice language. It's not Python, but most languages aren't.

Re:Python is not Javascript

[Peter La Casse]

makes it easier to accidentally break the code structure

I don't know what you mean here, either, unless you go around randomly adding whitespace for fun.

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.

Guido's reply is the same as always

[Anonymous Coward]

Glad to see Guido still takes both of these issues lightly. I've been using Python every day since 1995 and I can attest that these are still huge problems.

Take the error reporting. Both whitespace and "self" create really confusing errors for new, and old, users.

  * "takes exactly 1 argument, got 2" -- this is what you get for a missing "self". Few python users can figure this out without help or turning to example code.
  * Oops, someone edited a file and used tabs... indentation can be reported as a syntax error or indentation error. It depends.

On whitespace for a moment, the argument for whitespace is that it makes cleaner code. It does. The catch is that whitespace then needs to be policed forever on your project. You can actually end up with INCORRECT CODE because someone put in a line with a tab instead of spaces. Yeah, unit tests, code review, blah blah blah. Whatever. NO other language, interpreted or otherwise, requires this amount of added overhead to make sure code is nested properly (except for Python derivatives like Boo).

Am I complaining? No. I'm just pointing these out for non-Python users. The time for arguing these points is long past, if I really hated them I wouldn't use Python.

So I'm not sure why Bruce Eckel is even bringing some of this stuff up -- Guido has never changed his mind on these and never will. Eckel hints at it, but I will say it. I suspect Ruby will have more success and introduce more people to dynamic languages than Python ever did, and NOT because Ruby's "better". 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. And there really is decent VM with Ruby 2, and the Rails hype keeps Ruby in the mainstream, that language might go beyond where Python, Perl and maybe even PHP are today.

And as far as another commenter said about coding our own version of Python... what's the point when Ruby's sitting right there and fits most of the bill?

Re:Guido's reply is the same as always

[renoX]

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..

Re:Guido's reply is the same as always

[Anonymous Coward]

>> Seems to me, that what you're saying is that the mix of whitespace and tab is a problem,

You could be right. There is a standard for Python (4 spaces). Enforcing that across the language would help a lot. But arguing tabs vs. spaces is like arguing Flying Spaghetti Monster vs. Jesus.

Standard libraries

[Anonymous Brave Guy]

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:

1. Define frameworks, at a sensible level of abstraction, for using common things such as file systems, user interfaces, network protocols and relational databases.
2. Have a centralised, ideally peer-reviewed repository for libraries, and tools to make using it trivial.
3. Implement no more standard library features in a specific, complete way than are essential to support the above.

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.

Performance... CPU vs Programmers

[pavera]

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

Re:Performance... CPU vs Programmers

[Anonymous Coward]

I'm a Python guy and I call bullshit.

There's no problem on earth that should take 500 hours in C vs. 10 hours in Python given equally experienced programmers in both languages. In fact, implementing from scratch with no additional packages -- just the language itself -- you'll probably get a percentage of developer time improvement (depending on the problem), not multiple times over.

The implementation time myth has gotten out of control, starting with the Ruby on Rails guys. They started with this "10x faster" claim. Now your post claims a problem with 50x improvement by using Python. The thing that people fail to understand is that most of the coding-time benefit of Python or Ruby comes not from the language, but from garbage collection and the dozens of built-in packages -- and those are available in C as well if people seek them out. Plus, most of what is gained from dynamic typing is lost in extra unit test writing and/or debugging time.

Even in your specific example, your team was using an existing C implementation as reference. You could port to any language many times faster if you were handed a reference implementation in C. That's like giving someone GPS with Google Maps vs. telling them to navigate with a sextant and no map.

I use Python and like it a lot, but it's for a very specific problem domain that lies between scripting and executables. If someone cares at ALL about performance, they don't justify using Python with developer time myths.

Re:Performance... CPU vs Programmers

[goose-incarnated]

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

That isn't surprising; the first application will certainly take longer, no matter what the language is. What I suspect is that the original spec took 5 years and 3 programmers to prototype in C. Once you have a reference implementation in any language, then you have a bullet-proof, engraved-in-stone, never-to-be-changed-while-coding specification that makes actual development a walk in the park.

Attributing the development speedup to a language just makes you look silly! There are plenty of research papers comparing various languages that do not include the development of the spec to artificially cripple any language's benchmark - cite one of those instead.

Re:Performance... CPU vs Programmers

[lakeland]

Sure it is possible, ever written a new version after completing a prototype?

The first version is slow to write because you resolve all of the design issues. The second one is a piece of cake because you can easily test every little function in isolation.

Oh, and Python is quite a lot faster to develop in than C too. I'd say 5* faster.

Sure they did, way back in python 2.0

[speck]

It's easy, just use this at the top of your script:

from __future__ import braces

Maybe...

[SanityInAnarchy]

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.

Re:Maybe...

[chromatic]

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...

There haven't been any. They're all a ways off; no one's working on any of them full time, which means we're all squeezing one year of work into eight.

Clarification: languages are not slow/fast...

[alispguru]

... 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.

I'm thinking of going from Python to Perl or C...

[Anonymous Coward]

I may be your exception...

I've spent the last while wrestling with a short Python/Scapy app that monitors network activity and writes data to Oracle. Got it working fine as a MySQL app, then did a *lot* of swearing at the half-baked nature of various oracle interfaces before I finally got cx_oracle to work. My one unresolved concern after all this was a worry about performance: during high-traffic bursts, scapy drops packets.

Then I was asked to redeploy from a 32-bit to a 64-bit multi-core box. The result has been hairy enough that I'm about to break your rule and shift to something else (perl or c). cx_oracle depends on the oracle client, one of which is precompiled 32-bit only; the errors I get are cryptic and useless, and documentation is sorely lacking. And when I'm done, I'll probably still see performance problems, based on the rants I'm seeing here about python not using the other CPUs.

Given the rather substantial amount of data being shoved into Oracle databases worldwide, Python devs ought to be a bit embarrassed. But Larry Ellison and Oracle ought to be shot: they're running a commercial entity and they can't find time to document a clean/light connection and API to their database from Python!? Sheesh.

Re:Syntactic whitespace is like Haiku

[jk60]

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.

Diddums insult uw favwit wanguage?

[Bastard of Subhumani]

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.

Re:Diddums insult uw favwit wanguage?

[totally bogus dude]

Shouldn't that be 8 spaces looks like the same as a tab? Nope, you're right, just checked it - WordPad does indeed use 6 spaces for a tab by default. Odd!

I guess this at least demonstrates why it's considered bad form to mix spaces and tabs for indentation: different editors and display tools have their own notion of what a "tab" looks like. Try opening a document you've formatted in WordPad using a mixture of single-tabs and six-spaces Notepad, and you'll see what I mean (Notepad uses the more common 8 spaces per tab). So, any concerns around mixing tabs and spaces are absurd anyway, because it's such a bad practice.

It's perfectly possible to write Python with any old text editor, just like it's perfectly possible to write Java or C# or Perl or assembly, but using an editor with some basic features like maintaining your indentation level will make it more efficient and enjoyable. Unless, of course, you either never indent your code, or haphazardly indent your code; but in that case, the quality of your code has some serious failings.

I'm not a "whitespace as part of the syntax" fanboy by any means, and it did put me off a little bit when I first played with Python, but the fact is -- it makes absolutely no difference. You indent the code consistently anyway, or it just becomes too unpleasant to read.

There's plenty of reasons to dislike Python, but saying "omg I'm not using that language because it requires consistent indentation of code!" just seems really bizarre. It doesn't make it harder, 'cos you're already doing it!

Re:Diddums insult uw favwit wanguage?

[Bastard of Subhumani]

Nope, you're right, just checked it - WordPad does indeed use 6 spaces for a tab by default. Odd!

Indeed I am. Let me introduce you to a concept I've been mulling over called "having a fucking clue what you're talking about before opening your big fat gob". I might write a book about it one day.

Re:Diddums insult uw favwit wanguage?

[totally bogus dude]

Very nice. Now what about the rest of it, e.g. the bit where mixing tabs and spaces for indentation stands a very good chance of completely fucking you over if you ever decide to change text editor -- as your very own example makes so very clear -- and therefore it's pretty moot whether the interpreter can deal with it or not? Or the explanation as to why having to indent consistently makes a language an absolute no-go despite the fact you need to do it anyway to maintain readable code?

I really am curious about that last one. While I can kind of understand a gut-level "how dare the damned interpreter tell me how to format my code!" response, in practical terms it's just not a problem. I format the code exactly how I would if Python didn't require consistent indentation, i.e. the same way I do it in C or Perl, which don't give a hoot about whitespace -- because while the C compiler doesn't care about whitespace, I do.