Re: overriding base class

[Michele Simionato]

On Jun 30, 5:23 am, Carl Banks <[EMAIL PROTECTED]> wrote:

> Now that I've suggested that, I highly recommend you be sure you're
> very acquainted with new-style objects and method resolution order
> before attempting this.  You need extra care when using MI, even
> though this use of it is rather tame.
>
> Cark Banks

I would say that the burden on the writer of the hierarchy is not that
much.
The real burder is on the *reader* of the code, which can get easily
confused from where methods are coming. This is way I usually do not
recommend MI: because of the reading and maintenance effort (see for
instance the nightmarish situation in Zope 2). To the OP I would
suggest to
consider containment instead, to consider using proxy objects,
__getattr__ and
other similiar tricks that usually do the job.

Michele Simionato

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

Close/hide a child window

[Cubells]

Hi there:

I have two simple classes in two diferent files:

$ cat first.py

#/usr/bin/env python
# -*- coding: utf-8 -*-

import pygtk
pygtk.require('2.0')
import gtk

import second

class first:

def close_program(self, widget, data=None):
gtk.main_quit()
return False
def open_second(self, widget):
second_window = eval("second.second")(self)

def __init__(self):
window = gtk.Window(gtk.WINDOW_TOPLEVEL)
window.connect("delete_event", self.close_program)
window.set_title("First")
window.set_border_width(10)
button = gtk.Button("Open")
button.connect("clicked", self.open_second)
window.add(button)
window.show_all()

def main():
gtk.main()
return 0

if __name__ == "__main__":
first()   
main()


That's the second one:

$ cat second.py

#/usr/bin/env python
# -*- coding: utf-8 -*-

import pygtk
pygtk.require('2.0')
import gtk

class second(gtk.Window):

def close_second(self,widget):
self.hide()
#self.destroy()
#gtk.main_quit()
return False

def __init__(self, parent=None):
gtk.Window.__init__(self)
try:
self.set_screen(parent.get_screen())
except:
self.connect("destroy", lambda *w: gtk.main_quit())
window2 = gtk.Window(gtk.WINDOW_TOPLEVEL)
window2.set_title("Second")
window2.set_border_width(10)
window2.set_modal(True)
window2.set_resizable(False)
button2 = gtk.Button("Second")
button2.connect("clicked", self.close_second)
window2.add(button2)
window2.show_all()

def main():
gtk.main()
return 0

if __name__ == "__main__":
second()   
main()

The question is simple:

How can I close/hide/destroy the second window without to destroy the 
first window when I click the button2??
When I close the second window it works, but when I click the button2 it 
doesn't.

A lot of thanks...


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

Free usefull article.Do you need contents to add to your web site?

[mostselect]

Free usefull article.Do you need contents to add to your web site?
www.real-article.com

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

good matlab interface

[felix seltzer]

Does any one know of a good matlab interface?
I would just use scipy or numpy, but i also need to use
the matlab neural network functions.  I have tried PyMat, but am having
a hard time getting it to install correctly.

For that mater, a good neural net module for python would
work just as well as a good matlab interface.

Any suggestions?

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

Re: Python's "only one way to do it" philosophy isn't good?

[Michele Simionato]

On Jun 29, 3:42 pm, Douglas Alan <[EMAIL PROTECTED]> wrote:
> Michele Simionato <[EMAIL PROTECTED]> writes:
> >> I've written plenty of Python code that relied on destructors to
> >> deallocate resources, and the code always worked.
> > You have been lucky:
>
> No I haven't been lucky -- I just know what I'm doing.
>
>
>
> > $ cat deallocating.py
> > import logging
>
> > class C(object):
> > def __init__(self):
> > logging.warn('Allocating resource ...')
>
> > def __del__(self):
> > logging.warn('De-allocating resource ...')
> > print 'THIS IS NEVER REACHED!'
>
> > if __name__ == '__main__':
> > c = C()
>
> > $ python deallocating.py
> > WARNING:root:Allocating resource ...
> > Exception exceptions.AttributeError: "'NoneType' object has no
> > attribute 'warn'" in  > 0xb7b9436c>> ignored
>
> Right.  So?  I understand this issue completely and I code
> accordingly.

What does it mean you 'code accordingly'? IMO the only clean way out
of this issue
is to NOT rely on the garbage collector and to manage resource
deallocation
explicitely, not implicitely. Actually I wrote a recipe to help with
this
a couple of months ago and this discussion prompted me to publish it:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/523007
But how would you solve the issue using destructors only? I am just
curious,
I would be happy if there was a simple and *reliable* solution, but I
sort
of doubt it. Hoping to be proven wrong,


Michele Simionato

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

Re: ORM layer

[EuGeNe Van den Bulke]

David wrote:
> I am looking for an ORM for Python that fulfills a few simple needs.

* SQLObject
* SQLAlchemy (+Elixir)
* DejaVu

There are probably others but these are the most commonly used AFAIK.

EuGeNe -- http://www.3kwa.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: overriding base class

[Carl Banks]

On Jun 29, 7:36 pm, alf <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I want to develop a following lib:
>
> lib space user space
>
> A -> B -> | -> user_class
>
> however A and B are abstrac enough to have following:
>
> user_super_base_class -> | -> A -> B -> | -> user_class
>
> user space  lib space  user spaca
>
> Any idea how to do that?


One possibility is to use multiple inheritance to get the same
effect.  This is easy in Python but wouldn't work in C++.  Note: it's
very important use new-style classes, however, so always inherit from
object or some other new-style class.

First, in the library space define A and B.  Notice that even though A
derives from object, it calls the "base" class's method.

class A(object):
def method(self):
print "calling A.method"
super(A,self).method()

class B(A):
def method(self):
print "calling B.method"
super(B,self).method()

In user space, declare the base class as so.  Note that super is not
called because this is the "real" base.

class SuperBase(object):
def method(self):
print "calling SuperBase.method"

Then, the user class.  We use multiple inheritance here, and put
SuperBase at the end.  The effect is the same as if A had been derived
from SuperBase.

class User(B,SuperBase):
def method(self):
print "calling User.method"
super(User,self).method()


Calling this User().method() produces the following output:

 calling User.method
 calling B.method
 calling A.method
 calling SuperBase.method


Notice that A.method calls SuperBase.method, quite unintuitively for
someone not used to Python's MRO rules.  Basically, whenever you have
multiple bases, Python creates a consistent ordering of the bases,
called the Method Resolution Order (MRO), according to precedence.
You can exploit this to "insert" a super base class at the bottom.

You can see what the MRO of a class is with the __mro__ attribute.
For example, User.__mro__ is:

(,
 ,
 ,
 ,
 )

Even though A didn't derive directly from SuperBase, it acts as if it
had been, because it's right before SuperBase in the MRO.

Now that I've suggested that, I highly recommend you be sure you're
very acquainted with new-style objects and method resolution order
before attempting this.  You need extra care when using MI, even
though this use of it is rather tame.


Cark Banks

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

Re: Vista 64 + Python2.5 + wxpython 28 issue

[William Heymann]

On Friday 29 June 2007, Martin v. Löwis wrote:
> > There was no need for me to use 64 so I have switched back to 32 and
> > works fine.
> >
> > Python is not ready for the 64 world yet ;)
>
> It's a matter of standpoint. 64 bit is not ready for the world, yet.
>
> Regards,
> Martin

I think you mean 64bit windows. 64bit linux has been working great. I use 
64bit python and zope every day and they work very well and the ability to 
use more memory then 4G is very handy for my tests.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Paul Rubin]

Douglas Alan <[EMAIL PROTECTED]> writes:
> But that's a library issue, not a language issue.  The technology
> exists completely within Lisp to accomplish these things, and most
> Lisp programmers even know how to do this, as application frameworks
> in Lisp often do this kind.  The problem is getting anything put into
> the standard.  Standardizing committees just suck.

Lisp is just moribund, is all.  Haskell has a standardizing committee
and yet there are lots of implementations taking the language in new
and interesting directions all the time.  The most useful extensions
become de facto standards and then they make it into the real
standard.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Lenard Lindstrom]

Douglas Alan wrote:
> Lenard Lindstrom <[EMAIL PROTECTED]> writes:
> 
>> Douglas Alan wrote:
> 
>>> [I]n Python, you can be 100% sure that your files
>>> will be closed in a timely manner without explicitly closing them, as
>>> long as you are safe in making certain assumptions about how your code
>>> will be used.  Such assumptions are called "preconditions", which are
>>> an understood notion in software engineering and by me when I write
>>> software.
> 
>> So documenting an assumption is more effective than removing the
>> assumption using a with statement?
> 
> Once again I state that I have nothing against "with" statements.  I
> used it all the time ages ago in Lisp.
> 

Sorry if I implied that. I assumed it would be clear I was only 
referring to the specific case of implicitly closing files using 
reference counting.

> But (1) try/finally blocks were not to my liking for this sort of
> thing because they are verbose and I think error-prone for code
> maintenance.  I and many others prefer relying on the refcounter for
> file closing over the try/finally solution.  Consequently, using the
> refcounter for such things is a well-entrenched and succinct idiom.
> "with" statements are a big improvement over try/finally, but for
> things like file closing, it's six of one, half dozen of the other
> compared against just relying on the refcounter.
> 

I agree that try/finally is not a good way to handle resources.

> (2) "with" statements do not work in all situations because often you
> need to have an open file (or what have you) survive the scope in
> which it was opened.  You may need to have multiple objects be able to
> read and/or write to the file.  And yet, the file may not want to be
> kept open for the entire life of the program.  If you have to decide
> when to explicitly close the file, then you end up with the same sort
> of modularity issues as when you have to free memory explicitly.  The
> refcounter handles these sorts of situations with aplomb.
> 

Hmm. I come from a C background so normally don't think of a file object 
as leading a nomadic life. I automatically associate a file with a home 
scope that is responsible for opening and closing it. That scope could 
be defined by a function or a module. But I'm not a theorist so can't 
make any general claims. I can see, though, how ref count could close a 
file sooner than if one waits until returning to some ultimate enclosing 
scope.

> (3) Any code that is saving tracebacks should assume that it is likely
> to cause trouble, unless it is using code that is explicitly
> documented to be robust in the face of this, just as any code that
> wants to share objects between multiple threads should assume that
> this is likely to cause trouble, unless it is using code that is
> explicitly documented to be robust in the face of this.
> 

Luckily there is not much need to save tracebacks.

> (4) Any code that catches exceptions should either return soon or
> clear the exception.  If it doesn't, the problem is not with the
> callee, but with the caller.
> 

Explicitly clear the exception? With sys.exc_clear?

> (5) You don't necessarily want a function that raises an exception to
> deallocate all of its resources before raising the exception, since
> you may want access to these resources for debugging, or what have you.
> 

No problem:

 >>> class MyFile(file):
def __exit__(self, exc_type, exc_val, exc_tb):
if exc_type is None:
file.__exit__(self, None, None, None)
return False


 >>> del f

Traceback (most recent call last):
   File "", line 1, in 
 del f
NameError: name 'f' is not defined
 >>> try:
with MyFile("something", "w") as f:
raise StandardError("")
except StandardError:
print "Caught"


Caught
 >>> f.closed
False


But that is not very imaginative:

 >>> class MyFile(file):
def __exit__(self, exc_type, exc_val, exc_tb):
if exc_type is not None:
self.my_last_posn = self.tell()
return file.__exit__(self, exc_type, exc_val, exc_tb)


 >>> del f

Traceback (most recent call last):
   File "", line 1, in 
 del f
NameError: name 'f' is not defined
 >>> try:
with MyFile("something", "w") as f:
f.write("A line of text\n")
raise StandardError("")
except StandardError:
print "Caught"


Caught
 >>> f.closed
True
 >>> f.my_last_posn
16L

---
Lenard Lindstrom
<[EMAIL PROTECTED]>


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

Re: HTML Render Support in PyGTK

[felix seltzer]

http://directory.fsf.org/webauth/htmlpreproc/gtkhtml.html

might help. just like thomas though... more info on what your doing/have
done would help us help you

On 6/29/07, Thomas Jollans <[EMAIL PROTECTED]> wrote:


There was no need to re-ask so soon.

On Friday 29 June 2007, senthil arasu wrote:
> Hi,
> I am trying to render HTML in PyGTK widget but iam not getting the
expected
   ^^
What have you tried so far ?
> result.
> I would like to know whether PyGTK supports HTML rendering feature or
not.

I believe GTK+2 has an HTML renderer, I don't know whether it's included
in
PyGTK by default etc.

--
  Regards,   Thomas Jollans
GPG key: 0xF421434B may be found on various keyservers, eg pgp.mit.edu
Hacker key :
v4sw6+8Yhw4/5ln3pr5Ock2ma2u7Lw2Nl7Di2e2t3/4TMb6HOPTen5/6g5OPa1XsMr9p-7/-6

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


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

Re: Help needed in PyGTk

[felix seltzer]

try the pygtk mailing list,
"pygtk" <[EMAIL PROTECTED]>
they will probobly be able to help you more.

On 6/29/07, senthil arasu <[EMAIL PROTECTED]> wrote:


Hi,
I am trying to render HTML in PyGTK widget but iam not getting the
expected result.
I would like to know whether PyGTK supports HTML rendering feature or not.

Please help me to solve this issue.

thanks


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

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

Python/C API sig - New Mailing List

[Campbell Barton]

Hi, a new mailing list has been started to discuss and get help with 
using the Python/C api.

All the other lists were either about programming with Python or 
developing the core of Python.

If your working on a project that uses Pythons C/API you may be 
interested in joining this list.

http://mail.python.org/mailman/listinfo/capi-sig

-- 
Campbell J Barton (ideasman42)
-- 
http://mail.python.org/mailman/listinfo/python-list

overriding base class

[alf]

Hi,


I want to develop a following lib:

lib space user space

A -> B -> | -> user_class


however A and B are abstrac enough to have following:


user_super_base_class -> | -> A -> B -> | -> user_class

user space  lib space  user spaca



Any idea how to do that?

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

Re: Rappresenting infinite

[Facundo Batista]

[EMAIL PROTECTED] wrote:


