🌐 Mailman 3 June 2005 - Python-list - python.org

Re: Debugger Confusion
by Rex Eastbourne July 16, 2005

July 16, 2005

One thing: is it possible to go through the code within emacs? Doing it on the command line is useful, but it would be very helpful if I could have a little marker within the emacs buffer that showed me where I am. Rex

2 1

Re: Seeking IDE
by Jags July 8, 2005

July 8, 2005

Hi there, You could use the IDLE that is bundled along with the Python installation. If you don't like that, you could use any of the following editors: EditPlus, TextPad, UltraEdit, WingIDE, Komodo (from ActiveState) or jEdit. All these are Windows based. Cheers! - Jags.

2 1

psycopg authentication
by jslowery＠gmail.com July 8, 2005

July 8, 2005

Hello, I'm new to both PostgreSQL and psycopg and I'm trying to connect to my database running on localhost. I have postgres setup to do md5 authentication and this works when using a db admin tool on my local network. For some reason, psycopg fails with IDENT authentication. >>> import psycopg >>> psycopg.connect("dbname=jlowery user=jlowery host=localhost password=XXX") Traceback (most recent call last): File "<stdin>", line 1, in ? psycopg.OperationalError: FATAL 1: IDENT authentication failed for user "jlowery" Is there a way to make this module connect with MD5 auth?

4 5

pickle alternative
by simonwittber＠gmail.com July 8, 2005

July 8, 2005

I've written a simple module which serializes these python types: IntType, TupleType, StringType, FloatType, LongType, ListType, DictType It available for perusal here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/415503 It appears to work faster than pickle, however, the decode process is much slower (5x) than the encode process. Has anyone got any tips on ways I might speed this up? Sw.

6 20

Thoughts on Guido's ITC audio interview
by Dave Benjamin July 7, 2005

July 7, 2005

