Slashdot Mirror

This has been known for donkey's years. Guido has been talking about this compatibility break since the 90s. The changes were laid out in detail in PEP 3000, first published in 2006. They have already released two alphas. A conversion tool to automatically make some of the required changes (such as changing print statements to print() function calls) already exists.

This has been known for donkey's years. Guido has been talking about this compatibility break since the 90s. The changes were laid out in detail in PEP 3000, first published in 2006. They have already released two alphas. A conversion tool to automatically make some of the required changes (such as changing print statements to print() function calls) already exists.

http://svn.python.org/view/sandbox/trunk/2to3/

And, as others have stated, there'll be the 2.6 branch, which will be backwards compatible.

Or, in other words, the story is stupid and misleading.

The "What's New for 3.0?" article over on python.org:

http://docs.python.org/dev/3.0/whatsnew/3.0.html

hmmm every IDE I use that has a python mode translates tabs to spaces.

I work in a corporate environment - so we have defined spaces to be the standard - and this follows the python recommendation for new projects per pep-0008.

Sounds like a non-issue to me.

If there is anything that I have learned in the past 10 years of writing code (since before high school), I have learned that the following sequence of learning is ideal.
1. HTML/CSS/JavaScript - Get acquainted with web programming. None of that Nambly-pambly BBCode crap that they offer on MySpace.
2. Python - I wish I had got into this before I learned C++. Good for learning about shells if you decide to switch to Linux or BSD, especially if you decide to create your own website through a webhosting provider that uses SSH.
3. C/C++ and/or PHP/MySQL. - Playing with the big-boy toys at this point. The safety net that points 1 and 2 provided has been lowered.
4. OpenGL or Assembly Programming. - Really advanced programming! OpenGL is high-level. Assembly is low-level.
From there on, the sky is the limit.

I'm very happy to see something productive out of the Parrot community. They've promised some great things, and we've been waiting a long time to use their offerings. Some people in the community (see article below) have started to doubt the Parrot project's usefulness, but maybe this cool Perl6 development will make them re-think their stance.