>> No. You can make one that fits your requirements, though.
>
> I am struggling to oversee the implications of design choices for inf
> behaviour - especially if it comes to comparison with float type inf.
> The type in my application contains a gmpy.mpq and a float that is
> always kept between -1 and 1 by adding to the mpq on each operation.
> I am looking for a robust inf design for this type. (Note: mpq and
> float inf do not compare).

Infinity, and all its behaviours are well defined in the General Decimal
Arithmetic Specification, here at http://www2.hursley.ibm.com/decimal/.

You can always pass your float to Decimal through string, and then do
there *all* the operations:

>>> from decimal import *
>>> a = 3.4
>>> b = 1.0e1000
>>> Decimal(str(a))
Decimal("3.4")
>>> Decimal(str(b))
Decimal("Infinity")
>>> Decimal(str(b)) / 0
Decimal("Infinity")
>>> Decimal(str(b)) * 0
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.5/decimal.py", line 1140, in __mul__
return context._raise_error(InvalidOperation, '(+-)INF * 0')
  File "/usr/lib/python2.5/decimal.py", line 2325, in _raise_error
raise error, explanation
decimal.InvalidOperation: (+-)INF * 0
>>> setcontext(ExtendedContext)
>>> Decimal(str(b)) * 0
Decimal("NaN")
>>> 

Regards,

-- 
.   Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/


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

Building a Python app with Mozilla

[Thorsten Kampe]

Hi,

I've already sent this to the Komodo mailing list (which seemed to me 
the more appropriate place) but unfortunately I got no response.

I'd like to build a Python GUI app. Neither Tkinter nor Wxpython nor 
PyQT are actually what I want (because the lack of GUI builders and 
they don't really look good on Windows and Linux).

Komodo itself is an excellent example of a - at least Python driven - 
application that looks superb and has superior functionality so it 
seems natural to use the Komodo approach for me.

Some questions

* Is there a simple How-To how to build a very simple (Python) app 
with the Mozilla framework? Kind of "Hello world"...?

* Is is reasonable to think that building a GUI with Mozilla is easier 
than using Python frameworks because Mozilla does most of the GUI 
work?


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

Re: Vista 64 + Python2.5 + wxpython 28 issue

[Martin v. Löwis]

> There was no need for me to use 64 so I have switched back to 32 and works
> fine.
> 
> Python is not ready for the 64 world yet ;)

It's a matter of standpoint. 64 bit is not ready for the world, yet.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Lenard Lindstrom <[EMAIL PROTECTED]> writes:

> Douglas Alan wrote:

>> [I]n Python, you can be 100% sure that your files
>> will be closed in a timely manner without explicitly closing them, as
>> long as you are safe in making certain assumptions about how your code
>> will be used.  Such assumptions are called "preconditions", which are
>> an understood notion in software engineering and by me when I write
>> software.

> So documenting an assumption is more effective than removing the
> assumption using a with statement?

Once again I state that I have nothing against "with" statements.  I
used it all the time ages ago in Lisp.

But (1) try/finally blocks were not to my liking for this sort of
thing because they are verbose and I think error-prone for code
maintenance.  I and many others prefer relying on the refcounter for
file closing over the try/finally solution.  Consequently, using the
refcounter for such things is a well-entrenched and succinct idiom.
"with" statements are a big improvement over try/finally, but for
things like file closing, it's six of one, half dozen of the other
compared against just relying on the refcounter.

(2) "with" statements do not work in all situations because often you
need to have an open file (or what have you) survive the scope in
which it was opened.  You may need to have multiple objects be able to
read and/or write to the file.  And yet, the file may not want to be
kept open for the entire life of the program.  If you have to decide
when to explicitly close the file, then you end up with the same sort
of modularity issues as when you have to free memory explicitly.  The
refcounter handles these sorts of situations with aplomb.

(3) Any code that is saving tracebacks should assume that it is likely
to cause trouble, unless it is using code that is explicitly
documented to be robust in the face of this, just as any code that
wants to share objects between multiple threads should assume that
this is likely to cause trouble, unless it is using code that is
explicitly documented to be robust in the face of this.

(4) Any code that catches exceptions should either return soon or
clear the exception.  If it doesn't, the problem is not with the
callee, but with the caller.

(5) You don't necessarily want a function that raises an exception to
deallocate all of its resources before raising the exception, since
you may want access to these resources for debugging, or what have you.

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

How do I remotely access Scheduled Tasks from Windows XP to Windows Server 2003?

[kj7ny]

How can I access and manipulate Scheduled Tasks in Windows using
Python?

I have a Windows XP workstation running Python 2.4.4 using the
win32all modules to control the windows services on multiple Windows
2003 servers.  It works great.

However, I also need to remotely collect the settings for the
scheduled tasks (on those same Windows 2003 servers) and then
manipulate those task settings.

At the very least, I need to find out which ones are enabled and then
be able to disable and re-enable those tasks at will.  It would be
better to be able to also detect the account each task runs as so that
I could only disable selected tasks, but I'll any help I can get.

Thanks,

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

Re: appending file

[Falcolas]

On Jun 29, 1:04 pm, Kuo <[EMAIL PROTECTED]> wrote:
> # FPGA CLOCK^M
> NET "SYSCLK_A"  loc = N16  | TNM_NET = SYSCLK_A;^M
> NET "SYSCLK_AN" loc = M16  | TNM_NET = SYSCLK_A;^M

I see those bloody ^M's anytime I have to deal with a DOS file (since
it's the carrage return \r character). Is 'pin' a DOS generated file?
If you want to deal with a file which contains them, look for and get
rid of the \r character.

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

Re: ORM layer

[Bruno Desthuilliers]

David a écrit :
> I am looking for an ORM for Python that fulfills a few simple needs.
> 
> - ability to support a number of backends (probably mysql and sqlite  
> at present, csv a bonus)

I didn't knew csv was a relational database.

> - ability to be used easily from console python scripts, a bonus if I  
> can add a simple web GUI later using some framework
> - decent documentation a definite plus
> 
> I do not need:
> 
> - massively complex joins (I could write these myself if needed)
> - something engineered for hundreds of tables, I have only a few and  
> don't need overkill
> 
> Any recommendations?

The best hi-level RDBMS integration package in Python is probably 
SQLAlchemy. I say "hi-level RDBMS integration" because it's much more 
than an ORM. It's already used by some web applications (Trac amongst 
other) and frameworks (Pylons, Turbogears, ...) and the documentation is 
more than correct. So it matches most of your specs. OTHO, while fairly 
usable, it's not the simplest system around - even if some extensions 
like Elixir try to make things simpler-, so you may also want to have a 
look at other packages like SQLObject.

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

Re: Hooking __import__ when embedding the interpreter

[Stefan Bellon]

I think I solved all my three questions for myself now ...

On Fri, 29 Jun, Stefan Bellon wrote:

> 1) The above code seems to work ok when using the "import" statement,
>but it does not when using the dynamic __import__ function. If
>using it that way, I get:
> 
> >>> sys=__import__("sys")
> Traceback (most recent call last):
>   File "", line 1, in ?
> SystemError: new style getargs format but argument is not a tuple
> 
>What am I missing in order to get the __import__ function covered
>as well?

static PyMethodDef import_hook[] =
{   
{"__import__", __import__, METH_VARARGS, import_doc},
{NULL, NULL}
};

Adding the METH_VARARGS solved this, now the __import__ function is
intercepted as well.

> 2) Another point is, that I need to check _from where_ the module is
>imported. In fact, this is going to become part of the consistency
>check condition. How can I find out from which module the import
>was initiated?
> 
> 
> 3) My final point is related to 2) ... if I get to the module object,
>then how do I get at the source file name of that? I noticed that
>when a .pyc is available, then this is preferred. I'd like to get
>at the .py file itself. Is this available or do I just have to
>strip off the trailing 'c' (or 'o'?) if present (seems hacky to
>me).

By not focusing on the module but using
sys._getframe().f_code.co_filename I solved point 2 and 3 in one go.

I'm still looking forward to comments regarding this issue. ;-)

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

ANNOUNCE: Exscript 0.9 (Initial Release)

[Samuel]

Introduction 
-
Exscript is a scripting language for automating Telnet or SSH sessions. 
It supports a wide range of features, such as parallelization, AAA 
authentication methods, TACACS, and a very simple template language.

Exscript itself is written in Python, and it should run on any platform 
where Python supports OS threads.

This is the initial public release.


Dependencies
-
Python 2.2 or better
Python Crypto module


Download Exscript
--
Release: http://exscript.googlecode.com/files/exscript-0.9.tgz
SVN instructions: http://code.google.com/p/exscript/source


Links
--
Exscript project page: http://code.google.com/p/exscript/ 
Mailing list: http://groups.google.com/group/exscript
Bug tracker: http://code.google.com/p/exscript/issues/list 
Browse the source: http://exscript.googlecode.com/svn/trunk/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: HTML Render Support in PyGTK

[Thomas Jollans]

There was no need to re-ask so soon.

On Friday 29 June 2007, senthil arasu wrote:
> Hi,
> I am trying to render HTML in PyGTK widget but iam not getting the expected
   ^^
What have you tried so far ?
> result.
> I would like to know whether PyGTK supports HTML rendering feature or not.

I believe GTK+2 has an HTML renderer, I don't know whether it's included in 
PyGTK by default etc.

-- 
  Regards,   Thomas Jollans
GPG key: 0xF421434B may be found on various keyservers, eg pgp.mit.edu
Hacker key :
v4sw6+8Yhw4/5ln3pr5Ock2ma2u7Lw2Nl7Di2e2t3/4TMb6HOPTen5/6g5OPa1XsMr9p-7/-6


signature.asc
Description: This is a digitally signed message part.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: appending file

[Thomas Jollans]

On Friday 29 June 2007, Kuo wrote:
> Hi,
> I'm trying to read a file (fileA) and append to another file(fileB).
> However, I always get "^M" at the end. Does anyone know why ? Here is my
> code ?

I can't help you on your problem, but

> ucf.close;
> pin.close;

these statements don't do anything. You'll want

ucf.close()
pin.close()

> sys.exit(0);
>
> Here is what I get.
>
> # FPGA CLOCK^M
> NET "SYSCLK_A"  loc = N16  | TNM_NET = SYSCLK_A;^M
> NET "SYSCLK_AN" loc = M16  | TNM_NET = SYSCLK_A;^M
>
>
> Note that if I don't do "ucf.write(pin.read())", everything is ok.
>
> Thanks for any help.



-- 
  Regards,   Thomas Jollans
GPG key: 0xF421434B may be found on various keyservers, eg pgp.mit.edu
Hacker key :
v4sw6+8Yhw4/5ln3pr5Ock2ma2u7Lw2Nl7Di2e2t3/4TMb6HOPTen5/6g5OPa1XsMr9p-7/-6


signature.asc
Description: This is a digitally signed message part.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: appending file

[Bruno Desthuilliers]

Kuo a écrit :
> Hi,
> I'm trying to read a file (fileA) and append to another file(fileB). 
> However, I always get "^M" at the end. Does anyone know why ? Here is my 
> code ?
> 
> os.system("../syn/pin_assign.pl customer_netlist.txt")
> shutil.copy("../fileB", "fileB")
> ucf = open("fileB", "a")
> pin = open("fileA", "r")
> ucf.write(pin.read())
> ucf.close;
> pin.close;
> sys.exit(0);
> 
> Here is what I get.
> 
> # FPGA CLOCK^M
> NET "SYSCLK_A"  loc = N16  | TNM_NET = SYSCLK_A;^M
> NET "SYSCLK_AN" loc = M16  | TNM_NET = SYSCLK_A;^M
> 

Looks like a problem with newline format. Googling for "universal 
newline" may be a good start.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Lenard Lindstrom]

Douglas Alan wrote:
> 
> [I]n Python, you can be 100% sure that your files
> will be closed in a timely manner without explicitly closing them, as
> long as you are safe in making certain assumptions about how your code
> will be used.  Such assumptions are called "preconditions", which are
> an understood notion in software engineering and by me when I write
> software.
> 

So documenting an assumption is more effective than removing the 
assumption using a with statement?

--
Lenard Lindstrom
<[EMAIL PROTECTED]>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: win32event.WaitForInputIdle() returns too soon

[kyosohma]

On Jun 29, 3:03 pm, "Hans" <[EMAIL PROTECTED]> wrote:
> "Gabriel Genellina" <[EMAIL PROTECTED]> schreef in berichtnews:[EMAIL 
> PROTECTED]
>
>
>
> > En Thu, 28 Jun 2007 19:15:40 -0300, Hans <[EMAIL PROTECTED]> escribió:
>
> >> I'm sending keyboard and mouse events to a seperate windows application.
> >> I use win32event.WaitForInputIdle() before calling e.g.
> >> win32api.keybd_event()
> >> However it seems that WaitForInputIdle() returns too soon because some
> >> of my
> >> events get lost. Now I'v created my own  WaitForInputIdle() which calls
>
> > From the Microsoft docs for WaitForInputIdle: "The WaitForInputIdle
> > function only works with GUI applications. If a console application calls
> > the function, it returns immediately, with no wait."
> > A typical Python script is a console application.
>
> > --
> > Gabriel Genellina
>
> It would explain my problem.
> Perhaps I could create a small windows application as interface..
> I have to think about it ( and wait, as I currently don't have access to
> visual C++, nor the MS documentation)
>
> Thanks,
> Hans

Who says you have to create it with Visual C++? You could use Tkinter
or wxPython. Both are pretty easy to pick up and can look professional
with a little work.

Mike

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

Re: PEP 3107 and stronger typing (note: probably a newbie question)

[Bruno Desthuilliers]

Eduardo "EdCrypt" O. Padoan a écrit :
> On 6/22/07, John Nagle <[EMAIL PROTECTED]> wrote:

> Remember that pure CPython has no different "compile time" and
> runtiime.

Oh yes ? So what's the compiler doing, and what are those .pyc files ?
(hint: read the doc)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3107 and stronger typing (note: probably a newbie question)

[Bruno Desthuilliers]

John Nagle a écrit :
(snip)
> It looks like
> a compromise between the "no declarations" position and the "make
> the language strongly typed" position.  
(snip)
> The main advantage of strongly typed systems is that more errors
> are detected at compile time.  
(snip)