Guido gave a good, long interview, available at IT Conversations, as was recently announced by Dr. Dobb's Python-URL! The audio clips are available here: http://www.itconversations.com/shows/detail545.html http://www.itconversations.com/shows/detail559.html I'd like to comment on a few parts of that interview. One thing Guido mentions in his comparison of ABC (Python's predecessor) and Python is how ABC was inextricably tied to its environment (a la Smalltalk), where Python, though it supports an interactive mode, follows more of a UNIX-style "do one thing well" philosophy, and was designed to integrate with other tools rather than being a whole world to its own. I find that a similar comparison can be made between Python and Java. Java's startup time is so long that it is not practical for writing small tools for use in command-line scripts, and the propensity toward application servers and integrated development environments suggests a strong preference for a monolithic, self-contained, single-language environments. On the other hand, even though internally "there's only one way to do it" in Python, Python itself is one of many ways to develop software, and does not insist on being the one perfect way to do it. You can use whatever editor you like, and the language doesn't go out of its way to make it difficult to use other programs and processes, including the operating system if so desired. It is a bit ironic that, according to Guido, the command-line interpreter interface to Python was more of an afterthought, since my whole experience with Python has very much centered around the interpreter. Like many, I think, my first use for Python was as a calculator. =) In fact, since discovering Python, I've been very resistant toward learning any language that doesn't have an interpreter. Ruby, Scheme, OCaml and SML/NJ have been fun to learn because I can tinker with them at the command line. "perl -de 42" is rather frustrating to use, as is Haskell's "hugs" due to the inability to define new functions at the command line. Command-line interfaces are a great way to get up to speed on new languages and libraries. One of the advantages of Python is that it allows you to graft a CLI onto environments that weren't designed with one. For instance, Jython gives Java a command-line interface, and this makes working with Java much more tolerable since you can interact with libraries in real-time and learn how they behave at runtime. Likewise with PythonWin and COM scripting. I am glad to see that IronPython is designed with a command-line interpreter as well, should I ever need to learn my way around .NET in a hurry. Guido makes a funny jab at Paul Graham about Graham's nine things that make Lisp Lisp (available here: http://www.paulgraham.com/icad.html) - I had read this essay many times but never saw the subtle irony behind claims of "Greenspunning": in order to claim that a language is approaching Lisp, you have to define what it is about Lisp that other languages are purportedly emulating, and this begs the question of why you have the authority to declare which 9 (or n) attributes of Lisp are most important. I like Paul Graham and his essays a lot, but I must admit I had to laugh too when I heard the way Guido framed this argument. I'm not so sure that Python has 8 out of 9, though: the statement/expression dichotomy rules out #6, and the lack of macros rules out #9. These are arguable, depending on how you define things, but I think the most obvious thing that Python lacks compared with Lisp and Scheme (and also Ruby) is a symbol type (#7). I'm in the process of trying to understand what symbols are good for, outside the context of Lisp and its nested lists of symbols as executable code. Ruby seems to have come up with some creative uses for symbols within Python-like syntax, though I haven't seen anything terribly compelling so far. Guido briefly summarizes language comparisons with other languages: - Perl: similar niche, but Perl is for regexes and text processing, and Python is for objects, data structures, and more general-purpose programming. Obligatory TMTOWTDI argument. - PHP: very successful at its niche, being a point-solution for adding bits of script to web pages. Not very useful outside that context, and lots of language-design gaffes. - Java: the usual static vs. dynamic, static analysis vs. unit testing arguments. Guido says that there's such a small amount of problems that can be caught at compile time, and even the smallest amount of unit testing would also catch these problems. "The blindness of that [static] position... escapes me." - C/C++: same arguments as Java, plus most programmers aren't up to the task of manual memory-management. - Lisp: even though there's no code-equals-data in Python, you still have the compiler available at runtime, and there's a lot you can do to treat code as data even though they're not syntactically idnentical. - Smalltalk: very similar to Python, but Python is easier to integrate into existing shops that use other languages, mainly (IMO) because Smalltalk is a self-contained, integrated environment so the cost of introducing it is much higher There was also some discussion on why Java seems to be such a memory hog. Guido chalks it up to Java's "fancy schmancy garbage collection technology" with its heaps and threads and insistance on far-reaching low-level control over all the poitners in the heap. It is a bit ironic that (C)Python with its simple reference-counting plus cycle-detection seems much less resource-hungry than Java's GC, even though most language experts consider GC to be a vastly better technique. But I think this has more to do with Java's particular implementaion of GC; OCaml, for instance, is garbage-collected but has a very lean memory footprint. I think Python's decision to use reference counting was an instance of worse-is-better: at the time, reference counting was already known not to be "the right thing", but it worked, and the implementation was simple. Likewise with dynamic typing versus type inference. It seems that Guido shares Alan Kay's viewpoint that type inference is really "the right thing", but modern language technology is really not ready to make it mainstream, whereas dynamic typing works today, and is arguably a better "worse" solution than explicit/manifest static typing due to its verbosity. >From the perspective of writing C extensions, Guido claims that the amount of pain (regarding memory management) is about the same whether you're extending a reference-counted language like CPython or a garbage collected language like Java. Anyone with experience writing C extensions want to comment on this? Type inferencing is especially difficult to add to a dynamically typed language, and in general I think results are much better if you have type inference from the very beginning (like ML and Haskell) rather than trying to retrofit it later. Guido says that they've only been able to get it to work reliably in Python with constants, which isn't very useful. Regarding Ruby, Guido said that the community is much smaller than Python, and that it's much more of a "better Perl" than a "better Python". I think that, despite claims by both Guido and Matz, Ruby sits pretty much on the fence betwee the two languages. Guido says he dislikes the code block syntax in Ruby, but doesn't make it clear whether it's the syntax he dislikes or the code blocks themselves. He does mention that if you like Smalltalk, you'll probably like Ruby because of the code blocks... Generators and iterators are, according to Guido, an "80% solution" for the kinds of things people use code blocks for in Ruby. I think that the newly-proposed PEP 343 offers adds another 5-10% to the solution, perhaps; soon, Python will be able to do resource management in addition to iteration patterns without the use of code blocks. I can still think of additional uses for code blocks, and I have to wonder how many "point solutions" Python is going to gain in attempt to avoid adding code blocks to the language. This is not to say that I don't think generators or the newly proposed "with" keyword are cool features to have. (Upon review, I realize that Guido made the "80% solution" comment regarding generators vs. continuations, not code blocks. Still, generators are far more specific of a tool than either continuations or blocks.) Someone in the audience mentioned that the CPython VM is so solid they're surprised nobody's implemented a Java program on top of the Python VM (as opposed to the other way around, as in Jython). Someone in the audience surprised everyone by mentioning an actual project attempting this, called javaclass: http://www.boddie.org.uk/python/javaclass.html In response to any question on how to create a language, a community, a successful project, Guido's response tended to be the same: he doesn't really know what he did that made it work, or made the community follow Python so well and for so long. He says it's probably not a good idea to start a new project by following in the footsteps of an old one. If only we could tap a bit deeper into the mystique of successful software projects. ;) Cheers, Dave

13 15

Modules for inclusion in standard library?
by Reinhold Birkenfeld July 7, 2005

July 7, 2005

Hello, at the moment python-dev is discussing including Jason Orendorff's path module into the standard library. Do you have any other good and valued Python modules that you would think are bug-free, mature (that includes a long release distance) and useful enough to be granted a place in the stdlib? For my part, ctypes seems like a suggestion to start with. Reinhold

19 26

Programmers Contest: Fit pictures on a page
by hicinbothem＠ems.att.com July 6, 2005

July 6, 2005

GLOSSY: The Summer Programmer Of The Month Contest is underway! Deadline is September 30, 2005 http://dinsights.com/POTM -------------------------------------------------------------------------------- I love taking digital pictures, but that nice glossy photo paper is expensive! So when my lovely wife asks for prints of a bunch of pictures, I always try and fit them onto a single piece of paper. The summer POTM challenges you to write a program that will place up to 26 pictures on a sheet of paper with the least amount of leftover space. -------------------------------------------------------------------------------- The Programmer Of The Month (POTM) is a just-for-fun programming contest with an active forum and over 1100 members (we usually get 40-50 entries for each POTM challenge). Supported languages include C/C++/Perl/Ruby/PHP/Python/awk/shell. Emphasis is on the algorithms and the joy of programming. If it sounds like fun, please visit at http://dinsights.com/POTM ... =Fred (a.k.a. The POTM-MASTER)

12 16

Re: Favorite non-python language trick?
by todddeluca＠gmail.com July 6, 2005

July 6, 2005

If I had to choose one feature, I would like to see better support for nested lexical scopes. However, I imagine this is no easy "trick" to add to the language. > I'm curious -- what is everyone's favorite trick from a non-python > language? And -- why isn't it in Python?

5 5

unittest: collecting tests from many modules?
by Jorgen Grahn July 4, 2005

July 4, 2005

I have a set of tests in different modules: test_foo.py, test_bar.py and so on. All of these use the simplest possible internal layout: a number of classes containing test*() methods, and the good old lines at the end: if __name__ == "__main__": unittest.main() This is great, because each of the modules are runnable, and I can select classes or tests to run on the commandline if I want to. However, running all the tests from e.g. a Makefile is not that fun; I don't get a single pass/fail summary across the modules. What's the best way of creating a test.py which - aggregates the tests from all the test_*.py modules? - doesn't require me to enumerate all the test classes in test.py (forcing each module to define test_foo.theSuite or someting would be OK though) - retains the ability to select tests and verbosity (-q, -v) from the command line? Something like: import unittest import test_foo import test_bar if __name__ == "__main__": unittest.main(modules = ['test_foo', 'test_bar']) Seems to me this should be possible, since all the logic for doing it /is/ there for the local module; I'd assume there would be a way to make unittest search additional modules for test classes. But my head starts spinning when I read the source code ... /Jorgen -- // Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu \X/ algonet.se> R'lyeh wgah'nagl fhtagn!

6 7

Re: When someone from Britain speaks, Americans hear a "British accent"...
by Grant Edwards July 4, 2005

July 4, 2005

On 2005-06-30, Luis M. Gonzalez <luismgz(a)gmail.com> wrote: > Well, yes, it is kinda off topic, but very interesting... > Being myself an argentine with spanish as mother tongue and a > very bad English, it's hard foro me to tell the difference > between accents. I can hardly tell an Irish from an English... > But what I did tell is the broad range of different accents > within London when I visited the city in 2001. > > Some people seemed to speak very clear to me, and others > seemed to be speaking german! I'm an American who grew up watching plenty of BBC, and I run into afew native Londoners whom I have hard time understanding. I don't ever remember having troubly understanding people outside the city. -- Grant Edwards grante Yow! I KAISER ROLL?! What at good is a Kaiser Roll visi.com without a little COLE SLAW on the SIDE?

2 1