Re: Is inifinite loop not a good practice?

[Steve Holden]

Alvin A. Delagon wrote:
> Greetings,
> 
> I have to write a python script that would continously monitor and 
> process a queue database. Once the script sees an unprocessed record it 
> will create a thread to process it otherwise it will do nothing. I've 
> been planning to do an infinite loop within the script to do this but 
> I've been hearing comments that infinite loop is a bad programming 
> practice. I'm opted to run the script via crontab but I consider it as 
> my last resort. Do you have any suggestions on the design? Thanks in 
> advance!

Clearly no process written as an infinite look is expected to run 
forever - it will be brought down by system reboots, for example, 
without going into end-of-life issues.

The classic network server process is pretty much an infinite loop, 
though perhaps with a break condition actioned when the operator sets 
some flag with a command, and there's no real reason why you shouldn't 
cast your application as such a loop. You will need to do so with care, 
however.

The danger is that you will spend time that should really be allocated 
to other processes on the system checking for database updates. So you 
need to design your polling mechanism fairly carefully - perhaps it 
could sleep five seconds once it found there were no more records that 
needed processing before looking again, or some similar mechanism to 
ensure that the system doesn't spend too much time looking for changes.

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How many web framework for python ?

[Harald Armin Massa]

Bruno,

>In fact, there are actually too much *good* python web frameworks.

I tended to share that opinion, just because there are more web
frameworks then keywords in Python. But we should stop thinking of this
as a bug; it is a feature.

Because everyone and his girlfriend creates an own web framework for
Python, we have a clear security advantage over other languages. One
"ruby on rails" worm will bring down at least 2000 web 2.0 beta sites.
A worm for a Python web framework will be incompatible with all others.

Harald

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Harald Armin Massa]

>>OK, but then we should change ,
>>which starts with "Python is an interpreted, interactive,
>>object-oriented programming language."

I second this motion. Even tried to persuade the site maintainer
before. We should really, really change it. The perceived speed of
Python will at least triple on dropping that "interpreted" - and I am
NOT joking.

Harald

-- 
http://mail.python.org/mailman/listinfo/python-list

Is inifinite loop not a good practice?

[Alvin A. Delagon]

Greetings,

I have to write a python script that would continously monitor and 
process a queue database. Once the script sees an unprocessed record it 
will create a thread to process it otherwise it will do nothing. I've 
been planning to do an infinite loop within the script to do this but 
I've been hearing comments that infinite loop is a bad programming 
practice. I'm opted to run the script via crontab but I consider it as 
my last resort. Do you have any suggestions on the design? Thanks in 
advance!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: number ranges (was Re: Matlab page on scipy wiki)

[bonono]

Tim Hochberg wrote:
> Colin J. Williams wrote:
>
> >>
> >>It would be good if the range and slice could be merged in some way,
> >>although the extended slice is rather complicated - I don't understand it.
> >>
> >>   The semantics for an extended slicing are as follows. The primary
> >>   must evaluate to a mapping object, and it is indexed with a key that
> >>   is constructed from the slice list, as follows. If the slice list
> >>   contains at least one comma, the key is a tuple containing the
> >>   conversion of the slice items; otherwise, the conversion of the lone
> >>   slice item is the key. The conversion of a slice item that is an
> >>   expression is that expression. The conversion of an ellipsis slice
> >>   item is the built-in |Ellipsis| object. The conversion of a proper
> >>   slice is a slice object (see section section 4.2 The standard type
> >>   hierarchy )
> >>   whose |start|, |stop| and |step| attributes are the values of the
> >>   expressions given as lower bound, upper bound and stride,
> >>   respectively, substituting |None| for missing expressions.
> >>
> >>[source: http://www.network-theory.co.uk/docs/pylang/ref_60.html]
> >>
> >>The seems to be a bit of a problem with slicing that needs sorting out.
> >>
> >>The syntax for a slice list appears to allow multiple slices in a list:
> >>
> >>   extended_slicing ::= primary  "["
> >>   slice_list  "]"
> >>   slice_list ::= slice_item  (","
> >>   slice_item )* [","]
> >>
> >>but the current interpreter reports an error:
> >>
> >>>>> a= range(20)
> >>>>> a[slice(3, 9, 2)]
> >>   [3, 5, 7]
> >>>>> a[slice(3, 9, 2), slice(5, 10)]
> >>   Traceback (most recent call last):
> >> File "", line 1, in ?
> >>   TypeError: list indices must be integers
> >>>>>
> >>
>
> Extended slicing has nothing to do with lists. All that gobbeldy gook is
> trying to tell you is what the interpreter does with O[1:2:3, 4:5:6]
> where O is some arbitrary object. What it does is:
>
> O[1:2:3, 4:5:6] == O[slice(1,2,3), slice(4,5,6)]
>  == O.__getitem__((slice(1,2,3), slice(4,5,6)))
>
> In the case of python lists, __getitem__ doesn't support multiple slice
> arguments. However, you are free to define your own types which do
> support multiple slices.
>
That explains it but the current documentation in the reference manual
doesn't(I also tried what Colin did when reading that part). And as I
mentioned in another post, the current documentation suggests that
extended slicing is not supported for sequence type. As it said the
primary must be evaluated to mapping object for extended slicing.
Though it seems it doesn't matter as all python does now is turn
[start:stop:stride] into slice object and pass that to __getitem__, no
matter what object it is.

-- 
http://mail.python.org/mailman/listinfo/python-list

why does close() fail miserably on popen with exit code -1 ?!

[Atanas Banov]

i ran onto this weirdness today: seems like close() on popen-ed
(pseudo)file fails miserably with exception instead of returning exit
code, when said exit code is -1.

here is the simplest example (under Windows):

>>> print popen('exit 1').close()
1
>>> print popen('exit -1').close()
Traceback (most recent call last):
  File "", line 1, in ?
IOError: (0, 'Error')
>>> print popen('exit -2').close()
-2

has anyone have idea why is that?

- nas

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Donn Cave]

Quoth Alexander Schmolck <[EMAIL PROTECTED]>:
| "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
...
|> the only even remotely formal definition I've ever seen is "language with
|> designed to script an existing application, with limited support for handling
|> its own state". 
|
|> Early Tcl and JavaScript are scripting languages, Python is not.
|
| Right. Which shows that by this definition scripting language is not a
| meaningful and useful concept. No one will understand you correctly when you
| refer to "scripting language" and mean only something like the above -- and
| unless you spend a lot of your time talking about early tcl and early
| javascript I doubt you'd need a word for it, either.

Oddly enough, that's what I understand it to mean, too, so you can't
strictly say "no one".

On the other hand, I think it's obvious that a language like Python could
be used for scripting, without having been specifically designed for it as
described above.  There's an ambiguity in the phrase, out of context -
I can say "Python can serve as a scripting language for some applications",
but not "Python is a scripting language!", since its place in the taxonomy
of languages would be somewhere else.

Donn Cave, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Mac OS X Installation Problem

[Alex Martelli]

 wrote:
   ...
> But this begs the question, how do we upgrade our Python installations if OS X
> needs a certain version? Do we leave the pre-installed version alone and run a
> second Python installation? I suppose that the various package installers
> would know how to do that, right?

Yes, and yes.  The state for MacOSX Python is a bit in transition right
now (what with the introduction of intel Macs, and therefore the need
for Universal binaries), but soon, I hope, it will settle to a point
where downloading and installing Python (2.4.2 or better) without
disturbing Apple's own Python (2.3.5) will be trivial -- stay tuned!


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Mac OS X Installation Problem

[Alex Martelli]

 wrote:

> [EMAIL PROTECTED] (Alex Martelli) wrote:
> 
> >Edit a ~/.bashrc file to add /usr/local/bin to your PATH.
> 
> Hi Alex,
> 
> Easier said than done for a non-unix expert. Correct me if I am wrong. Bash
> looks at the contents of the PATH variable to decided which directories it
> should scan when parsing a command. If I type "Python -v", it will look in all
> of those directories for a file called "Python" and then execute it, passing
> it the -v parameter. Right?

Right.  The uppercase P in 'Python' would make the search fail in just
about every Unix in the world, but MacOSX is the exception (at least if
you're using its default HFS+ filesystem) and lets you be sloppy with
capitalization.


> I've been googling around for about an hour now, and I can't find any
> instructions on how to create or edit a .bashrc file. I tried to make one of

That depends on what text editor you favour.  Me, I love gvim, but most
people hate it.  MacOSX comes with TextEdit, scarce but really not
controversial, and emacs, the One Editor to Rule Them All.  TextWrangler
and subethaedit, both freely downloadable, are among the most beloved
free editors; BBEdit, I've heard, is widely considered the best for-pay
one.  What text editor you choose to edit text files on MacOSX, be it a
free or for-pay one, is hardly a suitable subject for the
comp.lang.python newsgroup, of course -- I apologize for the OT.

> Is there a web page somewhere that explains this?

There are many, basically one for each text editor program you may
choose.  TextEdit has a predilection for saving .RTF (a marked-up text
format Microsoft Word also likes) rather than plain text files, so I
would not recommend it in general, by the way -- too easy to err.

BTW, like in every other Unix, if you're having problem saving to a
textfile named .foobar, save to foobar without the initial dot, then
from a Terminal prompt, mv foobar .foobar  -- that's all it takes.

There are innumerable books and webpages about MacOSX and other Unix
variants, mostly pretty orthogonal to any Python issues or interests but
nevertheless interesting.  O'Reilly's "Learning Unix for Mac OS X
Tiger", for example, is really quite a good text.


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: number ranges (was Re: Matlab page on scipy wiki)

[Erik Max Francis]

John Zenger wrote:

> I strongly agree that Python should promote range or xrange to syntax. 
> I favor [0..10] rather than [0:10] because 0..10 is inherently easier to 
> understand.  Every maths text I have read uses the ".." notation to show 
> ranges; 

Math texts typically use a normal ellipsis "..." to indicate any sort of 
repeated pattern.

-- 
Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
   To know oneself, one should assert oneself.
   -- Albert Camus
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: number ranges (was Re: Matlab page on scipy wiki)

[John Zenger]

Colin J. Williams wrote:
> Bryan Cole wrote:
> 
>>>   
>>> First, I think the range() function in python is ugly to begin with.
>>> Why can't python just support range notation directly like 'for a in
>>> 0:10'.  Or with 0..10 or 0...10 syntax.  That seems to make a lot more
>>> sense to me than having to call a named function.   Anyway, that's a
>>> python pet peeve, and python's probably not going to change something
>>> so fundamental...   

I strongly agree that Python should promote range or xrange to syntax. 
I favor [0..10] rather than [0:10] because 0..10 is inherently easier to 
understand.  Every maths text I have read uses the ".." notation to show 
ranges; for that reason, perhaps, Haskell uses "..".  The colon is 
already overused; it both signals the beginning of compound statements, 
and has all sorts of slice/indexing meanings when it is inside square 
brackets, depending on how many colons there are and whether there are 
arguments between them.

Haskell also has a good step notation.  In Haskell:

[1..10] means [1,2,3,4,5,6,7,8,9,10]
[1,3..10] means [1,3,5,7,9]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Open Relay Test

[D]

Thanks guys for the info..the DSBL client app is exactly what I
need..unfortunately the app I'm writing will be for Windows (the only
client I saw was for Linux). Do you know if there's a Windows command
line port?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Mac OS X Installation Problem

[Matt]

Kevin Walzer <[EMAIL PROTECTED]> wrote:

>It's not considered a good idea to trash Apple system files. It's likely
>that system tools that depend on Python (CoreImage scripting comes to
>mind) are now broken and the only way to fix this is to reinstall the OS.

Thanks for the heads up. I thought that Apple had included Python as a 
convenience for its customers. I didn't realize it was actually being used by 
OS X. My Mac seems to be behaving OK, so maybe I don't use any of the Python 
parts, but I will keep that in mind in case it goes haywire in the future.