s/strongly/statically/

1/ strong typing is not necessarily static typing,
2/ static typing is not necessarily strong typing
3/ dynamic typing is not necessarily weak typing
4/ static typing is not necessarily declarative (ever heard of 
type-inference based systems ?)
-- 
http://mail.python.org/mailman/listinfo/python-list

HTML Render Support in PyGTK

[senthil arasu]

Hi,
I am trying to render HTML in PyGTK widget but iam not getting the expected
result.
I would like to know whether PyGTK supports HTML rendering feature or not.

Please help me to solve this issue.

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

Re: PEP 3107 and stronger typing (note: probably a newbie question)

[Bruno Desthuilliers]

Paul Rubin a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> 
>>Nope, he just asserted something wrong. Static typing is for compiler
>>optimization. Type checking is at most a side effect, and in some
>>languages (at least C, C++ and Java) can be totally defeated (usually
>>using typecasting).
> 
> 
>   "Definitions of type system vary, but the following one due to
>   Benjamin C. Pierce roughly corresponds to the current consensus in
>   the programming language theory community:
> 
> [A type system is a] tractable syntactic method for proving the
> absence of certain program behaviors by classifying phrases
> according to the kinds of values they compute. (Pierce 2002)."

Is this supposed to contradict my assertion that *static* typing is for 
compilers ?

C (and C++) are statically typed. It's usually agreed that C is weakly 
typed, and that C++ is somewhat more strongly typed. In both cases, you 
can totally defeat compile-time type-checking, with possibly some very 
unpredictable results. Python is dynamically typed, but doesn't allow 
the kind of results you can get from a C typecast.

>   -- http://en.wikipedia.org/wiki/Type_theory#Type_system



> C and C++ are basically untyped languages.  

Hem... This assertion is at least debatable. Care to post this on c.l.c 
or c.l.c++, so we get some feedback ?

> Java casts can only
> partially defeat its type system,

In Java, an erroneous typecast will result in a runtime error. Where's 
the benefit of static typechecking if you can get type errors at runtime?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: win32event.WaitForInputIdle() returns too soon

[Hans]

"Gabriel Genellina" <[EMAIL PROTECTED]> schreef in bericht 
news:[EMAIL PROTECTED]
> En Thu, 28 Jun 2007 19:15:40 -0300, Hans <[EMAIL PROTECTED]> escribió:
>
>> I'm sending keyboard and mouse events to a seperate windows application.
>> I use win32event.WaitForInputIdle() before calling e.g.
>> win32api.keybd_event()
>> However it seems that WaitForInputIdle() returns too soon because some 
>> of my
>> events get lost. Now I'v created my own  WaitForInputIdle() which calls
>
> From the Microsoft docs for WaitForInputIdle: "The WaitForInputIdle 
> function only works with GUI applications. If a console application calls 
> the function, it returns immediately, with no wait."
> A typical Python script is a console application.
>
> -- 
> Gabriel Genellina

It would explain my problem.
Perhaps I could create a small windows application as interface..
I have to think about it ( and wait, as I currently don't have access to
visual C++, nor the MS documentation)

Thanks,
Hans 


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

ORM layer

[David]

I am looking for an ORM for Python that fulfills a few simple needs.

- ability to support a number of backends (probably mysql and sqlite  
at present, csv a bonus)
- ability to be used easily from console python scripts, a bonus if I  
can add a simple web GUI later using some framework
- decent documentation a definite plus

I do not need:

- massively complex joins (I could write these myself if needed)
- something engineered for hundreds of tables, I have only a few and  
don't need overkill

Any recommendations?

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

Re: Rappresenting infinite

[Terry Reedy]

"John Nagle" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
|If Python numerics don't define
| +INF, -INF, and NaN, along with the tests for them, that's a
| flaw in the language.

Are you volunteering to fix the 'flaw'?  CPython floating point numerics 
are currently defined to be C doubles and whatever else the particular 
compiler/hardware provides.  But Tim Peters said at least 5 years ago that 
a volunteer could try to improve portability.  Various people have since 
talked about doing something.

|  We can assume IEEE floating point at this
| late date; it's been standard for twenty years and Java assumes it.

Not all processors running Python even have floats ;-)
In any case, the IEEE standard did not seem to define a standard C binding.
Neither did the C89 committee.  So gcc and msc differ on how to spell such 
things.
Not everyone is satisfied with the Java solution.




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

Re: Edit Audio Using Python?

[Ultrus]

Thanks to Aaron, I was able to read and write audio data using
Python's wave module. Trying to better understand the data I'm looking
at, what does each element of the frame represent, and how do I
convert a sample ranging from -32,768 to 32,768 back to a frame set
like below?

When using a 16 bit mono wav file, reading a frame of audio produces 2
numbers like this:

import wave
file = wave.open("myWave.wav")
frame = file.readframes(1) #read first frame
file.close
#ord(frame[0]) = 0 to 256, ord(frame[1]) = 0 to 256,
#possible max of 65,536, or sample with range of -32,768 to 32,768


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

Re: Voluntary Abstract Base Classes

[Daniel Nogradi]

> > Well, the short question is: what are they? I've read Guido's python
> > 3000 status report on
> > http://www.artima.com/weblogs/viewpost.jsp?thread=208549 where he
> > mentions ABC's but don't quite understand what the whole story is
> > about.
>
> The story is at PEP 3119:
> http://www.python.org/dev/peps/pep-3119/

Thanks, I overlooked that somehow.

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

appending file

[Kuo]

Hi,
I'm trying to read a file (fileA) and append to another file(fileB). 
However, I always get "^M" at the end. Does anyone know why ? Here is my 
code ?

os.system("../syn/pin_assign.pl customer_netlist.txt")
shutil.copy("../fileB", "fileB")
ucf = open("fileB", "a")
pin = open("fileA", "r")
ucf.write(pin.read())
ucf.close;
pin.close;
sys.exit(0);

Here is what I get.

# FPGA CLOCK^M
NET "SYSCLK_A"  loc = N16  | TNM_NET = SYSCLK_A;^M
NET "SYSCLK_AN" loc = M16  | TNM_NET = SYSCLK_A;^M


Note that if I don't do "ucf.write(pin.read())", everything is ok.

Thanks for any help.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Rappresenting infinite

[John Nagle]

Robert Kern wrote:
> [EMAIL PROTECTED] wrote:
> 
>>On Thu, 28 Jun 2007 23:20:30 -0500
>>Robert Kern <[EMAIL PROTECTED]> wrote:
>>
>>
>>>[EMAIL PROTECTED] wrote:
>>>
Does it differ from the
built-in inf?
>>>
>>>What built-in inf?
>>
>>$ python
>>Python 2.4.4 (#2, Apr  5 2007, 20:11:18)
>>[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
>>Type "help", "copyright", "credits" or "license" for more information.
>>
>a = 1.0e1000
>b = 2.0e1000
>a
>>
>>inf
>>
>b
>>
>>inf
>>
>a == b
>>
>>True
>>
>type(a)
>>
>>
> 
> 
> Okay, I thought you meant that there was an actual symbol 'inf' in the 
> builtins
> or in a module somewhere.
> 
> 
>>>No. You can make one that fits your requirements, though.

That sounds like a bug.  If Python numerics don't define
+INF, -INF, and NaN, along with the tests for them, that's a
flaw in the language.  We can assume IEEE floating point at this
late date; it's been standard for twenty years and Java assumes it.

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

Pydev 1.3.6 Released

[Fabio Zadrozny]

Hi All,

Pydev and Pydev Extensions 1.3.6 have been released

Details on Pydev Extensions: http://www.fabioz.com/pydev
Details on Pydev: http://pydev.sf.net
Details on its development: http://pydev.blogspot.com

Release Highlights in Pydev Extensions:
-

* Bug-Fixes

Release Highlights in Pydev:
--

* Bug Fix: Builtins were not correctly used after specifying interpreter
(so, the builtins would not be available in completions/code-analysis).
* Patch (from Carl Robinson): PyLint severities can now be specified.



What is PyDev?
---

PyDev is a plugin that enables users to use Eclipse for Python and Jython
development -- making Eclipse a first class Python IDE -- It comes with many
goodies such as code completion, syntax highlighting, syntax analysis,
refactor, debug and many others.


Cheers,

--
Fabio Zadrozny
--
Software Developer

ESSS - Engineering Simulation and Scientific Software
http://www.esss.com.br

Pydev Extensions
http://www.fabioz.com/pydev

Pydev - Python Development Enviroment for Eclipse
http://pydev.sf.net
http://pydev.blogspot.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Voluntary Abstract Base Classes

[Eduardo \"EdCrypt\" O. Padoan]

On 6/29/07, Daniel Nogradi <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> Well, the short question is: what are they? I've read Guido's python
> 3000 status report on
> http://www.artima.com/weblogs/viewpost.jsp?thread=208549 where he
> mentions ABC's but don't quite understand what the whole story is
> about.

The story is at PEP 3119:
http://www.python.org/dev/peps/pep-3119/

> Anyone has good use cases?

The Rationale in the PEP may help you to imagine one.



-- 
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
-- 
http://mail.python.org/mailman/listinfo/python-list

Help needed in PyGTk

[senthil arasu]

Hi,
I am trying to render HTML in PyGTK widget but iam not getting the expected
result.
I would like to know whether PyGTK supports HTML rendering feature or not.

Please help me to solve this issue.

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

Re: Voluntary Abstract Base Classes

[James Stroud]

Daniel Nogradi wrote:
> Hi list,
> 
> Well, the short question is: what are they? I've read Guido's python
> 3000 status report on
> http://www.artima.com/weblogs/viewpost.jsp?thread=208549 where he
> mentions ABC's but don't quite understand what the whole story is
> about.
> 
> Anyone has good use cases?
> 
> Daniel

My interpretation of his description is that this is a way to check for 
quack likes a duck behavior.

Say I want a function to check if something behaves like a slice, but 
don't want to resort to checking for explicit inheritence, I might now 
have to do something like (factoring out the checking):


def is_slice_like(candidate):
   for att in 'start', 'stop', 'step', 'indices':
 if not hasattr(candidate, att):
   return False
   return True

def doit(anarg):
   if not is_slice_like(anarg):
 raise Exception, 'Must give something like a slice.'
   do_rest_of_it()


However, with an ABC, you could define what it means to be slice-like by 
defining a slice-like ABC (e.g. SliceLike) and then virtually inheriting 
from this ABC:


# assuming abstract inheritence syntax is the same as regular
class MySlice(SliceLike):
   # etc.

def doit(anarg):
   if not issubclass(anarg.__class__, SliceLike):
 raise Exception, 'Must give something SliceLike.'

def main():
   anarg = MySlice(1,2,3)
   doit(anarg)


With ABCs, the concept of slice-like is more formalized and transparent 
than the attribute checking done in is_slice_like and is far more 
flexible than explicit type checking.

The concept seems to be borrowed from Java interfaces.

But I'm ready to be corrected on my interpretation.

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

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Duncan Booth <[EMAIL PROTECTED]> writes:

>> A precondition of much of my Python code is that callers won't
>> squirrel away large numbers of tracebacks for long periods of time.  I
>> can live with that.  Another precondition of much of my code is that
>> the caller doesn't assume that it is thread-safe.  Another
>> precondition is that the caller doesn't assume that it is likely to
>> meet real-time constraints.  Another precondition is that the caller
>> doesn't need my functions to promise not to generate any garbage that
>> might call the GC to invoked.

> None of that is relevant.

Of course it is.  I said "large number of tracebacks" up there, and
you promptly ignored that precondition in your subsequent
counterexample.

> Have you ever seen any code looking roughly like this?

> def mainloop():
>while somecondition:
>   try:
>   dosomestuff()
>   except SomeExceptions:
>   handletheexception()

Of course.

> Now, imagine somewhere deep inside dosomestuff an exception is
> raised while you have a file open and the exception is handled in
> mainloop. If the loop then continues with a fresh call to
> dosomestuff the traceback object will continue to exist until the
> next exception is thrown or until mainloop returns.

It's typically okay in my software for a single (or a few) files to
remain open for longer than I might expect.  What it couldn't handle
is running out of file descriptors, or the like.  (Just like it
couldn't handle running out of memory.)  But that's not going to
happen with your counterexample.

If I were worried about a file or two remaining open too long, I'd
clear the exception in the mainloop above, after handling it.  Python
lets you do that, doesn't it?

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Steve Holden <[EMAIL PROTECTED]> writes:

> "Python" doesn't *have* any refcounting semantics.

I'm not convinced that Python has *any* semantics at all outside of
specific implementations.  It has never been standardized to the rigor
of your typical barely-readable language standards document.

> If you rely on the behavior of CPython's memory allocation and
> garbage collection you run the risk of producing programs that won't
> port tp Jython, or IronPython, or PyPy, or ...

> This is a trade-off that many users *are* willing to make.

Yes, I have no interest at the moment in trying to make my code
portable between every possible implementation of Python, since I have
no idea what features such implementations may or may not support.
When I code in Python, I'm coding for CPython.  In the future, I may
do some stuff in Jython, but I wouldn't call it "Python" -- it'd call
it "Jython".  When I do code for Jython, I'd be using it to get to
Java libraries that would make my code non-portable to CPython, so
portability here seems to be a red herring.

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Hrvoje Niksic <[EMAIL PROTECTED]> writes:

>> Generators aren't slower than hand-coded iterators in *Python*, but
>> that's because Python is a slow language.

> But then it should be slow for both generators and iterators.

Python *is* slow for both generators and iterators.  It's slow for
*everything*, except for cases when you can have most of the work done
within C-coded functions or operations that perform a lot of work
within a single call.  (Or, of course, cases where you are i/o
limited, or whatever.)

>> *Perhaps* there would be some opportunities for more optimization if
>> they had used a less general mechanism.)

> Or if the generators were built into the language and directly
> supported by the compiler.  In some cases implementing a feature is
> *not* a simple case of writing a macro, even in Lisp.  Generators may
> well be one such case.

You can't implement generators in Lisp (with or without macros)
without support for generators within the Lisp implementation.  This
support was provided as "stack groups" on Lisp Machines and as
continuations in Scheme.  Both stack groups and continuations are
slow.  I strongly suspect that if they had provided direct support for
generators, rather than indirectly via stack groups and continuations,
that that support would have been slow as well.

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Duncan Booth]

Douglas Alan <[EMAIL PROTECTED]> wrote:

>> Is one of your preconditions that no one will ever handle an
>> exception raised by your code or by their own code when it is
>> invoked by yours?
> 
> A precondition of much of my Python code is that callers won't
> squirrel away large numbers of tracebacks for long periods of time.  I
> can live with that.  Another precondition of much of my code is that
> the caller doesn't assume that it is thread-safe.  Another
> precondition is that the caller doesn't assume that it is likely to
> meet real-time constraints.  Another precondition is that the caller
> doesn't need my functions to promise not to generate any garbage that
> might call the GC to invoked.

None of that is relevant.

Have you ever seen any code looking roughly like this?

def mainloop():
   while somecondition:
  try:
  dosomestuff()
  except SomeExceptions:
  handletheexception()

Now, imagine somewhere deep inside dosomestuff an exception is raised while 
you have a file open and the exception is handled in mainloop. If the loop 
then continues with a fresh call to dosomestuff the traceback object will 
continue to exist until the next exception is thrown or until mainloop 
returns.

There is no 'squirrelling away' needed here. The point is that it is easy 
to write code which accidentally holds onto tracebacks. It is not 
reasonable to expect the caller to analyse all situations where the 
traceback object could continue to exist.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Steve Holden]

Douglas Alan wrote:
> Michele Simionato <[EMAIL PROTECTED]> writes:
> 
>>> I've written plenty of Python code that relied on destructors to
>>> deallocate resources, and the code always worked.
> 
>> You have been lucky:
> 
> No I haven't been lucky -- I just know what I'm doing.
> 
>> $ cat deallocating.py
>> import logging
>>
>> class C(object):
>> def __init__(self):
>> logging.warn('Allocating resource ...')
>>
>> def __del__(self):
>> logging.warn('De-allocating resource ...')
>> print 'THIS IS NEVER REACHED!'
>>
>> if __name__ == '__main__':
>> c = C()
>>
>> $ python deallocating.py
>> WARNING:root:Allocating resource ...
>> Exception exceptions.AttributeError: "'NoneType' object has no
>> attribute 'warn'" in > 0xb7b9436c>> ignored
> 
> Right.  So?  I understand this issue completely and I code
> accordingly.
> 
>> Just because your experience has been positive, you should not
>> dismiss the opinion who have clearly more experience than you on
>> the subtilities of Python.
> 
> I don't dismiss their opinion at all.  All I've stated is that for my
> purposes I find that the refcounting semantics of Python to be useful,
> expressive, and dependable, and that I wouldn't like it one bit if
> they were removed from Python.
> 
> Those who claim that the refcounting semantics are not useful are the
> ones who are dismissing my experience.  (And the experience of
> zillions of other Python programmers who have happily been relying on
> them.)
> 
> |>oug

"Python" doesn't *have* any refcounting semantics. If you rely on the 
behavior of CPython's memory allocation and garbage collection you run 
the risk of producing programs that won't port tp Jython, or IronPython, 
or PyPy, or ...

This is a trade-off that many users *are* willing to make.

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden
--- Asciimercial --
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
--- Thank You for Reading -

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

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Jean-Paul Calderone <[EMAIL PROTECTED]> writes:

>>On the other hand, in Python, you can be 100% sure that your files
>>will be closed in a timely manner without explicitly closing them, as
>>long as you are safe in making certain assumptions about how your code
>>will be used.  Such assumptions are called "preconditions", which are
>>an understood notion in software engineering and by me when I write
>>software.

> You realize that Python has exceptions, right?

Yes, of course.

> Have you ever encountered a traceback object?

Yes, of course.

> Is one of your preconditions that no one will ever handle an
> exception raised by your code or by their own code when it is
> invoked by yours?

A precondition of much of my Python code is that callers won't
squirrel away large numbers of tracebacks for long periods of time.  I
can live with that.  Another precondition of much of my code is that
the caller doesn't assume that it is thread-safe.  Another
precondition is that the caller doesn't assume that it is likely to
meet real-time constraints.  Another precondition is that the caller
doesn't need my functions to promise not to generate any garbage that
might call the GC to invoked.

If I had to write all my code to work well without making *any*
assumptions about what the needs of the caller might be, then my code
would have to be much more complicated, and then I'd spend more effort
making my code handle situations that it won't face for my purposes.
Consequently, I'd have less time to make my software have the
functionality that I actually require.

Regarding, specifically, tracebacks holding onto references to open
files -- have you considered that you may actually *want* to see the
file in the state that it was in when the exception was raised for the
purposes of debugging, rather than having it forcefully closed on you?

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Looking for an interpreter that does not request internet access

[Thorsten Kampe]

* Hrvoje Niksic (Fri, 29 Jun 2007 13:07:01 +0200)
> James Alan Farrell <[EMAIL PROTECTED]> writes:
> 
> > Hello,
> > I recently installed new anti-virus software and was surprised the
> > next time I brought up IDLE, that it was accessing the internet.
> >
> > I dislike software accessing the internet without telling me about it,
> > especially because of my slow dial up connection (there is no option
> > where I live), but also because I feel it unsafe.
> 
> When I start up IDLE, I get this message:
> 
> 
> Personal firewall software may warn about the connection IDLE
> makes to its subprocess using this computer's internal loopback
> interface.  This connection is not visible on any external
> interface and no data is sent to or received from the Internet.
> 
> 
> It would seem to explain the alarm you're seeing.

Actually it wouldn't. 127.0.0.1 is definitely not "the Internet" and 
it would make James' posting even mysterious...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Hrvoje Niksic]

Douglas Alan <[EMAIL PROTECTED]> writes:

>>>  The downside is that they are not quite as flexible as iterators
>>> (which can be hard to code) and generators, which are slow.
>
>> Why do you think generators are any slower than hand-coded iterators?
>
> Generators aren't slower than hand-coded iterators in *Python*, but
> that's because Python is a slow language.

But then it should be slow for both generators and iterators.

> *Perhaps* there would be some opportunities for more optimization if
> they had used a less general mechanism.)