Will Parrot ever truly deliver? (http://pinderkent.blogsavy.com/archives/124)

Earlier today I was reading an article about Parrot. Parrot is, as stated on the projects Web site, a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator.

So Parrot does sound like an interesting piece of technology. Its understandable how a common runtime for scripting languages could prove beneficial. But will it ever be a platform suitable for serious, production usage? I have my doubts.

Parrot has been under active development for quite some time now. The initial 0.0.1 release was made on September 10, 2001. During 2007, weve seen a release every month or so. So a lot of effort has been put into Parrot over the past six years. It has surpassed one of the major stumbling blocks with many Open Source projects, in that it has managed to build at least some development momentum. Unfortunately for its supporters, Parrot has never really seemed to catch on. I think there are a number of reasons for this.

Stability is probably the first problem. I dont mean stability in terms of the runtime crashing, or anything of that sort. Im talking about concept stability. There has always seemed to be a relatively large amount of change between releases. While this is good, in that there are improvements being made and new ideas being implemented, this causes problems for users who want to build reliably upon Parrot. Individuals and businesses often do not, or cannot, invest the time and effort to track a continually-moving target like Parrot.

The language implementations for Parrot, while many in number, have been of limited use. Looking at the status messages of some of the most promising and practical language implementations shows why this might be the case. Such messages include:

• Incomplete - but all examples and test cases are working. (Amber for Parrot)
• Most of the samples work. (BASIC/compiler)
• Has been broken for a long time. (BASIC/interpreter)
• Parser is pretty complete. Generates PIR for basic Ruby programs (Cardinal, Ruby CVS Head 1.9 implementation)
• Functioning, all samples working, lacks IO routines (Cola)
• Working for some simple forms. Due to some broken features, most of the bootstrapping code has been commented out. (Common Lisp)
• Functioning for handcrafted test cases. Loading frozen state is currently broken. Far from complete. (Parrot m4)
• This project has been abandoned. Any takers? (Pint, an experimental PHP implementation)
• Passes nearly 25% of tcls (lightly converted) test suite, using a Test::More like harness. (Tcl)

So while there are many interesting language implementation projects for smaller or more obscure languages that have reached further stages of completion, the ones that were most likely to be of practical use seem to be lacking. Now, this is understandable. Maintaining a suitably complete Ruby, Python, Perl or Tcl implementati

[1] - http://docs.python.org/modindex.html

Python does NOT lack expressive power either. Things like list comprehensions are beautiful:

>>> [str(round(355/113.0, i)) for i in range(1,6)]
['3.1', '3.14', '3.142', '3.1416', '3.14159']

http://www.network-theory.co.uk/docs/pytut/ListComprehensions.html
Both powerful and easy to remember without needing any extra documentation

Except that he isn't limiting how you can program in Python. lambdas are still in Python 3 if you really want to use them. But for most applications of lambda in Python, list comprehensions are superior. They're not only easier to read, but also provide better performance.

Considering the vast gulf of language flexibility between Python and actual "bondage and discipline" languages such as Pascal or OCaml, the notion it should be counted among them is difficult to take seriously.

Python has been ported to both of those systems, actually. And a fairly large number of others. I'd say they have their bases covered. There's no version for, say, PaulOS. But I think it'll squeeze by.

http://www.python.org/download/other/

The bad news is that they are wasting their time using the Matlab syntax, while there is a much better alternative for doing exactly the same thing. Python is universal, if there's anything you can do with a computer, the simplest way to do it is with Python, so why do it the hard way?

Not sure about the C++ problems you mention, but in Python there is Kamaelia and a dozen of other libraries targeted for creating scalable parallel systems.

Btw. an earlier post mentions the upcoming QT concurrency framework - if Trolltech is able to pull this out on all C++ platforms they support, then it kind of justifies Stroustrup's position, isn't it?

The question is, would you also be ok with python being even slower than it is now?

Yes. Using Python is already a trade-off about it being easier to write code over it being optimally efficient.

I am pretty sure (without having searched for it) that an 'exact' class exists for Python, where all math is handled internally, perhaps base 10 to avoid strange rounding errors.

Something like that. The Demical class was created to overcome this problem. In fact, reading from PEP 327, it's clear there's another major problem with Python's "out of the box" floating point support. As it states (from Alex Martelli), "Python (out of the box) doesn't let you have binary floating point numbers with whatever precision you specify: you're limited to what your hardware supplies."

Considering that Python was designed to run on all varities of hardware, having such a core variability with floating point numbers really makes the native floating point support rather risky to ever use. Python's tutorials even include an Floating Point Arithmetic: Issues and Limitations whose final answer basically reduces to: Pathological cases exist, but use clever % formatting to hide it. Personally, I'd be happier if they used Decimal for floating point arithmetic with "sane" defaults (and yes, I'm punting on what exactly "sane" defaults would be).

The question is, would you also be ok with python being even slower than it is now?

Yes. Using Python is already a trade-off about it being easier to write code over it being optimally efficient.

I am pretty sure (without having searched for it) that an 'exact' class exists for Python, where all math is handled internally, perhaps base 10 to avoid strange rounding errors.

Something like that. The Demical class was created to overcome this problem. In fact, reading from PEP 327, it's clear there's another major problem with Python's "out of the box" floating point support. As it states (from Alex Martelli), "Python (out of the box) doesn't let you have binary floating point numbers with whatever precision you specify: you're limited to what your hardware supplies."

Considering that Python was designed to run on all varities of hardware, having such a core variability with floating point numbers really makes the native floating point support rather risky to ever use. Python's tutorials even include an Floating Point Arithmetic: Issues and Limitations whose final answer basically reduces to: Pathological cases exist, but use clever % formatting to hide it. Personally, I'd be happier if they used Decimal for floating point arithmetic with "sane" defaults (and yes, I'm punting on what exactly "sane" defaults would be).

What exactly is "bad" about JQuery?

Bad GUI standards? What does that have to do with JavaScript? If you can name a GUI standard within a single language that it better, please let me know. Certainly you don't mean Python's GUI since there's no standard there at all. It's the same story with C, C++, Ruby, Perl, Pascal, and all of the others. A notable exception is Java (aside from the AWT/Swing duplication), and a large number of people hate that. Name something better.

What's wrong with DOM/CSS, especially when there is nothing about JavaScript itself that's intimately tied with DOM/CSS. There's no reason within the language's constraints that an applications programmer couldn't integrate JavaScript with GTK+ or Qt.

As for debuggers, have you even used Venkman? Or are you still using alert() calls for your debugging?

Probably, but I wouldn't be surprised if it fails on 0.1

>>> [print i for i in range(30, 0, 1)]
File "<stdin>", line 1
[print i for i in range(30, 0, 1)]
^
SyntaxError: invalid syntax
>>>

You hit the "print is a statement" design flaw. If you were thinking p3k, then it requires parentheses.

[print(line) for line in listname]

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

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.

on_connect do(self):
  self.connected = True

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

x = a if b else c

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.

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.

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/

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.

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.

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.

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.

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.

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.

Indeed:

Backslash can be used to allow continuing the program line past a carriage-return, but you almost never have to use it. Python is smart enough to do the right thing when it sees an open bracket, a comma separated list, and a carriage-return.

From Moving To Python From Other Languages.

An article on functional programming is the perfect time to introduce my new son, Nick, to Slashdot. Previous releases were in C, Perl, and Python. Since Nick's functional, this one is in Lisp.

Mod me up or my son will spit up on you.

It is just sad to read the Python implementation of this functionality. Almost nothing is written according to the Python Style Guide. Weird "__foo"-variables can be found, then it's not Python2.3 compliant because of ONE silly "staticmethod", many "getters" and "setters" which are just useless in this script. If MS wants to show their code to the scripting community, they should at least make it pretty and according to the language's coding standards. But maybe that is their understanding of "pretty". Who knows.

Python is not compiled. Perl is not compiled. Javascript is not compiled. These languages are read in, line by line, and executed.

You fail it.

If you're interested in Python Web development, you'll find a host of network and Web specific frameworks. I suggest checking out Twisted, Zope, Plone, and Django for examples. You may also find some other goodies when you explore the Python Cheese Shop.

Of course, no mention of Python can pass by without someone bringing up Ruby on Rails, so I'll just do that right now. :) However, I have no experience with it whatsoever, so I'll withhold any opinion.

"We would still be thankful for RMS though. "

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard! And happy birthday!

I'll be flamed for sure (espec. by the usual Ruby suspects), BUT... I was once where you are now, and I ain't lookin back. ;)

My 2 cents anyhow, for what they're worth (...wait...2 cents?)

Hmm. It seems to have changed recently (for some value of recently).

See this mailing list post for a copy of it as it was a few years ago.

As far as having to learn Elisp goes, one thing I can think of specifically is folding. Vim has this built in. That doesn't seem to be the case with Emacs. I searched Google and the best I could come up with was a bunch of Elisp. I didn't want to paste a bunch of code without having any idea how it worked.

To be fair, Emacs can do things that Vim cannot (e.g. a built-in shell, which is handy sometimes) but there are also other Emacs problems for which the solution seems to be "use this mode and paste in this Elisp code."

git-svn looks very interesting, as it should provide a way to add distributed scm capabilities on top of svn, where you're working with projects that use svn. It'd be useful even just for the ability to take partial local history and keep local modifications under revision control. I wonder if there's anything similar for Mercurial...

Having written MPI and Linda work-alike libraries, developed parallel and distributed systems, and being a heavy user of threads and remote procedure calls (via xml-rpc), I will say that the general issue that all of these different systems try to handle is one of API. How does one have data X handled by function Y in thread/process Z. In the realm of threading, we use queues with locks. MPI/PVM/Linda/XML-RPC all use sockets to pass data between processes, and all but Linda requires that you specify the destination process explicitly.

One interesting recent development is the processing package for Python: http://www.python.org/pypi/processing/ . The idea is that you create processes like you would threads, then use shared queues, key-value mappings, etc., to pass data between the processes like you would threads. By sticking with generalizations that are seen to be 'easy' to understand and use (primarily queues), they bypass the majority of the difficulty people have when using threads and processes. Of course it doesn't hurt that the data transfer is pretty fast.

The only limiting factors with the particular implementation is that it relies on fork in *nix, and the transfer of code as data in Windows (which isn't generally possible for all languages, especially with the NX processor extension). If Windows had a usable fork, and if there was a 'fork across machines' (think mosix), many of these discussions would result in "just program it like you had a thread and use shared queues and the processing package for your language".

Python Path For Windows 2k and XP, Python20 !!

Install Python in the root of your C. i.e. C:\Python20\

Go to your start button, go up to My Computer and Right click it and go to properties.

Click on the Advanced tab, click on Environment Variables button at the bottom.

Below the System Variables box, (the second box), hit New.

In the Variable Name box, type PYTHONPATH

In the Variable Value box, type this exactly:

C:\PYTHON20;C:\PYTHON20\DLLS;C:\PYTHON20\LIB;C:\PY THON20\LIB\LIB-TK

You can copy and paste that.

Hit OK repeatedly.

Reboot.

Oh, you forgot:

5,343 built-in functions, assuming all the standard modules are installed. By comparison Python has 71. In other words, you have to keep track of about 75 times the number of name collisions when dealing with PHP versus Python.

This could be almost instantly fixed if they'd add namespaces to PHP, but that keeps getting shot down.