But this begs the question, how do we upgrade our Python installations if OS X 
needs a certain version? Do we leave the pre-installed version alone and run a 
second Python installation? I suppose that the various package installers 
would know how to do that, right?

Thanks,
Matt



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Format file size for printing

[John Zenger]

I know of no built-in way, but you could probably code this in a few 
lines using print "%.1f" and so on.

(Some of us, by the way, are in the camp that believes a kilobyte is 
1024 bytes, not 1000, so 103803 bytes for us is about 101.4 kilobytes).

abcd wrote:
> is there a built-in way of printing the size of a file nicely?
> 
> So if the file size is 103803 bytes it prints out like: 103.8K
> or
> 0.1MB 
> 
> something liek that?
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Mac OS X Installation Problem

[Matt]

[EMAIL PROTECTED] (Alex Martelli) wrote:

>Edit a ~/.bashrc file to add /usr/local/bin to your PATH.

Hi Alex,

Easier said than done for a non-unix expert. Correct me if I am wrong. Bash 
looks at the contents of the PATH variable to decided which directories it 
should scan when parsing a command. If I type "Python -v", it will look in all 
of those directories for a file called "Python" and then execute it, passing 
it the -v parameter. Right?

I've been googling around for about an hour now, and I can't find any 
instructions on how to create or edit a .bashrc file. I tried to make one of 
my own using bash and nano, but got stuck with the save command. It looks like 
I am supposed to use the "M-O" command to save it in Mac format, but I have no 
idea how to type that. A search of the nano docs for "M-O" didn't turn up 
anything either. I also tried to make a .bashrc file on my Windows box and 
copy it to my Mac, but the Finder gave me an error message saying that I'm not 
allowed to make files that begin with a dot.

Is there a web page somewhere that explains this?

Thanks,
Matt



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Komodo - Will it Lock Me In?

[Matt]

"Peter Decker" <[EMAIL PROTECTED]> wrote:

>You should take a look at Dabo, 

Yes, I have Dabo installed on my system. I made a small test app, but was 
unable to deploy it. I was getting an error from py2exe, I think, about how my 
wxPython installation was not correct. This is the kind of thing I am talking 
about. If Dabo were an integrated system, I wouldn't have to spend many days 
struggling to install package after package and then get them all to play nice 
with each other.

Having said that, I will continue to struggle and like Dabo as the best option 
so far.

Thanks,
Matt



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Komodo - Will it Lock Me In?

[Matt]

Trent Mick <[EMAIL PROTECTED]> wrote:

>Perhaps you are thinking of some of the C/C++ IDEs (like Visual Studio
>on Windows and Xcode on the Mac)

Hi Trent, Ravi,

Actually, I had two things in mind:

1) HTML editors - I made a website using Yahoo Sitebuilder. It's a pretty good 
tool, but I didn't want to use it any more, but could not simply open my HTML 
files with another editor. I had to spend many hours ripping out the 
Sitebuilder goo first.

2) "RAD" tools. If you write code in VisualBasic, you can't use hardly any of 
it in another Basic RAD tool such as RealBasic. They are ostensibly the same 
language, Basic, but in reality there is only a surface resemblance.

I want to avoid this if I can with Python. I want to have my code, and then 
work on it with different tools. I don't want to have to commit to one tool, 
and then pray that the tool remains in existance. I was really pissed off when 
Microsoft killed Visual Basic 6, and I was stuck with a huge mound of now 
worthless code. I have to rewrite *all* of it. I never want to go through that 
again, which is why I am considering Python.

Thanks,
Matt



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Komodo - Will it Lock Me In?

[Peter Decker]

On 2/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> My goal was to test out Python by writing a simple GUI app and then deploying
> it to Mac OS X and Windows XP. Using a product such as RealBasic, a totally
> green newbie could accomplish this in a few minutes.. So, I guess my main
> question is, is there such a RAD tool for Python?

You should take a look at Dabo, especially the Visual Designer. You
can create GUI applications visually in a matter of minutes without
having to write any code at all. If you want the app to do interesting
things, you can add as much code as you need to accomplish this. No
need to become a Python expert. http://dabodev.com

--

# p.d.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Komodo - Will it Lock Me In?

[Matt]

"Ravi Teja" <[EMAIL PROTECTED]> wrote:

>Matt, in most cases, installing packages in Python is about as easy as
>it gets. 

Yes, it is easy, sort-of. I have installed many, many packages so far. My 
point is that with a polished IDE, you don't have to go through all of this. 
You download an installer, run it, start up the IDE and start writing code. 
There are many such RAD tools. I would like such a thing for Python. I've 
spent several days installing package after package, everything from Eclipse 
to py2app, and I still don't have a good development environment. It seems 
that one must be a Python expert before he can write his first simple 
hello-world app.

My goal was to test out Python by writing a simple GUI app and then deploying 
it to Mac OS X and Windows XP. Using a product such as RealBasic, a totally 
green newbie could accomplish this in a few minutes.. So, I guess my main 
question is, is there such a RAD tool for Python?

Thanks,
Matt



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Fredrik Lundh]

Alexander Schmolck wrote:

> My point was that Guido probably (and fortunately!) was unaware of the extent
> to which you can have both dynamism and speed

any my point was that chosing to ignore something doesn't mean
that you're ignorant.

(but since you keep repeating this nonsense, it's clear that you're
pretty ignorant wrt. software design.  too much CS exposure?).





-- 
http://mail.python.org/mailman/listinfo/python-list

New Module: CommandLoop

[Crutcher]

This is something I've been working on for a bit, and I think it is
more or less ready to bring up on this list. I'd like to add a module
(though probably not for 2.5).

Before you ask, this module is _not_ compatible with cmd.py, as it is
command oriented, whereas cmd.py is line oriented.

Anyway, I'm looking for feedback, feature requests before starting the
submission process.

Code available here:
http://littlelanguages.com/web/software/python/modules/cmdloop.py

Base class for writing simple interactive command loop environments.

CommandLoop provides a base class for writing simple interactive user
environments.  It is designed around sub-classing, has a simple command
parser, and is trivial to initialize.

Here is a trivial little environment written using CommandLoop:

   import cmdloop

   class Hello(cmdloop.CommandLoop):
   PS1='hello>'

   @cmdloop.aliases('hello', 'hi', 'hola')
   @cmdloop.shorthelp('say hello')
   @cmdloop.usage('hello TARGET')
   def helloCmd(self, flags, args):
   '''
   Say hello to TARGET, which defaults to 'world'
   '''
   if flags or len(args) != 1:
   raise cmdloop.InvalidArguments
   print 'Hello %s!' % args[0]

   @cmdloop.aliases('quit')
   def quitCmd(self, flags, args):
   '''
   Quit the environment.
   '''
   raise cmdloop.HaltLoop

   Hello().runLoop()

Here's a more complex example:

   import cmdloop

   class HelloGoodbye(cmdloop.CommandLoop):
   PS1='hello>'

   def __init__(self, default_target = 'world'):
   self.default_target = default_target
   self.target_list = []

   @cmdloop.aliases('hello', 'hi', 'hola')
   @cmdloop.shorthelp('say hello')
   @cmdloop.usage('hello [TARGET]')
   def helloCmd(self, flags, args):
   '''
   Say hello to TARGET, which defaults to 'world'
   '''
   if flags or len(args) > 1:
   raise cmdloop.InvalidArguments
   if args:
   target = args[0]
   else:
   target = self.default_target
   if target not in self.target_list:
   self.target_list.append(target)
   print 'Hello %s!' % target

   @cmdloop.aliases('goodbye')
   @cmdloop.shorthelp('say goodbye')
   @cmdloop.usage('goodbye TARGET')
   def goodbyeCmd(self, flags, args):
   '''
   Say goodbye to TARGET.
   '''
   if flags or len(args) != 1:
   raise cmdloop.InvalidArguments
   target = args[0]
   if target in self.target_list:
   print 'Goodbye %s!' % target
   self.target_list.remove(target)
   else:
   print "I haven't said hello to %s." % target

   @cmdloop.aliases('quit')
   def quitCmd(self, flags, args):
   '''
   Quit the environment.
   '''
   raise cmdloop.HaltLoop

   def _onLoopExit(self):
   if len(self.target_list):
   self.pushCommands(('quit',))
   for target in self.target_list:
   self.pushCommands(('goodbye', target))
   else:
   raise cmdloop.HaltLoop

   HelloGoodbye().runLoop()

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MySQLDB - parameterised SQL - "TypeError: not all arguments converted during string formatting"

[shearichard]

Hi Dennis - Thanks for your help with this 

Dennis Lee Bieber wrote:
> On 19 Feb 2006 16:26:15 -0800, [EMAIL PROTECTED] declaimed the
> following in comp.lang.python:
>
> > Hi - I have written some python to insert a row into a table using
> > MySQLDB. I have never before written SQL/Python using embedded
> > parameters in the SQL and I'm having some difficulties. Could someone
> > point me in the right direction please ?
> > sqlQuery = "INSERT INTO EVA_COMPANY
> > (COM_ADDRESS,COM_AUTOID,COM_COMPANY_ADDRESS,COM_STRUCT_OWNER_CODE)
> > VALUES (?,?,?,?) "
>
>   One: I believe MySQLdb uses %s placeholders, not ?
>
> >>> import MySQLdb
> >>> MySQLdb.paramstyle
> 'format'
>
> From the DB-API PEP
>
>  paramstyle
>
> String constant stating the type of parameter marker
> formatting expected by the interface. Possible values are
> [2]:
>
> 'qmark' Question mark style,
> e.g. '...WHERE name=?'
> 'numeric'   Numeric, positional style,
> e.g. '...WHERE name=:1'
> 'named' Named style,
> e.g. '...WHERE name=:name'
> 'format'ANSI C printf format codes,
> e.g. '...WHERE name=%s'
> 'pyformat'  Python extended format codes,
> e.g. '...WHERE name=%(name)s'
>
>

Great stuff. I had seen some example code which used question marks and
rather too slavishly used it as a model. As you say MySQLDb does indeed
use 'format' and so %s are the way to go ...

>
> > print sqlQuery
> > sql = cursor.execute(sqlQuery,("test","NULL","Tester1017",5))
>
>   Two: I think it is smart enough to translate a Python None to a
> MySQL NULL -- which is different from a four-character string containing
> NULL (or even a zero-character string "").