Or if the generators were built into the language and directly
supported by the compiler.  In some cases implementing a feature is
*not* a simple case of writing a macro, even in Lisp.  Generators may
well be one such case.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Looking for an interpreter that does not request internet access

[Thorsten Kampe]

* James Alan Farrell (Tue, 26 Jun 2007 01:07:46 GMT)
> I recently installed new anti-virus software and was surprised the
> next time I brought up IDLE, that it was accessing the internet.
> 
> I dislike software accessing the internet without telling me about it,
> especially because of my slow dial up connection (there is no option
> where I live), but also because I feel it unsafe.
> 
> Can anyone recommend an interpreter that does not access the internet
> when it starts (or when it is running, unless I specifically write a
> program that causes it to do so, so as a browser)?

Sorry, but this is really ridiculous. When you start Idle it 
explicitly tells you


Personal firewall software may warn about the connection IDLE
makes to its subprocess using this computer's internal loopback
interface.  This connection is not visible on any external
interface and no data is sent to or received from the Internet.


You shouldn't use any kind of software (Antivirus or Personal 
Firewall) if you have no idea how it's working or can't interpret the 
messages they give.

If your Antivirus really told you that Idle is accessing the 
"Internet" than uninstall this crap.

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

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

"Chris Mellon" <[EMAIL PROTECTED]> writes:

>> On the other hand, in Python, you can be 100% sure that your files
>> will be closed in a timely manner without explicitly closing them, as
>> long as you are safe in making certain assumptions about how your code
>> will be used.  Such assumptions are called "preconditions", which are
>> an understood notion in software engineering and by me when I write
>> software.

> Next time theres one of those "software development isn't really
> engineering" debates going on I'm sure that we'll be able to settle
> the argument by pointing out that relying on *explicitly* unreliable
> implementation details is defined as "engineering" by some people.

The proof of the pudding is in it's eating.  I've worked on very large
programs that exhibited very few bugs, and ran flawlessly for many
years.  One managed the memory remotely of a space telescope, and the
code was pretty tricky.  I was sure when writing the code that there
would be a number of obscure bugs that I would end up having to pull
my hair out debugging, but it's been running flawlessly for more than
a decade now, without require nearly any debugging at all.

Engineering to a large degree is knowing where to dedicate your
efforts.  If you dedicate them to where they are not needed, then you
have less time to dedicate them to where they truly are.

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 16bit hash

[Paul Rubin]

Robin Becker <[EMAIL PROTECTED]> writes:
> whether it's any better than using the lowest bits I have no real
> idea. I suppose (sha being flavour of the month) I should really use

I think if you have more than a few fonts you really have to assign
the id's uniquely instead of using hashes, to avoid collisions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PEP 3107 and stronger typing (note: probably a newbie question)

[Paul Rubin]

Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> Nope, he just asserted something wrong. Static typing is for compiler
> optimization. Type checking is at most a side effect, and in some
> languages (at least C, C++ and Java) can be totally defeated (usually
> using typecasting).

  "Definitions of type system vary, but the following one due to
  Benjamin C. Pierce roughly corresponds to the current consensus in
  the programming language theory community:

[A type system is a] tractable syntactic method for proving the
absence of certain program behaviors by classifying phrases
according to the kinds of values they compute. (Pierce 2002)."

  -- http://en.wikipedia.org/wiki/Type_theory#Type_system

C and C++ are basically untyped languages.  Java casts can only
partially defeat its type system, so it's not untyped.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Shed Skin Python-to-C++ Compiler 0.0.21, Help needed

[felix seltzer]

does this project include support for pygtk type GUI's?

On 6/29/07, Mark Dufour <[EMAIL PROTECTED]> wrote:


Hi all,

I have just released version 0.0.22 of Shed Skin, an experimental
Python-to-C++ compiler. Among other things, it has the exciting new
feature of being able to generate (simple, for now) extension modules,
so it's much easier to compile parts of a program and use them (by
just importing them). Here's the complete changelog:

-support for generating simple extension modules (linux/windows; see
README)
-dos text format fix (long overdue)
-improved detection of dynamic types (avoid hanging on them)
-improved overloading (__nonzero__, __int__, __abs__ etc.)
-add str(ing).{capitalize, capwords, swapcase, center, ato*)
-fix string.maketrans
-several other minor bug fixes

For more details about Shed Skin and a collection of 27 programs, at a
total of about 7,000 lines, that it can compile (resulting in an
average speedup of about 39 times over CPython and 11 times over Psyco
on my computer), please visit the homepage at:

http://mark.dufour.googlepages.com

I could really use some help in pushing Shed Skin forward. Please try
the latest release and send in bug reports, or join the project via
the homepage.


Thanks,
Mark Dufour.


On 3/31/07, Mark Dufour <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I have recently released version 0.0.20 and 0.0.21 of Shed Skin, an
> optimizing Python-to-C++ compiler. Shed Skin allows for translation of
> pure (unmodified), implicitly statically typed Python programs into
> optimized C++, and hence, highly optimized machine language. Besides
> many bug fixes and optimizations, these releases add the following
> changes:
>
> -support for 'bisect', 'collections.deque' and 'string.maketrans'
> -improved 'copy' support
> -support for 'try, else' construction
> -improved error checking for dynamic types
> -printing of floats is now much closer to CPython
>
> For more details about Shed Skin and a collection of 27 programs, at a
> total of about 7,000 lines, that it can compile (resulting in an
> average speedup of about 39 times over CPython and 11 times over Psyco
> on my computer), please visit the homepage at:
>
> http://mark.dufour.googlepages.com
>
> I could really use more help it pushing Shed Skin further. Simple ways
> to help out, but that can save me lots of time, are to find smallish
> code fragments that Shed Skin currently breaks on, and to help
> improve/optimize the (C++) builtins and core libraries. I'm also
> hoping someone else would like to deal with integration with CPython
> (so Shed Skin can generate extension modules, and it becomes easier to
> use 'arbitrary' external CPython modules such as 're' and 'pygame'.)
> Finally, there may be some interesting Master's thesis subjects in
> improving Shed Skin, such as transforming heap allocation into stack-
> and static preallocation, where possible, to bring performance even
> closer to manual C++. Please let me know if you are interested in
> helping out, and/or join the Shed Skin mailing list.
>
>
> Thanks!
> Mark Dufour.
> --
> "One of my most productive days was throwing away 1000 lines of code"
> - Ken Thompson
>

Mark Dufour.
--
"One of my most productive days was throwing away 1000 lines of code"
- Ken Thompson
--
http://mail.python.org/mailman/listinfo/python-list

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

Voluntary Abstract Base Classes

[Daniel Nogradi]

Hi list,

Well, the short question is: what are they? I've read Guido's python
3000 status report on
http://www.artima.com/weblogs/viewpost.jsp?thread=208549 where he
mentions ABC's but don't quite understand what the whole story is
about.

Anyone has good use cases?

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

Re: How to close a program I execute with subprocess.Popen?

[A.T.Hofkamp]

On 2007-06-29, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I want to end the execution of the command when the user closes my
> application.
>
> Right now I'm using an object my_child of type subprocess.Popen to
> execute the command, inside a thread with an infinite loop where we
> constantly ask for its output.
>
> To end the program when the user closes the application, I send a
> SIGTERM to the process with pid my_child.pid using os.kill. But I also
> have to send a SIGTERM to my_child.pid + 1 because my_child.pid is the

Maybe that holds for a system recently started and mostly idle, but it need
not be the case. If you have more users active, and each user is forking
processes, (or one user is forking several processes concurrently), the order
of assigning process IDs is not defined.  
For systems that run for a longer time, unused process IDs are re-used, skipping
over process IDs that are still living.

> pid of /bin/sh -c which is the one which calls the command, because
> when I try to run Popen with shell=False, it sends an exception and
> says the file or directory doesn't exist.

The shell performs a search over PATH to find the command executable (ie it
maps 'ls' to '/bin/ls'). If you provide a full path to the command you are
starting, you don't need the shell.

> Anyone knows of a better way to close the command than using a
> SIGTERM? I just can't help myself thinking this is an ugly dirty hack.

