Slashdot Mirror

Both the % operator and the string.Template module are retained in version 3.

According to the plan "it will be deprecated in Python 3.1 and removed from the language at some later time"

Well, I really like Python, but I agree with the grandparent that lack of good debugging tools is really annoying. Frankly, I'd like a debugger that'd allow me to easily insert breakpoints and watchpoints into a program. Also, I'd like the debugger to be standardized and included with the default distribution of the language. C, C++, Java, Perl and Ruby all come with debuggers. Why doesn't Python?

It does come with one, although I have to admit that I prefer winpdb, since it not only has an optional GUI for debugging, but it supports debugging/breakpoints remotely - which is really nice for mod_wsgi and mod_python apps.

I can't really offer any help in regards to an IDE - vim does what I need it to, without wasting a bunch of resources.

Well at my college we are all Linux, they start you off with C++, but IMO I think they should start off with Python to ease in the freshmen. I would suggest Django/Python for web programming (I am in the process of learning), also PHP (which I love and currently do all my side projects in) as for non web programming I would go with C/C++, and dare I say Java.

You can find Python book online, and Django book as well.

For a good IDE I really like Geany, it works well with a Linux system, and it's light weight. It looks for installed compilers so you don't have install anything on top it as long as you have all the stuff you needs like GCC, OpenJDK, etc.

According to: PEP 8, Style Guide for Python Code, each indent should be four spaces.

http://www.python.org/dev/peps/pep-0008/

>> Free Resources for Windows Perl Development

The definitive one: http://python.org/

That'a reminds me of something else I like about Python.. its language is documented.

Mod parent up!

If there's a single feature that makes python stand out, it's that python has such a high standard of documentation that it is easy to pick up a new project grab the modules you need and start working. The documentation even extends to the implementation of python itself, which makes extending python via modules written in C really easy.

If you're looking for a language that will allow you to write clean code, and accomplish complex projects quickly and easily, Python is the way to go; the white space convention may seem odd at first (I certainly was very suspicious of it), but after a couple hours you'll find it quite comfortable, and you'll only get one indenting error for every ten semi-colons you would have forgotten in C, so it's ultimately a big time saver.

This isn't to say Python doesn't have its downsides. I've been working on several large projects, and performance issues do come up, but those can be worked around via C modules when necessary. All in all, thanks to the clear syntax and excellent documentation you'll find that you can write programs many times quicker in python than in C within just a few days of learning it.