... just to confirm that yes using a Python None works fine if you wish
to put a Null into a column ...
>
> >
> > CREATE TABLE `eva_company` (
> >   `COM_AUTOID` int(9) unsigned NOT NULL auto_increment,
>
>   As an auto-increment field, the recommendation would be to not even
> mention the field in the INSERT SQL -- that also takes care of the
> problem of specifying NULL to a non-null field!
>

... yes it didn't start off that way but I was busy trying everthing I
could think of to try to make it happier.

thanks for your help it's all working now.

regards

richard.




> --
>  > == <
>  >   [EMAIL PROTECTED]  | Wulfraed  Dennis Lee Bieber  KD6MOG <
>  >  [EMAIL PROTECTED] |   Bestiaria Support Staff   <
>  > == <
>  >   Home Page: <
>  >Overflow Page: <

-- 
http://mail.python.org/mailman/listinfo/python-list

Eric3 Help/Tutorial

[Julius Lucks]

Does anyone know of Help docs/tutorials that explain Eric3's plethora
of features?

http://www.die-offenbachs.de/detlev/eric3.html

Thanks,

Julius

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[funktion]

gedit

-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Which is faster? (if not b in m) or (if m.count(b) > 0)

[Delaney, Timothy (Tim)]

Jean-Paul Calderone wrote:

> Not since Python 2.4:
> 
> >>> dis.dis(lambda: x not in y)
>   1   0 LOAD_GLOBAL  0 (x)
>   3 LOAD_GLOBAL  1 (y)
>   6 COMPARE_OP   7 (not in)
>   9 RETURN_VALUE
> >>> dis.dis(lambda: not (x in y))
>   1   0 LOAD_GLOBAL  0 (x)
>   3 LOAD_GLOBAL  1 (y)
>   6 COMPARE_OP   7 (not in)
>   9 RETURN_VALUE
> >>>

Damn - I missed that change. Peephole optimiser I guess.

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: commenting out blocks of code

[Neil Hodgson]

Atanas Banov:

> here is something you both seems to have not considered: imagine you
> make decision if ^Q has to comment or uncomment based on the 1st line
> and not on each line individually in the block. 

   When first implementing Ctrl+Q, this looked to have similar
advantages and disadvantages to the chosen implementation. However, it
wouldn't allow a technique I've come to use which is to have two
versions of some code or section of a configuration file and to toggle
between the two by selecting the whole range and pressing Ctrl+Q.

> #code1
> ##comment1
> ##comment2
> #code2
> 
> 
> note how ## maintains where comments were. now, for the same selection,
> ^Q again? 1st character is #, so the editor is asked to uncomment,
> dwim:

   The problem with "##" as opposed to "#~" is that "##" is common in
much source code particularly in barrier comments and comment sections:

 Persistence section 
## These functions are responsible for load
## and save for the core media database.

   Neil
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Which is faster? (if not b in m) or (if m.count(b) > 0)

[Jean-Paul Calderone]

On Mon, 20 Feb 2006 10:08:48 +1100, "Delaney, Timothy \(Tim\)" <[EMAIL 
PROTECTED]> wrote:
>Farel wrote:
>
>> Tim, Are you saying that:
>>  not (b in m)
>> is faster than:
>> b not in m
>
>On the contrary. `not (b in m)` requires negating the result of `b in m`
>(via an additional bytecode operation). `b not in m` doesn't. However,
>the difference in performance is minimal, as testing using the timeit
>module will show you.

Not since Python 2.4:

>>> dis.dis(lambda: x not in y)
  1   0 LOAD_GLOBAL  0 (x)
  3 LOAD_GLOBAL  1 (y)
  6 COMPARE_OP   7 (not in)
  9 RETURN_VALUE
>>> dis.dis(lambda: not (x in y))
  1   0 LOAD_GLOBAL  0 (x)
  3 LOAD_GLOBAL  1 (y)
  6 COMPARE_OP   7 (not in)
  9 RETURN_VALUE
>>> 

>
>The important difference is the improvement in clarity. There is no
>possibility for misinterpretation as to the meaning of `b not in m`,
>whereas with the original `not b in m` I had to actually go check the
>precedence rules to be sure what would happen. Adding the parentheses
>makes it clear, but doesn't read as well as using the `not in` operator.
>
>As others have said, if you really care about the performance of
>something, the timeit module is your friend. Discussions about *why* you
>get certain performance results are then useful.

But this stuff is all still true :)

Jean-Paul
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Req. for module style/organization

[Ziga Seilnacht]

RayS wrote:
> I've begun a Python module to provide a complete interface to the
> Meade LX200 command set, and have searched for a style/development
> guide for Python Lib/site-packages type modules, but only saw guides
> for C-modules.  I realize that I need to make some changes to follow
> http://www.python.org/doc/essays/styleguide.html
> better. Does anyone have an appropriate URL for me to follow for this
> task? Is one of the C-module guides appropriate?
>

There are two informal Python Enhancements Proposals:
Style Guide for C Code - http://www.python.org/peps/pep-0007.html
Style Guide for Python Code - http://www.python.org/peps/pep-0008.html

>
> I have:
> LX200/
>  __init__.py
>  LXSerial.py
>  Telescope.py
>  Focuser.py
>  LXUtils.py
>  ... etc
> Each file has one class defined.

This style is not encuraged any more because of the ambiguity with
imports; see
http://mail.python.org/pipermail/web-sig/2006-February/002093.html
for details.

> All advice is appreciated,
> Ray

Ziga

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: SPE IDE videos and more...

[Claudio Grondi]

[EMAIL PROTECTED] wrote:
> I'm happy to spread the word about showmedo.com, an excellent
> collection of python programming videos.
> 
>>From the website
> http://showmedo.com/videoListPage?listKey=TheBigPythonList:

The server response under:

   http://showmedo.com/videoListPage?listKey=TheBigPythonList:

was:
"""
500 Internal error
Server got itself in trouble

Powered by Cherrypy 2.1.0
"""

If there is not enough trouble around to suffer from, why not get itself 
in trouble? ;-)

As the computer becomes more and more human like, even able to get 
itself in trouble, the fact that it has the courage to admit the true 
reason for the trouble emerges it as a stupid machine.

:-))

By the way: it was _me_ who caused the server to be in trouble feeding 
it with a bad URL instead of the right one:

   http://showmedo.com/videoListPage?listKey=TheBigPythonList

Sometimes it is good, that there is no human on the other end of the 
line knowing about all this dirty words which can be thrown back as 
excuse for own malfunction ...

Claudio
-- 
http://mail.python.org/mailman/listinfo/python-list

MySQLDB - parameterised SQL - "TypeError: not all arguments converted during string formatting"

[shearichard]

Hi - I have written some python to insert a row into a table using
MySQLDB. I have never before written SQL/Python using embedded
parameters in the SQL and I'm having some difficulties. Could someone
point me in the right direction please ?

The python looks like this :

import MySQLdb
import MySQLdb.cursors
conn = MySQLdb.Connect(host='localhost', user='abc,passwd='def',
db='ghi',compress=1)

cursor = conn.cursor(cursorclass=MySQLdb.cursors.DictCursor)
sqlQuery = "INSERT INTO EVA_COMPANY
(COM_ADDRESS,COM_AUTOID,COM_COMPANY_ADDRESS,COM_STRUCT_OWNER_CODE)
VALUES (?,?,?,?) "
print sqlQuery
sql = cursor.execute(sqlQuery,("test","NULL","Tester1017",5))
cursor.close()
conn.commit()

... and the table looks like this ...