In principle, you should only kill your own child processes, your child process
should handle its own childs (your grant child processes). SIGTERM is one way.
Another solution often adopted is to close the stdin of the child. This
notifies the child that no more data will arrive, and many commands react on
that message by terminating.  Try running

command < /dev/null

/dev/null is the empty input stream.

Last but not least, many commands do something special when sent -HUP. Look in
the manual page of the command for clean ways to close the command down.


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

Re: Set builtin lookups

[Alex Martelli]

Steve Holden <[EMAIL PROTECTED]> wrote:

> Marc 'BlackJack' Rintsch wrote:
> > In <[EMAIL PROTECTED]>, Evan Klitzke
> > wrote:
> > 
> >> I have a question about the internal representation of sets in Python.
> >> If I write some code like
> >>
> >> if x in some_list:
> >> do_something()
> >>
> >> the lookup for the in statement is O(n), where n is the number of
> >> elements in the list. Is this also true if I am using a set or are
> >> sets represented by a hash table?
> > 
> > Sets are implemented as hash tables.
> > 
> > Ciao,
> > Marc 'BlackJack' Rintsch
> 
> More importantly, no, neither sets nor dictionaries have O(N) lookup 
> costs. As an experiment or two can show.

The exception would be for objects with a bad or unlucky __hash__ that
happens to return the same value for every object:

class oops(object):
  def __hash__(self): return 123456

this one you might expect to produce O(N) behavior:-).


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

Re: What happens to a thread with an unhandled exception?

[Frank Millman]

On Jun 29, 2:51 pm, Frank Millman <[EMAIL PROTECTED]> wrote:
> Hi all
>
> I am doing something which works, but I have a gut feel that it cannot
> be relied upon. Can someone confirm this one way or the other.
[...]
> My worry is that the thread with the unhandled exception may
> eventually get garbage-collected, in which case the cleanup method
> will no longer be accessible. Could this happen, or does the thread
> stay in memory until termination of the main program?
>

I just noticed Diez's reply to a related question earlier today, where
he suggested wrapping the thread's run() method in a try/finally
construct. It works perfectly in my situation - if there is an
unhandled exception, my cleanup method is called before the exception
is raised. Thanks, Diez (even though you did not realise you were
helping me).

Frank

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

Re: Python's "only one way to do it" philosophy isn't good?

[Jean-Paul Calderone]

On Fri, 29 Jun 2007 09:56:14 -0400, Douglas Alan <[EMAIL PROTECTED]> wrote:
>"Chris Mellon" <[EMAIL PROTECTED]> writes:
>
>> You're arguing against explicit resource management with the argument
>> that you don't need to manage resources. Can you not see how
>> ridiculously circular this is?
>
>No.  It is insane to leave files unclosed in Java (unless you know for
>sure that your program is not going to be opening many files) because
>you don't even know that the garbage collector will ever even run, and
>you could easily run out of file descriptors, and hog system
>resources.
>
>On the other hand, in Python, you can be 100% sure that your files
>will be closed in a timely manner without explicitly closing them, as
>long as you are safe in making certain assumptions about how your code
>will be used.  Such assumptions are called "preconditions", which are
>an understood notion in software engineering and by me when I write
>software.

You realize that Python has exceptions, right?  Have you ever encountered
a traceback object?  Is one of your preconditions that no one will ever
handle an exception raised by your code or by their own code when it is
invoked by yours?

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

Application Crashing

[Robert Rawlins - Think Blue]

Hello Guys,

 

I find my application is freezing/crashing every now and then and it
becoming a bit of a frustration, so this morning I sat down to try and
locate the problem. After doing some debugging I think I've found the line
of code that causes my problem.

 

Print 'Read Results'

New = e.read()

Print 'Results Read'

 

The last thing the application does is print the words 'Read Results' which
leads me to think that the troublesome line is e.read(). This line is
reading the contents of a file object created by a popen command. This runs
without fail most of the time, but on a reasonably regular occurrence it
seems to crash my app.

 

I've tried wrapping it in a try/except, which I don't know much about and
that doesn't appear to make any difference, the app still crashes.

 

  print 'Reading Push'

  

  try:

 new = e.read()

  except:

 new = 'fault'

 

Print 'Results Read'

 

I'm not sure if this makes any difference, but this is all being run from
within a thread.

 

I need some help on handling this a little better to avoid my application
from dying on me, if anyone can offer some advice on what can be done it
would be greatly appreciated, I'm hoping just a small code solution will be
available.

 

Thanks guys, I look forward to hearing from you,

 

Rob

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

Re: Python's "only one way to do it" philosophy isn't good?

[Chris Mellon]

On 6/29/07, Douglas Alan <[EMAIL PROTECTED]> wrote:
> "Chris Mellon" <[EMAIL PROTECTED]> writes:
>
> > You're arguing against explicit resource management with the argument
> > that you don't need to manage resources. Can you not see how
> > ridiculously circular this is?
>
> No.  It is insane to leave files unclosed in Java (unless you know for
> sure that your program is not going to be opening many files) because
> you don't even know that the garbage collector will ever even run, and
> you could easily run out of file descriptors, and hog system
> resources.
>
> On the other hand, in Python, you can be 100% sure that your files
> will be closed in a timely manner without explicitly closing them, as
> long as you are safe in making certain assumptions about how your code
> will be used.  Such assumptions are called "preconditions", which are
> an understood notion in software engineering and by me when I write
> software.
>

Next time theres one of those "software development isn't really
engineering" debates going on I'm sure that we'll be able to settle
the argument by pointing out that relying on *explicitly* unreliable
implementation details is defined as "engineering" by some people.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Rappresenting infinite

[Robert Kern]