Python is absolutely unusable on real world projects (any project where you aren't the sole developer) due to that indentation crap.

It's fine if you don't like Python and don't want to use it, but to say that it's completely unusable on real world projects is a bit absurd. And while you may find it hard to read, I think it's obvious because if it looks like code is a block, it is. The main trick to read and follow PEP-8, use a decent editor and write unittests.

Trolling? I'll bite.

Free: http://pythonide.blogspot.com/search/label/spe
Free: http://die-offenbachs.de/eric/index.html
Free: http://docs.python.org/library/pdb.html#module-pdb (and included with Python)
Commercial, but excellent (my team uses it): http://www.wingware.com/
Commercial: http://www.activestate.com/Products/komodo_ide/index.mhtml

If you really love Visual Studio for some reason: http://www.activestate.com/Products/visual_python/index.plex
If you love Eclipse: http://pydev.sourceforge.net/

And for the lazy, "import pdb; pdb.set_trace()" has always been my favorite way to debug python software. Add that line anywhere; get a breakpoint. Make it conditional with an if statement.

Not to mention introspection right down to the bytecode at runtime (there is even a Python module that lets you edit the bytecode at runtime, if you are sufficiently crazy).

In short, you have not used Python for more than 10 minutes if you really think the debugging isn't good.

IHBT. HAND.

There's a standard: It's spaces.

From http://www.python.org/dev/peps/pep-0008/:

The most popular way of indenting Python is with spaces only. The
second-most popular way is with tabs only. Code indented with a mixture
of tabs and spaces should be converted to using spaces exclusively. When
invoking the Python command line interpreter with the -t option, it issues
warnings about code that illegally mixes tabs and spaces. When using -tt
these warnings become errors. These options are highly recommended!

For new projects, spaces-only are strongly recommended over tabs. Most
editors have features that make this easy to do.

I'm not too sure of what I think of Python's use of indentation to delimit blocks.

Have you ever actually tried using python? I am very much in favor of capital punishment for everyone who doesn't properly indent his code in other languages anyhow, so being forced to indent in python wasn't really a problem for me. I do not understand why people keep bringing up this argument, there are valid reasons why python was designed this way and it is something you get used to after 5 minutes. And if you really insist on using braces, you can still use them:
if button_pressed: #{
launch_missiles() #this line must be indented but slashdot does not allow me to
#}

For example, some of the following: OCaml, Python, Ruby, C++, D.
But there are really lot of them available. What's best, depends on what you try to do and your taste.

Someone should ask this question every time Slashdot runs an IPv6 story.

In related news, http://python.org/ is accessible via IPv6 now.

what if, tomorrow, your database gets a few thousand hundred records with strings of Chinese or Japanese characters added?

We do next to no business in China, Japan, or Korea because overseas shipping is so expensive.

The best you can do [for side-by-side Python 2 and Python 3 in a Windows environment] is name your Python 3000 files differently (e.g. ".py3"), and associate that.

That won't work so well. Python already relies on file name suffixes being .py.

Also, of course, CPython (what is downloadable from http://python.org/ is the reference Python implementation, but it isn't the only one, and it's certainly not the fastest one. There's Psyco, and then there are Jython and IronPython, which can both be pretty impressive performance-wise thanks to JIT.

Now, when is Python going to get proper lexical scoping, like Perl's had since 1994?

It had always been there. If you mean the fact that it was previously not possible to access variable from outer non-global scope, then it is fixed in 3.0 with the new "nonlocal" statement.

The statement is an error as the types don't match. Quite a few people claimed this in response to my previous posts.

They are correct. "UTF-8 String" is not really an UTF-8 constant, it's just a plain Unicode string now. It makes sense, too, as comparing a byte array with a string is not generally well-defined operation. And yes, of course, it's a breaking change, and is on the changelog.

Now you can still have byte array literals if you want them, but they are opt-in via "b" prefix (much like Unicode strings were opt-in via "u" in 2.x). So:

if byte_string == b"UTF-8 constant":

works.

It also appears to be impossible to make an unadorned string constant that contains an *invalid* UTF-8 encoding, since the translation is done at compile time, so no changes to the current encoding will help.

Well, if it's invalid, it's no longer UTF-8, right? So not a valid Unicode string anyway - why would you want it to pretend to be one? You can still make a byte array like that (though of course it will fail if you then try to decode it as if it was UTF-8 - because it's not).

In Python 2.0 and in most other languages "\xC2\xA2" is a cent-sign

True for Python 2.0, false for "most other languages". It's not true for most post-Java mainstream and/or generally well-known languages (C#, VB, Haskell, R6RS - to name a few). So Python is simply standardizing on what's already widely accepted. Of course, it also makes most sense when you deal with Unicode strings - forget about bytes, work with codepoints. In-memory representation of the string shouldn't be your concern, anyway.

Also the documentation claims that b"\u00A2" is invalid, but that makes it really difficult to make byte string constants containing arbitrary UTF-8 in a more readable way.

Well, of course it's invalid - it's a byte array, not a string! And why do you think that it would have to be UTF-8 even if it was allowed? Why not UTF-16 or UCS4?

Of course, nothing stops you from using str.encode, e.g.: "\u00A2".encode("utf-8") - which is quite explicit about what's going on, and yet short enough at the same time. By the way, if you omit the argument to encode, it will just use the default system encoding for non-wide-chars, which is usually precisely what you want on Unix.

I know you may have been joking, but instead of this:

>>> print "Hello, world!"

for Python 3.0+ you must do this:

>>> print("Hello, world!")

It makes sense in the long run. Anyway, see the very start of the "What's New" page, "Print Is A Function":
http://docs.python.org/dev/3.0/whatsnew/3.0.html

too bad it doesnt install from source out of the box, even with libgdbm-dev installed

make
running build
running build_ext

Failed to find the necessary bits to build these modules:
_dbm
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

see bug here. Why they would announce a release that wouldn't build for a major distribution such as ubuntu baffles me.

Python provides a 2to3 source-to-source conversion tool...

1. >>> import antigravity
2. Automagic xkcd in browser!
3. >>> print "Hello, world!"

4. File "", line 2
   print "Hello, world!"
   SyntaxError: invalid syntax

5. :(

Like http://docs.python.org/library/2to3.html, perhaps?

OK, never mind, I just saw it, there seems to be such a beast: http://docs.python.org/dev/3.0/library/2to3.html#to3-reference

The release notes might interest people:
http://docs.python.org/dev/3.0/whatsnew/3.0.html

Also note that in the end of the release notes are info on the migration path from Python 2 to 3. I'll leave the rest to people who bother to RTFA... ;)

(For reference, Python is up to 2.6 - and their 3rd RC for 3.0)

http://python.org/news/ :-P

There is an elegant Knight's Tour solver right inside your Python distribution. You can find it at /usr/lib/python2.5/test/test_generators.py. Written by Tim Peters (a.k.a. timbot).

but the 2to3 tool will make this simple transforms (xrange->range, print "foo"->print("foo") automatically.

Except for the print statement....

You should see the terrible things I've been doing to my Neural Networks. I keep them locked up my my cold dark (but well lubed) HDD all day long. Unless I run them, in which case I make them run at 2.4GHz (which I'm sure wears on their calves like no other). Look, I architecturally, these control systems and Image recognition systems might resemble the very same structures we humans use for cognition. I do not believe that this resemblance means we should anthropomorphize them.

I just hope that if one day, one of these systems has an emergent property which looks like cognition we are able to recognize it, or perhaps the system itself will let us know.

BTW - I am using that python package to do a little project. It doesn't work particularly well yet, but I suppose its still just a work in progress.

Don't teach BASIC.

Agreed. But don't teach them C either, because that would be the other extreme.

I recommend Python as an easy-to-learn yet extremely useful general-purpose (this sorts out PHP) language.

What's ill defined about this?
python reference
It includes, as you can see, a full grammar specification and data model.

Now that's a ridiculous comparison between Perl 6 and Python 3.0.

Python 3.0 has gone from "a bunch of proposals" to an actual, feature-complete beta in recent months. And most reasonable observers actually believe that there will be a final, shiny 3.0 release this month. Moreover, Python 2.6-final is out and it has most of the 3.0 features backported to it, including the backwards-incompatible ones (optionally turned on and off).

Perl 6 seems to have languished somewhere between "idea" and "implementation" from around 2000 to 2005. Now it turns out that (SURPRISE!), "there's more than one way to do it" with Perl 6. There's a Haskell-based implementation and a Parrot-based implementation, and a few others that aren't as mature too, it seems. I've had a very hard time assessing how mature these are and how much continuity they will find in the final release... since they aren't developed by a core group of developers with a track record.

Python 3.0 is credibly just around the corner, coming from the same core team that brought us all the previous releases. Perl 6 is still stuck in the vague surreal mess of possibility and intrigue that makes Perl simultaneously so much fun and so frustrating.

Even if CPAN was the only argument for using perl (which it isn't), it would still be one hell of an argument.

Not when the opposition has an equivalent tool/repository, at which point it's just par for the course. See PyPi and EasyInstall/Setuptools.

(As for good high-level Python XML toolkits, I'm personally fond of lxml, but there are plenty 'round; if you couldn't find one, it's because you didn't know where to look).

That might seem wrong given that Python lists threading modules, but just look at Python's GIL to know what I mean. As in, no matter what you do, Python will still be running on one core. So, if you just want a performance boost because of a lot of I/O, then threads can get you there. Unfortunately, if you want to take advantage of a multi-core CPU with Python, Python's threads won't get you there. There has actually been a lot of discussion on this topic, but Guido just refuses to do it. The interpreter has no threads and the lib is not thread safe.

If you want to do multi-processing with Python, look at its subprocess module.

Guido's blog post on the GIL:
http://www.artima.com/weblogs/viewpost.jsp?thread=214235

The FAQ entry on a (fallacious) reason why they won't remove it:
http://www.python.org/doc/faq/library/#can-t-we-get-rid-of-the-global-interpreter-lock

``It is unfortunate that the mono is so closely associated with Windows, if the mono team had created/implemented a
completely new set of cross-platform libraries (that bore no relation to Microsoft's framework) it would be more accepted.''

But then they would just have done what various others have already done, wouldn't they?

(Mind you, there online documentation could be better - PHP's site for example, is so much friendlier).

They're actually hard at work on that problem too. In addition to Python 2.6 being released, the Python documentation is now generated using Sphinx. See for example the new tutorial output. Big WTF the first time I saw it, but it's a decent improvement with more in the pipeline.

Another common pattern to use for this, as well as for libraries, is the following:

try:
import one_way_to_do_it
except:
import more_common_way_to_do_it

But how well does a try block work with things that depend on from __future__ statements that Python 2.5.x doesn't recognize, such as the different print syntax and the different string literal syntax ("8bitchars", u"32bitchars" vs. b"8bitchars", "32bitchars")? From Python 2.5.x's definition of a future statement:

A future statement must appear near the top of the module. The only lines that can appear before a future statement are:

• the module docstring (if any),
• comments,
• blank lines, and
• other future statements.

This appears to exclude try statements.

From What's new in Python 3.0: The str and bytes types cannot be mixed; you must always explicitly convert between them, using the str.encode() (str -> bytes) or bytes.decode() (bytes -> str) methods.

That's the right way to do it, but I agree that as a retrofit to existing code, it's a headache.

Worse, it's a problem that's detected at run time, not compile time, at least with the CPython implementation.

3.0rc1 (beta) is already available and has been for some time now. The advantage of 2.6 is not as much its backward-compatibility but its ability to tell you exactly what needs to change (via runtime warnings) for 3.0 without actually breaking your code. I've been using both for months now, so this article isn't exactly hot news.

And if it's like some other languages you might have a long time to wait before 3.0.

Given that the first release candidate of Python 3.0 is already out, I doubt we'll be in for a very long wait.

Here are the changes.
I really have to check out the multiprocessing package. Too bad that I have to wait for the print function and the new division handling.

C#/.NET - http://msdn.microsoft.com/
Haskell - http://haskell.org/
Nemerle - http://nemerle.org/
OCaml - http://caml.inria.fr/
PHP - http://php.net/
Python - http://python.org/
Ruby - http://ruby-doc.org/ (API docs), http://ruby-lang.org/ (for more links and info)
SML - http://smlnj.org/ (the most popular implementation), http://standardml.org/Basis/ (standard library)

(X)HTML/CSS/DOM/XSL/etc. - http://w3.org/

Hm. Now that I've written it down, I see most of these are obvious, but then it makes sense, that the "official" sites tend to be the best reference.

komodo edit is an extremely powerful editor that works with a slew of languages on Windows, Mac and Linux. It is free as in beer. It is packaged by ActiveState as just an editor - but really it has many features that fall more into the IDE camp - yet it is light-weight and responsive - more like an editor. This review of komodo edit may be helpful.
 
  Komodo IDE is the big brother to Komodo edit I guess. I've never used it because the cost is outside my budget. ($295 for a full single user license - there is a student version but I don't know what it costs)
 
  SPE is free/free I believe. It is multiplatform and the price is right to at least give it a try.
 
All these and more are listed on the python ide page of the python.org wiki.
 
Personally - right now I use Komodo edit while I wait for python support in netbeans.

I'm not sure you'll read this but I hope so.

I'm about to start to learn how to program on my own, just for fun. For me it's to become better at certain computer challenges and to see if I'd like it enough to change career and start a B.Sc in computer science next year. That being said...

I read a lot on the subject and there are languages that are powerful and yet easy enough to learn. I'm especially thinking about Python since this is the language I decided to pick up.

In order to decide if this language is for you, read the foreword and the preface of "How to Think Like a Computer Scientist, 2nd edition". This open source textbook can be found here: http://openbookproject.net//thinkCSpy/

I also found a lot of info on the Python wiki: http://wiki.python.org/moin/BeginnersGuide

I hope this helps you decide.

Here is the quote from "How to Think Like a Computer Scientist, 2nd edition" that explains why to pick up Python.

How and why I came to use Python

In 1999, the College Board's Advanced Placement (AP) Computer Science exam was given in C++ for the first time. As in many high schools throughout the country, the decision to change languages had a direct impact on the computer science curriculum at Yorktown High School in Arlington, Virginia, where I teach. Up to this point, Pascal was the language of instruction in both our first-year and AP courses. In keeping with past practice of giving students two years of exposure to the same language, we made the decision to switch to C++ in the first-year course for the 1997-98 school year so that we would be in step with the College Board's change for the AP course the following year.

Two years later, I was convinced that C++ was a poor choice to use for introducing students to computer science. While it is certainly a very powerful programming language, it is also an extremely difficult language to learn and teach. I found myself constantly fighting with C++'s difficult syntax and multiple ways of doing things, and I was losing many students unnecessarily as a result. Convinced there had to be a better language choice for our first-year class, I went looking for an alternative to C++.

I needed a language that would run on the machines in our GNU/Linux lab as well as on the Windows and Macintosh platforms most students have at home. I wanted it to be free software, so that students could use it at home regardless of their income. I wanted a language that was used by professional programmers, and one that had an active developer community around it. It had to support both procedural and object-oriented programming. And most importantly, it had to be easy to learn and teach. When I investigated the choices with these goals in mind, Python stood out as the best candidate for the job.

I asked one of Yorktown's talented students, Matt Ahrens, to give Python a try. In two months he not only learned the language but wrote an application called pyTicket that enabled our staff to report technology problems via the Web. I knew that Matt could not have finished an application of that scale in so short a time in C++, and this accomplishment, combined with Matt's positive assessment of Python, suggested that Python was the solution I was looking for.

(Note: I haven't used Python enough to know if there's some way to do line continuations in it.)

implicit line joining and explicit line joining

basically, a \ for explicit and just continue the comprehension/function call/etc. for the implicit.

(Note: I haven't used Python enough to know if there's some way to do line continuations in it.)

implicit line joining and explicit line joining

basically, a \ for explicit and just continue the comprehension/function call/etc. for the implicit.

well, if they were smart, they'd have used Jython to run Django on the JVM.

Django already runs on Jython.

hmm why dont you start here: http://docs.python.org/dev/tutorial/index.html

http://python.org/

They all still suck for about the same reasons they sucked three years ago.

Python is a nice language, but it still suffers from the limitations of the CPython implementation. It's slow, and integration with standard C modules is troublesome.

Three years ago, ctypes wasn't part of the standard library. It is now, and it's great, not troublesome at all.

Python has distro packaging problems - the Python maintainers don't coordinate with the maintainers of key modules, like the ones for talking to databases, and as a result Linux distros don't consistently ship with a CPython and a set of modules that play well together.

Can you give an example? The DB-API seems like good coordination to me and easy_install psycopg2 and similar have never let me down.

They all still suck for about the same reasons they sucked three years ago.

Python is a nice language, but it still suffers from the limitations of the CPython implementation. It's slow, and integration with standard C modules is troublesome.

Three years ago, ctypes wasn't part of the standard library. It is now, and it's great, not troublesome at all.

Python has distro packaging problems - the Python maintainers don't coordinate with the maintainers of key modules, like the ones for talking to databases, and as a result Linux distros don't consistently ship with a CPython and a set of modules that play well together.

Can you give an example? The DB-API seems like good coordination to me and easy_install psycopg2 and similar have never let me down.