CREATE TABLE `eva_company` (
  `COM_AUTOID` int(9) unsigned NOT NULL auto_increment,
  `COM_COMPANY_NAME` varchar(128) NOT NULL,
  `COM_TRADING_NAME` varchar(128) default NULL,
  `COM_ADDRESS` varchar(256) NOT NULL,
  `COM_POSTAL_ADDRESS` varchar(256) default NULL,
  `COM_CONTACT_NAME` varchar(56) default NULL,
  `COM_CONTACT_POSITION` varchar(56) default NULL,
  `COM_CONTACT_TELEPHONE` varchar(16) default NULL,
  `COM_CONTACT_FAX` varchar(16) default NULL,
  `COM_CONTACT_EMAIL` varchar(256) default NULL,
  `COM_STRUCT_OWNER_CODE` int(9) unsigned default NULL,
  `COM_INDUSTRY_CODE` varchar(16) default NULL,
  `COM_INDUSTRY_DESC` varchar(56) default NULL,
  `COM_NUMBER_OF_SITES` int(9) default NULL,
  `COM_NATURE_OF_RELATIONSHIP` varchar(128) default NULL,
  PRIMARY KEY  (`COM_AUTOID`),
  KEY `IDX_COM1` (`COM_STRUCT_OWNER_CODE`),
  KEY `IDX_COM0` (`COM_COMPANY_NAME`),
  CONSTRAINT `FK_COS_COM0` FOREIGN KEY (`COM_STRUCT_OWNER_CODE`)
REFERENCES `eva_code_comp_struct_ownership` (`COS_AUTOID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;

... but when I try to execute the python I get an error ...

Traceback (most recent call last):
  File "sheadbtest1.py", line 8, in ?
sql = cursor.execute(sqlQuery,("test","NULL","Tester1017",5))
  File
"C:\bin\installed\Python2.4.1\Lib\site-packages\MySQLdb\cursors.py",
line 132, in execute
self.errorhandler(self, TypeError, m)
  File
"C:\bin\installed\Python2.4.1\Lib\site-packages\MySQLdb\connections.py",
line 33, in defaulterrorhandler
raise errorclass, errorvalue
TypeError: not all arguments converted during string formatting

... as I say if anyone could provide me with some tips I'd appreciate
it.

thanks

richard shea.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: number ranges (was Re: Matlab page on scipy wiki)

[Tim Hochberg]

Colin J. Williams wrote:

>>
>>It would be good if the range and slice could be merged in some way,
>>although the extended slice is rather complicated - I don't understand it.
>>
>>   The semantics for an extended slicing are as follows. The primary
>>   must evaluate to a mapping object, and it is indexed with a key that
>>   is constructed from the slice list, as follows. If the slice list
>>   contains at least one comma, the key is a tuple containing the
>>   conversion of the slice items; otherwise, the conversion of the lone
>>   slice item is the key. The conversion of a slice item that is an
>>   expression is that expression. The conversion of an ellipsis slice
>>   item is the built-in |Ellipsis| object. The conversion of a proper
>>   slice is a slice object (see section section 4.2 The standard type
>>   hierarchy )
>>   whose |start|, |stop| and |step| attributes are the values of the
>>   expressions given as lower bound, upper bound and stride,
>>   respectively, substituting |None| for missing expressions.
>>
>>[source: http://www.network-theory.co.uk/docs/pylang/ref_60.html]
>>
>>The seems to be a bit of a problem with slicing that needs sorting out.
>>
>>The syntax for a slice list appears to allow multiple slices in a list:
>>
>>   extended_slicing ::= primary  "["
>>   slice_list  "]"
>>   slice_list ::= slice_item  (","
>>   slice_item )* [","]
>>
>>but the current interpreter reports an error:
>>
>>>>> a= range(20)
>>>>> a[slice(3, 9, 2)]
>>   [3, 5, 7]
>>>>> a[slice(3, 9, 2), slice(5, 10)]
>>   Traceback (most recent call last):
>> File "", line 1, in ?
>>   TypeError: list indices must be integers
>>>>>
>>

Extended slicing has nothing to do with lists. All that gobbeldy gook is 
trying to tell you is what the interpreter does with O[1:2:3, 4:5:6] 
where O is some arbitrary object. What it does is:

O[1:2:3, 4:5:6] == O[slice(1,2,3), slice(4,5,6)]
 == O.__getitem__((slice(1,2,3), slice(4,5,6)))

In the case of python lists, __getitem__ doesn't support multiple slice 
arguments. However, you are free to define your own types which do 
support multiple slices.

This type of slicing was added to support Numeric originally and as far 
as I know is still only really used in Numeric and its successors 
Numarray and Numpy. Since this was originally posted to the numpy list I 
assume you are familiar with multidimensional indexing of arrays -- that 
is extended slicing in action.

If you really want to learn about it, and for most people it's 
unnecessary although perhaps entertaining, play with the following class:


class ExtendedSlicingDemo(object):
 def __getitem__(self, key):
 return key

esd = ExtendedSlicingDemo()

print esd[1:2:3]
print esd[1:2:3, 3:4:5]
print esd[1:2:3, ..., 3:4:5]
#

=>

slice(1, 2, 3)
(slice(1, 2, 3), slice(3, 4, 5))
(slice(1, 2, 3), Ellipsis, slice(3, 4, 5))

-tim

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alex Martelli]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
   ...
> Ho, really ? How many applications using Python as scripting language ?

http://wiki.python.org/moin/AppsWithPythonScripting lists many, but it's
obviously woefully incomplete -- e.g., it's missing Civilization IV, a
very popular, major new game whose use of Python has been in the news a
lot.  Besides, with ActiveScripting on Windows and Apple Events on the
Mac, all normal applications on both widespread platforms are "using
Python as scripting language", at least potentially -- that makes it
essentially a desperate task to try to count them all...:-(


Alex


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alex Martelli]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:

> DH a écrit :
> (snip)
> > 
> > It is by design. Python is dynamically typed.  It is essentially an
> > interpreted scripting language like javascript or ruby or perl,
> 
> It's not a "scripting" language, and it's not interpreted.

OK, but then we should change ,
which starts with "Python is an interpreted, interactive,
object-oriented programming language." -- if "it's not interpreted",
then why is this crucial page on Python's main site lying outright?


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Boddie]

Steven D'Aprano wrote:
> On Sun, 19 Feb 2006 13:02:16 -0800, Paul Boddie wrote:
>
> >> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> >> >
> >> > Ok, then what do you think happens to 'machine' code ?
> >> >
> >> > "interpreted" usually means "no compilation, all parsing etc
> >> > redone at each execution", which is not the case with a
> >> > bytecode/vm based implementation.
> >
> > Such criteria sound more like those which would distinguish interactive
> > languages from others.
>
> How can that be? Python is interactive, and yet it has a bytecode/vm
> implementation.

The criteria were "no compilation, all parsing etc redone at each
execution": things which would possibly describe features of a language
where much use is made of an interactive mode, and where there wouldn't
be many advantages in generating instructions in another form for later
execution. Not that this applies to Python, since it does compile
source code to bytecode instructions as we all know, and the only
re-parsing occurs in well-defined circumstances, but there have been
other "dare I say scripting?" languages whose execution models have
apparently involved ASTs instead of virtual machine instruction sets.

[...]

> > And it's even better to think about the nature of the machine...
>
> Is it? Why? Do you particularly know what happens when your machine code
> hits the CPU?

In general, yes: it's interpreted by a virtual machine implementation
in hardware. But this is where the nature of the machine is important,
as I originally wrote, since you don't want highly complicated
instructions implemented in hardware for a variety of well-understood
reasons.

[...]

> Let's be frank: "interpreted language" has negative connotations which may
> have been valid in the 1960s and perhaps even the 1970s, but are no longer
> automatically valid. Nevertheless, those connotations stick around,
> generally amongst the less knowledgeable. That hurts Python's commercial
> success, and Python's commercial success is vital for anyone who wishes to
> get paid to program in Python.

I think we're mostly in agreement here. My point was, as usual,
tangential: there is a certain class of instructions conveniently or
economically implementable in hardware; CPython's runtime also has
instructions more complicated than those. Consequently, when people
used to speculate about Python CPUs and other magical devices that
would make Python run much faster (see [1] for more recent material
which doesn't specifically do so, although I believe the speaker made
references to such devices; see [2] for an old mailing list thread),
one has to accept that there are certain constraints that have a severe
effect on whether such devices are viable or not. If some people want
to classify runtime environments on this basis then I don't have a
problem with that, provided that they are honest about it and put
things like the Java VM in the same category as CPython.

Paul

[1]
http://www.python-in-business.org/ep2005/talk.chtml?talk=2116&track=692
[2]
http://mail.python.org/pipermail/python-list/1999-June/thread.html#4543

-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Which is faster? (if not b in m) or (if m.count(b) > 0)

[Delaney, Timothy (Tim)]

Farel wrote:

> Tim, Are you saying that:
>  not (b in m)
> is faster than:
> b not in m

On the contrary. `not (b in m)` requires negating the result of `b in m`
(via an additional bytecode operation). `b not in m` doesn't. However,
the difference in performance is minimal, as testing using the timeit
module will show you.

The important difference is the improvement in clarity. There is no
possibility for misinterpretation as to the meaning of `b not in m`,
whereas with the original `not b in m` I had to actually go check the
precedence rules to be sure what would happen. Adding the parentheses
makes it clear, but doesn't read as well as using the `not in` operator.

As others have said, if you really care about the performance of
something, the timeit module is your friend. Discussions about *why* you
get certain performance results are then useful.

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Terry Reedy]

>> Of course it is. What do you think happens to the bytecode?

> Ok, then what do you think happens to 'machine' code ?

I believe that on modern CISC processors the human level 'machine code' is 
interpreted by subroutines written in the actual machine code usually 
called 'microcode'.

tjr





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Fredrik Lundh" <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> 
> > You might want to argue about whether scriping language is a meaningful and
> > useful concept, but it's really hard to see how you could talk about 
> > "scripting
> > languages" without including python.
> 
> define "scripting language".

Pretty much any definition that isn't practically useless would do. I'd
personally opt for something like:

 A language that doesn't make all common simple tasks difficult and painful.

If that sounds too wishy-washy, note that I specifically question whether
scripting language is a useful and meaningful concept to start with -- I just
find it silly to take issue with calling python a scripting language but not
with the term scripting language itself (especially given that even the python
tutorial talks about python scripts and that almost anyone who uses the term
would include python).
 
> the only even remotely formal definition I've ever seen is "language with
> designed to script an existing application, with limited support for handling
> its own state". 

> Early Tcl and JavaScript are scripting languages, Python is not.

Right. Which shows that by this definition scripting language is not a
meaningful and useful concept. No one will understand you correctly when you
refer to "scripting language" and mean only something like the above -- and
unless you spend a lot of your time talking about early tcl and early
javascript I doubt you'd need a word for it, either.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Valentino Volonghi aka Dialtone]

Steven D'Aprano <[EMAIL PROTECTED]> wrote:

> By that logic, all languages are interpreted. What do you think happens to
> the machinecode?

Interpreted to transistors state by an internal mapping in the CPU
opcode ==> input configuration.

-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: http://vvolonghi.blogspot.com
New Pet: http://www.stiq.it
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Countdown Timer

[KennethGorelick]

Thank you!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Steven D'Aprano]

On Sun, 19 Feb 2006 13:02:16 -0800, Paul Boddie wrote:

> Torsten Bronger wrote:
>> Hallöchen!
>>
>> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>> >
>> > Ok, then what do you think happens to 'machine' code ?
>> >
>> > "interpreted" usually means "no compilation, all parsing etc
>> > redone at each execution", which is not the case with a
>> > bytecode/vm based implementation.
> 
> Such criteria sound more like those which would distinguish interactive
> languages from others.

How can that be? Python is interactive, and yet it has a bytecode/vm
implementation.

And I'm just waiting for somebody to mention Forth, which completely
breaks down the barriers between compilation and interpretation. In a
world of virtual machines, bytecode compilers, CPUs which emulate other
CPUs using embedded software, and Forth, I would have thought that it was
as obvious as the Sun in the sky that compiled versus interpreted is a
false dichotomy.



>> That sounds like an implementation feature rather than a language
>> feature.  Besides, it's not a very sensible distinction in my opinion.
>> Much better is to think about the structure of the interpreting
>> machine.
> 
> And it's even better to think about the nature of the machine...

Is it? Why? Do you particularly know what happens when your machine code
hits the CPU?


>> I'm not a CS person (only a physicist) but if you *need* a bytecode
>> interpreter on top of the CPU interpretation, it's an interpreted
>> language to me.
> 
> Yet one could potentially have that bytecode interpreter in hardware.

Not potentially, in actuality. I know of only one example, and it
wasn't commercially success, but in 1993 IBM developed a version of
the PowerPC RISC chip that had support for the Intel x86 instruction set.

What has been done once can be done again.

[snip]

> I'm not sure why people get all defensive about Python's
> interpreted/scripting designation or about the details of the CPython
> implementation, especially considering that the virtual machine
> technology in use has been around for a decade and a half, and that
> various projects have been experimenting with alternatives.

I can't speak for others, but for me it is because generally the people
who are the quickest to insist that Python is interpreted appear to mean
it as a put-down. I never hear "Python has the rapid development and
flexibility that only an interpreted language can give", it is always "Of
course Python is slow, it is interpreted, what do you expect?".

Even if they themselves are perfectly aware of the subtle shades of
modern language design, and that interpretation does not mean that every
line of code is parsed repeatedly as it is run, it seems to me that very
often they don't mind one bit if others, less informed than them, come
away with that impression.

Let's be frank: "interpreted language" has negative connotations which may
have been valid in the 1960s and perhaps even the 1970s, but are no longer
automatically valid. Nevertheless, those connotations stick around,
generally amongst the less knowledgeable. That hurts Python's commercial
success, and Python's commercial success is vital for anyone who wishes to
get paid to program in Python. 


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[Old Duck]

Mladen Adamovic wrote:

> Hi!
> 
> I wonder which editor or IDE you can recommend me for writing Python
> programs. I tried with jEdit but it isn't perfect.


My personal favorite is Kate (comes with KDE).

- Duck
-- 
http://mail.python.org/mailman/listinfo/python-list

Format file size for printing

[abcd]

is there a built-in way of printing the size of a file nicely?

So if the file size is 103803 bytes it prints out like: 103.8K
or
0.1MB 

something liek that?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Making mouse wheel work with pmw ScrolledCanvas widget

[dan . gass]

This looks like it has nothing to do with Pmw (Mega widgets) but is
really a basic Tkinter problem.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Fredrik Lundh" <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> 
> > What's far more interesting to me, however, is that I think there a good
> > reasons to suspect python's slowness is more of a feature than a flaw: I'd 
> > not
> > be suprised if on the whole it greatly increases programmer productivity and
> > results in clearer and more uniform code.
> 
> > So ironically, some share of python's success might actually be due to
> > ignorance on Guido's part
> 
> it didn't, for even a millisecond, strike you that maybe, just maybe, the
> "make it as dynamic as we possibly can" choice was made on purpose ?

Python is far less dynamic than smalltalk, and presumably also self (last time
I checked there was no implementation for x86, so I have no practical
experience with self). Even common lisp could reasonably be called more
dynamic than python. And all these language communities did in fact still
manage to come up with efficient implementations.

Thus the "make it as dynamic as it possibly can" choice is hardly the cause
for python's slowness, so what's your point?

My point was that Guido probably (and fortunately!) was unaware of the extent
to which you can have both dynamism and speed and the extent to which very
dynamic languages are suitable for writing robust software. I'm pretty sure I
remember reading stuff by Guido himself in which he indicated that he
originally thought that a language with a similar level of dynamism as python
had to be slow anyway and I'm also pretty sure that I read some other stuff by
him which indicates that he thought a language like python would be only
suitable for relatively small scale development. If you don't doubt he wrote
that I'm not sure what we're disagreeing about (because clearly both
statements are wrong), if you do maybe I or someone else can find the right
reference, or maybe I really misremembered.

Anyayw, I'm pretty sure that Guido wouldn't have bothered to add things like
compiler macros to python, whatever his level of his technical expertise
concerning efficient implementations of highly dynamic languages might have
been.

However I don't find it at all implausible to assume that had Guido known all
the stuff that say, David Ungar and Guy Steele were aware of at the same time,
python would have come out not necessarily less dynamic but considerably
faster -- to its own detriment.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[Sybren Stuvel]

Mladen Adamovic enlightened us with:
> I wonder which editor or IDE you can recommend me for writing Python 
> programs. I tried with jEdit but it isn't perfect.

I use gvim (if I have X) and vim (if I don't). The only negative thing
about it, is its learning curve ;-)

Sybren
-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself? 
 Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Steven D'Aprano]

On Sun, 19 Feb 2006 19:26:20 +, Alexander Schmolck wrote:

> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> 
>> DH a écrit :
>> (snip)
>> > It is by design. Python is dynamically typed. It is essentially an
>> > interpreted scripting language like javascript or ruby or perl,
>> 
>> 
>> It's not a "scripting" language, and it's not interpreted.
> 
> Of course it is. What do you think happens to the bytecode? 

By that logic, all languages are interpreted. What do you think happens to
the machinecode?


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[Benji York]

Rene Pijlman wrote:
> Sriram Krishnan:
> 
>>Check out http://wiki.python.org/moin/PythonEditors.
> 
> 
> This page can't be taken seriously. vi is not listed.

I hope your  key is broken; I wouldn't wish old-school vi on my 
worst enemy.  Fortunately that page lists the wonderful Vim instead, so 
seriousness has been maintained.

To the OP: a serious editor is a basic necessity of coding, so pick 
Emacs, Vim, or something equivalent.  Just make sure it's customizable 
and you enjoy customizing it because you'll want to.
--
Benji York
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How many web framework for python ?

[Sybren Stuvel]

Ville Vainio enlightened us with:
> When you write your own framework, you are helping yourself.

True. And if that doesn't have a negative effect on others (which I
think it doesn't) there is nothing wrong with that.

> If you use an existing framework and possibly contribute patches to
> it, you help other people too.

Also true, but there is more to it. If I can create my own framework,
get more experienced, and be able to spare time in the long run
because I can quickly implement features I want, it makes me a more
efficient and experienced person. That leaves me more useful when
helping people, and gives me more time to help them too.

> - Other people have already solved your problems

I have no problems. My web framework is working just as I want it to.

> also problems that you can't think of yet.

What problems didn't I think of yet?

> - Not reusing code is just plain evil.

I'm using mod_python, Cheetah, SQLObject and PostgreSQL. I publish all
my own code under an Open Source license so other people can learn
from and contribute to it. How am I not reusing code?

Sybren
-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself? 
 Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: number ranges (was Re: Matlab page on scipy wiki)

[Colin J. Williams]

Colin J. Williams wrote:
> Bryan Cole wrote:
> 
>>>   
>>> First, I think the range() function in python is ugly to begin with.
>>> Why can't python just support range notation directly like 'for a in
>>> 0:10'.  Or with 0..10 or 0...10 syntax.  That seems to make a lot more
>>> sense to me than having to call a named function.   Anyway, that's a
>>> python pet peeve, and python's probably not going to change something
>>> so fundamental...   
>>
>>
>> There was a python PEP on this. It got rejected as having too many
>> 'issues'. Pity, in my view.
>>
>> see http://www.python.org/peps/pep-0204.html
>>
>> BC
>>  
>>
> This decision appears to have been made nearly six years ago.  It would
> be a good idea to revisit the decision, particularly since the reasons
> for rejection are not clearly spelled out.
> 
> The conditional expression (PEP 308) was rejected but is currently being
> implemented in Python version 2.5.  It will have the syntax A if C else B.
> 
> I have felt, as Gary Ruben says above, that the range structure is ugly.
> 
> Two alternatives have been suggested:
> a) a:b:c
> b) a..b..c
> 
> Do either of these create parsing problems?
> for i in a:b:
> Should this be treated as an error, with a missing c (the increment)
>  print i
> 
> for i in 2..5:
>  print i   We
> don't know whether the 2 is an integer until the second period is scanned.
> 
> It would be good if the range and slice could be merged in some way,
> although the extended slice is rather complicated - I don't understand it.
> 
>The semantics for an extended slicing are as follows. The primary
>must evaluate to a mapping object, and it is indexed with a key that
>is constructed from the slice list, as follows. If the slice list
>contains at least one comma, the key is a tuple containing the
>conversion of the slice items; otherwise, the conversion of the lone
>slice item is the key. The conversion of a slice item that is an
>expression is that expression. The conversion of an ellipsis slice
>item is the built-in |Ellipsis| object. The conversion of a proper
>slice is a slice object (see section section 4.2 The standard type
>hierarchy )
>whose |start|, |stop| and |step| attributes are the values of the
>expressions given as lower bound, upper bound and stride,
>respectively, substituting |None| for missing expressions.
> 
> [source: http://www.network-theory.co.uk/docs/pylang/ref_60.html]
> 
> The seems to be a bit of a problem with slicing that needs sorting out.
> 
> The syntax for a slice list appears to allow multiple slices in a list:
> 
>extended_slicing ::= primary  "["
>slice_list  "]"
>slice_list ::= slice_item  (","
>slice_item )* [","]
> 
> but the current interpreter reports an error:
> 
> >>> a= range(20)
> >>> a[slice(3, 9, 2)]
>[3, 5, 7]
> >>> a[slice(3, 9, 2), slice(5, 10)]
>Traceback (most recent call last):
>  File "", line 1, in ?
>TypeError: list indices must be integers
> >>>
> 
> I have taken the liberty of cross posting this to c.l.p.
> 
> Colin W.
This was originally posted to the numpy discussion list.

Colin W.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[Colin J. Williams]

Rene Pijlman wrote:
> Mladen Adamovic:
> 
>>I wonder which editor or IDE you can recommend me for writing Python 
>>programs.
> 
> 
> vi
> 
Scite is a good editor.  It is available for both Windows and Linux.
Boa-Constructor is an IDE rather than an editor.  Although it focuses
on wxPython, it has a good editor.

Colin W
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[Rene Pijlman]

Sriram Krishnan:
>Check out http://wiki.python.org/moin/PythonEditors.

This page can't be taken seriously. vi is not listed.

-- 
René Pijlman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Boddie]

Torsten Bronger wrote:
> Hallöchen!
>
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> >
> > Ok, then what do you think happens to 'machine' code ?
> >
> > "interpreted" usually means "no compilation, all parsing etc
> > redone at each execution", which is not the case with a
> > bytecode/vm based implementation.

Such criteria sound more like those which would distinguish interactive
languages from others.

> That sounds like an implementation feature rather than a language
> feature.  Besides, it's not a very sensible distinction in my
> opinion.  Much better is to think about the structure of the
> interpreting machine.

And it's even better to think about the nature of the machine...

> I'm not a CS person (only a physicist) but if
> you *need* a bytecode interpreter on top of the CPU interpretation,
> it's an interpreted language to me.

Yet one could potentially have that bytecode interpreter in hardware.
What typically prevents this is the potential difficulty of realising
complicated software designs in reasonably priced hardware, thus
introducing the nature of the machine: how complicated the instructions
are, what additional support would be required for implementing those
instructions, and so on. Low-level or systems programming languages are
compilable to instructions which are convenient to implement in
hardware and require little additional support: concepts such as stacks
(for various purposes) are supported by machine instructions and
registers, for example, whereas more advanced memory management is left
to software running on top of the virtual machine (although I imagine
that various Lisp machines did some interesting things in this domain).

> I've had such a discussion about TeX already, and my personal
> conclusion was that you can defend almost any opinion in that area.
> However, one should ensure that the definitions make a pragmatic and
> useful distinction.

Agreed. The CPython virtual machine consists of "complicated"
instructions: that is, some of those instructions may involve
non-trivial amounts of work and may be integrated with other subsystems
that can realistically only be implemented in software. Even virtual
machines like that of the Java platform have moderately high-level
instructions, resulting in various "Java optimised" hardware
implementations not attempting to provide a complete coverage of all
the available instructions (as far as I am aware).

I'm not sure why people get all defensive about Python's
interpreted/scripting designation or about the details of the CPython
implementation, especially considering that the virtual machine
technology in use has been around for a decade and a half, and that
various projects have been experimenting with alternatives.

Paul

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[Rene Pijlman]

F. Petitjean:
>Rene Pijlman:
>> vi
>
>I beg to disagree :-) Use ed
>"Ed is the standard text editor."
>http://www.gnu.org/fun/jokes/ed.msg.html

That was 1991. This is 2006.

-- 
René Pijlman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: number ranges (was Re: Matlab page on scipy wiki)

[Colin J. Williams]

Bryan Cole wrote:

>>
>>
>>First, I think the range() function in python is ugly to begin with.
>>Why can't python just support range notation directly like 'for a in
>>0:10'.  Or with 0..10 or 0...10 syntax.  That seems to make a lot more
>>sense to me than having to call a named function.   Anyway, that's a
>>python pet peeve, and python's probably not going to change something
>>so fundamental... 
>>
>>
>
>There was a python PEP on this. It got rejected as having too many
>'issues'. Pity, in my view.
>
>see http://www.python.org/peps/pep-0204.html
>
>BC
>  
>
This decision appears to have been made nearly six years ago.  It would
be a good idea to revisit the decision, particularly since the reasons
for rejection are not clearly spelled out.

The conditional expression (PEP 308) was rejected but is currently being
implemented in Python version 2.5.  It will have the syntax A if C else B.

I have felt, as Gary Ruben says above, that the range structure is ugly.

Two alternatives have been suggested:
a) a:b:c
b) a..b..c

Do either of these create parsing problems?
for i in a:b:
Should this be treated as an error, with a missing c (the increment)
  print i

for i in 2..5:
  print i   We
don't know whether the 2 is an integer until the second period is scanned.

It would be good if the range and slice could be merged in some way,
although the extended slice is rather complicated - I don't understand it.

The semantics for an extended slicing are as follows. The primary
must evaluate to a mapping object, and it is indexed with a key that
is constructed from the slice list, as follows. If the slice list
contains at least one comma, the key is a tuple containing the
conversion of the slice items; otherwise, the conversion of the lone
slice item is the key. The conversion of a slice item that is an
expression is that expression. The conversion of an ellipsis slice
item is the built-in |Ellipsis| object. The conversion of a proper
slice is a slice object (see section section 4.2 The standard type
hierarchy )
whose |start|, |stop| and |step| attributes are the values of the
expressions given as lower bound, upper bound and stride,
respectively, substituting |None| for missing expressions.

[source: http://www.network-theory.co.uk/docs/pylang/ref_60.html]

The seems to be a bit of a problem with slicing that needs sorting out.

The syntax for a slice list appears to allow multiple slices in a list:

extended_slicing::= primary  "["
slice_list  "]"
slice_list  ::= slice_item  (","
slice_item )* [","]

but the current interpreter reports an error:

 >>> a= range(20)
 >>> a[slice(3, 9, 2)]
[3, 5, 7]
 >>> a[slice(3, 9, 2), slice(5, 10)]
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: list indices must be integers
 >>>

I have taken the liberty of cross posting this to c.l.p.

Colin W.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[SPE - Stani's Python Editor]

SPE: http://pythonide.stani.be

I use it on Ubuntu. For a quick start, view:
http://showmedo.com/videoListPage?listKey=PythonDevelopmentWithSPE

Stani

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[F. Petitjean]

Le Sun, 19 Feb 2006 21:33:59 +0100, Rene Pijlman a écrit :
> Mladen Adamovic:
>>I wonder which editor or IDE you can recommend me for writing Python 
>>programs.
>
> vi

I beg to disagree :-) Use ed
"Ed is the standard text editor."
http://www.gnu.org/fun/jokes/ed.msg.html


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[Armin Steinhoff]

Mladen Adamovic wrote:
> Hi!
> 
> I wonder which editor or IDE you can recommend me for writing Python 
> programs. I tried with jEdit but it isn't perfect.
>

Nothing is perfect ... but try SciTE and Eric 
http://www.die-offenbachs.de/detlev/eric3.html

--Armin

http://www.steinhoff-automation.com


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python multithreading on cluster system? Embedding python in PVM?

[Armin Steinhoff]

abhinav wrote:
> Hi guys.I have read that one cannot perform true multithreading in
> python due to global interpreter lock mechanism.Suppose i have to
> implement a crawler on a say cluster system like clusterknoppix so that
> i can use parallel virtual machine (PVM)for programming in
> multiprocessor environment or say open MPI.Can i integrate python with
> PVM or MPI.Can i embed python into C for programming in multiprocessor
> environment.Is there any way of embedding python in PVM or MPI so that
> i can implement a true cluster based search engine?
> Any help would be very kind.Thanks.
> 


http://pypvm.sourceforge.net

--Armin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[Sriram Krishnan]

Mladen Adamovic wrote:
> Hi!
> 
> I wonder which editor or IDE you can recommend me for writing Python 
> programs. I tried with jEdit but it isn't perfect.
> 

Check out http://wiki.python.org/moin/PythonEditors. I personally use Emacs

-- 
Sriram
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[Jonathan Daugherty]

# I wonder which editor or IDE you can recommend me for writing Python
# programs. I tried with jEdit but it isn't perfect.

It depends on what you need; what don't you like about JEdit?  What do
you think a good editor or IDE should provide?

-- 
  Jonathan Daugherty
  http://www.parsed.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: editor for Python on Linux

[Rene Pijlman]

Mladen Adamovic:
>I wonder which editor or IDE you can recommend me for writing Python 
>programs.

vi

-- 
René Pijlman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Countdown Timer

[[EMAIL PROTECTED]]

take a look at the time module.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Torsten Bronger]

Hallöchen!

Bruno Desthuilliers <[EMAIL PROTECTED]> writes:

> Alexander Schmolck a écrit :
>
>> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>> 
>>> [...]
>>>
>>> It's not a "scripting" language, and it's not interpreted.
>>
>> Of course it is. What do you think happens to the bytecode?
>
> Ok, then what do you think happens to 'machine' code ?
>
> "interpreted" usually means "no compilation, all parsing etc
> redone at each execution", which is not the case with a
> bytecode/vm based implementation.

That sounds like an implementation feature rather than a language
feature.  Besides, it's not a very sensible distinction in my
opinion.  Much better is to think about the structure of the
interpreting machine.  I'm not a CS person (only a physicist) but if
you *need* a bytecode interpreter on top of the CPU interpretation,
it's an interpreted language to me.

I've had such a discussion about TeX already, and my personal
conclusion was that you can defend almost any opinion in that area.
However, one should ensure that the definitions make a pragmatic and
useful distinction.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[63q2o4i02]

Great, thank you and everyone for this nice discussion.

Michael

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Another stupid newbie question

[Byte]

"Do yourself a HUGE favour and read this before posting any more
questions
to comp.lang.python. Trust me, you really will thank us.

http://www.catb.org/~esr/faqs/smart-questions.html "

I find that webpage highly insulting, and so should you. It is treating
you like a small child, who needs to be told everything. If you need
more information, just ask. I myself have been on hardware lists/fourms
for quite a while now. I never answer questions that go into too much
detail, I find it off-putting and insulting - I feel it treats me like
some sort of robot, that requires all eventualities to be programed
into it to start answering the questions. I just ask politly for more
info, if I need it. But questions from people saying 'Please help' etc.
is great. They know they are in the wrong, and intend to be humorus.
They dont intend to annoy/offend anybody. And really, I dont need to be
told how to be polite, thank you. As regards to grammer/spelling, what
if sombody is unsure of how to spell something? And did you ever hear
of being in a rush?

 -- /usr/bin/byte

-- 
http://mail.python.org/mailman/listinfo/python-list

Countdown Timer

[KennethGorelick]

Could someone tell me what modules I should look at in the Python
Manual to create a countdown timer that counts the years, days, hours,
minutes, and seconds to a given day?  Thanks in advance!  I'm fairly
new to the language, so please put it in newbie terms.  I only know the
basics.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Ed Jensen]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> It's not a "scripting" language, and it's not interpreted.

http://www.python.org/doc/faq/general.html#what-is-python

"Python is an interpreted, interactive, object-oriented programming
language."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Bruno Desthuilliers]

Alexander Schmolck a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> 
> 
>>DH a écrit :
>>(snip)
>>
>>>It is by design. Python is dynamically typed. It is essentially an
>>>interpreted scripting language like javascript or ruby or perl,
>>
>>
>>It's not a "scripting" language, and it's not interpreted.
> 
> 
> Of course it is. What do you think happens to the bytecode?

Ok, then what do you think happens to 'machine' code ?

"interpreted" usually means "no compilation, all parsing etc redone at 
each execution", which is not the case with a bytecode/vm based 
implementation.

> And if python
> isn't a scripting language, then what on earth is? 

bash is a scripting language for *n*x systems. javascript is a scripting 
language for web browsers. VBScript is a scripting language for  MS 
applications.

> You might want to argue about whether scriping language is a meaningful and
> useful concept,

A scripting languagee is a language whose main purpose is to be embbeded 
in an application to provide the user a way of programmaticaly automate 
some tedious tasks.

Now you could of course argue about what is an application...

> but it's really hard to see how you could talk about "scripting
> languages" without including python.

Ho, really ? How many applications using Python as scripting language ? 
And how many applications written in Python ?

Python *can* be used as a scripting language (and is not too bad at it), 
but it *is* not a scripting language.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Fredrik Lundh]

Alexander Schmolck wrote:

> You might want to argue about whether scriping language is a meaningful and
> useful concept, but it's really hard to see how you could talk about 
> "scripting
> languages" without including python.

define "scripting language".

the only even remotely formal definition I've ever seen is "language with
designed to script an existing application, with limited support for handling
its own state".  Early Tcl and JavaScript are scripting languages, Python
is not.





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[63q2o4i02]

Great, thanks for a very complete answer.
michael

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: general coding issues - coding style...

[Bruno Desthuilliers]

calmar a écrit :
> Hi all,
> 
> since I'm just a 'handicraft'/beginner or so,
> 
> could anybody provide me with some (rough) hints, about how to enhance the 
> code
> here:
> 
> http://calmar.ws/tmp/cal.html

1/ learn OO and get rid of globals.
2/ use dict or list based dispatch instead of long if/elif/elif... clauses
3/ stdout is meant for *normal* program outputs. Errors and verbosity go 
to stderr
4/ triple quoted strings are fine for multiline text
5/ os.path is fine for portable filepath operations
6/ things that dont change during program execution (ie : constants) 
should not be defined inside a function



> Cheers and thanks a lot
> calmar
> 
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Fredrik Lundh]

Alexander Schmolck wrote:

> What's far more interesting to me, however, is that I think there a good
> reasons to suspect python's slowness is more of a feature than a flaw: I'd not
> be suprised if on the whole it greatly increases programmer productivity and
> results in clearer and more uniform code.

> So ironically, some share of python's success might actually be due to
> ignorance on Guido's part

it didn't, for even a millisecond, strike you that maybe, just maybe, the
"make it as dynamic as we possibly can" choice was made on purpose ?





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[63q2o4i02]

Cool, thank you.  That's the answer I was looking for :)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

Bruno Desthuilliers <[EMAIL PROTECTED]> writes:

> DH a écrit :
> (snip)
> > It is by design. Python is dynamically typed. It is essentially an
> > interpreted scripting language like javascript or ruby or perl,
> 
> 
> It's not a "scripting" language, and it's not interpreted.

Of course it is. What do you think happens to the bytecode? And if python
isn't a scripting language, then what on earth is? 

You might want to argue about whether scriping language is a meaningful and
useful concept, but it's really hard to see how you could talk about "scripting
languages" without including python.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

[EMAIL PROTECTED] writes:

> Hi, I've been thinking about Python vs. Lisp.  I've been learning
> Python the past few months and like it very much.  A few years ago I
> had an AI class where we had to use Lisp, and I absolutely hated it,
> having learned C++ a few years prior.  They didn't teach Lisp at all
> and instead expected us to learn on our own.  I wasn't aware I had to
> uproot my thought process to "get" it and wound up feeling like a
> moron.
> 
> In learning Python I've read more about Lisp than when I was actually
> trying to learn it, and it seems that the two languages have lots of
> similarities:
> 
> http://www.norvig.com/python-lisp.html
> 
> I'm wondering if someone can explain to me please what it is about
> Python that is so different from Lisp that it can't be compiled into
> something as fast as compiled Lisp?  

Nothing. Given a sufficiently smart implementation any language can be as fast
as any other -- it might just be a billion times harder to write that
implementation for language A than for language B.

> From this above website and others, I've learned that compiled Lisp can be
> nearly as fast as C/C++, so I don't understand why Python can't also
> eventually be as efficient? Is there some *specific* basic reason it's
> tough? Or is it that this type of problem in general is tough, and Lisp has
> 40+ years vs Python's ~15 years?

I think if you're looking for one single reason, it is presumably that (IIRC)
python was designed on the erronous assumption that dynamically typed
languages have to be slow (and are unsuitable for real applications anyway)
wheras common lisp wasn't. Furthermore the people involved in common lisp were
much more knowledgeable and experienced in things like compiler design and had
a long history of similar languages and various implementations to build upon.

As common lisp and scheme demonstrate you can have high level of dynamism (and
in a number of things both are more dynamic than python) and still get very
good performance (in some cases close to or better than C). But both these
languages have been designed with compiler writers and the generation of fast
code in mind, so they made design decisions to ease writing fast lisp
compilers and programs.

For example:

- python classes (and to some extent modules) are essentially dictionaries
  that you can modify and customize more or less at will at run-time and that
  behave interchangeably in many respects. I'm sure that presents several
  optimization headaches.

  By contrast if the common lisp compiler sees the symbol CL:LIST (usually
  written just LIST, because the CL package is imported by default) it can
  safely assume that it refers to the builtin LIST function, because you're
  not allowed to rebind the function value of functions in the CL package.
  Python can assume no such thing if it comes across ``list`` -- for all it
  knows it might as well be the number 42. Also the package and class system
  are completely separate and although common lisp's OO system is rather more
  powerful than python's it has been designed to be implementable efficiently.

- in python almost everything has to happen at run-time, whereas in common
  lisp you can do things at compile time, load time or run-time e.g:

- common lisp has a mechanism for making compiler declarations (so you can
  tell the compiler to inline a function, or the type of a variable, or to
  optimize something for speed and not for space etc.)

- common lisp has macros (proper ones, not C style) which allow you to build
  efficient abstractions

- common lisp has compiler macros. This sort of means that you can write 
your
  own compiler optimizations for your functions (i.e. if you know that your
  expensive FOO function is indempotent you could arrange for all calls of 
the
  form (FOO (FOO A)) to be replaced with simply A, in a similar way as an
  optimizing compiler might replace (a+b+c+d)*0 with 0).

What's far more interesting to me, however, is that I think there a good
reasons to suspect python's slowness is more of a feature than a flaw: I'd not
be suprised if on the whole it greatly increases programmer productivity and
results in clearer and more uniform code.

If you know the language to be dog slow any way, you're much less likely to
waste your time (and that of future maintainers) on the pointless
microoptimizations that geeks so love. Also, since only builtins have
reasonable performance there's added motiviation to become very familiar with
the available builtins (and standard libarary) and far less temptation to roll
one's own version of say dict.setdefault (even if it it sucks). The fact that
non-standard library code is inherently somewhat inferior (because it will
either be written in python and slow or written in C and a pain to install)
adds further incentive to attempt community wide standardization.

I think it's not unreasonable to speculate that all this decreases produc

Req. for module style/organization

[RayS]

I've begun a Python module to provide a complete interface to the 
Meade LX200 command set, and have searched for a style/development 
guide for Python Lib/site-packages type modules, but only saw guides 
for C-modules.  I realize that I need to make some changes to follow
http://www.python.org/doc/essays/styleguide.html
better. Does anyone have an appropriate URL for me to follow for this 
task? Is one of the C-module guides appropriate?

I had quickly parsed the official PDF into prototype methods and 
started off, got some good advice from Python-list and MAPUG, and 
broke it into Classes:
http://rjs.org/Python/LX200.zip
Not having written a generic module before, I'd like input on 
organization and style.  As I usually learn from examples, I browsed 
2.4 Lib/site-packages/ and saw a wide variety of structure:
-some have empty __init__.py files, others are loaded
-some have module vars and methods, others not
-some have 0, 1, or many classes per .py file

I have:
LX200/
 __init__.py
 LXSerial.py
 Telescope.py
 Focuser.py
 LXUtils.py
 ... etc
Each file has one class defined.
In the above, LXSerial, Telescope and Focuser are actual separate 
objects (there are others). None can be used without the serial port, 
but some might be used without a scope present. They all ultimately 
rely on a set of atomic serial commands in somewhat overlapping 
categories, not all of which are available on every model device 
(many other makers follow the LX set for its inertia). There is a 
second com port available for optional separate control, but rarely 
used by anyone.
I am trying also to follow the ASCOM standard for names and 
high-level function behavior, as just a subset of the total of 
methods. (ASCOM is the biggest standard in the amateur astro 
industry, but is entirely MS COM, not even CORBA.) That part isn't very hard.

Currently, a user creates a port object, tests ports if desired, then 
opens one (presumably with an LX on the other end, or it Excepts). A 
Telescope object is created before or after, and the port object is 
set as an attribute of the scope. Alternatively, I could require that 
the port is passed explicitly to the Telescope methods, and likewise 
the accessory's methods... There is the issue of inheritance and 
making Classes aware of parents' objects and other Classes' stuff (if needed).

Where in this structure should constants be defined? __init__, 
module*.py, or the module's Class(s)?
Should I rename LXSerial to _serial?
BAUD rate is 9600, so speed here is a non-issue.

The seeming lack of uniformity in the Libs/* is causing my uncertainty:
All advice is appreciated,
Ray

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Bruno Desthuilliers]

DH a écrit :
(snip)
> 
> It is by design. Python is dynamically typed.  It is essentially an 
> interpreted scripting language like javascript or ruby or perl,

It's not a "scripting" language, and it's not interpreted.

> although 
> python fans will be quick to tell you python is compiled to byte code. 

CQFD.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How many web framework for python ?

[Ville Vainio]

Sybren Stuvel wrote:

> Why forget it? I've written my own web framework
> (http://www.unrealtower.org/) and it works great! It was a good

Some reasons:

- Waste. When you write your own framework, you are helping yourself.
If you use an existing framework and possibly contribute patches to it,
you help other people too.

- Other people have already solved your problems, also problems that
you can't think of yet.

- Not reusing code is just plain evil.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Terry Hancock]

On Sun, 19 Feb 2006 00:54:22 -0500
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
> In order to be that fast, some of the dynamism of
> intepreted Lisp must be  given up.  In particular object
> code is not list data.  Python with  type-dynamism
> eliminated can also be translated to decent C/C++ and then
> compiled.  See PyRex and Weave.  There is also Psyco,
> which I believe  translates directly to machine code.

I thought it was just "Pyrex" as in "Still as clear as
glass, but can really take the heat.".  ;-)

Now it's a small snake / dog chimera.  Eeeww. You've ruined
it for me.

> > so I don't understand why Python can't also eventually
> > be as efficient? Is there some *specific* basic reason
> > it's tough?  Or is it that this type of problem in
> > general is tough, and Lisp has 40+ years vs Python's ~15
> > years?

Otherwise, I think this has been well-answered -- if you
give up the same features, you can get the same speed. But
who cares?

Those things only matter in a very limited domain, and real
programs can use Python for logic and Python extension
modules for things that truly need optimization. If you use
Pyrex, you can even still pretend you're programming in
Python when you write those extensions. I'm sure that's why
some 3D libraries have opted to write the fast code in Pyrex
instead of C (even though either is possible).

 -- 
Terry Hancock ([EMAIL PROTECTED])
Anansi Spaceworks http://www.AnansiSpaceworks.com

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Kay Schluehr]

Roy Smith wrote:
> DH <[EMAIL PROTECTED]> wrote:
> > -python has true closures (although nothing like ruby's blocks)
>
> What is a "true closure"?  Or, maybe what I'm asking is what kind of
> closure wouldn't be a true closure?  Is there some kind of ersatz closure
> other language try to pass off, in violation of truth in closure laws?

A "true closure" is what Python doesn't have ;)

If you enclose variables in a certain functional context in which they
are not defined they are turned into something immutable in Python.
Assigning a value to the same name creates a new object instead of
rebinding the old name. This "readonly" semantics confuses many
programmers coming from other languages at least all Lispers/Schemers
I've talked to. Python does not provide a rebinding operator for free
variables by BDFL decision.

Kay

-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] ConfigObj 4.2.0

[Fuzzyman]

`ConfigObj 4.2.0 `_
is now available.

The main improvements are *full* Unicode support,a s well as the
addition of the 'convenience' `Section Methods
`_

* *as_bool*
* *as_int*
* *as_float*

More compelling reasons to choose **ConfigObj** for reading and writing
config files in Python. :-)

What's New ?
==

The full changelog is :

Removed ``BOM_UTF8`` from ``__all__``.

The ``BOM`` attribute has become a boolean. (Defaults to ``False``.) It
is *only* ``True`` for the ``UTF16`` and UTF8 encodings.

File like objects no longer need a ``seek`` attribute.

Full unicode support added. New options/attributes ``encoding``,
``default_encoding``.

ConfigObj no longer keeps a reference to file like objects. Instead the
``write`` method takes a file like object as an optional argument.
(Which will be used in preference of the ``filename`` attribute if that
exists as well.)

utf16 files decoded to unicode.

If ``BOM`` is ``True``, but no encoding specified, then the utf8 BOM is
written out at the start of the file. (It will normally only be
``True`` if the utf8 BOM was found when the file was read.)

File paths are *not* converted to absolute paths, relative paths will
remain relative as the ``filename`` attribute.

Fixed bug where ``final_comment`` wasn't returned if ``write`` is
returning a list of lines.

Deprecated ``istrue``, replaced it with ``as_bool``.

Added ``as_int`` and ``as_float``.

What is ConfigObj ?
===

**ConfigObj** is a simple but powerful config file reader and writer:
an *ini file round tripper*.

It's main feature is that it is very easy to use, with a
straightforward programmer's interface and a simple syntax for config
files. It has lots of other features though. It is intended as a more
powerful (but simpler to use) replacement for `ConfigParser
`_.

It's features include :

* Nested sections (subsections), to any level
* List Values
* Multiple Line Values
* Full Unicode support
* String interpolation (substitution)
* Integrated with a powerful validation system

- including automatic type checking/conversion
- repeated sections
- and allowing default values

* All comments in the file are preserved
* The order of keys/sections is preserved
* No external dependencies

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: ANN: FreeImagePy 1.2.2

[Terry Hancock]

On Thu, 16 Feb 2006 09:34:18 -0500
Andrew Gwozdziewycz <[EMAIL PROTECTED]> wrote:
> > Knowing some details about PIL and as good as no details
> > about FreeImage, I would like in this context to become
> > enlightened by the answer to the question, when does it
> > make sense to use FreeImage instead of PIL?
> >  From what I know up to now I can't see any use for
> >  FreeImage :-( .
> 
> both freeimagepy and freeimage are released under the GPL,
> PIL is not.

This is misleading! The PIL license is GPL-compatible (i.e.
it could be incorporated into a GPL work), as it is a
non-copyleft free license. You may be confused by Lundh's
proprietary-then-free release strategy: he always releases a
newer version under a proprietary license, at which point
the old version is free-licensed.  But the old version is
completely without strings -- you could, if you wanted, try
to give Mr. Lundh "a run for his money" by extending PIL
faster than he can.

Not exactly "cricket", but legal. ;-)

However, while PIL is very strong at image-manipulation, it
is weak on file-format compatibility: As long as you stick
to PNG format, you can do just about anything you want (and
there is decent JPG and GIF support). But if you have
compelling reasons to output data in other formats, you'll
find PIL disappointing -- there are many formats it can't
deal with at all, and most of the rest it can only import
(in the wild, there are *dozens* of obscure image formats to
be found).

IMHO, this isn't too serious an issue -- it's just
specialization: PIL is for *image manipulation* not *image
conversion*, and it provides enough of the latter for the
most common applications.

Other choices include ImageMagick, but API stability,
particularly of the Python bindings, is a real problem (in
fact, I think there's more than one python binding for
ImageMagick, but I'm not sure -- which goes some way to
showing why it's a frustrating package to use).  Things
may have improved lately, I haven't checked in awhile.

So, IMHO, there's still PLENTY of room for innovation in
the application area of image-handling tools for
Python.  PIL is not a "category-killer". At least not yet.

Cheers,
Terry

 -- 
Terry Hancock ([EMAIL PROTECTED])
Anansi Spaceworks http://www.AnansiSpaceworks.com

-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] SPE IDE videos and more...

[SPE - Stani's Python Editor]

I'm happy to spread the word about showmedo.com, an excellent
collection of python programming videos.

>From the website
http://showmedo.com/videoListPage?listKey=TheBigPythonList:

"""Want to learn how to use some of the best Python programming tools
out there, including the supercharged IPython interpreter and the great
free editor SPE? Or maybe you want to see how easy it is to create
great-looking, powerful graphical user interfaces using wxPython. If
so, take a gander at the videos below."""

They have two SPE specific videos:

"""
Python with Stani's Python Editor (SPE)

Two videos to demonstrate editing and debugging of Python code using
the excellent SPE toolkit.

Python Development and Navigation with SPE
--
SPE is a well-featured cross-platform development environment for
Python. Here I show you how to write a simple Python program, save the
code, run it and navigate using the Explorer, Index and UML Viewer.
Complimentary material can be found in the manual and the tutorial at
http://www.serpia.org.

Debugging with WinPDB from Within SPE
--
The WinPDB graphical debugger can be launched from within SPE to debug
Python code. Here I show how to launch the debugger, step through the
code and stack frame, inspect variables and exit back to SPE. I also
explain the significance of the Magic Letters.
"""

The SPE videos area available at the url:
http://showmedo.com/videoListPage?listKey=PythonDevelopmentWithSPE.

Contribute back to your favorite open source projects by submitting
your own python videos to this wonderfull project! If you need
inspiration look at the requested videos: http://showmedo.com/requests
Who will make the first wxGlade video? Anyone who contributes a video
can request a SPE pdf manual as a reward.

Stani

--
http://pythonide.stani.be
http://pythonide.stani.be/screenshots
http://pythonide.stani.be/manual/html/manual.html
--

PS Other python videos have as topic:
"""
Beginning Python
--
Three videos covering the download and installation of the Python
programming language on a Windows machine and a small introduction to
the Python interpreter.

Python Development with IPython
--
Four videos leading you through the installation and basic mastery of
the powerful IPython interactive Python environment

Python GUI Programming with wxPython
--
A series of videos for beginners showing how easy it is to quickly
develop professional looking graphical user interfaces exploiting the
ease and power of the Python programming language. wxPython is fast
becomming one of the most popular cross-platform GUI programming
solutions. This set of videos aims to show you why.

"""

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: define loop statement?

[Cameron Laird]

In article <[EMAIL PROTECTED]>,
David Isaac <[EMAIL PROTECTED]> wrote:
.
.
.
>Admiration wins out over revulsion.  ;-)
>Thanks,
>Alan Isaac
>
>PS Here's the motivation.  Python closely resembles pseudocode.  With
>a very little LaTeX hacking, it is often possible to write algorithms is
>Python that typeset as reasonable pseudocode.  A simple repetitive
>loop is a bit of a sticking point.
>
>

Wow.  Innovative.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Cameron Laird]

In article <[EMAIL PROTECTED]>,
Roy Smith  <[EMAIL PROTECTED]> wrote:
>DH <[EMAIL PROTECTED]> wrote:
>> -python has true closures (although nothing like ruby's blocks)
>
>What is a "true closure"?  Or, maybe what I'm asking is what kind of 
>closure wouldn't be a true closure?  Is there some kind of ersatz closure 
>other language try to pass off, in violation of truth in closure laws?

It's an apt question.

What's a "true closure"?  That's the easiest part, in some ways:  
Wikipedia, for example, tells that it's "a function that refers
to free variables in its lexical context" http://en.wikipedia.org/wiki/Closure_%28computer_science%29 >,
that is the context of the domain of the function's definition.

Some languages--Lisp, but also many others--definitely have it.
Basic definitely didn't.  Tcl ... well, after weeks of discussion
http://wiki.tcl.tk/closures >, the conclusion was that Tcl
almost has as much as it can, given that "lexical context" just
doesn't have much standing in Tclonia.  So, yes, George Mikan and
Allen Iverson both definitely played basketball, and well, but,
at the same time, it's useful to distinguish the things they do
with a ball.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How many web framework for python ?

[Alex Martelli]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
   ...
> > There are very good web framework for java and ruby ,
> > Is there one for python ?
> 
> In fact, there are actually too much *good* python web frameworks.

Dear Mr. BDFL,

there are too many good web frameworks nowadays. Please eliminate three.

PS: I am *not* a crackpot!


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Terry Reedy" <[EMAIL PROTECTED]> writes:

> <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> > In learning Python I've read more about Lisp than when I was actually
> > trying to learn it, and it seems that the two languages have lots of
> > similarities:
> >
> > http://www.norvig.com/python-lisp.html
> >
> > I'm wondering if someone can explain to me please what it is about
> > Python that is so different from Lisp that it can't be compiled into
> > something as fast as compiled Lisp?  From this above website and
> > others, I've learned that compiled Lisp can be nearly as fast as C/C++,
> 
> In order to be that fast, some of the dynamism of intepreted Lisp must be 
> given up.  In particular object code is not list data.  

I'm not entirely sure what you are talking about, but you're almost certainly
very confused about something. Not all common lisp implementations even have
an interpreter (which doesn't tend to be visible to the user).

'as

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Should we still be learning this?

[Max]

John Zenger wrote:
> Don't overly concern yourself with your course being 100% up to date. 
> When learning programming, the concepts are what is important, not the 
> syntax or libraries you happen to be using.  Even if they were to teach 
> you the latest and greatest features of 2.4.2, that would be out of date 
> in a few months/years when the next version comes along and the Python 
> gods decide to deprecate the entire os module or something.
> 

All of us know how to program: the idea is that those who got more than 
70% for Java in high school can learn a second language instead of doing 
Java all over again.

> 
> And BTW, map and filter are such useful concepts that it makes sense to 
> teach them to students even if they will one day be deprecated in 
> Python.  If you want to teach yourself Haskell or a Lisp dialect (and 
> you should!), knowing those concepts will come in very handy.
> 

True. But I think list comprehensions are also damn useful (and AFAIR, 
Haskell has them too).

I already know some Scheme (I've played the "game" Lists And Lists, a 
Scheme tutorial, and used the GIMP's script-fu). I have tried to learn 
Haskell, but - though I think I understand everything I read on it - I 
can't get my programs to run.

--Max
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Should we still be learning this?

[Max]

Felipe Almeida Lessa wrote:
> Em Sáb, 2006-02-18 às 15:13 +0200, Max escreveu:
> 
>>>I wonder if they need some updating.
>>>
>>
>>And so does Dive Into Python (our textbook, diveintopython.org) which 
>>has the same deficiencies in its outline.
> 
> 
> Are they being *paid* for teaching? Then they should overcome this issue
> of Dive Into Python by either using their own material our by improving
> Dive Into Python and giving it back to the community.
> 

Indeed they are. It is a university course. It doesn't actually cover 
anything I don't know, but it's a choice between relearning Java and 
relearning Python (since I plan to major in computer science, I have to 
do first year)

--Max
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[bearophileHUGS]

Luis M. González>[Shed-Skin] ... but so far it looks great (only one
developer though..).<

Two developers, I am there too :-)

I think people aren't much interested so far because there aren't good
ways to link/join/use SSPython compied code from CPython code. A good
solution is probably to:
- Develop code in CPython
- find if there are slow spots that Psyco can't improve enough
- in this situation move the parts in a module and do some tweaks to
adapt the code (if necessary)
- compile the .py module (to a .pyd, etc) with SS (a single click can
be enough on some operating systems), and then import it as before.

To do this it SS requires to know the types of the input data of the
functions/classes in the module. There are solutions to this, the
simpler one to me seems to infer such types from the code below the if
__name__ == "__main__":
That part can contain tests of all the functions/classes, so such parts
can be used to infer types of the whole module.
To do this automatically SS has to use something like SWIG.

Other developers can probably help with such things, otherwise SS will
probably be dead in a year from now... this is not good for me.

Bye,
bearophile

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How many web framework for python ?

[Sybren Stuvel]

Bruno Desthuilliers enlightened us with:
>> I want to write a web framework for python based on mod_python as
>> my course homework , could you give some advise ?
>
> Yes : forget it.

Why forget it? I've written my own web framework
(http://www.unrealtower.org/) and it works great! It was a good
learning experience in using mod_python. Besides that, I found the
existing frameworks not quite suitable to my taste, and I like my own
much more.

Please, feel free to take a look at it, and let me know what you think
;-)

Sybren
-- 
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself? 
 Frank Zappa
-- 
http://mail.python.org/mailman/listinfo/python-list

Python multithreading on cluster system? Embedding python in PVM?

[abhinav]

Hi guys.I have read that one cannot perform true multithreading in
python due to global interpreter lock mechanism.Suppose i have to
implement a crawler on a say cluster system like clusterknoppix so that
i can use parallel virtual machine (PVM)for programming in
multiprocessor environment or say open MPI.Can i integrate python with
PVM or MPI.Can i embed python into C for programming in multiprocessor
environment.Is there any way of embedding python in PVM or MPI so that
i can implement a true cluster based search engine?
Any help would be very kind.Thanks.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: define loop statement?

[David Isaac]

"Benji York" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Here's a flagrant hack:

Admiration wins out over revulsion.  ;-)
Thanks,
Alan Isaac

PS Here's the motivation.  Python closely resembles pseudocode.  With
a very little LaTeX hacking, it is often possible to write algorithms is
Python that typeset as reasonable pseudocode.  A simple repetitive
loop is a bit of a sticking point.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Luis M. González]

>IMO, it's the lack of competing implementations.

I beg to differ in this point.
There are other implementations, but they are not called "python" and
they are not a 100% python in syntax and features.
For example, Boo is 95% python syntax wise, but statically typed.
This fundamental difference makes it as fast as C# or any other .NET
(or mono) language.
Being statically typed doesn't mean that you have to declare types
everywhere, like in C. It uses type inference, so you can declare a
variable x= 5 and the compiler will know that x is an integer of value
5.
Pyrex is statically typed too, but it's used mainly as an extension
language for Cpython.

Now talking specifically about python, there are projects aimed at
speeding it up substantially:

Pypy is a project that relies heavily in type inference (for
translation to lower level code) and dynamic optimization. It's based
mainly on psyco, which has already probed that it can massively speed
up python code.

Shed-Skin: it's a pyton-to-c++ compiler. It won't support the most
dynamic features of python, and requires the programmer to restric a
little bit his coding style in order to allow static compilation, but
so far it looks great (only one developer though..).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 2-dimensional data structures

[Gerard Flanagan]

anthonyberet wrote:
> I want to work on a sudoku brute-forcer, just for fun.
>...
> Thanks for the advice (to everyone in the thread).
> I think I will go with nested lists.
> However, I am running into a conceptual problem.
> My approach will be firstly to remove all the impossible digits for a
> square by searching the row and column for other occurances.
>
> However, I wondering how to approach the search of the nine regions of
> the grid. I am thinking of producing another nested list, again 9x9 to
> store the contents of each region, and to update this after each pass
> through -and update of- the main grid (row and column).
>
> I am not sure how to most efficiently identify which region any given
> square on the grid is actually in - any thoughts, for those that have
> done this? - I don't want a massive list of IF conditionals if I can
> avoid it.


Some 'UselessPython' :

import math

def SudokuOrder( length ):
block_length = int(math.sqrt(length))
for block in range(length):
row_offset = block_length * ( block // block_length )
col_offset = block_length * ( block % block_length )
for i in range( block_length ):
for j in range( block_length ):
yield i+row_offset, j+col_offset

grid = list(SudokuOrder(9))

BLOCK1 = grid[:9]
BLOCK2 = grid[9:18]
BLOCK9 = grid[72:81]

print
print 'BLOCK1 ->', BLOCK1
print
print 'BLOCK2 ->', BLOCK2
print
print 'BLOCK9 ->', BLOCK9


BLOCK1 -> [(0, 0), (0, 1), (0, 2), (1, 0), (1, 1), (1, 2), (2, 0), (2,
1), (2, 2)]

BLOCK2 -> [(0, 3), (0, 4), (0, 5), (1, 3), (1, 4), (1, 5), (2, 3), (2,
4), (2, 5)]

BLOCK9 -> [(6, 6), (6, 7), (6, 8), (7, 6), (7, 7), (7, 8), (8, 6), (8,
7), (8, 8)]


Gerard

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Any Tkinker based rich text widget?

[Fredrik Lundh]

[EMAIL PROTECTED] wrote:

> I am using the standard python GUI Tkinter as my program's main
> interface. Although I know wxPython has some widget to support rich
> text widget, but I do not have time to shift to wx series. Does
> anyone know any Tkinter based widget that support:
>
> 1. Blod, Italic, Underline and their combinations.
> 2. Several most commonly used fonts, like Times New Roman and Arial
> 3. Multiline text
> 4. Cross platform support. Available in Linux-RedHat and Mac OS series
> and Windows 2000 or above.
> 5.Image embedding. Support jpeg, gif, bmp. The more the better.
>
> and better support:
> Hyperlink, Text color, the more the better.

Tkinter's standard Text widget can do all this, of course:

http://effbot.org/tag/Tkinter.Text

by default, Tkinter only supports GIF and PPM, but you can use PIL's
ImageTk.PhotoImage class instead of Tkinter's own PhotoImage to get
support for ~30 more formats:

http://www.pythonware.com/products/pil/
http://effbot.org/tag/PIL.ImageTk

to deal with hyperlinks, use tag event bindings:

http://effbot.org/zone/tkinter-text-hyperlink.htm

:::

there's in fact a complete browser built on top of Tk's Text widget:

http://grail.sourceforge.net/

but I don't know how much work it would be to "widgetize" that
application.

hope this helps!





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Get parameters from URL using CGI

[John Zenger]

import cgi
import cgitb; cgitb.enable()  # Optional; for debugging only

print "Content-Type: text/html"
print

f = cgi.FieldStorage()
for i in f.keys():
print "",i,":",f[i].value


abcd wrote:
> i want to create a CGI script which simply prints out values given via
> the URL (such as when a GET is performed).
> 
> So if I have a script named, foo.cgi and I access it by going to:
> 
> http://www.somesite.com/cgi-bin/foo.cgi?name=john&age=90
> 
> I want foo.cgi to print out:
> name: john
> age: 90
> 
> 
> how do i get the values from the URL like that?
> 
> thanks
> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Fredrik Lundh]

Roy Smith wrote:

> I dread the day that competing Python implementations spring up.

where were you in 1997?

http://www.python.org/workshops/1997-10/proceedings/hugunin.html





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Torsten Bronger]

Hallöchen!

Roy Smith <[EMAIL PROTECTED]> writes:

> [...]
>
> It's been a while since I've dabbled in lisp, but my recollection
> is that the plethora of different implementations has also meant
> that portability is a fantasy.
>
> I dread the day that competing Python implementations spring up.

Even worse: In one of them Microsoft is involved.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How many web framework for python ?

[Bruno Desthuilliers]

Bo Yang a écrit :
> Hello everybody ,
> I am a student major in software engeering .
> I need to do something for my course .
> 
> There are very good web framework for java and ruby ,
> Is there one for python ?

In fact, there are actually too much *good* python web frameworks.

> I want to write a web framework for python based on
> mod_python as my course homework , could you give some
> advise ?

Yes : forget it.
-- 
http://mail.python.org/mailman/listinfo/python-list