[EMAIL PROTECTED] wrote:
> On Thu, 28 Jun 2007 23:20:30 -0500
> Robert Kern <[EMAIL PROTECTED]> wrote:
> 
>> [EMAIL PROTECTED] wrote:
>>> Does it differ from the
>>> built-in inf?
>> What built-in inf?
> 
> $ python
> Python 2.4.4 (#2, Apr  5 2007, 20:11:18)
> [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
 a = 1.0e1000
 b = 2.0e1000
 a
> inf
 b
> inf
 a == b
> True
 type(a)
> 

Okay, I thought you meant that there was an actual symbol 'inf' in the builtins
or in a module somewhere.

>> No. You can make one that fits your requirements, though.
> 
> I am struggling to oversee the implications of design choices for inf
> behaviour - especially if it comes to comparison with float type inf.
> The type in my application contains a gmpy.mpq and a float that is
> always kept between -1 and 1 by adding to the mpq on each operation.
> I am looking for a robust inf design for this type. (Note: mpq and
> float inf do not compare).

You probably won't find one. You'll have to write it yourself.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

"Chris Mellon" <[EMAIL PROTECTED]> writes:

> You're arguing against explicit resource management with the argument
> that you don't need to manage resources. Can you not see how
> ridiculously circular this is?

No.  It is insane to leave files unclosed in Java (unless you know for
sure that your program is not going to be opening many files) because
you don't even know that the garbage collector will ever even run, and
you could easily run out of file descriptors, and hog system
resources.

On the other hand, in Python, you can be 100% sure that your files
will be closed in a timely manner without explicitly closing them, as
long as you are safe in making certain assumptions about how your code
will be used.  Such assumptions are called "preconditions", which are
an understood notion in software engineering and by me when I write
software.

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Dennis Lee Bieber <[EMAIL PROTECTED]> writes:

>   LISP and FORTH are cousins...

Not really.  Their only real similarity (other than the similarities
shared by most programming languages) is that they both use a form of
Polish notation.

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Michele Simionato <[EMAIL PROTECTED]> writes:

>> I've written plenty of Python code that relied on destructors to
>> deallocate resources, and the code always worked.

> You have been lucky:

No I haven't been lucky -- I just know what I'm doing.

> $ cat deallocating.py
> import logging
>
> class C(object):
> def __init__(self):
> logging.warn('Allocating resource ...')
>
> def __del__(self):
> logging.warn('De-allocating resource ...')
> print 'THIS IS NEVER REACHED!'
>
> if __name__ == '__main__':
> c = C()
>
> $ python deallocating.py
> WARNING:root:Allocating resource ...
> Exception exceptions.AttributeError: "'NoneType' object has no
> attribute 'warn'" in  0xb7b9436c>> ignored

Right.  So?  I understand this issue completely and I code
accordingly.

> Just because your experience has been positive, you should not
> dismiss the opinion who have clearly more experience than you on
> the subtilities of Python.

I don't dismiss their opinion at all.  All I've stated is that for my
purposes I find that the refcounting semantics of Python to be useful,
expressive, and dependable, and that I wouldn't like it one bit if
they were removed from Python.

Those who claim that the refcounting semantics are not useful are the
ones who are dismissing my experience.  (And the experience of
zillions of other Python programmers who have happily been relying on
them.)

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

How to close a program I execute with subprocess.Popen?

[revenant81]

I'm writing a program which has to execute a command, get its output
and show it on a treeview.
This command runs for a very long time.
I want to end the execution of the command when the user closes my
application.

Right now I'm using an object my_child of type subprocess.Popen to
execute the command, inside a thread with an infinite loop where we
constantly ask for its output.

To end the program when the user closes the application, I send a
SIGTERM to the process with pid my_child.pid using os.kill. But I also
have to send a SIGTERM to my_child.pid + 1 because my_child.pid is the
pid of /bin/sh -c which is the one which calls the command, because
when I try to run Popen with shell=False, it sends an exception and
says the file or directory doesn't exist.

Anyone knows of a better way to close the command than using a
SIGTERM? I just can't help myself thinking this is an ugly dirty hack.

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

Re: The Modernization of Emacs: terminology buffer and keybinding

[Joel J. Adamson]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> writes:

> I find Windows and its tools as frustrating as you seem to find
> Unix, but I strongly suspect that being shown the ropes by someone
> who understands and likes the system would help a lot.  

I feel the same way about Windows being frustrating, however I find
that having a Windows "expert" around helps very little.  Heck, *I*
was a Windows expert for as long as I was using it.  I always found it
to be totally opaque.  It always seemed like the only way to make
things work was to BUY something --- something that really offended
me.  It became clear to me quickly that Windows is basically a
billboard on a CRT --- the help files only told me to buy stuff, or
how "fun and easy" it was to do something, without actually saying how
to do it.  When I got XP and wanted to change my desktop theme ---
guess what?  They decided to start charging for that too.

With Windows I never got it; with Unix of any kind (linux, SunOS,
etc), I have felt like I got it right away.

Joel

-- 
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA  02114
(617) 643-1432
(303) 880-3109

*Joel's guide to sending attachments:
1.  put all the files you want to send in a folder and archive the
folder using tar, then compress it with gzip or bzip2
2.  please send me .pdf, .html, or text in place of Word documents:
http://www.gnu.org/philosophy/sylvester-response.html

*Did you know there's a FREE alternative to using word processors?
http://www.edafe.org/latex/
http://en.wikipedia.org/wiki/LaTeX
http://nitens.org/taraborelli/latex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Hrvoje Niksic <[EMAIL PROTECTED]> writes:

> Douglas Alan <[EMAIL PROTECTED]> writes:

>> I think you overstate your case.  Lispers understand iteration
>> interfaces perfectly well, but tend to prefer mapping fuctions to
>> iteration because mapping functions are both easier to code (they
>> are basically equivalent to coding generators) and efficient (like
>> non-generator-implemented iterators).  The downside is that they are
>> not quite as flexible as iterators (which can be hard to code) and
>> generators, which are slow.

> Why do you think generators are any slower than hand-coded iterators?

Generators aren't slower than hand-coded iterators in *Python*, but
that's because Python is a slow language.  In a fast language, such as
a Lisp, generators are like 100 times slower than mapping functions.
(At least they were on Lisp Machines, where generators were
implemented using a more generator coroutining mechanism [i.e., stack
groups].  *Perhaps* there would be some opportunities for more
optimization if they had used a less general mechanism.)

CLU, which I believe is the language that invented generators, limited
them to the power of mapping functions (i.e., you couldn't have
multiple generators instantiated in parallel), making them really
syntactic sugar for mapping functions.  The reason for this limitation
was performance.  CLU was a fast language.

|>oug
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: equality & comparison by default

[A.T.Hofkamp]

On 2007-06-29, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> En Thu, 28 Jun 2007 11:38:56 -0300, A.T.Hofkamp <[EMAIL PROTECTED]>  
> escribió:
>
>> The point I intended to make was that having a default __hash__ method on
>> objects give weird results that not everybody may be aware of.
>> In addition, to get useful behavior of objects in sets one should  
>> override
>> __hash__ anyway, so what is the point of having a default  
>> object.__hash__ ?
>
> __hash__ and equality tests are used by the dictionary implementation, and  
> the default implementation is OK for immutable objects. I like the fact  

I don't understand exactly how mutability relates to this.

The default __eq___ and __hash__ implementation for classes is ok if you never
have equivalent objects. In that case, == and 'is' are exactly the same
function in the sense that for each pair of arguments, they deliver the same
value.

This remains the case even if I mutate existing objects without creating
equivalent objects.

As soon as I create two equivalent instances (either by creating a duplicate at
a new address, or by mutating an existing one) the default __eq__ should be
redefined if you want these equivalent objects to announce themselves as
equivalent with the == operator.

> that I can use almost anything as dictionary keys without much coding.

Most data-types of Python have their own implementation of __eq__ and __hash__
to make this work. This is good, it makes the language easy to use. However for
home-brewn objects (derived from object) the default implementation of these
functions may easily cause unexpected behavior and we may be better off without
a default implementation for these functions. That would prevent use of such
objects in combination with == or in sets/dictionaries without an explicit
definition of the __eq__ and __hash__ functions, but that is not very bad,
since in many cases one would have to define the proper equivalence notion
anyway.

> This must always be true: (a==b) => (hash(a)==hash(b)), and the  
> documentation for __hash__ and __cmp__ warns about the requisites (but  
> __eq__ and the other rich-comparison methods are lacking the warning).

I don't know exactly what the current documentation says. One of the problems
is that not everybody is reading those docs. Instead they run a simple test
like "print set([Car(1),Car(2)])". That gives the correct result even if the
"(a==b) => (hash(a)==hash(b))" relation doesn't hold due to re-definition of
__eq__ but not __hash__ (the original designer never expected to use the class
in a set/dictionary for example) , and the conclusion is "it works". Then they
use the incorrect implementation for months until they discover that it doesn't
quite work as expected, followed by a long debugging session to find and
correct the problem.

Without default __eq__ and __hash__ implementations for objects, the program
would drop dead on the first experiment. While it may be inconvenient at that
moment (to get the first experiment working, one needs to do more effort), I
think it would be preferable to having an incorrect implementation for months
without knowing it. In addition, a developer has to think explicitly about his
notion of equivalence.

Last but not least, in the current implementation, you cannot see whether there
is a __eq__ and/or __hash__ equivalence notion. Lack of an explicit definition
does not necessarily imply there is no such notion.  Without default object
implementation this would also be uniqly defined.


Albert

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

Re: Help Needed in WxPython

[kyosohma]

On Jun 29, 7:50 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> senthil arasu wrote:
> > Hi,
> > Currently Iam integrating GUI Framework in Python.
> > As per design design,I need to use tab buttons to launch different HTML
> > pages in same frame(without launching seperate window ). I have already
> > tried with webbrowser class & WxPython GUI kit. Iam unable to get the
> > expected result.
>
> > I am wanted to be clear..!whether python supports my design or i need to
> > go for some other option
>
> > I need somebody to help me.
>
> > thanks
>
> Could you use the webbrowser module to control presentation of HTML pages?
>
> regards
>   Steve
> --
> Steve Holden+1 571 484 6266   +1 800 494 3119
> Holden Web LLC/Ltd  http://www.holdenweb.com
> Skype: holdenweb  http://del.icio.us/steve.holden
> --- Asciimercial --
> Get on the web: Blog, lens and tag the Internet
> Many services currently offer free registration
> --- Thank You for Reading -

senthil arasu,

If you're on Windows, you can use wxPython's
wx.lib.iewin.IEHtmlWindow, which wraps Internet Explorer somehow using
ActiveX. I've heard that some of the people in the wxPython user's
group are working on a more generic WebKit, but I don't think it's
done yet. Other than that, the only other module wxPython provides
that I'm aware of is wx.HtmlWindow which is pretty limited.

If the IEHtmlWindow doesn't work for you, then you're probably better
off using webbrowser to open the native browser with the specified
page from within Python/wxPython.

Mike

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

Re: It is not possible to create a recursive function over a pyGTK treeStore

[sebastien . abeille]

A little update : I finally found an example of a file browser using
gtkTreestore that parse the file system recursively :
http://www.koders.com/python/fidDB37D29C69F526E5EEA9A7D8B4FC5B87E92A78CC.aspx?s=filter_out_extensions#L113

I still need to check how it works, but I am sure that it will answer
my question.
Thank you


On 29 juin, 13:30, [EMAIL PROTECTED] wrote:
> Hello,
>
> I would like to create a minimalist file browser using pyGTK.
>
> Having read lot of tutorials, it seems to me that that in my case, the
> best solution is
> to have a gtk.TreeStore containing all the files and folders so that
> it would map the
> file system hierarchy.
>
> I wrote a recursive function that would go through the file system
> tree.
>
> My problem is that a sub-node of a gtk.TreeStore is not a
> gtk.TreeStore, but
> a gtk.TreeIter. And gtk.treeter has almost no functions I would be
> able to use (like "append")
> Therefore I can not explore the whole file system.
>
> Do you have another way so that I would be able to put all the file
> system hierarchy
> into a gtk.TreeStore?
> I was quite happy with my recursive solution ...
>
> ===
> code :
> #!/usr/bin/env python
> import pygtk
> pygtk.require('2.0')
> import gtk, gobject, os
>
> prefdir="/tmp/a"
>
> class InfoModele:
>
> def matchPathTreetoModelTree(self, path, treeStoreNode):
> files = [f for f in os.listdir(path) if f[0] <> '.']
> for i in range(len(files)):
> if os.path.isfile(path+'/'+files[i]):
> print path+'/'+files[i]+" is a file"
> treeStoreNode.append( None, 
> (path+'/'+files[i], None) )
> if os.path.isdir(path+'/'+files[i]): #is a directory, 
> go
> recursively
> print path+'/'+files[i]+" is a directory"
> mother = self.tree_store.append( None, 
> (path+'/'+files[i], None) )
> 
> self.matchPathTreetoModelTree(path+'/'+files[i], mother)
>
> def __init__(self):
> self.tree_store = gtk.TreeStore( gobject.TYPE_STRING,
> gobject.TYPE_STRING)
> path=prefdir
> self.matchPathTreetoModelTree(prefdir, self.tree_store)
>
> if __name__ == "__main__":
> i=InfoModele()
>
> =
> file system :
> a
> |-ab/
>|-abc/
>|-abcd
>
> 
> Program output :
> /tmp/a/ab is a directory
> /tmp/a/ab/abc is a file
> Traceback (most recent call last):
>   File "question.py", line 28, in 
> i=InfoModele()
>   File "question.py", line 25, in __init__
> self.matchPathTreetoModelTree(prefdir, self.tree_store)
>   File "question.py", line 20, in matchPathTreetoModelTree
> self.matchPathTreetoModelTree(path+'/'+files[i], mother)
>   File "question.py", line 16, in matchPathTreetoModelTree
> treeStoreNode.append( None, (path+'/'+files[i], None) )
> AttributeError: 'gtk.TreeIter' object has no attribute 'append'


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

Re: It is not possible to create a recursive function over a pyGTK treeStore

[Bruno Desthuilliers]

[EMAIL PROTECTED] a écrit :
> Hello,
> 
> I would like to create a minimalist file browser using pyGTK.
> 
> Having read lot of tutorials, it seems to me that that in my case, the
> best solution is
> to have a gtk.TreeStore containing all the files and folders so that
> it would map the
> file system hierarchy.
> 
> I wrote a recursive function that would go through the file system
> tree.
> 
> My problem is that a sub-node of a gtk.TreeStore is not a
> gtk.TreeStore, but
> a gtk.TreeIter. And gtk.treeter has almost no functions I would be
> able to use (like "append")
> Therefore I can not explore the whole file system.
> 
> Do you have another way so that I would be able to put all the file
> system hierarchy
> into a gtk.TreeStore?

Sorry, no anwser to that - I don't do much GUI programming. But asking 
on GTK mailing-list may be a good idea.

> I was quite happy with my recursive solution ...

A couple of comments on the code:

> #!/usr/bin/env python
> import pygtk
> pygtk.require('2.0')
> import gtk, gobject, os
> 
> 
> prefdir="/tmp/a"
> 
> class InfoModele:

Do yourself (and the world) a favour: use new-styles classes. And while 
we're at it, be consistant wrt/ naming:

   class InfoModel(object):

>   def matchPathTreetoModelTree(self, path, treeStoreNode):


You're of course free to use mixedCase, but unless this is a 
project-specific (or workplace-specific) convention, it might be better 
to stick to pep08 (all_lower_with_underscores). But if you choose 
mixedCase, at least be consistant
(ie : self.tree_store => self.treeStore)


>   files = [f for f in os.listdir(path) if f[0] <> '.']

could also use str.startswith here:

files = [f for f in os.listdir(path) \
  if not f.startswith('.')]

But I don't see the point of this listcomp when you could filter out 
special names in the for loop.

>   for i in range(len(files)):

Coming from a C-like language ?-)

The for loop in Python is much smarter than this. You don't have to use 
an explicit indexing, you can just iterate over the sequence, ie, 
instead of:

   for i in range(len(files)):
  the_file = files[i]
  do_something_with(the_file)

You can do:

   for the_file in files:
  do_something_with(the_file)

NB : if you need the index for any other reason, you can use enumerate(seq):

   for i, the_file in enumerate(files):
  print >> sys.stderr, "file #%s" % i
  do_something_with(the_file)


>   if os.path.isfile(path+'/'+files[i]):
>   print path+'/'+files[i]+" is a file"
>   treeStoreNode.append( None, (path+'/'+files[i], 
> None) )

My...

1/: use os.path.join()
2/: avoid recomputing the same value thrice or more, especially if 
within a loop
3/ (optional, but good to know): within loops, make the often used 
methods locals - this will save *a lot* of lookup time (since Python is 
highly dynamic, the compiler cannot optimize much here).
4/ stdout is for normal program outputs. Error messages, debug 
informations et al should go to stderr

>   if os.path.isdir(path+'/'+files[i]): 

Note that you should'nt do this test if the previous succeeded, since 
both are exclusive. IOW, use a elif.

 >  print path+'/'+files[i]+" is a directory"
 >  mother = self.tree_store.append(None, (path+'/'+files[i], None))

You certainly have an error here. If you're already in a subdirectory, 
you don't want to create the node on the root but on the parent's 
directory node - IOW, dont use self.tree_store, but treeStoreNode. Which 
allow to further simplify the code (cf below)

 >  self.matchPathTreetoModelTree(path+'/'+files[i], mother)
> 
>   def __init__(self):
>   self.tree_store = gtk.TreeStore( gobject.TYPE_STRING,
> gobject.TYPE_STRING)
>   path=prefdir

This should be an argument of the initializer

>   self.matchPathTreetoModelTree(prefdir, self.tree_store)
(snip)

Suggestion:

class InfoModel(object):
   def __init__(self, path):
 self.basepath = path
 self.treeStore = gtk.TreeStore(
  gobject.TYPE_STRING,
  gobject.TYPE_STRING
  )
 self.matchPathTreetoModelTree(path, self.treeStore)

   def matchPathTreetoModelTree(self, path, treeStoreNode):
 isdir = os.path.isdir
 join = os.path.join
 append= treeStoreNode.append
 recurse = self.matchPathTreetoModelTree

 filenames = os.listdir(path)
 for filename in filenames:
   if filename.startswith('.'):
 continue

   filepath = join(path, filename)
   # tracing for debug - assuming this will disappear
   # before going to prod, it's ok to repeat the call
   # to isdir() here
   print >> sys.stderr,  "%s is a %s" \
   % (filepath, ('file', 'dir')[isdir(filepath)])

   # nb: you may want to filter out non-regular files
   # lik

What happens to a thread with an unhandled exception?

[Frank Millman]

Hi all

I am doing something which works, but I have a gut feel that it cannot
be relied upon. Can someone confirm this one way or the other.

I have a multi-threaded server, which responds to client logins and
sets up a thread for each active session. A thread can stay active for
a long time.

I use a subclass of threading.Thread to handle the session, to which I
have added a number of attributes and methods, plus a reference back
to the main thread. When a user logs in, I call a 'setup' method in
the thread, which among other things updates a dictionary in the main
thread to record the fact that they are logged in. When they log out,
I call a 'cleanup' method in the thread, which among other things
removes their id from the dictionary of active logins.

It sometimes happens that an unhandled exception occurs in a thread.
The main thread continues, other threads are unaffected, and users can
continue to log in. However, the user that was active at the time
cannot log back in as their cleanup method was never called.

There are a number of ways to handle this, but I found one which seems
quite effective. In the dictionary of active logins, I store a
reference to the thread which is managing the session. If the user
tries to log back in, I can detect that the thread is in a suspended
state, and I use the reference to invoke the thread's cleanup method.
This removes the entry from the dictionary of active logins and
enables the user to log in again successfully.

My worry is that the thread with the unhandled exception may
eventually get garbage-collected, in which case the cleanup method
will no longer be accessible. Could this happen, or does the thread
stay in memory until termination of the main program?

Thanks for any pointers.

Frank Millman

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

Re: Help Needed in WxPython

[Steve Holden]

senthil arasu wrote:
> Hi,
> Currently Iam integrating GUI Framework in Python.
> As per design design,I need to use tab buttons to launch different HTML 
> pages in same frame(without launching seperate window ). I have already 
> tried with webbrowser class & WxPython GUI kit. Iam unable to get the 
> expected result.
> 
> I am wanted to be clear..!whether python supports my design or i need to 
> go for some other option
> 
> I need somebody to help me.
> 
> thanks
> 
Could you use the webbrowser module to control presentation of HTML pages?

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden
--- Asciimercial --
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
--- Thank You for Reading -

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

Re: Python's "only one way to do it" philosophy isn't good?

[Chris Mellon]

On 6/28/07, Douglas Alan <[EMAIL PROTECTED]> wrote:
> "Chris Mellon" <[EMAIL PROTECTED]> writes:
>
> > Obviously. But theres nothing about the with statement that's
> > different than using smart pointers in this regard.
>
> Sure there is -- smart pointers handle many sorts of situations, while
> "with" only handles the case where the lifetime of the object
> corresponds to the scope.
>

The entire point of RAII is that you use objects who's lifetime
corresponds with a scope. Smart pointers are an RAII technique to
manage refcounts, not a resource management technique in and of
themselves.


> > To the extent that your code ever worked when you relied on this
> > detail, it will continue to work.
>
> I've written plenty of Python code that relied on destructors to
> deallocate resources, and the code always worked.
>

This is roughly equivilent to someone saying that they don't bother
initializing pointers to 0 in C, because it's always worked for them.
The fact that it works in certain cases (in the C case, when you're
working in the debug mode of certain compilers or standard libs) does
not mean that code that relies on it working is correct.

> > There are no plans to replace pythons refcounting with fancier GC
> > schemes that I am aware of.
>
> This is counter to what other people have been saying.  They have been
> worrying me by saying that the refcounter may go away and so you may
> not be able to rely on predictable object lifetimes in the future.
>

Well, the official language implementation explicitly warns against
relying on the behavior you've been relying on. And of course, for the
purposes you've been using it it'll continue to work even if python
did eliminate refcounting - "soon enough" deallocation of non-time
sensitive resources. So I don't know what you're hollering about.

You're arguing in 2 directions here. You don't want refcounting to go
away, because you rely on it to close things exactly when there are no
more references. On the other hand, you're claiming that implicit
management and its pitfalls are fine because most of the time you
don't need the resource to be closed in a  deterministic manner.

If you're relying on refcounting for timely, guaranteed,
deterministic resource managment then your code is *wrong* already,
for the same reason that someone who assumes that uninitialized
pointers in C will be 0 is wrong.

If you're relying on refcounting for "soon enough" resource management
then it'll continue to work no matter what GC scheme python may or may
not move to.

> > Nothing about Pythons memory management has changed. I know I'm
> > repeating myself here, but you just don't seem to grasp this
> > concept.  Python has *never* had deterministic destruction of
> > objects. It was never guaranteed, and code that seemed like it
> > benefited from it was fragile.
>
> It was not fragile in my experience.  If a resource *positively*,
> *absolutely* needed to be deallocated at a certain point in the code
> (and occasionally that was the case), then I would code that way.  But
> that has been far from the typical case for me.
>

Your experience was wrong, then. It's fragile because it's easy for
external callers to grab refcounts to your objects, and it's easy for
code modifications to cause resources to live longer. If you don't
*care* about that, then by all means, don't control the resource
explicitly. You can continue to do this no matter what - people work
with files like this in Java all the time, for the same reason they do
it in Python. Memory and files are not the end all of resources.

You're arguing against explicit resource management with the argument
that you don't need to manage resources. Can you not see how
ridiculously circular this is?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: equality & comparison by default (was Re: Too many 'self' in python.That's a big flaw in this language.)

[Steve Holden]

A.T.Hofkamp wrote:
> On 2007-06-29, Steve Holden <[EMAIL PROTECTED]> wrote:
>> Just the same there are sound reasons for it, so I'd prefer to see you 
>> using "counterintuitive" or "difficult to fathom" rather than "broken" 
>> and "wrong".
> 
> You are quite correct, in the heat of typing an answer, my wording was too
> strong, I am sorry.
> 
No problem, I do the same thing myself ...

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden
--- Asciimercial --
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
--- Thank You for Reading -

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

Re: equality & comparison by default (was Re: Too many 'self' in python.That's a big flaw in this language.)

[A.T.Hofkamp]

On 2007-06-28, Roy Smith <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
>  "A.T.Hofkamp" <[EMAIL PROTECTED]> wrote:
>
>> In object oriented programming, objects are representations of values, and 
>> the
>> system shouldn't care about how many instances there are of some value, just
>> like numbers in math. Every instance with a certain value is the same as 
>> every
>> other instance with the same value.
>
> Whether two things are equal depends on the context.  Is one $10 note equal 
> to another?  It depends.
>
> If the context is a bank teller making change, then yes, they are equal.  
> What's more, there are lots of sets of smaller notes which would be equally 
> fungible.
>
> If the context is a district attorney showing a specific $10 note to a jury 
> as evidence in a drug buy-and-bust case, they're not.  It's got to be 
> exactly that note, as proven by a recorded serial number.
>
> In object oriented programming, objects are representations of the real 
> world.  In one case, the $10 note represents some monetary value.  In 
> another, it represents a piece of physical evidence in a criminal trial.  
> Without knowing the context of how the objects are going to be used, it's 
> really not possible to know how __eq__() should be defined.

I can see your point, but am not sure I agree. The problem is that OO uses
models tailored to an application, ie the model changes with each application.

In a bank teller application, one would probably not model the serial number,
just the notion of $10 notes would be enough, as in "Note(value)". The contents
of a cash register would then for example be a dictionary of Note() objects to
a count. You can merge two of such dictionaries, where the 'value' data of the
Note objects would be the equivalence notion.

In an evidence application one **would** record the serial number, since it is
a relevant distinguishing feature between notes, ie one would model Note(value,
serialnumber).
In this application the combination of value and serial number together defines
equivalence.

However, also in this situation we use values of the model for equivalence. If
we have a data base that relates evidence to storage location, and we would
like to know where a particular note was stored, we would compare Note objects
with each other based in the combination of value and serial number, not on
their id()'s.
 

> You tell me.  This is really just the "does 1 == (1 + 0j)" question in 
> disguise.  There's reasonable arguments to be made on both sides, but there 
> is no one true answer.  It depends on what you're doing.

While we don't agree on how OO programming handles equality (and it may well be
that there are multiple interpretations possible), wouldn't your argument also
not lead to the conclusion that it is better not to have a pre-defined __eq__
method?


Albert

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

It is not possible to create a recursive function over a pyGTK treeStore

[sebastien . abeille]

Hello,

I would like to create a minimalist file browser using pyGTK.

Having read lot of tutorials, it seems to me that that in my case, the
best solution is
to have a gtk.TreeStore containing all the files and folders so that
it would map the
file system hierarchy.

I wrote a recursive function that would go through the file system
tree.

My problem is that a sub-node of a gtk.TreeStore is not a
gtk.TreeStore, but
a gtk.TreeIter. And gtk.treeter has almost no functions I would be
able to use (like "append")
Therefore I can not explore the whole file system.

Do you have another way so that I would be able to put all the file
system hierarchy
into a gtk.TreeStore?
I was quite happy with my recursive solution ...



===
code :
#!/usr/bin/env python
import pygtk
pygtk.require('2.0')
import gtk, gobject, os


prefdir="/tmp/a"

class InfoModele:

def matchPathTreetoModelTree(self, path, treeStoreNode):
files = [f for f in os.listdir(path) if f[0] <> '.']
for i in range(len(files)):
if os.path.isfile(path+'/'+files[i]):
print path+'/'+files[i]+" is a file"
treeStoreNode.append( None, (path+'/'+files[i], 
None) )
if os.path.isdir(path+'/'+files[i]): #is a directory, go
recursively
print path+'/'+files[i]+" is a directory"
mother = self.tree_store.append( None, 
(path+'/'+files[i], None) )

self.matchPathTreetoModelTree(path+'/'+files[i], mother)

def __init__(self):
self.tree_store = gtk.TreeStore( gobject.TYPE_STRING,
gobject.TYPE_STRING)
path=prefdir
self.matchPathTreetoModelTree(prefdir, self.tree_store)

if __name__ == "__main__":
i=InfoModele()

=
file system :
a
|-ab/
   |-abc/
   |-abcd


Program output :
/tmp/a/ab is a directory
/tmp/a/ab/abc is a file
Traceback (most recent call last):
  File "question.py", line 28, in 
i=InfoModele()
  File "question.py", line 25, in __init__
self.matchPathTreetoModelTree(prefdir, self.tree_store)
  File "question.py", line 20, in matchPathTreetoModelTree
self.matchPathTreetoModelTree(path+'/'+files[i], mother)
  File "question.py", line 16, in matchPathTreetoModelTree
treeStoreNode.append( None, (path+'/'+files[i], None) )
AttributeError: 'gtk.TreeIter' object has no attribute 'append'

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

RE: Writing TGA image files?

[Adam Pletcher]

Sorry, I was replying via the email list and didn't realize it would thread 
that way.
 
- Adam



From: [EMAIL PROTECTED] on behalf of Ben Finney
Sent: Fri 6/29/2007 2:55 AM
To: python-list@python.org
Subject: Re: Writing TGA image files?



"Adam Pletcher" <[EMAIL PROTECTED]> writes:

> Does anyone have Python code for writing Targa (TGA) image files?

Please post your question as a new message, instead of a reply to an
existing thread that has nothing to do with the question you're
asking. Otherwise your message will be obscured among the many other
messages in the same thread.

--
 \  "I have never made but one prayer to God, a very short one: 'O |
  `\   Lord, make my enemies ridiculous!' And God granted it."  -- |
_o__) Voltaire |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list


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

Re: equality & comparison by default (was Re: Too many 'self' in python.That's a big flaw in this language.)

[A.T.Hofkamp]

On 2007-06-29, Steve Holden <[EMAIL PROTECTED]> wrote:
> Just the same there are sound reasons for it, so I'd prefer to see you 
> using "counterintuitive" or "difficult to fathom" rather than "broken" 
> and "wrong".

You are quite correct, in the heat of typing an answer, my wording was too
strong, I am sorry.


Albert

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

Re: Looking for an interpreter that does not request internet access

[Hrvoje Niksic]

James Alan Farrell <[EMAIL PROTECTED]> writes:

> Hello,
> I recently installed new anti-virus software and was surprised the
> next time I brought up IDLE, that it was accessing the internet.
>
> I dislike software accessing the internet without telling me about it,
> especially because of my slow dial up connection (there is no option
> where I live), but also because I feel it unsafe.

When I start up IDLE, I get this message:


Personal firewall software may warn about the connection IDLE
makes to its subprocess using this computer's internal loopback
interface.  This connection is not visible on any external
interface and no data is sent to or received from the Internet.


It would seem to explain the alarm you're seeing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python's "only one way to do it" philosophy isn't good?

[Hrvoje Niksic]

Douglas Alan <[EMAIL PROTECTED]> writes:

> I think you overstate your case.  Lispers understand iteration
> interfaces perfectly well, but tend to prefer mapping fuctions to
> iteration because mapping functions are both easier to code (they
> are basically equivalent to coding generators) and efficient (like
> non-generator-implemented iterators).  The downside is that they are
> not quite as flexible as iterators (which can be hard to code) and
> generators, which are slow.

Why do you think generators are any slower than hand-coded iterators?
Consider a trivial sequence iterator:

$ python -m timeit -s 'l=[1] * 100
class foo(object):
  def __init__(self, l):
self.l = l
self.i = 0
  def __iter__(self):
return self
  def next(self):
self.i += 1
try:
  return self.l[self.i - 1]
except IndexError:
  raise StopIteration
' 'tuple(foo(l))'
1 loops, best of 3: 173 usec per loop

The equivalent generator is not only easier to write, but also
considerably faster:

$ python -m timeit -s 'l=[1] * 100
def foo(l):
  i = 0
  while 1:
try:
  yield l[i]
except IndexError:
  break
i += 1
' 'tuple(foo(l))'
1 loops, best of 3: 46 usec per loop
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Shed Skin Python-to-C++ Compiler 0.0.21, Help needed

[Mark Dufour]

Hi all,

I have just released version 0.0.22 of Shed Skin, an experimental
Python-to-C++ compiler. Among other things, it has the exciting new
feature of being able to generate (simple, for now) extension modules,
so it's much easier to compile parts of a program and use them (by
just importing them). Here's the complete changelog:

-support for generating simple extension modules (linux/windows; see README)
-dos text format fix (long overdue)
-improved detection of dynamic types (avoid hanging on them)
-improved overloading (__nonzero__, __int__, __abs__ etc.)
-add str(ing).{capitalize, capwords, swapcase, center, ato*)
-fix string.maketrans
-several other minor bug fixes

For more details about Shed Skin and a collection of 27 programs, at a
total of about 7,000 lines, that it can compile (resulting in an
average speedup of about 39 times over CPython and 11 times over Psyco
on my computer), please visit the homepage at:

http://mark.dufour.googlepages.com

I could really use some help in pushing Shed Skin forward. Please try
the latest release and send in bug reports, or join the project via
the homepage.


Thanks,
Mark Dufour.


On 3/31/07, Mark Dufour <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I have recently released version 0.0.20 and 0.0.21 of Shed Skin, an
> optimizing Python-to-C++ compiler. Shed Skin allows for translation of
> pure (unmodified), implicitly statically typed Python programs into
> optimized C++, and hence, highly optimized machine language. Besides
> many bug fixes and optimizations, these releases add the following
> changes:
>
> -support for 'bisect', 'collections.deque' and 'string.maketrans'
> -improved 'copy' support
> -support for 'try, else' construction
> -improved error checking for dynamic types
> -printing of floats is now much closer to CPython
>
> For more details about Shed Skin and a collection of 27 programs, at a
> total of about 7,000 lines, that it can compile (resulting in an
> average speedup of about 39 times over CPython and 11 times over Psyco
> on my computer), please visit the homepage at:
>
> http://mark.dufour.googlepages.com
>
> I could really use more help it pushing Shed Skin further. Simple ways
> to help out, but that can save me lots of time, are to find smallish
> code fragments that Shed Skin currently breaks on, and to help
> improve/optimize the (C++) builtins and core libraries. I'm also
> hoping someone else would like to deal with integration with CPython
> (so Shed Skin can generate extension modules, and it becomes easier to
> use 'arbitrary' external CPython modules such as 're' and 'pygame'.)
> Finally, there may be some interesting Master's thesis subjects in
> improving Shed Skin, such as transforming heap allocation into stack-
> and static preallocation, where possible, to bring performance even
> closer to manual C++. Please let me know if you are interested in
> helping out, and/or join the Shed Skin mailing list.
>
>
> Thanks!
> Mark Dufour.
> --
> "One of my most productive days was throwing away 1000 lines of code"
> - Ken Thompson
>

Mark Dufour.
-- 
"One of my most productive days was throwing away 1000 lines of code"
- Ken Thompson
-- 
http://mail.python.org/mailman/listinfo/python-list

XML Parsing Help,

[Robert Rawlins - Think Blue]

Hello Chaps,

 

I'm looking for some help with XML parsing, I've been playing around with
this over the past few days and the only solution I can come up with seems
to be a little slow and also leaves what I think is a memory leak in my
application, which causes all kinds of problems. 

 

I have a very simple XML file which I need to loop over the elements and
extract the attribute information from, but the loop must be conditional as
the attributes must meet a certain criteria.

 

My current solution is using minidom, which I've read isn't one of the
better parsers, if anyone knows of any that are better for the task I would
love to hear it, the content is extracted regularly so whatever we chose
needs to be quick. Take a look at this brief example of the XML we're
dealing with:

 













 

Now what I need to do is loop through the 'event' elements and locate the
first one which has a type of '2' and return the name and location, if it is
unable to find any events with the type of 2 then I want it to return the
default event which is defined by the attributes of the schedules element.

 

I'm pretty inexperienced with parsing XML in python and could really use
some help selecting a parser and writing the code, I'm sure it's all quite
simple I'm just looking for the best solution.

 

Thanks guys,

 

Rob

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

Hooking __import__ when embedding the interpreter

[Stefan Bellon]

Hi all,

I am embedding the Python interpreter using the C API and extending it
using modules generated by SWIG. In order to guarantee consistency
about importing those modules, I would like to "hook" into the Python's
import statement and __import__ function and do some checks there.

I have experimented a bit already, but still have a few questions and
would be happy if anybody from the group could shed some light on those.

At present, I have the following test code:


#include 
#include 

static PyObject *
__import__(PyObject *self, PyObject *args)
{
char *name;
PyObject *globals = NULL;
PyObject *locals = NULL;
PyObject *fromlist = NULL;

if (!PyArg_ParseTuple
(args, "s|OOO:__import__", &name, &globals, &locals, &fromlist))
{
return NULL;
}

PyObject *m = PyDict_GetItemString(PyImport_GetModuleDict(), name);
if (m)
{
Py_INCREF(m);
return m;
}

if (!strcmp(name, "foobar")) // to be replaced by the consistency check!
{
PyErr_SetString
  (PyExc_ImportError, "cannot import module right now");
return NULL;
}

return PyImport_ImportModuleEx(name, globals, locals, fromlist);
}

static PyMethodDef import_hook[] =
{
{ "__import__", __import__ },
{ NULL, NULL }
};

int main()
{
Py_Initialize();

Py_InitModule("import_hook", import_hook);

PyObject_SetAttrString
  (PyImport_ImportModule("__builtin__"),
   "__import__",
   PyObject_GetAttrString
 (PyImport_ImportModule("import_hook"), "__import__"));

PyRun_InteractiveLoop(stdin, "");

Py_Finalize();
}


The code of __import__ above was inspired by the code of
builtin__import__ in Python/bltinmodule.c with the addition of the
early exit if the module is already loaded and the "consistency"
check which I reduced to some "cannot load module foobar" for ease
of the test case.


Now to my open questions.

1) The above code seems to work ok when using the "import" statement,
   but it does not when using the dynamic __import__ function. If using
   it that way, I get:

>>> sys=__import__("sys")
Traceback (most recent call last):
  File "", line 1, in ?
SystemError: new style getargs format but argument is not a tuple

   What am I missing in order to get the __import__ function covered
   as well?


2) Another point is, that I need to check _from where_ the module is
   imported. In fact, this is going to become part of the consistency
   check condition. How can I find out from which module the import
   was initiated?


3) My final point is related to 2) ... if I get to the module object,
   then how do I get at the source file name of that? I noticed that
   when a .pyc is available, then this is preferred. I'd like to get at
   the .py file itself. Is this available or do I just have to strip
   off the trailing 'c' (or 'o'?) if present (seems hacky to me).


I am very much looking forward to your suggestions!

Greetings,
Stefan

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

if - Jython - Windows

[wannaknow]

Hi all,

I am using an open source testing framework called Marathon that
uses Jython and i am trying to create a test that will:
- click a menu item
- select Login from the list
- a new window will popup
- insert username and password
- click OK

-*-*- at this point if the login was successful there is no message
to be displayed. If the login was unsuccessful though a popup
window pops up and displays some info about the login-error and an OK
button.
What i want to do is check whether there was an error window or not
and display a simple successful/unsuccessful message. Whats
happening though is that if the login was successful (meaning that the
pop-up window will not open), Marathon is waiting for the error
window,
stops and does not continue with ELIF or ELSE!

This Is The Test Code, any help would be greatly appreciated:


if window('Desktop'):
 click('login')
 select_menu('Login ...')

 if window('Please Login'):
  select('TextField', 'username')
  select('PasswordField', 'password')
  click('Ok')

  if window('Recent Error(s)'):
   click('OK')
   print "\n\nError Detected: Login Failed...\n\n"
  else:
   print "\n\nSuccessfull Login...\n\n"
  close()

 close()

close()

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

Re: socket on cygwin python

[bacon . chao]

On Jun 26, 12:49 am, Jason Tishler <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 25, 2007 at 01:53:18PM +0100, Michael Hoffman wrote:
> > [EMAIL PROTECTED] wrote:
> > > I've installed cygwin with latest python 2.5.1, but it seems that the
> > > socket lib file do NOT support IPv6(cygwin\lib\python2.5\lib-dynload
> > > \_socket.dll), what can I do if I want to use IPv6?
>
> > I don't think Cygwin supports IPv6.
>
> That was my impression too and seems to be substantiated by the
> following:
>
>http://win6.jp/Cygwin/index.html
>
> Jason
>
> --
> PGP/GPG Key:http://www.tishler.net/jason/pubkey.ascor key servers
> Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

Got it! Thank you very much, Jason, both Michael.
I've chosen to be a Linuxer not only to solve this. :)

Ming

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

Re: Collections of non-arbitrary objects ?

[Bruno Desthuilliers]

walterbyrd a écrit :
>> Did you try to sort a tuple ?
>>
>>  >>> (1, "aaa").sort()
>> Traceback (most recent call last):
>>File "", line 1, in ?
>> AttributeError: 'tuple' object has no attribute 'sort'
> 
> I can do this:
> 
 x = (3,2,1)
 x = tuple(sorted(list(x)))
 >
> Which, although senseless, effectively sorts the x tuple.

Err...

> But, you are
> right, I am not really sorting the tuple,

Indeed.

> I'm sorting a list, which
> has been made from the tuple, then changing it back to a tuple.

Exactly. You're in fact *creating* a new tuple - how you do it is 
somewhat irrelevant. This is certainly not the same thing as in-place 
sorting.

 From a purely practical POV, using tuples as "frozen lists" can 
sometimes make sens - be it for micro-optimization (tuples are cheaper 
than lists). But still, you'll find that in most cases(with most==almost 
always), tuples are used for (eventually heterogenous) data *where the 
order is significant* (fields in a db row, argument list, base classes 
lists, 2D or 3D points, etc), and can not be changed without changing 
the semantic of the data, while lists are used to collect (more or less) 
homogenous data where the order doesn't impact the semantic of the data 
(which is one of the reasons why list can be sorted and tuples cannot). 
As a matter of fact, a dict can be build from a list of (key,value) 
tuples - and it's obvious that the order of the elements in each tuple 
is significant, while the order of tuples in the list is not.

HTH


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

Re: Python & MySQL problem with input to table..!

[hiroc13]

Thanks It is working!

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

Re: Writing TGA image files?

[Campbell Barton]

Ben Finney wrote:
> "Adam Pletcher" <[EMAIL PROTECTED]> writes:
> 
>> Does anyone have Python code for writing Targa (TGA) image files?
> 
> Please post your question as a new message, instead of a reply to an
> existing thread that has nothing to do with the question you're
> asking. Otherwise your message will be obscured among the many other
> messages in the same thread.
> 

This blender script writes a tga with python only functions.

http://projects.blender.org/plugins/scmsvn/viewcvs.php/trunk/blender/release/scripts/uv_export.py?root=bf-blender&view=markup

-- 
Campbell J Barton (ideasman42)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python & MySQL problem with input to table..!

[Justin Ezequiel]

On Jun 29, 4:26 pm, hiroc13 <[EMAIL PROTECTED]> wrote:
> >>> import MySQLdb
> >>> db = MySQLdb.connect (host = "localhost", user = "root", passwd = "pass", 
> >>> db = "base1")
> >>> c = db.cursor ()
> >>> c.execute(""" INSERT INTO table1 (prvo, drugo) VALUES ('test', '1') """)
> >>> c.execute("SELECT * FROM table1")
> >>> res = c.fetchall ()
> >>> print res
>
> When I start this code I get ((15L, 'test', 1L),) on the screen but if
> I first execute this:
>
> >>> import MySQLdb
> >>> db = MySQLdb.connect (host = "localhost", user = "root", passwd = "pass", 
> >>> db = "base1")
> >>> c = db.cursor ()
> >>> c.execute(""" INSERT INTO table1 (prvo, drugo) VALUES ('test', '1') """)
>
>  this write to table1
> and now this:
>
> >>> Import MySQLdb
> >>> db = MySQLdb.connect (host = "localhost", user = "root", passwd = "pass", 
> >>> db = "base1")
> >>> c = db.cursor ()
> >>> c.execute("SELECT * FROM table1")
> >>> res = c.fetchall ()
> >>> print res
>
> I get only this: "()" - the table1 is empty ... I write 10 times same
> thing to table... only PRIMARY KEY is change
>
> WHY

try a `db.commit()` after the INSERT


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

Re: Getting some element from sets.Set

[Raymond Hettinger]

>  $ python -m timeit -s "s = set('abcdef')" "x = iter(s).next()"
>  100 loops, best of 3: 0.399 usec per loop
>
>  $ python -m timeit -s "s = set('abcdef')" "x = s.pop(); s.add(x)"
>  100 loops, best of 3: 0.339 usec per loop
>
> So it looks like it's more efficient to use s.pop() + s.add().


There's a faster, cleaner way:

>python -m timeit -s "s = set('abcdef')" "x = iter(s).next()"
100 loops, best of 3: 0.539 usec per loop

>python -m timeit -s "s = set('abcdef')" "x = s.pop(); s.add(x)"
100 loops, best of 3: 0.465 usec per loop

>python -m timeit -s "s = set('abcdef')" "for x in s: break"
100 loops, best of 3: 0.175 usec per loop


FWIW, the latter approach is general purpose and works with any
iterable (useful for reading the first line of file objects for
example).


Raymond

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

Python & MySQL problem with input to table..!

[hiroc13]

>>> import MySQLdb
>>> db = MySQLdb.connect (host = "localhost", user = "root", passwd = "pass", 
>>> db = "base1")
>>> c = db.cursor ()
>>> c.execute(""" INSERT INTO table1 (prvo, drugo) VALUES ('test', '1') """)
>>> c.execute("SELECT * FROM table1")
>>> res = c.fetchall ()
>>> print res

When I start this code I get ((15L, 'test', 1L),) on the screen but if
I first execute this:

>>> import MySQLdb
>>> db = MySQLdb.connect (host = "localhost", user = "root", passwd = "pass", 
>>> db = "base1")
>>> c = db.cursor ()
>>> c.execute(""" INSERT INTO table1 (prvo, drugo) VALUES ('test', '1') """)

 this write to table1
and now this:

>>> Import MySQLdb
>>> db = MySQLdb.connect (host = "localhost", user = "root", passwd = "pass", 
>>> db = "base1")
>>> c = db.cursor ()
>>> c.execute("SELECT * FROM table1")
>>> res = c.fetchall ()
>>> print res

I get only this: "()" - the table1 is empty ... I write 10 times same
thing to table... only PRIMARY KEY is change

WHY

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

Re: Writing TGA image files?

[Ben Finney]

"Adam Pletcher" <[EMAIL PROTECTED]> writes:

> Does anyone have Python code for writing Targa (TGA) image files?

Please post your question as a new message, instead of a reply to an
existing thread that has nothing to do with the question you're
asking. Otherwise your message will be obscured among the many other
messages in the same thread.

-- 
 \  "I have never made but one prayer to God, a very short one: 'O |
  `\   Lord, make my enemies ridiculous!' And God granted it."  -- |
_o__) Voltaire |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Subprocess with and without shell

[James T. Dennis]

George Sakkis <[EMAIL PROTECTED]> wrote:
> On May 15, 5:30 am, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:

>> George Sakkis <[EMAIL PROTECTED]> wrote:
>>>  I'm trying to figure out why Popen captures the stderr of a specific
>>>  command when it runs through the shell but not without it. IOW:

>>>  cmd = [my_exe, arg1, arg2, ..., argN]
>>>  if 1: # this captures both stdout and stderr as expected
>>>  pipe = Popen(' '.join(cmd), shell=True, stderr=PIPE, stdout=PIPE)
>>>  else: # this captures only stdout
>>>  pipe = Popen(cmd, shell=False, stderr=PIPE, stdout=PIPE)

>>>  # this prints the empty string if not run through the shell
>>>  print "stderr:", pipe.stderr.read()
>>>  # this prints correctly in both cases
>>>  print "stdout:", pipe.stdout.read()

>>>  Any hints ?

>> Post an example which replicates the problem!

> I would, but the specific executable being spawned is not a python
> script, it's a compiled binary (it's not an extension module either;
> it's totally unrelated to python). I don't claim there is a bug or
> anything suspicious about Popen, but rather I'd like an explanation of
> how can a program display different behavior depending on whether it
> runs through the shell or not.

> George

 Well, I would try inspecting your environment ... in the shell
 and from within your Python process.  See if there's anything
 there.

 If run a command via an interactive shell and it behaves differently
 when run via Popen then see if perhaps it's doing something like
 checking to see if it's stdin, or stdout are TTYs (using the C
 library functions like isatty() for example).  You might try
 running the program under a Pexpect rather than SubProcess (since
 Pexpect will run the process with it's std* descriptors connected
 to pty devices).  Alternatively try running the program in a shell
 pipeline to see if it behaves more like you're seeing when you run
 it under Python.  (Since running it in the middle of a pipeline,
 perhaps with 2>&1 as well, is ensuring that all of the std* descriptors
 are connected to pipes.  (You could also run with 2>/tmp/some.FIFO
 after doing a mknod p /tmp/some.FIFO (Linux) or mkfifo /tmp/some.FIFO
 (BSD) to create the named pipe, of course).

 If none of that worked ... try running the program under stace,
 truss, ktrace or whatever system call tracing facility your OS
 provides ... or under gdb.




-- 
Jim Dennis,
Starshine: Signed, Sealed, Delivered

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

RE: Vista 64 + Python2.5 + wxpython 28 issue

[Simon Roses Femerling]

Hello Martin,

Thanks for your reply.

There was no need for me to use 64 so I have switched back to 32 and works
fine.

Python is not ready for the 64 world yet ;)

Sincerely,

SRF

-Original Message-
From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED] 
Sent: jueves, 28 de junio de 2007 23:25
To: Simon Roses Femerling
Cc: python-list@python.org
Subject: Re: Vista 64 + Python2.5 + wxpython 28 issue

> Is there any 64 version installer or do I need to build myself ?

There are hardly AMD64 versions of *anything* but the base Python
distribution. I strongly advise to use the 32-bit version on AMD64
(in fact, I see little reason to run Win64 at all unless you have
more that 4GiB in the box, or unless you are developing a software
product that you explicitly target for Win64).

If you absolutely need to run 64-bit code, be prepared to compile
everything for yourself, and be prepared that it won't work out
of the box, and cost you many person days to fix and debug. Never
forget to feed back the fixes you make to the respective authors
of the open source software.

Notice that you won't just need a 64-bit version of wxpython,
but also such versions of all underlying libraries wxpython
happens to be build on.

Regards,
Martin


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