deselect an iterm in ListBox wxPython

[Bailu]

Hi,

   I am a newbie in wxPython and doing a program with ListBox,
I want to select and deselect items in this box,
I have use

self.devlist = wx.ListBox(self, style=wx.LB_MULTIPLE)
self.Bind(wx.EVT_LISTBOX, self.select_dev, self.devlist)

to create this box, but don't know how to implement self.select_dev
to find out which one is clicked

deselect it, if it was selected  ( this is not working at default)
select it, if it was not (toggle)

The default behavior is, the selection is increasing, I can't deselect
any of them.

Thanks.

Lingyun

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

Re: Destruction of generator objects

[Kay Schluehr]

On Aug 9, 1:14 am, Stefan Bellon <[EMAIL PROTECTED]> wrote:
> On Wed, 08 Aug, MRAB wrote:
> > Simple! :-)
>
> Sorry, I forgot to mention that I am forced to using Python 2.4.
>
> --
> Stefan Bellon

It doesn't matter. You can use try...finally as well in Python 2.4.
It's just not possible to use except and finally clauses in one
statement such as:

try:
1/0
except ZeroDivisionError:
print "incident!"
finally:
print "cleanup"

However in theory you don't really need finally but you can simulate
it using nested try...except statements:

-

try:
try:
1/0
try:
print "cleanup"
except Exception:
raise FinallyException( sys.exc_info() )
except ZeroDivisionError:
print "incident!"
try:
print "cleanup"
except Exception:
raise FinallyException( sys.exc_info() )
except Exception:
exc_cls, exc_value, exc_tb = sys.exc_info()
if exc_cls == FinallyException:
fin_exc_cls, fin_exc_value, fin_exc_tb = exc_value[0]
raise fin_exc_cls, fin_exc_value, fin_exc_tb
else:
print "cleanup"
except Exception:
raise FinallyException( sys.exc_info() )
raise exc_cls, exc_value, exc_tb

---

Note that this expression is regenerated from the above
try...except..finally statement using Py25Lite ( see [1],[2] ) which
is a tool used to provide some Python 2.5 constructs for programmers
working with Python 2.4.

[1] http://www.fiber-space.de/EasyExtend/doc/EE.html
[2] http://www.fiber-space.de/EasyExtend/doc/Py25Lite/Py25Lite.html

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

Re: The Future of Python Threading

[Bryan Olson]

Justin T. wrote:
> True, but Python seems to be the *best* place to tackle this problem,
> at least to me. It has a large pool of developers, a large standard
> library, it's evolving, and it's a language I like :). Languages that
> seamlessly support multi-threaded programming are coming, as are
> extensions that make it easier on every existent platform. Python has
> the opportunity to lead that change.

I have to disagree. A dynamic scripting language, even a great
one such as Python, is not the vehicle to lead an advance of
pervasive threading. The features that draw people to Python
do not play nicely with optimizing multi-core efficiency; they
didn't play all that well with single-core efficiency either.
Python is about making good use of our time, not our machines'
time.

Finer-grain locking sounds good, but realize how many items
need concurrency control. Python offers excellent facilities
for abstracting away complexity, so we programmers do not
mentally track all the possible object interactions at once.
In a real application, objects are more intertwingled than
we realize. Whatever mistakes a Python programmer makes,
the interpreter must protect its own data structures
against all possible race errors.

Run-time flexibility is a key Python feature, and it
necessarily implies that most bindings are subject to
change. Looking at a Python function, we tend to focus on
the named data objects, and forget how many names Python
is looking up at run time. How often do we take and release
locks on all the name-spaces that might effect execution?

The GIL both sucks and rocks. Obviously cores are becoming
plentiful and the GIL limits how we can exploit them. On
the other hand, correctness must dominate efficiency. We
lack exact reasoning on what we must lock; with the GIL,
we err on the side of caution and correctness. Instead of
trying to figure out what we need to lock, we default to
locking everything, and try to figure out what we can
safely release.

[Steve Holden:]
>> Be my guest, if it's so simple.
>>
> I knew somebody was going to say that! I'm pretty busy, but I'll see
> if I can find some time to look into it.

If you want to lead fixing Python's threading, consider
first delivering a not-so-grand but definite
improvement. Have you seen how the 'threading' module
in Python's standard library implements timeouts?


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

question: howto transfer objects between server and client?

[OpenPavilion]

Hello community,

maybe one of you can help me out with a question regarding the
transfer of objects betwen client an server:
I have three files:

### ClassA.py ###
class ClassA:
def setA(self, newA):
self.a = newA
def getA(self):
return self.a

### client.py ###
import xmlrpclib
from ClassA import *
a = ClassA()
a.setA(4711)
server = xmlrpclib.ServerProxy("http://localhost:";)
print server.getA(a)# <= here I would like to hand over an
object

### server.py ###
import SimpleXMLRPCServer
from ClassA import *
class Handler:
def getA(self, aClass):
return aClass.getA()   # <- XMLRPC only transports simple types 
and
dictionaries, but no objects
handler_object = Handler()
server = SimpleXMLRPCServer.SimpleXMLRPCServer(("localhost", ))
server.register_instance(handler_object)
print "Listening on port "
server.serve_forever()


The problem is, that though I hand a ClassA object to the XMLRPC
server, the server only receives a dictionary (only transfering simple
objects is a XMLRPC feature: http://docs.python.org/lib/module-xmlrpclib.html)

Since XMLRPC has limited features:  Is there any other server/client
technique to transfer objects (not strings, or dictionaries, but self
defined object types) ?

Regards
Bernd

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

Re: question: howto transfer objects between server and client?

[Irmen de Jong]

OpenPavilion wrote:

> Since XMLRPC has limited features:  Is there any other server/client
> technique to transfer objects (not strings, or dictionaries, but self
> defined object types) ?

Take a look at Pyro;  http://pyro.sourceforge.net

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

python 2.5 bug

[vedrandekovic]

Hello,

I was install Python 2.5 and uninstall Python 2.4 now I cannot run my
scripts, only from idle

What should I do?


Regards,
Vedran

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

Re: question: howto transfer objects between server and client?

[OpenPavilion]

On 11 Aug., 11:21, Irmen de Jong <[EMAIL PROTECTED]> wrote:
> OpenPavilion wrote:
> > Since XMLRPC has limited features:  Is there any other server/client
> > technique to transfer objects (not strings, or dictionaries, but self
> > defined object types) ?
>
> Take a look at Pyro;  http://pyro.sourceforge.net
>
> --Irmen

Thanks Irmen,

just found out, that if I use "pickle.dumps(object)" (on client side)
and "pickle.loads(object)" (on server side) before and after sending,
I have access to the object.

I love this python language !
Python is a really, really nice language and I often find that the
solution is easier as I thought in the first place ...

Thanks anyway !!
Regards
Bernd

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

Re: python 2.5 bug

[vedrandekovic]

On 11 kol, 11:59, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote:
> > I was install Python 2.5 and uninstall Python 2.4 now I cannot run my
> > scripts, only from idle
>
> > What should I do?
>
> Install 2.4 again.  Both can be installed in parallel.
>
> Ciao,
> Marc 'BlackJack' Rintsch

I need python 2.5 for work becose python 2.4 module tokenizer has no
attribute "untokenize"

Regards,
Vedran

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

Re: Destruction of generator objects

[Stefan Bellon]

On Sat, 11 Aug, Kay Schluehr wrote:
> On Aug 9, 1:14 am, Stefan Bellon <[EMAIL PROTECTED]> wrote:

> > Sorry, I forgot to mention that I am forced to using Python 2.4.

> It doesn't matter. You can use try...finally as well in Python 2.4.
> It's just not possible to use except and finally clauses in one
> statement such as:

[snip]

The problem is yield inside try-finally which is not possible in 2.4.

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

Re: python 2.5 bug

[Marc 'BlackJack' Rintsch]

On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote:

> I was install Python 2.5 and uninstall Python 2.4 now I cannot run my
> scripts, only from idle
> 
> What should I do?

Install 2.4 again.  Both can be installed in parallel.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Modernization of Emacs: keyboard shortcuts pain

[Xah Lee]

The following is a FAQ from emacs modernization
http://xahlee.org/emacs/modernization.html

Q: Emacs's undo is superior, because the prevalent Undo/Redo system
actually loss info.

A: Emac's undo is very confusing and does not have a Redo command. To
redo after a undo, people are told to type something then do a undo.
Long time emacs user argue that it is technically superior because it
lets user to revert to any possible state of the past.

A practical problem with the way of emacs undo is that it repeats the
states in the action record. In the prevalent undo model, the action
record is linear, and each entry is unique. A user can easily arrive
at a desired previous state using undo and redo. In emacs's model, it
traverses the queue back and forth (or add existing states to the
stack). It is hard for a user to know when to do undo or do "some
random typing followed by undo" to get to the state he wants. In
particular, once a person did more than once of "some random typing
followed by undo", the undo record becomes too convoluted for a person
to keep in mind and often the undo action becomes useless at that
point.

If you take a survey among programers who use emacs for at least 1
year, perhaps more than 90% are confused by emacs's undo model and do
not find it useful. If you take a survey of software users other than
emacs, i do not think anyone will report their software's undo lacks
something to be desired.

It is reasonable to argue, that people work better with a simple undo/
redo model. Undo is practically used to erase a mistake or doing a
simple one-time revision. Once a user did a sequence of undos and
redos, we can assume that he arrived at a satisfactory point and
intends to start fresh from that point. If he needs extra revision
control, a more proper mechanism, one that people actually use, is to
revert to the saved version.

  Xah
  [EMAIL PROTECTED]
  http://xahlee.org/

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

Re: The Future of Python Threading

[Cameron Laird]

In article <[EMAIL PROTECTED]>,
Seun Osewa  <[EMAIL PROTECTED]> wrote:
>> I think I've heard Guido say the last attempt at removing the Global
>> Interpreter Lock (GIL) resulted in a Python that was much slower...
>
>What is it about Python that makes a thread-safe CPython version much
>slower?  Why doesn'ttrue threading slow down other languages like Perl
>and Java?
>
>I'm thinking it might be the reference counting approach to memory
>management... but what do you guys think is the reason?
>

Crudely, Perl threading is fragile, and Java requires
coding at a lower level.

Memory management is indeed important, and arguably 
deserves at least as much attention as multi-core
accomodations.  I know of no easy gains from here
on, just engineering trade-offs.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Future of Python Threading

[Cameron Laird]

In article <[EMAIL PROTECTED]>,
Chris Mellon <[EMAIL PROTECTED]> wrote:
.
.
.
>There's nothing "undocumented" about IPC. It's been around as a
>technique for decades. Message passing is as old as the hills.
.
.
.
... and has significant successes to boast, including
the highly-reliable and high-performing QNX real-time
operating system, and the already-mentioned language
Erlang.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Destruction of generator objects

[Kay Schluehr]

On Aug 11, 12:16 pm, Stefan Bellon <[EMAIL PROTECTED]> wrote:
> On Sat, 11 Aug, Kay Schluehr wrote:
> > On Aug 9, 1:14 am, Stefan Bellon <[EMAIL PROTECTED]> wrote:
> > > Sorry, I forgot to mention that I am forced to using Python 2.4.
> > It doesn't matter. You can use try...finally as well in Python 2.4.
> > It's just not possible to use except and finally clauses in one
> > statement such as:
>
> [snip]
>
> The problem is yield inside try-finally which is not possible in 2.4.
>
> --
> Stefan Bellon

Oh, yeah... i overlooked this.

Honestly, I'd recommend wrapping the generator into a function object,
create the resource on construction ( or pass it ) and destroy it
implementing __del__.

def gen_value(self):
while True:
yield self.iter.next()

class GeneratorObj(object):
def __init__(self, obj, gen):
self.iter = make_iter(obj)
self.gen  = gen(self)

def __del__(self):
destroy(self.iter)

def next(self):
return self.gen.next()


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

Re: cookielib

[John J. Lee]

Boris Ozegovic <[EMAIL PROTECTED]> writes:

> Hi
>
> I have HTTP client which accepts cookies.  If client allready has cookie,
> but that cookie has expired, server sends him new cookie, and in response
> object Set-Cookie: header everything is fine, but if I reload request,
> client sends expired cookie, and not the new one.  In cookiejar there is
> only new and valid cookie, and if I use regular browser everything is fine.
> The code is following:
>
> urlopen = urllib2.urlopen
> Request = urllib2.Request
> cj = cookielib.LWPCookieJar()
> COOKIEFILE = 'cookies.lwp'
>   
> if os.path.isfile(COOKIEFILE):
> # if we have a cookie file already saved
> # then load the cookies into the Cookie Jar
> cj.load(COOKIEFILE)
>
> opener = urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))
> urllib2.install_opener(opener)
> url = "http://localhost:8000/files/index.html";
> params = {'question':question}
> data = urllib.urlencode(params)
> Request(url, data)
> try:
> response = urlopen(Request)
> etc.
> 
> Only if I create new request object the new cookie is send, but I don't
> want to create new object.  And idea?

You seem to suggest in your first paragraph that you call urlopen more
than once, but in the code you show, you call it only once.

This is the way HTTP cookies work: you can't send back a cookie before
you've received it.  So, you need two HTTP requests: one to get the
cookie, and a second to send it back again.

However, some websites arrange things so that a single attempt to load
a URL results in multiple HTTP requests.  One common way to do that is
by using an "HTTP Refresh" -- look at the top of the HTML to see if
there's a META tag something like this:



This means that the browser should reload the page after a pause of
one second.  Often, the reloaded page then does not contain another
meta refresh tag, so that the page does not reload every second
forever (the server knows not to include the tag because it received
the cookie).

This tag can be supported by appropriate Python code.  So, two HTTP
requests needn't necessarily mean two urlopen calls.  This library
handles refresh redirections, and supports essentially the same
interface as urllib2 and cookielib (the union of the two interfaces):

http://wwwsearch.sourceforge.net/mechanize/


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

Re: Something in the function tutorial confused me.

[Neil Cerutti]

On 2007-08-11, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Neil Cerutti <[EMAIL PROTECTED]> wrote:
>...
>> The Python Language Reference seems a little confused about the
>> terminology.
>> 
>>   3.4.7 Emulating numeric types
>>   6.3.1 Augmented assignment statements
>> 
>> The former refers to "augmented arithmetic operations", which I
>> think is a nice terminology, since assignment is not necessarily
>> taking place. Then the latter muddies the waters.
>
> Assignment *IS* "necessarily taking place"; if you try the augmented
> assignment on something that DOESN'T support assignment, you'll get an
> exception.  Consider:
>
 tup=([],)
 tup[0] += ['zap']
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'tuple' object does not support item assignment
>
> Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT,
> so tuples don't allow a += on any of their items.
>
> If you thought that += wasn't an assignment, this behavior and
> error message would be very problematic; since the language
> reference ISN'T confused and has things quite right, this
> behavior and error message are perfectly consistent and clear.

Thanks for the correction. I was under the illusion that
sometimes augmented assignment would instead mutate the
object.

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

Re: wxPython - drawing without paint event

[Bjoern Schliessmann]

 [EMAIL PROTECTED] wrote:

> On a related topic, it seems like it would be nice to do *all*
> drawing in
> response to paint events. When I get an event from the timer, I
> would just tell wx that part of the window needs redrawing, and
> depend on it to give me a paint even when nothing of higher
> priority needs to be done.
> I've seen this kind of logic recommended in other GUI tookits. Is
> it a good idea in wxPython, and, if so, how does one do it?

At least it is not required -- there are device contexts for use
inside and outside of paint events. 

One nice strategy from an example in "wxPython in Action" is the
following:

* the frame has Draw methods that draw into a BufferedDC, which is
chained to a bitmap member

* inside the paint method, the bitmap member is drawn to screen

Regards,


Björn

-- 
BOFH excuse #393:

Interference from the Van Allen Belt.

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

Re: The Future of Python Threading

[[EMAIL PROTECTED]]

Justin T. wrote:
> On Aug 10, 2:02 pm, [EMAIL PROTECTED] (Luc Heinrich) wrote:
>> Justin T. <[EMAIL PROTECTED]> wrote:
>>> What these seemingly unrelated thoughts come down to is a perfect
>>> opportunity to become THE next generation language.
>> Too late: 
>>
>> :)
>>
>> --
>> Luc Heinrich
> 
> Uh oh, my ulterior motives have been discovered!
> 
> I'm aware of Erlang, but I don't think it's there yet. For one thing,
> it's not pretty enough. It also doesn't have the community support
> that a mainstream language needs. I'm not saying it'll never be
> adequate, but I think that making python into an Erlang competitor
> while maintaining backwards compatibility with the huge amount of
> already written python software will make python a very formidable
> choice as languages adapt more and more multi-core support. Python is
> in a unique position as its actually a flexible enough language to
> adapt to a multi-threaded environment without resorting to terrible
> hacks.
> 
> Justin
> 
Multi-core or multi-CPU computers are more and more popular, especially in 
scientific computation. It will be a great great thing if multi-core support 
can be added to python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ipc mechanisms and designs.

[king kikapu]

On Aug 10, 10:33 pm, Nikita the Spider <[EMAIL PROTECTED]>
wrote:
> In article <[EMAIL PROTECTED]>,
>  king kikapu <[EMAIL PROTECTED]> wrote:
>
>
>
> Hi King Kikapu
> There's a shared memory module for Python, but it is *nix only, I'm
> afraid. I realize you said "mainly Windows" but this module seems to do
> what you want so maybe you can work out a creative solution.
>
> http://NikitaTheSpider.com/python/shm/


Yes, i am currently developing mainly on windows but a cross-platform
solution would surely interests me. I will check it out this!

@Alex: Thanks, it looks very-very interesting...


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

Re: The Future of Python Threading

[Kay Schluehr]

Have you checked out the processing [1] package? I've currently the
impression that people want to change the whole language before they
checkout a new package. It would be nice to read a review.

[1] http://cheeseshop.python.org/pypi/processing

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

Re: Destruction of generator objects

[Stefan Bellon]

On Sat, 11 Aug, Kay Schluehr wrote:

> Honestly, I'd recommend wrapping the generator into a function object,
> create the resource on construction ( or pass it ) and destroy it
> implementing __del__.
> 
> def gen_value(self):
> while True:
> yield self.iter.next()
> 
> class GeneratorObj(object):
> def __init__(self, obj, gen):
> self.iter = make_iter(obj)
> self.gen  = gen(self)
> 
> def __del__(self):
> destroy(self.iter)
> 
> def next(self):
> return self.gen.next()

Ok, I think there is an __iter__ missing in order to implement the
iterator protocol, and I don't see why the generator cannot be inside
the class itself.

Anyway, I came up with this code now:

class ListGenerator(object):
def __init__(self, iter):
print "gen init"
self.iter = iter
self.gen = self._value()

def __del__(self):
print "gen del"
destroy(self.iter)

def _value(self):
print "gen value"
while more(self.iter):
yield next(self.iter)

def __iter__(self):
print "gen iter"
return self

def next(self):
print "gen next"
return self.gen.next()

When iterating over such a generator, I see the following output:

>>> list(obj)
gen init
gen iter
gen next
gen value
gen next
gen next
gen next
gen next
['Item1', 'Item2', 'Item3', 'Item4']

But I do not see an output of "gen del" which makes me think that the
destructor is not called, thus not releasing the resource. It seems I
have not completely understood how generators work ...

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

LRU cache?

[Paul Rubin]

Anyone got a favorite LRU cache implementation?  I see a few in google
but none look all that good.  I just want a dictionary indexed by
strings, that remembers the last few thousand entries I put in it.

It actually looks like this is almost a FAQ.  A well-written
implementation would probably make a good standard library module.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Destruction of generator objects

[Kay Schluehr]

On Aug 11, 2:00 pm, Stefan Bellon <[EMAIL PROTECTED]> wrote:
> On Sat, 11 Aug, Kay Schluehr wrote:
> > Honestly, I'd recommend wrapping the generator into a function object,
> > create the resource on construction ( or pass it ) and destroy it
> > implementing __del__.
>
> > def gen_value(self):
> > while True:
> > yield self.iter.next()
>
> > class GeneratorObj(object):
> > def __init__(self, obj, gen):
> > self.iter = make_iter(obj)
> > self.gen  = gen(self)
>
> > def __del__(self):
> > destroy(self.iter)
>
> > def next(self):
> > return self.gen.next()
>
> Ok, I think there is an __iter__ missing in order to implement the
> iterator protocol, and I don't see why the generator cannot be inside
> the class itself.

Sure.

[...]

> But I do not see an output of "gen del" which makes me think that the
> destructor is not called, thus not releasing the resource. It seems I
> have not completely understood how generators work ...

But why shall the destructor be called? Your example does not indicate
that a ListGenerator object is somewhere destroyed neither explicitely
using del nor implicitely by destroying the scope it is living in.

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

Re: Deleting objects on the fly

[Dustan]

On Aug 10, 1:49 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "Campbell Barton" <[EMAIL PROTECTED]> wrote in message
>
> news:[EMAIL PROTECTED]| Michele Simionato wrote:
>
> | > Probably not, 'del x' just decrements the reference count,
>
> Or ashttp://docs.python.org/ref/del.html
> puts it, " Deletion of a name removes the binding of that name from the
> local or global namespace,"
>
> | del x will remove x from memory if nothing else is refering to it,
>
> This is implementation dependent: true for CPython, not for Jython, ??? for
> IronPython.

Wait a second; do you mean to say that in Jython, del x will never
remove x from memory? How do you free up RAM?

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

Re: Deleting objects on the fly

[Paul Rubin]

Dustan <[EMAIL PROTECTED]> writes:
> > | del x will remove x from memory if nothing else is refering to it,
> > This is implementation dependent: true for CPython, not for Jython, ??? for
> > IronPython.
> Wait a second; do you mean to say that in Jython, del x will never
> remove x from memory? How do you free up RAM?

It stays around until the GC picks it up.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 2.5 bug

[Thorsten Kampe]

*  (Sat, 11 Aug 2007 02:41:26 -0700)
> I was install Python 2.5 and uninstall Python 2.4 now I cannot run my
> scripts, only from idle
> 
> What should I do?

1. read "How To Ask Questions The Smart Way"[1]

2. read "How to Report Bugs Effectively"[2]

3. don't call something a "bug" if the "bug" is likely the person
   sitting in front of your computer

4. don't do something you don't fully understand (in this case
   installing Python 2.5 and uninstalling Python 2.4)


Thorsten
[1] http://catb.org/~esr/faqs/smart-questions.html
[2] http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Metaclass v.s. Property function.

[Jens Thiede]

I don't like the property function, usable in the new-style classes,
because having to remember to manage a list of "foo = property(...)"
assignments just plain sucks, so I wrote a metaclass that does things
a little differently. Please have a look and tell me whether this is
useful or impractical. The metaclass is here: http://pastebin.com/m5b06b571
and some simple testcode is here: http://pastebin.com/m382f2ae9.
Notice the first line though.

Thanks for any replies,

Jens Thiede.

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

Re: Destruction of generator objects

[Stefan Bellon]

On Sat, 11 Aug, Kay Schluehr wrote:

> But why shall the destructor be called? Your example does not indicate
> that a ListGenerator object is somewhere destroyed neither explicitely
> using del nor implicitely by destroying the scope it is living in.

After having constructed the list itself, the generator is exhausted
and not iterated or referenced anymore, so the generator should be
destroyed, shouldn't it?

Ok, let's make the example easier and take out the external iterator
resource and just concentrate on the Python part:

class ListGenerator(object):
def __init__(self):
print "gen init"
self.gen = self._value()

def __del__(self):
print "gen del"

def _value(self):
print "gen value"
for i in xrange(4):
yield i

def __iter__(self):
print "gen iter"
return self

def next(self):
print "gen next"
return self.gen.next()

Now, doing the following:

>>> a = ListGenerator()
gen init
>>> a
<__main__.ListGenerator object at 0x4020c3ec>
>>> for i in a: print i
... 
gen iter
gen next
gen value
0
gen next
1
gen next
2
gen next
3
gen next
>>> del a
>>>

So why is the destructor not called when the generator is even
explicitly 'del'ed? Does somebody else still hold a reference on it?
But then, even when terminating the interpreter, __del__ is not called.
When taking out the yield statement, __del__ is called again. It looks
to me that as soon as a generator function is involved in the class,
the __del__ is not called anymore.

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

Re: Destruction of generator objects

[Marc 'BlackJack' Rintsch]

On Sat, 11 Aug 2007 14:50:33 +0200, Stefan Bellon wrote:

> On Sat, 11 Aug, Kay Schluehr wrote:
> 
>> But why shall the destructor be called? Your example does not indicate
>> that a ListGenerator object is somewhere destroyed neither explicitely
>> using del nor implicitely by destroying the scope it is living in.
> 
> After having constructed the list itself, the generator is exhausted
> and not iterated or referenced anymore, so the generator should be
> destroyed, shouldn't it?
> 
> Ok, let's make the example easier and take out the external iterator
> resource and just concentrate on the Python part:
> 
> class ListGenerator(object):
> def __init__(self):
> print "gen init"
> self.gen = self._value()
> 
> def __del__(self):
> print "gen del"
> 
> def _value(self):
> print "gen value"
> for i in xrange(4):
> yield i
> 
> def __iter__(self):
> print "gen iter"
> return self
> 
> def next(self):
> print "gen next"
> return self.gen.next()
> 
> Now, doing the following:
> 
 a = ListGenerator()
> gen init
 a
> <__main__.ListGenerator object at 0x4020c3ec>
 for i in a: print i
> ... 
> gen iter
> gen next
> gen value
> 0
> gen next
> 1
> gen next
> 2
> gen next
> 3
> gen next
 del a

> 
> So why is the destructor not called when the generator is even
> explicitly 'del'ed?

The generator is not ``del``\ed, just the name `a` is removed.

> Does somebody else still hold a reference on it?

Yes, the interactive Python shell holds the last non-`None` result in `_`:

>>> from forum import ListGenerator
>>> a = ListGenerator()
gen init
>>> a

>>> for i in a: print i
...
gen iter
gen next
gen value
0
gen next
1
gen next
2
gen next
3
gen next
>>> del a
>>> _

>>> 42
gen del
42

> But then, even when terminating the interpreter, __del__ is not called.

Because that is not guaranteed by the language reference.  The reason why
it is a bad idea to depend on `__del__` for important resource management.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Finding gurus (was Re: Something in the function tutorial confused me.)

[Aahz]

In article <[EMAIL PROTECTED]>,
Alex Martelli <[EMAIL PROTECTED]> wrote:
>
>Because of this, a Google search for
>
>  " " python
>
>may sometimes help; when you get 116,000 hits, as for "Steve Holden"
>python, that may be a reasonable indication that the poster is one of
>the world's Python Gurus (in fact, the winner of the 2007 Frank WIllison
>Award -- congratulations, Steve!!!).

Sometimes that precise search pattern isn't appropriate, of course.  ;-)
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"And if that makes me an elitist...I couldn't be happier."  --JMS
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: LRU cache?

[Thomas Wittek]

Paul Rubin schrieb:
> Anyone got a favorite LRU cache implementation?  I see a few in google
> but none look all that good.  I just want a dictionary indexed by
> strings, that remembers the last few thousand entries I put in it.

I don't know a module for that (although it might exist), but I could
imagine how to implement it.

Generally a LRU cache could be implemented as a (linked) list with a
max. size of N.
On usage of an object this object will be moved to the top of the list
(and removed from the old position).
If it's not yet stored in the cache, you (fetch it from the source and)
add it on top and remove the last one, if the list exceeds N entries.

So you need to do two things:
1) Maintain a list: Use a (linked) list.
2) Random access to that list: Use a dict (hash), that also has to be
updated on removal/addition of objects.

-- 
Thomas Wittek
Web: http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
GPG: 0xF534E231
-- 
http://mail.python.org/mailman/listinfo/python-list

Augmented assignment (was Re: Something in the function tutorial confused me.)

[Aahz]

In article <[EMAIL PROTECTED]>,
Neil Cerutti  <[EMAIL PROTECTED]> wrote:
>On 2007-08-11, Alex Martelli <[EMAIL PROTECTED]> wrote:
>> Neil Cerutti <[EMAIL PROTECTED]> wrote:
>>...
>>> The Python Language Reference seems a little confused about the
>>> terminology.
>>> 
>>>   3.4.7 Emulating numeric types
>>>   6.3.1 Augmented assignment statements
>>> 
>>> The former refers to "augmented arithmetic operations", which I
>>> think is a nice terminology, since assignment is not necessarily
>>> taking place. Then the latter muddies the waters.
>>
>> Assignment *IS* "necessarily taking place"; if you try the augmented
>> assignment on something that DOESN'T support assignment, you'll get an
>> exception.  Consider:
>>
> tup=([],)
> tup[0] += ['zap']
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> TypeError: 'tuple' object does not support item assignment
>>
>> Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT,
>> so tuples don't allow a += on any of their items.
>>
>> If you thought that += wasn't an assignment, this behavior and
>> error message would be very problematic; since the language
>> reference ISN'T confused and has things quite right, this
>> behavior and error message are perfectly consistent and clear.
>
>Thanks for the correction. I was under the illusion that sometimes
>augmented assignment would instead mutate the object.

Although Alex is essentially correct, the situation is a bit more complex
and you are correct that augmented assignment allows the object to decide
whether to mutate in place.  However, the critical part of Alex's point
is what you need to focus on: it's the *tuple* in Alex's example that
intercepts the assignment call, not the list contained in the tuple.

Obviously, you can easily work around it:

>>> t = ([],)
>>> l = t[0]
>>> l += ['foo']
>>> t
(['foo'],)

And this proves that you are correct about the list getting mutated in
place and reflected back in the tuple.  Generally speaking, augmented
assignment with nested container objects is a Bad Idea IMO -- split out
the bits you want to work with.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"And if that makes me an elitist...I couldn't be happier."  --JMS
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: deselect an iterm in ListBox wxPython

[kyosohma]

On Aug 11, 2:53 am, Bailu <[EMAIL PROTECTED]> wrote:
> Hi,
>
>I am a newbie in wxPython and doing a program with ListBox,
> I want to select and deselect items in this box,
> I have use
>
> self.devlist = wx.ListBox(self, style=wx.LB_MULTIPLE)
> self.Bind(wx.EVT_LISTBOX, self.select_dev, self.devlist)
>
> to create this box, but don't know how to implement self.select_dev
> to find out which one is clicked
>
> deselect it, if it was selected  ( this is not working at default)
> select it, if it was not (toggle)
>
> The default behavior is, the selection is increasing, I can't deselect
> any of them.
>
> Thanks.
>
> Lingyun

You should look at the wxPython demo's code for the wx.ListBox. It
looks like they use the wx.EVT_LISTBOX event. See below:


# this writes to a multiline TextCtrl
self.log.WriteText('EvtListBox: %s, %s, %s, %s\n' %
   (event.GetString(),
event.IsSelection(),
event.GetSelection(),
event.GetClientData()))


I'm not sure, but I think it uses the SetSelection() method to select
an item, which seems to deselect the previously selected item...at
least, that's how I interpret the demo.

The demo is here: http://wxpython.org/download.php

If you need additional help, try posting to the wxPython User's group:
http://wxpython.org/maillist.php

Regards,

Mike

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

Re: Finding gurus (was Re: Something in the function tutorial confused me.)

[Steve Holden]

Aahz wrote:
> In article <[EMAIL PROTECTED]>,
> Alex Martelli <[EMAIL PROTECTED]> wrote:
>> Because of this, a Google search for
>>
>>  " " python
>>
>> may sometimes help; when you get 116,000 hits, as for "Steve Holden"
>> python, that may be a reasonable indication that the poster is one of
>> the world's Python Gurus (in fact, the winner of the 2007 Frank WIllison
>> Award -- congratulations, Steve!!!).
> 
> Sometimes that precise search pattern isn't appropriate, of course.  ;-)

Of course, Alex didn't mention that there are actually 117,000 hits, and 
the last thousand have nothing to do with programming ;-)

Alex, thanks for your congratulations, as no public announcement has yet 
been made (apart from at OSCON) I haven't mentioned the Frank Willison 
Award until now. The certificate arrived this week, and I am humbled by 
the honor.

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: Destruction of generator objects

[Stefan Bellon]

On Sat, 11 Aug, Marc 'BlackJack' Rintsch wrote:

> On Sat, 11 Aug 2007 14:50:33 +0200, Stefan Bellon wrote:

> > But then, even when terminating the interpreter, __del__ is not
> > called.
> 
> Because that is not guaranteed by the language reference.  The reason
> why it is a bad idea to depend on `__del__` for important resource
> management.

Ok, but then we are back to my initial question of whether the destroy
of

def get_data(obj):
iter = make_iter(obj)
while more(iter):
yield next(iter)
destroy(iter)

can be guaranteed somehow in Python 2.4 while it can be done in Python
2.5 like follows:

def get_data(obj):
iter = make_iter(obj)
try:
while more(iter):
yield next(iter)
finally:
destroy(iter)

And then the answer is: no, it cannot be done in 2.4 (like Alex
Martelli already said ;-)

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

Re: Deleting objects on the fly

[Steve Holden]

Dustan wrote:
> On Aug 10, 1:49 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>> "Campbell Barton" <[EMAIL PROTECTED]> wrote in message
>>
>> news:[EMAIL PROTECTED]| Michele Simionato wrote:
>>
>> | > Probably not, 'del x' just decrements the reference count,
>>
>> Or ashttp://docs.python.org/ref/del.html
>> puts it, " Deletion of a name removes the binding of that name from the
>> local or global namespace,"
>>
>> | del x will remove x from memory if nothing else is refering to it,
>>
>> This is implementation dependent: true for CPython, not for Jython, ??? for
>> IronPython.
> 
> Wait a second; do you mean to say that in Jython, del x will never
> remove x from memory? How do you free up RAM?
> 
Because the exact method of garbage collection is independent of the 
language definition, Jython uses the Java garbage collector, which works 
(approximately) as follows.

In that language memory is allocated until a request cannot be 
satisfies, then a scan is performed for unreferenced objects whose space 
is reclaimed. Only if this doesn't yield enough space to allocate the 
new object is more memory requested from the OS by the process.

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

A new french book on Python

[Tarek]

Hello,

A new french book is coming out on the 16th of august. It's focused on
Python good practices, agility, and all the things that makes a Python
developer loves the language.

If you are interested, the web page is here : 
http://programmation-python.org/guide

Regards

Tarek

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

Re: LRU cache?

[Steve Holden]

Thomas Wittek wrote:
> Paul Rubin schrieb:
>> Anyone got a favorite LRU cache implementation?  I see a few in google
>> but none look all that good.  I just want a dictionary indexed by
>> strings, that remembers the last few thousand entries I put in it.
> 
> I don't know a module for that (although it might exist), but I could
> imagine how to implement it.
> 
> Generally a LRU cache could be implemented as a (linked) list with a
> max. size of N.
> On usage of an object this object will be moved to the top of the list
> (and removed from the old position).
> If it's not yet stored in the cache, you (fetch it from the source and)
> add it on top and remove the last one, if the list exceeds N entries.
> 
> So you need to do two things:
> 1) Maintain a list: Use a (linked) list.
> 2) Random access to that list: Use a dict (hash), that also has to be
> updated on removal/addition of objects.
> 
Paul's an old enough hand that he's well able to determine this for 
himself. He's also polite enough not to reply along those lines :-)

*I* don't know of module for tracking how plants grow, but I could 
imagine how to implement it ...

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: Augmented assignment (was Re: Something in the function tutorial confused me.)

[Roel Schroeven]

Aahz schreef:
> In article <[EMAIL PROTECTED]>,
> Neil Cerutti  <[EMAIL PROTECTED]> wrote:
>> On 2007-08-11, Alex Martelli <[EMAIL PROTECTED]> wrote:
>>> Neil Cerutti <[EMAIL PROTECTED]> wrote:
>>>...
 The Python Language Reference seems a little confused about the
 terminology.

   3.4.7 Emulating numeric types
   6.3.1 Augmented assignment statements

 The former refers to "augmented arithmetic operations", which I
 think is a nice terminology, since assignment is not necessarily
 taking place. Then the latter muddies the waters.
>>> Assignment *IS* "necessarily taking place"; if you try the augmented
>>> assignment on something that DOESN'T support assignment, you'll get an
>>> exception.  Consider:
>>>
>> tup=([],)
>> tup[0] += ['zap']
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> TypeError: 'tuple' object does not support item assignment
>>>
>>> Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT,
>>> so tuples don't allow a += on any of their items.
>>>
>>> If you thought that += wasn't an assignment, this behavior and
>>> error message would be very problematic; since the language
>>> reference ISN'T confused and has things quite right, this
>>> behavior and error message are perfectly consistent and clear.
>> Thanks for the correction. I was under the illusion that sometimes
>> augmented assignment would instead mutate the object.
> 
> Although Alex is essentially correct, the situation is a bit more complex
> and you are correct that augmented assignment allows the object to decide
> whether to mutate in place.  However, the critical part of Alex's point
> is what you need to focus on: it's the *tuple* in Alex's example that
> intercepts the assignment call, not the list contained in the tuple.
> 
> Obviously, you can easily work around it:
> 
 t = ([],)
 l = t[0]
 l += ['foo']
 t
> (['foo'],)

I'm missing something here, I think. As far as I can tell, the language 
reference says that the target is evaluated before the augmented 
assignment is performed. If that's the case, I don't see how the tuple 
in Alex' example has anything to with it: the assignment is to the list, 
not the tuple.

And watch this (Python 2.4.2):

 >>> tup = ([],)
 >>> tup[0] += ['zap']

Traceback (most recent call last):
   File "", line 1, in -toplevel-
 tup[0] += ['zap']
TypeError: object does not support item assignment

So far that's the same as Alex' example, but look at the value of the 
tuple now:

 >>> tup
(['zap'],)

Despite the TypeError, the list *has* changed.

-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

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

RE: Do you want to know about ISLAM

[sdrodrian]

[EMAIL PROTECTED] wrote:

> Do you want to know about ISLAM,
> the fastest growing peril to the World ?

> If yes, this is the ONLY site you need visit:

  http://islamisbad.com

Or, you could just read your newspapers
with your BRAINS instead of your sheep's horns.

S D Rodrian
http://poems.sdrodrian.com
http://physics.sdrodrian.com
http://mp3s.sdrodrian.com

All religions are local.
Only science is universal.











.

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

Re: The Future of Python Threading

[Nick Craig-Wood]

Bjoern Schliessmann <[EMAIL PROTECTED]> wrote:
>  Nick Craig-Wood wrote:
>  [GIL]
> > That is certainly true.  However the point being is that running
> > on 2 CPUs at once at 95% efficiency is much better than running on
> > only 1 at 99%...
> 
>  How do you define this percent efficiency?

Those are hypothetical numbers.  I guess that a finely locked python
will spend a lot more time locking and unlocking individual objects
than it currently does locking and unlocking the GIL.  This is for two
reasons

1) the GIL will be in cache at all times and therefore "hot" and quick
to access

2) much more locking and unlocking of each object will need to be
done.

> >>> The truth is that the future (and present reality) of almost
> >>> every form of computing is multi-core,
> >> 
> >>  Is it? 8)
> > 
> > Intel, AMD and Sun would have you believe that yes!
> 
>  Strange, in my programs, I don't need any "real" concurrency (they
>  are network servers and scripts). Or do you mean "the future of
>  computing hardware is multi-core"? That indeed may be true.

I meant the latter.  I agree with you though that not all programs
need to be multi-threaded.  Hence my proposal for two python binaries.

> >>  The question is: If it really was, how much of useful
> >>  performance gain would you get?
> > 
> > The linux kernel has been through these growing pains already... 
> > SMP support was initially done with the Big Kernel Lock (BKL)
> > which is exactly equivalent to the GIL.
> 
>  So, how much performance gain would you get? Again, managing
>  fine-grained locking can be much more work than one simple lock.

Assuming that you are not IO bound, but compute bound and that compute
is being done in python then you'll get a speed up proportional to how
many processors you have, minus a small amount for locking overhead.

> > The linux kernel has moved onwards to finer and finer grained
> > locking.
> 
>  How do you compare a byte code interpreter to a monolithic OS
>  kernel?

In this (locking) respect they are quite similar actually.  You can
think of kernel code as being the python interpreter (BKL vs GIL),
user space being as C extensions running with the GIL unlocked and
calling back into the python interpreter / kernel.

> > I'd like to see a python build as it is at the moment and a
> > python-mt build which has the GIL broken down into a lock on each
> > object. python-mt would certainly be slower for non threaded
> > tasks, but it would certainly be quicker for threaded tasks on
> > multiple CPU computers.
> 
>  From where do you take this certainty? For example, if the program
>  in question involves mostly IO access, there will be virtually no
>  gain. Multithreading is not Performance.

Yes you are right of course.  IO bound tasks don't benefit from
multi-threading.  In fact usually the reverse.  Twisted covers this
ground extremely well in my experience.  However IO bound tasks
probably aren't taxing your quad core chip either...

> > The user could then choose which python to run.
> > 
> > This would of course make C extensions more complicated...
> 
>  Also, C extensions can release the GIL for long-running
>  computations.

Provided they stay in C.  If they call any python stuff then they need
to take it again.

-- 
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Augmented assignment (was Re: Something in the function tutorial confused me.)

[Aahz]

In article <[EMAIL PROTECTED]>,
Roel Schroeven  <[EMAIL PROTECTED]> wrote:
>Aahz schreef:
>> 
>> Although Alex is essentially correct, the situation is a bit more complex
>> and you are correct that augmented assignment allows the object to decide
>> whether to mutate in place.  However, the critical part of Alex's point
>> is what you need to focus on: it's the *tuple* in Alex's example that
>> intercepts the assignment call, not the list contained in the tuple.
>> 
>> Obviously, you can easily work around it:
>> 
> t = ([],)
> l = t[0]
> l += ['foo']
> t
>> (['foo'],)
>
>I'm missing something here, I think. As far as I can tell, the language 
>reference says that the target is evaluated before the augmented 
>assignment is performed. If that's the case, I don't see how the tuple 
>in Alex' example has anything to with it: the assignment is to the list, 
>not the tuple.
>
>And watch this (Python 2.4.2):
>
> >>> tup = ([],)
> >>> tup[0] += ['zap']
>
>Traceback (most recent call last):
>   File "", line 1, in -toplevel-
> tup[0] += ['zap']
>TypeError: object does not support item assignment
>
>So far that's the same as Alex' example, but look at the value of the 
>tuple now:
>
> >>> tup
>(['zap'],)
>
>Despite the TypeError, the list *has* changed.

Yup!  Here's why:

>>> def foo(bar): bar[0] += ['zap']
... 
>>> import dis
>>> dis.dis(foo)
  1   0 LOAD_FAST0 (bar)
  3 LOAD_CONST   1 (0)
  6 DUP_TOPX 2
  9 BINARY_SUBSCR   
 10 LOAD_CONST   2 ('zap')
 13 BUILD_LIST   1
 16 INPLACE_ADD 
 17 ROT_THREE   
 18 STORE_SUBSCR
 19 LOAD_CONST   0 (None)
 22 RETURN_VALUE

Notice the critical sequence: BINARY_SUBSCR, INPLACE_ADD, STORE_SUBSCR.
It has to work that way to allow this:

>>> l = [7]
>>> l[0] += 1
>>> l
[8]

There's simply no way to get augmented assignment to work correctly with
both lists and tuples when you allow both mutable and immutable elements.
Someone will always get surprised, and overall with strings and numbers
being the canonical list elements, I think making augmented assignment
work correctly with lists and immutables was the best decision.

But the unfortunate side-effect is that you get the TypeError with
augmented assignment in tuples only after the mutation has been done.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"And if that makes me an elitist...I couldn't be happier."  --JMS
-- 
http://mail.python.org/mailman/listinfo/python-list

Public Telnet Server?

[Dave]

Hi there. I'm a beginner at Python and I'm writing my first Python
script. It's a text adventure about coffee and mixing drinks and being
crazy and such. I keep updating it and want my friends to beta test it
for me, but some of them don't have the right version of Python or
don't want to get Python at all. Is there an easy way I can set up a
public telnet server so they can just telnet the server and play it?
If anyone could give me some options and/or advice, I'd really
appreciate it!

Dave

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

Re: I am giving up perl because of assholes on clpm -- switching to Python

[Dr.Ruud]

Paul Boddie schreef:

> let us
> avoid comp.lang.python becoming some kind of linux-kernel ego trip
> where anyone who has stuck around has an interest in perpetuating a
> hostile atmosphere.

"When did you stop beating your wife?" 

-- 
Affijn, Ruud

"Gewoon is een tijger."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am giving up perl because of assholes on clpm -- switching to Python

[Dr.Ruud]

grocery_stocker schreef:

> In the beginning there was Mathematics
> And all was good
> Then one day God said "Let there be the Lambda Calculus"
> And hence the Lambda Calculus was born.
> However, God felt the the Lambda Calculus needed a mate
> So god said "Let there be Lisp"
> And thus, Lisp was born.
> 
> As the years went on, god became depressed by how impure the Lisp had
> become.
> For from the Lisp, came Emacs Lisp, Java, Perl, Ruby, and Python.

http://xkcd.com/224/ 

-- 
Affijn, Ruud

"Gewoon is een tijger."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: I am giving up perl because of assholes on clpm -- switching to Python

[Dr.Ruud]

RedGrittyBrick schreef:

> treasure the saints, tolerate the irritable and
> ignore the whiners.

*You are what you read.* What is "irritating" to some, is "to the point"
to others.

That should say enough, but some people just can not stand short
replies, they can not hold themselves back from reading all negative
kinds of things into them. Too little attention maybe? (I am just making
the same mistake to show how it works.)

Only rarely someone mistakes the "to the point" for the "irritating",
without acknowledging their mistake in the first or second next reply.
Newbies with the wrong focus, under pressure, probably suffering lack of
sleep? (I am just making things worse.)

-- 
Affijn, Ruud

"Gewoon is een tijger."

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

Re: Metaclass v.s. Property function.

[Duncan Booth]

Jens Thiede <[EMAIL PROTECTED]> wrote:

> I don't like the property function, usable in the new-style classes,
> because having to remember to manage a list of "foo = property(...)"
> assignments just plain sucks, so I wrote a metaclass that does things
> a little differently. Please have a look and tell me whether this is
> useful or impractical. The metaclass is here:
> http://pastebin.com/m5b06b571 and some simple testcode is here:
> http://pastebin.com/m382f2ae9. Notice the first line though.
> 
Here's something I posted a while back which lets you use property as a 
decorator:

 class C(object):
def __init__(self, colour):
self._colour = colour

@property.set
def colour(self, value):
self._colour = value

@property.get
def colour(self):
return self._colour

@property.delete
def colour(self):
self._colour = 'none' 

See:
http://groups.google.co.uk/group/comp.lang.python/browse_thread/thread/b442d08c9a019a8/8a381be5edc26340

Whether you like that style is of course a matter of personal opinion.
-- 
http://mail.python.org/mailman/listinfo/python-list

Who told str() to round my int()'s!!!

[Adam W.]

After a fair amount of troubleshooting of why my lists were coming
back a handful of digits short, and the last digit rounded off, I
determined the str() function was to blame:

>>> foonum
0.0071299720384678782
>>> str(foonum)
'0.00712997203847'
>>>

Why in the world does str() have any business rounding my numbers, and
how do I get around this?

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

How to change a PyObject passed to the C extension

[MD]

Hi,
   I have a Python C extension which is passed a PyObject containing
an integer value. Is it possible to change this same PyObject so that
now the integer is of a different value?

Thanks and Regards,
-MD

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

Re: How to change a PyObject passed to the C extension

[Marc 'BlackJack' Rintsch]

On Sat, 11 Aug 2007 09:43:19 -0700, MD wrote:

>I have a Python C extension which is passed a PyObject containing
> an integer value. Is it possible to change this same PyObject so that
> now the integer is of a different value?

No it is not.  Even if you poke around in the object ``struct`` this would
have severe consequences for cached/shared objects.  Just imagine:

from your_module import bzzzt

def f():
print 2 + 2

bzzzt(2)   # This changes the value of 2 to 3.
f()# This prints '6'!

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Ligmail bug?

[No.23]

#!/usr/bin/env python

import libgmail
from time import gmtime, strftime

fp = open('/tmp/python.list', 'w')
ga = libgmail.GmailAccount("[EMAIL PROTECTED]", "mypass")
ga.login()

result = self.ga.getMessagesByLabel('python.list', True)
result_len = len(result)
cnt = 0
if result_len:
for thread in result:
cnt += 1
thread_len = len(thread)
print 'Thread: %d/%d Msg: %d %s' % (cnt,
result_len,
thread_len, 
thread.subject)
for msg in thread:
print '  Msg: %d/%d %s' % (msg.number, 
   thread_len, 
   msg.subject)
source = msg.source.replace('\r','').lstrip()
fp.write('From - ' + \
  strftime("%a %b %d %H:%M:%S %Y", 
  gmtime()) + '\n')
fp.write(source)
fp.write('\n\n')

Thread: 1/1244 Msg: 7 \u003cb\>Deleting objects on the fly\u003c/b\>
  Msg: 1/7 Deleting objects on the fly
  Msg: 2/7 Re: Deleting objects on the fly
  Msg: 3/7 Re: Deleting objects on the fly
  Msg: 4/7 Re: Deleting objects on the fly
  Msg: 5/7 Re: Deleting objects on the fly
  Msg: 6/7 Re: Deleting objects on the fly
  Msg: 7/7 Re: Deleting objects on the fly
Thread: 2/1244 Msg: 1 \u003cb\>A new french book on Python\u003c/b\>
  Msg: 1/1 A new french book on Python
Thread: 3/1244 Msg: 14 \u003cb\>Destruction of generator objects\u003c/b\>
  Msg: 1/14 Destruction of generator objects
  Msg: 2/14 Re: Destruction of generator objects
  Msg: 3/14 Re: Destruction of generator objects
  Msg: 4/14 Re: Destruction of generator objects
  Msg: 5/14 Re: Destruction of generator objects
  Msg: 6/14 Re: Destruction of generator objects
  Msg: 7/14 Re: Destruction of generator objects
  Msg: 8/14 Re: Destruction of generator objects
  Msg: 9/14 Re: Destruction of generator objects
  Msg: 10/14 Re: Destruction of generator objects
  Msg: 11/14 Re: Destruction of generator objects
  Msg: 12/14 Re: Destruction of generator objects
  Msg: 13/14 Re: Destruction of generator objects
  Msg: 14/14 Re: Destruction of generator objects
..
Thread: 307/1244 Msg: 1 MailingLogger 3.2.0 Released!
   Msg: 1/1 MailingLogger 3.2.0 Released!
 Thread: 308/1244 Msg: 13 Why no maintained wrapper to Win32?
   Msg: 1/13 Why no maintained wrapper to Win32?
   Msg: 2/13 Re: Why no maintained wrapper to Win32?
   Msg: 3/13 Re: Why no maintained wrapper to Win32?
   Msg: 4/13 Re: Why no maintained wrapper to Win32?
   Msg: 5/13 Re: Why no maintained wrapper to Win32?
   Msg: 6/13 Re: Why no maintained wrapper to Win32?
   Msg: 7/13 Re: Why no maintained wrapper to Win32?
   Msg: 8/13 Re: Why no maintained wrapper to Win32?
   Msg: 9/13 Re: Why no maintained wrapper to Win32?
   Msg: 10/13 Re: Why no maintained wrapper to Win32?
   Msg: 11/13 Re: Why no maintained wrapper to Win32?
   Msg: 12/13 Re: Why no maintained wrapper to Win32?
   Msg: 13/13 Re: Why no maintained wrapper to Win32?
 Thread: 309/1244 Msg: 5 Encryption recommendation
   Msg: 1/5 Encryption recommendation
   Msg: 2/5 Re: Encryption recommendation
   Msg: 3/5 Re: Encryption recommendation
   Msg: 4/5 Re: Encryption recommendation
   Msg: 5/5 Re: Encryption recommendation
 Thread: 310/1244 Msg: 3 Simple question about logging module.
   Msg: 1/3 Simple question about logging module.
   Msg: 2/3 Re: Simple question about logging module.
   Msg: 3/3 Re: Simple question about logging module.
 Thread: 311/1244 Msg: 5 Plotting Images
   Msg: 1/5 Plotting Images
   Msg: 2/5 Re: Plotting Images
   Msg: 3/5 Re: Plotting Images
   Msg: 4/5 Re: Plotting Images
   Msg: 5/5 Re: Plotting Images
 Thread: 312/1244 Msg: 33 From D
 Thread: 313/1244 Msg: 4 get directory and file names
 Thread: 314/1244 Msg: 7 Compiling 2.5.1 on OpenBSD 4.1
 Thread: 315/1244 Msg: 2 how to add a toolbar to a Frame using wxpython
 Thread: 316/1244 Msg: 1 create a toolbar + images using wxpython for windows
 Thread: 317/1244 Msg: 4 Pysqlite storing file as blob example
 Thread: 318/1244 Msg: 1 Nasm_with_C++_with_Python
 Thread: 319/1244 Msg: 2 interaction of 'with' and 'yield'
 Thread: 320/1244 Msg: 5 problems with logging module
 Thread: 321/1244 Msg: 5 win32 question in Python
 Thread: 322/1244 Msg: 6 File handle not being released by close
 Thread: 323/1244 Msg: 6 Replacing overloaded functions with closures.
 Thread: 324/1244 Msg: 1 Where can I get a complete user interface about 
pylibpcap?
 Thread: 325/1244 Msg: 7 making a variable available in a function from 
decoratorThread: 326/1244 Msg: 1 www.cerocom.com
 Thread: 327/1244 Msg: 6 OOP in Python book?
 Thread: 328/1244 Msg: 3 Help text embedding in C code?
 Thread: 329/1244 Msg: 16 128 or 96 bit integer types?
 Thread: 330/1244 Msg: 2 Re: yield keyword usage
 Thread: 331/1244 Msg: 11 How to write GUI and event separately in wxPython??
 Thread: 332/1244 Msg: 2

Re: Who told str() to round my int()'s!!!

[Marc 'BlackJack' Rintsch]

On Sat, 11 Aug 2007 16:40:02 +, Adam W. wrote:

> After a fair amount of troubleshooting of why my lists were coming
> back a handful of digits short, and the last digit rounded off, I
> determined the str() function was to blame:
> 
 foonum
> 0.0071299720384678782
 str(foonum)
> '0.00712997203847'

> 
> Why in the world does str() have any business rounding my numbers, and
> how do I get around this?

If `str()` would not round you would get very long numbers because of the
inaccuracies of floating point values.  I know Python is lying when 0.1
prints as 0.1, but do you really want to see
0.1555111512312578270211815834045410156250 instead?

Use string formatting to tell the number of digits you want to see:

In [16]: '%.56f' % 0.1
Out[16]: '0.1555111512312578270211815834045410156250'

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Who told str() to round my int()'s!!!

[Adam W.]

On Aug 11, 12:53 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> If `str()` would not round you would get very long numbers because of the
> inaccuracies of floating point values.  I know Python is lying when 0.1
> prints as 0.1, but do you really want to see
> 0.1555111512312578270211815834045410156250 instead?

I want str() to convert whatever I give it to a string and do nothing
else.  I will worry about long FP values in previous steps.  I still
find it very disturbing that str() is doing this AND it is
undocumented in all of my books.

> Use string formatting to tell the number of digits you want to see:
>
> In [16]: '%.56f' % 0.1
> Out[16]: '0.1555111512312578270211815834045410156250'

The book I used to learn Python never introduced string formatting, I
suppose I will have to use another and learn it if that is the only
way...


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

Re: Augmented assignment (was Re: Something in the function tutorial confused me.)

[Roel Schroeven]

Aahz schreef:
 def foo(bar): bar[0] += ['zap']
> ... 
 import dis
 dis.dis(foo)
>   1   0 LOAD_FAST0 (bar)
>   3 LOAD_CONST   1 (0)
>   6 DUP_TOPX 2
>   9 BINARY_SUBSCR   
>  10 LOAD_CONST   2 ('zap')
>  13 BUILD_LIST   1
>  16 INPLACE_ADD 
>  17 ROT_THREE   
>  18 STORE_SUBSCR
>  19 LOAD_CONST   0 (None)
>  22 RETURN_VALUE
> 
> Notice the critical sequence: BINARY_SUBSCR, INPLACE_ADD, STORE_SUBSCR.
> It has to work that way to allow this:
> 
 l = [7]
 l[0] += 1
 l
> [8]
> 
> There's simply no way to get augmented assignment to work correctly with
> both lists and tuples when you allow both mutable and immutable elements.
> Someone will always get surprised, and overall with strings and numbers
> being the canonical list elements, I think making augmented assignment
> work correctly with lists and immutables was the best decision.

Thank you, I get it now. With that disassembled code in mind I had 
another look at the relevant section in the Language Reference; now I 
have a much better understanding of what's really happening.

I used to interpret the target in 'The target is only evaluated once' 
more like an L-value in C/C++. That's not correct, of course, but I 
didn't understand exactly how wrong it was until now.

-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

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

Re: Who told str() to round my int()'s!!!

[Roel Schroeven]

Adam W. schreef:
> After a fair amount of troubleshooting of why my lists were coming
> back a handful of digits short, and the last digit rounded off, I
> determined the str() function was to blame:
> 
 foonum
> 0.0071299720384678782
 str(foonum)
> '0.00712997203847'
> 
> Why in the world does str() have any business rounding my numbers, and
> how do I get around this?

You could use repr() instead of str() (AFAIK that's what the interactive 
interpreter used to print your foonum), but in any case you should be 
aware of the limits inherent in floating point arithmetic and in 
conversions between decimal and binary fractions. See e.g. 
http://docs.python.org/tut/node16.html


-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

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

Re: Augmented assignment (was Re: Something in the function tutorial confused me.)

[OKB (not okblacke)]

Aahz wrote:

>> tup=([],)
>> tup[0] += ['zap']
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> TypeError: 'tuple' object does not support item assignment

> Obviously, you can easily work around it:
> 
 t = ([],)
 l = t[0]
 l += ['foo']
 t
> (['foo'],)

This is quite shocking to me, although after staring at the 
documentation for a while I guess I understand it.  But it seems to me 
that the documentation is somewhat misleading on this point, where it 
says:

"An augmented assignment evaluates the target (which, unlike normal 
assignment statements, cannot be an unpacking) and the expression list, 
performs the binary operation specific to the type of assignment on the 
two operands, and assigns the result to the original target."

This sentence is phrased as though it is the whole story, but it 
isn't, because the operation might not in fact wind up being an 
assignment.  Shouldn't there be an "except see below" or something 
there, to alert the reader that in some cases a true assignment doesn't 
occur?  (I realize that the exception follows quite closely on the heels 
of this sentence, but it doesn't follow immediately, and is separated by 
a paragraph break and intervening material about the parallel to 
unaugmented x = x + 1.  On initial reading my tendency is to read the 
end of the sentence quoted above, see a paragraph break and apparently 
explanatory material, and go "oh, okay, I now have the full 
specification of this syntax" when in fact I don't.)

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
--author unknown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Augmented assignment (was Re: Something in the function tutorial confused me.)

[Roel Schroeven]

OKB (not okblacke) schreef:
> Aahz wrote:
> 
>>> tup=([],)
>>> tup[0] += ['zap']
 Traceback (most recent call last):
   File "", line 1, in 
 TypeError: 'tuple' object does not support item assignment
> 
>> Obviously, you can easily work around it:
>>
> t = ([],)
> l = t[0]
> l += ['foo']
> t
>> (['foo'],)
> 
>   This is quite shocking to me, although after staring at the 
> documentation for a while I guess I understand it.  But it seems to me 
> that the documentation is somewhat misleading on this point, where it 
> says:
> 
>   "An augmented assignment evaluates the target (which, unlike normal 
> assignment statements, cannot be an unpacking) and the expression list, 
> performs the binary operation specific to the type of assignment on the 
> two operands, and assigns the result to the original target."
> 
>   This sentence is phrased as though it is the whole story, but it 
> isn't, because the operation might not in fact wind up being an 
> assignment. 

The way I understand this now, the assignment really always is an 
assignment.

1.
   - For immutable objects, the 'binary operation specific to the type of
 assignment on the two operands' doesn't modify any object, but only
 returns a new object which is the result of the operation.
   - For mutable objects that support the inplace-version of the
 operator, the operator modifies the object and then returns it.
3. In both cases that result is assigned to the target. In the second 
case the object was already modified so the assignment doesn't 
accomplish very much, but it still happens.

That explains why "tup[0] += ['zap']" both has an effect (tup[0] now 
contains 'zap') and raises an exception: tup[0] is modified because it 
is a list and lists support inplace addition, but the assignment fails 
because tuples don't support item assignment.

-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

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

Re: python 2.5 bug

[Laurent Pointal]

 [EMAIL PROTECTED] wrote:

> On 11 kol, 11:59, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>> On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote:
>> > I was install Python 2.5 and uninstall Python 2.4 now I cannot run my
>> > scripts, only from idle
>>
>> > What should I do?
>>
>> Install 2.4 again.  Both can be installed in parallel.
>>
>> Ciao,
>> Marc 'BlackJack' Rintsch
> 
> I need python 2.5 for work becose python 2.4 module tokenizer has no
> attribute "untokenize"

IMHO Python 2.4 was registered for .py files, Python 2.5 take precedence
when installed, but when Python 2.4 has been removed, it remove .py files
association too (so break Python 2.5 association).

* manually associate .py/.pyc/.pyo files to python.exe, .pyw files to
pythonw.exe.

* or reinstall Python 2.5 so that it re-setup ad-hoc associations.


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

decorators - more than just syntactic sugar

[Helmut Jarausch]

Hi,

are decorators more than just syntactic sugar in python 2.x and what
about python 3k ?
How can I find out the predefined decorators?

Many thanks for your help,

Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: decorators - more than just syntactic sugar

[Marc 'BlackJack' Rintsch]

On Sat, 11 Aug 2007 20:30:54 +0200, Helmut Jarausch wrote:

> are decorators more than just syntactic sugar in python 2.x and what
> about python 3k ?

They are just syntactic sugar.

@spam
def ham():
pass

is the same as

def ham():
pass

ham = spam(ham)

> How can I find out the predefined decorators?

*The* predefined decorators?  Decorators are just functions after all. 
There are some meant to be used as decorators but there are also
"ordinary" functions that may make sense as decorators.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 2.5 bug

[Thorsten Kampe]

* Laurent Pointal (Sat, 11 Aug 2007 20:09:03 +0200)
>  [EMAIL PROTECTED] wrote:
> > On 11 kol, 11:59, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> >> On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote:
> >> > I was install Python 2.5 and uninstall Python 2.4 now I cannot run my
> >> > scripts, only from idle
> 
> IMHO Python 2.4 was registered for .py files, Python 2.5 take precedence
> when installed, but when Python 2.4 has been removed, it remove .py files
> association too (so break Python 2.5 association).
> 
> * manually associate .py/.pyc/.pyo files to python.exe, .pyw files to
> pythonw.exe.
> 
> * or reinstall Python 2.5 so that it re-setup ad-hoc associations.

Yeah. Did the Original Poster mention any details about his problem. 
Like - for instance - that he's using Windows?

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

Re: Who told str() to round my int()'s!!!

[Marc 'BlackJack' Rintsch]

On Sat, 11 Aug 2007 17:10:05 +, Adam W. wrote:

> On Aug 11, 12:53 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>> If `str()` would not round you would get very long numbers because of the
>> inaccuracies of floating point values.  I know Python is lying when 0.1
>> prints as 0.1, but do you really want to see
>> 0.1555111512312578270211815834045410156250 instead?
> 
> I want str() to convert whatever I give it to a string and do nothing
> else.

But those long numbers are very disturbing and nobody wants them as usual
string representation.  Most programming languages "lie" at this point to
the user so it would be very unexpected too.

> I will worry about long FP values in previous steps.

What do you mean here?  Have you looked at the example above?  That is the
closest you get to 0.1 -- there's no way to round the floating point
value, it can only be done by converting to `str()`.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Who told str() to round my int()'s!!!

[Steve Holden]

Roel Schroeven wrote:
> Adam W. schreef:
>> After a fair amount of troubleshooting of why my lists were coming
>> back a handful of digits short, and the last digit rounded off, I
>> determined the str() function was to blame:
>>
> foonum
>> 0.0071299720384678782
> str(foonum)
>> '0.00712997203847'
>>
>> Why in the world does str() have any business rounding my numbers, and
>> how do I get around this?
> 
> You could use repr() instead of str() (AFAIK that's what the interactive 
> interpreter used to print your foonum), but in any case you should be 
> aware of the limits inherent in floating point arithmetic and in 
> conversions between decimal and binary fractions. See e.g. 
> http://docs.python.org/tut/node16.html
> 
> 
I should also point out that the subject line for this thread is 
inaccurate, as it wasn't rounding ints at all.

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: Who told str() to round my int()'s!!!

[Zentrader]

On Aug 11, 9:40 am, "Adam W." <[EMAIL PROTECTED]> wrote:
> After a fair amount of troubleshooting of why my lists were coming
> back a handful of digits short, and the last digit rounded off, I
> determined the str() function was to blame:
>
> >>> foonum
>
> 0.0071299720384678782
>
> >>> str(foonum)
> '0.00712997203847'
>
> Why in the world does str() have any business rounding my numbers, and
> how do I get around this?

If 15 digit precision is a concern, I would suggest that you us the
decimal class instead of floating points.  Floating point problems on
X86 machines are well documented.
http://docs.python.org/lib/module-decimal.html
http://pydoc.org/2.4.1/decimal.html
http://gmpy.sourceforge.net/

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

Re: Ligmail bug?

[Steve Holden]

No.23 wrote:
[way too much, ending with]
>File "/usr/local/lib/python2.5/urllib2.py", line 1076, in do_open
>  raise URLError(err)
>  urllib2.URLError:  resolution')>
> 
> 
> other information:
> Shell:~ >: uname -a
> OpenBSD ob41.org 4.1 ob41#0 i386
> Shell:~ >: python
> Python 2.5 (r25:51908, Mar  8 2007, 20:46:47)
> [GCC 3.3.5 (propolice)] on openbsd4
> Type "help", "copyright", "credits" or "license" for more information.
 import libgmail
 print libgmail.Version
> 0.1.6
> 
> 
So why does a temporary failure in name resolution seem like a library 
bug? This is just the library reporting back an error from the network 
or transport layer.

Is the error repeatable? How many times over what period of time have 
you experienced it?

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

ANN: Compyler 0.1

[Grant Olson]

Compyler is a pre-alpha x86 native code compiler.  So far it can generate
primitive .pyds but not standalone executables.  It can run some simple test
cases including pystones (although there is a memory leak there).  And no, I
don't expect it'll ever be much faster than Cpython . I was primarily
interested in being able to distribute low-footprint standalone executables
written in python and code obfustication.

The basic approach taken by compyler is to transliterate python bytecode
into x86 assembly, instead of trying to generate assembly from the syntax
tree.

This is basically abandonware.  I haven't touched this in six months, but
did do a lot of up front work.  I basically wanted to release it before my
hardrive blows up in case anyone was looking for prior art.

The code also contains a version of pyasm that has some more patches and
features than the official distribution if you're one of pyasm's 3 users.

More info can be found at:

http://members.verizon.net/~olsongt/compyler/index.html


-Grant

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

Re: python 2.5 bug

[vedrandekovic]

On 11 kol, 20:58, Thorsten Kampe <[EMAIL PROTECTED]> wrote:
> * Laurent Pointal (Sat, 11 Aug 2007 20:09:03 +0200)
>
> >  [EMAIL PROTECTED] wrote:
> > > On 11 kol, 11:59, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> > >> On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote:
> > >> > I was install Python 2.5 and uninstall Python 2.4 now I cannot run my
> > >> > scripts, only from idle
>
> > IMHO Python 2.4 was registered for .py files, Python 2.5 take precedence
> > when installed, but when Python 2.4 has been removed, it remove .py files
> > association too (so break Python 2.5 association).
>
> > * manually associate .py/.pyc/.pyo files to python.exe, .pyw files to
> > pythonw.exe.
>
> > * or reinstall Python 2.5 so that it re-setup ad-hoc associations.
>
> Yeah. Did the Original Poster mention any details about his problem.
> Like - for instance - that he's using Windows?
>
> Thorsten

Hello,

Now I was restart my windows and python 2.5 also.Now everything works
fine except python and py2exe script install ( of course something
must destroy my day ) now when I run:

$ cd c:\Python25\Lib\site-packages\
$ python mysetup.py py2exe
'python' is not recognized as an internal or external command,
operable program or batch file.

why?


Regards,
Vedran

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

SUCK my HUSBAND'S CUM from my CUNT

[Tony]

 

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

SUCK my HUSBAND'S CUM from my CUNT

[Tony]

 

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

Re: Something in the function tutorial confused me.

[Gregory D. Weber]

Neil Cerutti wrote:
> On 2007-08-11, Alex Martelli <[EMAIL PROTECTED]> wrote:
>> Neil Cerutti <[EMAIL PROTECTED]> wrote:
>>...
>>> The Python Language Reference seems a little confused about the
>>> terminology.
>>>
>>>   3.4.7 Emulating numeric types
>>>   6.3.1 Augmented assignment statements
>>>
>>> The former refers to "augmented arithmetic operations", which I
>>> think is a nice terminology, since assignment is not necessarily
>>> taking place. Then the latter muddies the waters.
>> Assignment *IS* "necessarily taking place"; if you try the augmented
>> assignment on something that DOESN'T support assignment, you'll get an
>> exception.  Consider:
>>
> tup=([],)
> tup[0] += ['zap']
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> TypeError: 'tuple' object does not support item assignment
>>
>> Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT,
>> so tuples don't allow a += on any of their items.
>>
>> If you thought that += wasn't an assignment, this behavior and
>> error message would be very problematic; since the language
>> reference ISN'T confused and has things quite right, this
>> behavior and error message are perfectly consistent and clear.
> 
> Thanks for the correction. I was under the illusion that
> sometimes augmented assignment would instead mutate the
> object.
> 

I too thought += was an assignment.  And it bit me very painfully a few weeks 
ago.

If it's an assignment, then wouldn't "x += y" mean the same thing as "x = x + 
y"?

If so, why does an assignment to variable a, below, have the *side effect* of 
changing variable b ... ?

>>> a = [1, 2, 3]
>>> b = a
>>> b
[1, 2, 3]
>>> a += [4]
>>> a
[1, 2, 3, 4]
>>> b
[1, 2, 3, 4]

... but using the "x = x + y" style, the assignment to variable c, below, does 
*not* have a side effect on variable d (as indeed it should not!)?

>>> c = [1, 2, 3]
>>> d = c
>>> d
[1, 2, 3]
>>> c = c + [4]
>>> c
[1, 2, 3, 4]
>>> d
[1, 2, 3]
>>> 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Something in the function tutorial confused me.

[Roel Schroeven]

Gregory D. Weber schreef:
> Neil Cerutti wrote:
>> On 2007-08-11, Alex Martelli <[EMAIL PROTECTED]> wrote:
>>> Neil Cerutti <[EMAIL PROTECTED]> wrote:
>>>...
 The Python Language Reference seems a little confused about the
 terminology.

   3.4.7 Emulating numeric types
   6.3.1 Augmented assignment statements

 The former refers to "augmented arithmetic operations", which I
 think is a nice terminology, since assignment is not necessarily
 taking place. Then the latter muddies the waters.
>>> Assignment *IS* "necessarily taking place"; if you try the augmented
>>> assignment on something that DOESN'T support assignment, you'll get an
>>> exception.  Consider:
>>>
>> tup=([],)
>> tup[0] += ['zap']
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>> TypeError: 'tuple' object does not support item assignment
>>>
>>> Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT,
>>> so tuples don't allow a += on any of their items.
>>>
>>> If you thought that += wasn't an assignment, this behavior and
>>> error message would be very problematic; since the language
>>> reference ISN'T confused and has things quite right, this
>>> behavior and error message are perfectly consistent and clear.
>> Thanks for the correction. I was under the illusion that
>> sometimes augmented assignment would instead mutate the
>> object.
>>
> 
> I too thought += was an assignment.  And it bit me very painfully a few weeks 
> ago.

It is an assignment, but not only an assignment: first either the 
creation of a new object (in case of immutable objects) or the 
modification of an existing object (in case of mutable objects), than an 
assignment.

> If it's an assignment, then wouldn't "x += y" mean the same thing as "x = x + 
> y"?

No:
- x += y, x is only evaluated once
- in x += y, the operation is performed in-place if possible, meaning 
that (quoting from the language reference): rather than creating a new 
object and assigning that to the target, the old object is modified instead

> If so, why does an assignment to variable a, below, have the *side effect* of 
> changing variable b ... ?
> 
 a = [1, 2, 3]
-> A list is created and assigned to a
 b = a
-> That list is also assigned to b
 b
> [1, 2, 3]
 a += [4]
-> The list is modified (the list [4] is added to it) and assigned to a. 
It was already assigned to a, so that assignment doesn't do very much in 
this case. But it is performed.
 a
> [1, 2, 3, 4]
 b
> [1, 2, 3, 4]
-> Both a and b are still bound to the original (but now modified) list 
object

> ... but using the "x = x + y" style, the assignment to variable c, below, 
> does *not* have a side effect on variable d (as indeed it should not!)?
> 
 c = [1, 2, 3]
-> A list is created and assigned to c
 d = c
-> That list is also assigned to d
 d
> [1, 2, 3]
 c = c + [4]
-> A new list object is created (the sum of the original one and the 
list [4]) and assigned to c
 c
> [1, 2, 3, 4]
-> c is now bound to the new list object
 d
> [1, 2, 3]
-> ... while d is still bound to the original list object


I hope this clears up things a bit...

-- 
If I have been able to see further, it was only because I stood
on the shoulders of giants.  -- Isaac Newton

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

Re: Metaclass v.s. Property function.

[Dustan]

On Aug 11, 7:33 am, Jens Thiede <[EMAIL PROTECTED]> wrote:
> I don't like the property function, usable in the new-style classes,
> because having to remember to manage a list of "foo = property(...)"
> assignments just plain sucks, so I wrote a metaclass that does things
> a little differently. Please have a look and tell me whether this is
> useful or impractical. The metaclass is here:http://pastebin.com/m5b06b571
> and some simple testcode is here:http://pastebin.com/m382f2ae9.
> Notice the first line though.

Are you overusing property, by any chance? In your example, bar seems
to be an unneeded property; it could just be a normal attribute.

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

Re: Augmented assignment (was Re: Something in the function tutorial confused me.)

[Aahz]

In article <[EMAIL PROTECTED]>,
OKB (not okblacke) <[EMAIL PROTECTED]> wrote:
>
>   This sentence is phrased as though it is the whole story, but it 
>isn't, because the operation might not in fact wind up being an 
>assignment.  Shouldn't there be an "except see below" or something 
>there, to alert the reader that in some cases a true assignment doesn't 
>occur?  (I realize that the exception follows quite closely on the heels 
>of this sentence, but it doesn't follow immediately, and is separated by 
>a paragraph break and intervening material about the parallel to 
>unaugmented x = x + 1.  On initial reading my tendency is to read the 
>end of the sentence quoted above, see a paragraph break and apparently 
>explanatory material, and go "oh, okay, I now have the full 
>specification of this syntax" when in fact I don't.)

That's a good idea -- doc patches are always welcome!
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"And if that makes me an elitist...I couldn't be happier."  --JMS
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Augmented assignment (was Re: Something in the function tutorial confused me.)

[Aahz]

In article <[EMAIL PROTECTED]>,
Roel Schroeven  <[EMAIL PROTECTED]> wrote:
>
>I used to interpret the target in 'The target is only evaluated once' 
>more like an L-value in C/C++. That's not correct, of course, but I 
>didn't understand exactly how wrong it was until now.

It's true almost everywhere except augmented assignment.  Augmented
assignment is a prime example of the compromises one needs to make in
adding features.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"And if that makes me an elitist...I couldn't be happier."  --JMS
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Who told str() to round my int()'s!!!

[John Machin]

On Aug 12, 5:37 am, Zentrader <[EMAIL PROTECTED]> wrote:
> On Aug 11, 9:40 am, "Adam W." <[EMAIL PROTECTED]> wrote:
>
> > After a fair amount of troubleshooting of why my lists were coming
> > back a handful of digits short, and the last digit rounded off, I
> > determined the str() function was to blame:
>
> > >>> foonum
>
> > 0.0071299720384678782
>
> > >>> str(foonum)
> > '0.00712997203847'
>
> > Why in the world does str() have any business rounding my numbers, and
> > how do I get around this?
>
> If 15 digit precision is a concern, I would suggest that you us the
> decimal class instead of floating points.  Floating point problems on
> X86 machines are well 
> documented.http://docs.python.org/lib/module-decimal.htmlhttp://pydoc.org/2.4.1/decimal.htmlhttp://gmpy.sourceforge.net/

If you are concerned with precision of *communication*:

The problem is not with floating "points" in general; floating point
arithmetic can be done using a decimal representation for the numbers.
The problem is not with "X86" machines in particular; just about all
modern machines have floating point hardware which implements the IEEE
754 standard for binary flaoting point arithmetic. The problem is with
trying to represent in one base (e.g. 10) a non-integer number that is
expressed in a different base (e.g. 2) -- where the number can be
represented exactly only in one base (e.g. 1./10.) or in neither (e.g.
1./3.)

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

Re: Something in the function tutorial confused me.

[David Wahler]

On 8/11/07, Gregory D. Weber <[EMAIL PROTECTED]> wrote:
> I too thought += was an assignment.  And it bit me very painfully a few weeks 
> ago.
>
> If it's an assignment, then wouldn't "x += y" mean the same thing as "x = x + 
> y"?
>
> If so, why does an assignment to variable a, below, have the *side effect* of 
> changing variable b ... ?
>
> >>> a = [1, 2, 3]
> >>> b = a
> >>> b
> [1, 2, 3]
> >>> a += [4]
> >>> a
> [1, 2, 3, 4]
> >>> b
> [1, 2, 3, 4]
>
> ... but using the "x = x + y" style, the assignment to variable c, below, 
> does *not* have a side effect on variable d (as indeed it should not!)?
>
> >>> c = [1, 2, 3]
> >>> d = c
> >>> d
> [1, 2, 3]
> >>> c = c + [4]
> >>> c
> [1, 2, 3, 4]
> >>> d
> [1, 2, 3]

>>> help(list.__iadd__)
Help on wrapper_descriptor:

__iadd__(...)
x.__iadd__(y) <==> x+=y

For mutable (built-in) objects such as lists, __iadd__ modifies the
list and then returns the list object; for immutable objects, __iadd__
is equivalent to __add__ and just returns the new value. However, in
both cases, the result is then rebound to x. This can lead to some
behaviors you might not normally expect:

>>> t = ([],)
>>> t[0] += [1]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'tuple' object does not support item assignment
>>> t
([1],)

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

Re: Who told str() to round my int()'s!!!

[Bjoern Schliessmann]

Adam W. wrote:

> Why in the world does str() have any business rounding my numbers,

You are at the floating point numbers precision limit. Using str,
numbers are rounded to your machine's float precision in decimal
notation. Since floats are internally represented in binary
notation of constant precision, the decimal precision expressed in
number of places is not constant. Thus, safe rounding must be
applied to get consistent results.

> and how do I get around this?

If you don't want this (and thus introduce random deviations if you
assume greater precision than the number of places str gives you),
use repr. You've been warned.

>>> foonum = .0071299720384678782
>>> foonum
0.0071299720384678782
>>> str(foonum)
'0.00712997203847'
>>> repr(foonum)
'0.0071299720384678782'

Regards,


Björn

-- 
BOFH excuse #5:

static from plastic slide rules

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

Re: Public Telnet Server?

[Bjoern Schliessmann]

Dave wrote:

> Hi there. I'm a beginner at Python and I'm writing my first Python
> script. It's a text adventure about coffee and mixing drinks and
> being crazy and such. I keep updating it and want my friends to
> beta test it for me, but some of them don't have the right version
> of Python or don't want to get Python at all.

Sounds like Windows users. Isn't py2exe an option?

Regards,


Björn

-- 
BOFH excuse #339:

manager in the cable duct

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

Re: python 2.5 bug

[Bjoern Schliessmann]

Thorsten Kampe wrote:

> Yeah. Did the Original Poster mention any details about his
> problem. Like - for instance - that he's using Windows?

Don't you know the empiric law of platforms? :) "Users who ask about
OS specific problems and not state their platform are Windows
users."

Regards,


Björn

-- 
BOFH excuse #284:

Electrons on a bender

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

Re: The Future of Python Threading

[Bjoern Schliessmann]

Nick Craig-Wood wrote:
> Bjoern Schliessmann <[EMAIL PROTECTED]>

>>  So, how much performance gain would you get? Again, managing
>>  fine-grained locking can be much more work than one simple lock.
> 
> Assuming that you are not IO bound, but compute bound and that
> compute is being done in python then you'll get a speed up
> proportional to how many processors you have, minus a small amount
> for locking overhead.

Assuming this: Agreed.
 
Regards,


Björn

-- 
BOFH excuse #348:

We're on Token Ring, and it looks like the token got loose.

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

Re: python 2.5 bug

[Thorsten Kampe]

*  (Sat, 11 Aug 2007 12:50:38 -0700)
> On 11 kol, 20:58, Thorsten Kampe <[EMAIL PROTECTED]> wrote:
> > * Laurent Pointal (Sat, 11 Aug 2007 20:09:03 +0200)
> > >  [EMAIL PROTECTED] wrote:
> > > > On 11 kol, 11:59, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> > > >> On Sat, 11 Aug 2007 02:41:26 -0700, vedrandekovic wrote:
> > > >> > I was install Python 2.5 and uninstall Python 2.4 now I cannot run my
> > > >> > scripts, only from idle
> >
> > > IMHO Python 2.4 was registered for .py files, Python 2.5 take precedence
> > > when installed, but when Python 2.4 has been removed, it remove .py files
> > > association too (so break Python 2.5 association).
> >
> > > * manually associate .py/.pyc/.pyo files to python.exe, .pyw files to
> > > pythonw.exe.
> >
> > > * or reinstall Python 2.5 so that it re-setup ad-hoc associations.
> >
> > Yeah. Did the Original Poster mention any details about his problem.
> > Like - for instance - that he's using Windows?
> >
> Now I was restart my windows and python 2.5 also.Now everything works
> fine except python and py2exe script install ( of course something
> must destroy my day ) now when I run:
> 
> $ cd c:\Python25\Lib\site-packages\
> $ python mysetup.py py2exe
> 'python' is not recognized as an internal or external command,
> operable program or batch file.
> 
> why?

Because the directory containing python.exe is not in your path. By 
the way: the Python installation routine doesn't modify your path so 
it is likely unrelated to that.

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

Re: The Future of Python Threading

[Ben Sizer]

On Aug 10, 5:13 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> On 8/10/07, Ben Sizer <[EMAIL PROTECTED]> wrote:
>
> > On 10 Aug, 15:38, Ben Finney <[EMAIL PROTECTED]>
> > wrote:
> > > Last I checked, multiple processes can run concurrently on multi-core
> > > systems. That's a well-established way of structuring a program.
>
> > It is, however, almost always more complex and slower-performing.
>
> > Plus, it's underdocumented. Most academic study of concurrent
> > programming, while referring to the separately executing units as
> > 'processes', almost always assume a shared memory space and the
> > associated primitives that go along with that.
>
> This is simply not true. Firstly, there's a well defined difference
> between  'process' and a 'thread' and that is that processes have
> private memory spaces. Nobody says "process" when they mean threads of
> execution within a shared memory space and if they do they're wrong.

I'm afraid that a lot of what students will be taught does exactly
this, because the typical study of concurrency is in relation to
contention for shared resources, whether that be memory, a file, a
peripheral, a queue, etc. One example I have close to hand is
'Principles of Concurrent and Distributed Programming', which has no
mention of the term 'thread'. It does have many examples of several
processes accessing shared objects, which is typically the focus of
most concurrent programming considerations.

The idea that processes have memory space completely isolated from
other processes is both relatively recent and not universal across all
platforms. It also requires you to start treating memory as
arbitrarily different from other resources which are typically
shared.

> And no, "most" academic study isn't limited to shared memory spaces.
> In fact, almost every improvement in concurrency has been moving
> *away* from simple shared memory - the closest thing to it is
> transactional memory, which is like shared memory but with
> transactional semantics instead of simple sharing.

I think I wasn't sufficiently clear; research may well be moving in
that direction, but you can bet that the typical student with their
computer science or software engineering degree will have been taught
far more about how to use synchronisation primitives within a program
than how to communicate between arbitrary processes.

> There's nothing "undocumented" about IPC. It's been around as a
> technique for decades. Message passing is as old as the hills.

I didn't say undocumented, I said underdocumented. The typical
programmer these days comes educated in at least how to use a mutex or
semaphore, and will probably look for that capability in any language
they use. They won't be thinking about creating an arbitrary message
passing system and separating their project out into separate
programs, even if that has been what UNIX programmers have chosen to
do since 1969. There are a multitude of different ways to fit IPC into
a system, but only a few approaches to threading, which also happen to
coincide quite closely to how low-level OS functionality handles
processes meaning you tend to get taught the latter. That's why it's
useful for Python to have good support for it.

> > Hardly. Sure, so you don't have to worry about contention over objects
> > in memory, but it's still completely asynchronous, and there will
> > still be a large degree of waiting for the other processes to respond,
> > and you have to develop the protocols to communicate. Apart from
> > convenient serialisation, Python doesn't exactly make IPC easy, unlike
> > Java's RMI for example.
>
> There's nothing that Python does to make IPC hard, either. There's
> nothing in the standard library yet, but you may be interested in Pyro
> (http://pyro.sf.net) or Parallel Python
> (http://www.parallelpython.com/). It's not erlang, but it's not hard
> either. At least, it's not any harder than using threads and locks.

Although Pyro is good in what it does, simple RPC alone doesn't solve
most of the problems that typical threading usage does. IPC is useful
for the idea of submitting jobs in the background but it doesn't fit
so well to situations where there are parallel loops both acting on a
shared resource. Say you have a main thread and a network reading
thread - given a shared queue for the data, you can safely do this by
adding just 5 lines of code: 2 locks, 2 unlocks, and a call to start
the networking thread. Implementing that using RPC will be more
complex, or less efficient, or probably both.

--
Ben Sizer

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

Re: I am giving up perl because of assholes on clpm -- switching to Python

[Robert Dailey]

I had this very same problem with the doxygen mailing list... doxygen is
such a great tool but full of assholes in their mailing list.

On 8/2/07, Jamie <[EMAIL PROTECTED]> wrote:
>
> In <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] mentions:
> >Python is a better language, with php support, anyway, but I am fed up
> >with attitudes of comp.lang.perl.misc. Assholes in this newsgroup ruin
> >Perl experience for everyone. Instead of being helpful, snide remarks,
> >back-biting, scare tactings, and so on proliferate and self
> >reinforce. All honest people have left this sad newsgroup. Buy bye,
> >assholes, I am not going to miss you!!!
> >
> >Martha
>
> I've heard people tell the same story, that perl folks are... rude.
>
> Actually, I've pretty much heard (and noticed) that about linux, too.
>
> Yet, linux is still a good operating environment, so is perl.
>
> You'll find rude people everywhere you look. While it may be true that
> there is a higher percentage of hard-core tech folks who might lack
> social skills, at least they don't err.. well, maybe they do.. byte. :-)
>
> Seriously, it is one of the problems facing perl (and linux) people ARE
> turned away by the attitude. It is rather embarassing/unflattering when
> someone is critical of your work.
>
> I see a lot of ideas about things should be "made easier" but I think
> thats the wrong course. We really just need to be nicer to new folks.
>
> Jamie
> --
> http://www.geniegate.comCustom web programming
> Perl * Java * UNIXUser Management Solutions
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Something in the function tutorial confused me.

[Neil Cerutti]

> On 2007-08-11, Alex Martelli <[EMAIL PROTECTED]> wrote:
>> Neil Cerutti <[EMAIL PROTECTED]> wrote:
>>...
>>> The Python Language Reference seems a little confused about
>>> the terminology.
>>> 
>>>   3.4.7 Emulating numeric types
>>>   6.3.1 Augmented assignment statements
>>> 
>>> The former refers to "augmented arithmetic operations", which
>>> I think is a nice terminology, since assignment is not
>>> necessarily taking place. Then the latter muddies the waters.
>>
>> Assignment *IS* "necessarily taking place"; if you try the
>> augmented assignment on something that DOESN'T support
>> assignment, you'll get an exception.  Consider:
>>
> tup=([],)
> tup[0] += ['zap']
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> TypeError: 'tuple' object does not support item assignment
>>
>> Tuples don't support item ASSIGNMENT, and += is an ASSIGNMENT,
>> so tuples don't allow a += on any of their items.
>>
>> If you thought that += wasn't an assignment, this behavior and
>> error message would be very problematic; since the language
>> reference ISN'T confused and has things quite right, this
>> behavior and error message are perfectly consistent and clear.
>
> Thanks for the correction. I was under the illusion that
> sometimes augmented assignment would instead mutate the object.

OK, I've thought about this some more and I think the source of
my confusion was I thought assignment in Python meant binding a
name to something, not mutating an object. But in the case of
augmented assignment, assignment no longer means that?

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

Re: The Future of Python Threading

[Ant]

On Aug 11, 5:43 am, Seun Osewa <[EMAIL PROTECTED]> wrote:
> > I think I've heard Guido say the last attempt at removing the Global
> > Interpreter Lock (GIL) resulted in a Python that was much slower...
>
> What is it about Python that makes a thread-safe CPython version much
> slower?  Why doesn'ttrue threading slow down other languages like Perl
> and Java?

I have no idea about Perl - but there's probably some hideous black
magic going on ;-)

As for Java, making code thread safe *does* slow down the code. It is
the very reason that the language designers made the collections API
non-thread safe by default (you have to wrap the standard collections
in a synchronised wrapper to make them thread safe).

--
Ant...


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

Re: I am giving up perl because of assholes on clpm -- switching to Python

[Greg Donald]

On 8/11/07, Robert Dailey <[EMAIL PROTECTED]> wrote:
> I had this very same problem with the doxygen mailing list... doxygen is
> such a great tool but full of assholes in their mailing list.

I'm not defending any assholes you may have ran into, but I find the
thing to do is only ask questions in such a way that no one can
possibly have a reason to be an asshole.

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


-- 
Greg Donald
http://destiney.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Threading problem when many sockets open

[Philip Zigoris]

Hi all,

I have written a socket based service in python and under fairly heavy
traffic it performs really well.  But i have encountered the following
problem: when the system runs out of file descriptors, it seems to
stop switching control between threads.

Here is some more detail:

The system has n+2 threads, where n is usually around 10.  This was
implemented using the 'threading' and 'socket' modules in the python
2.5 standard library.

-- The "master" thread accepts new socket connections and then
enqueues the connection on a Queue (from the standard library).

-- There are n "handler threads" that pop a connection off of the
queue, read some number of bytes (~10), do some processing and then
send ~100 bytes back over the connection and close it.

-- The last thread is just a logging thread that has a queue of
messages that it writes to either stdout or a file.

Under pretty substantial load, the processing is quick enough that the
connections do not pile up very quickly.  But, in some cases they do.
And what I found was that as soon as the size of the Queue of
connections reached a high enough number (and it was always the same),
all of the processing seemed to stay in the "master" thread.  I
created a siege client that opened up 1000+ connections and the server
would go into a state where the master thread repeatedly polled the
socket and printed an error.  The Queue size stayed fixed at 997 even
if i shut down all of the connectionso n the client side.  Under
normal operating conditions, those connections would be detected as
broken in the handler thread and a message would be logged.  So it
seems that the "handler" threads aren't doing anything. (And they are
still alive, i check that in the master thread).

OK.  I hope all of this is clear.  Currently, I've solved the problem
by putting a cap on the queue size and i haven't seen the problem
reoccur.  But it would be nice to understand exactly what went wrong.

Thanks in advance.

-- 
--
Philip Zigoris I SPOCK I 650.366.1165
Spock is Hiring!
www.spock.com/jobs
-- 
http://mail.python.org/mailman/listinfo/python-list

C++ Runtime Library error message - Pythonwin?

[goldtech]

Hi,

Doing GIS [Geographic Information Systems] scripts.

I was running a batch clip script that worked OK for 126 iterations
 then I got the following message:

"Microsoft Visual C++ Runtime Library

program: C:\python21\pythonwin\pythonwin.exe

This application has requested the runtime to terminate in an unusual
 way. Please contact the applications support team for more
information."


What does this mean? Using XP. Is there a log on my system that gives
more info?

Thanks

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

Binary, Hex, and Decimal string conversions

[Robert Dailey]

Hi, I was wondering if there is a built in module that supports conversion
in any direction between Binary, Hex, and Decimal strings? Thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

New Programms for free

[Hasipups]

http://www.pennergame.de/ref.php?uid=5572

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

Re: Something in the function tutorial confused me.

[Alex Martelli]

Neil Cerutti <[EMAIL PROTECTED]> wrote:
   ...
> OK, I've thought about this some more and I think the source of
> my confusion was I thought assignment in Python meant binding a
> name to something, not mutating an object. But in the case of
> augmented assignment, assignment no longer means that?

"Plain" assignment *to a plain name* does mean "binding a name" (the
LHS) to "something" (the RHS).

Other assignments (ones that are not "plain" assignments to names) may
have different meanings.  For example:

>>> class act(object):
...   def __init__(self, c): self._c = c
...   def getC(self): return self._c
...   def setC(self, *ignore): self._c += 1
...   c = property(getC, setC)
...   
>>> x = act(0)
>>> x.c
0
>>> x.c = 23
>>> x.c
1
>>> 

Here's an example where a plain assignment (to an attribute of x, not to
a plain name) obviously DOESN'T mean "binding a name to something": the
"something" (the RHS) is completely ignored, so the plain assignment is
mutating an object (x) and not binding any name to anything.

Plain assignments to items and slices can also often be best seen as
"mutating an object" (the one being indexed or sliced on the LHS) rather
than "binding a name".  For example:

>>> l=list('ciao')
>>> l[1:3]='app'
>>> l
['c', 'a', 'p', 'p', 'o']

If I was teaching Python and came upon this example, I would definitely
not try to weaselword the explanation of what's going on in terms of
"binding a name" (or several ``names'', including ``rebinding" a new
``name'' l[4] to the 'o' that was previously ``bound'' to l[3], etc:-):
it's just orders of magnitudes simpler to explain this as "mutating an
object", namely the list l.

I take almost 3 pages in "Python in a Nutshell" (47 to 49 in the second
edition) to summarily explain every kind assignment -- and that's in a
work in which I've tried (successfully, I believe from reviews) to be
very, *VERY* concise;-).

Summarizing that summary;-), a plain assignment to an identifier binds
that name; a plain assignment to an attribute reference x.y asks object
x (x can be any expression) to bind its attribute named 'y'; a plain
assignment to an indexing x[y] (x and y are arbitrary expressions) asks
object x to bind its item indicated by the value of y); a plain
assignment to a slicing is equivalent to the plain assignment to the
indexing with an index of slice(start, stop, stride) [[slice is a Python
builtin type]].

Plain assignment to an identifier "just happens"; all other cases of
plain assignment are requests to an object to bind one or more of its
attributes or items (i.e., requests for specific mutations of an object)
-- as for, say any method call (which might also be a request for some
kind of mutation), the object will do whatever it pleases with the
request (including, perhaps, "refusing" it, by raising an exception).

Then we get into unpacking assignments and augmented assignments, but I
don't really want to write two more pages worth of summary...;-).


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

Pausing and Unpausing Threads

[Aaron J. M.]

Hello,

This is a question about how to pause and unpause threads (as the
title suggests).

I've created an extension of threading.Thread which I'll call Server.
Server has a collection of Controlers.  A Controler has a method
turn(), which lets it do various interesting things.  While the
Server is running, it loops through each of its Controlers and calls
their turn() method.

One of these Controlers is a subclass called DirectedControler.
What a DirectedControler is meant to do is wait until it is given an
Action object it can invoke.  Actions are basically an implementation
of the Command pattern.  Actions are also invalid in certain
circumstances; they return False when executed if they didn't do
anything.  Therefore, when a DirectedControler is given a turn, it
waits while:
- It has no Action
- The last Action it was given didn't do anything

Actions are sent to the DirectedControler by a Client that exists in
the main thread.

What I'm trying to figure out is how to make the DirectedControler
pause while it is waiting for a valid Action.  So far I just put it
into a loop like this:

def turn(self):
while self.__action is None or not self.__action.execute():
self.__action = None # Throw away invalid actions
pass

self.__action = None # Action was valid.  Clear the way for the
 # next turn's Action.

Where the Action is set like this (by the Client):

def setAction(self, action):
if self.__action is None:
self.__action = action

I'm worried that this loop may wast some CPU cycles, and wonder if
there's a better way through thread synchronization using such things
as Events or Conditions.

Thank you,

Aaron J. M.

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

Re: wxPython - drawing without paint event

[glenn . chappell]

On Aug 11, 3:31 am, Bjoern Schliessmann  wrote:
>  [EMAIL PROTECTED] wrote:
> > On a related topic, it seems like it would be nice to do *all*
> > drawing in
> > response topaintevents. When I get aneventfrom the timer, I
> > would just tell wx that part of the window needs redrawing, and
> > depend on it to give me apainteven when nothing of higher
> > priority needs to be done.
>
> One nice strategy from an example in "wxPython in Action" is the
> following:
>
> * the frame has Draw methods that draw into a BufferedDC, which is
> chained to a bitmap member
>
> * inside thepaintmethod, the bitmap member is drawn to screen

Okay, but how do I tell wx that it needs to send me a paint event?

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

Re: python 2.5 bug

[Dustan]

On Aug 11, 12:32 am, Thorsten Kampe <[EMAIL PROTECTED]> wrote:
> 4. don't do something you don't fully understand (in this case
>installing Python 2.5 and uninstalling Python 2.4)

If we were all limited by that rule, none of us would never have used
a computer in the first place. Operating a computer is a learning
experience, no matter what level you're at (although admittedly the
lessons learned can sometimes be hurtful).

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

Re: Module imports during object instantiation

[Ritesh Raj Sarraf]

On Aug 11, 3:17 am, James Stroud <[EMAIL PROTECTED]> wrote:
> You do realize your import statement will only be called for nt and dos
> systems don't you?
>

Yes. I would like to load a Windows Python Module (which is, say a
specific implementation for Windows only) in such a condition where I
find that the platform is Dos/NT.

Loading it globally doesn't make sense because when from the same
class an object is created on a non-windows platfom, it would be
waste. It would either ImportError or else just load the module and
never use it.

As per my understanding __init__ is executed only once during object
creation. For such situations (that I've explained above), I think
__init__() is the correct place to put imports.

Ritesh

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

Re: Web based Reporting tool for Python

[Madhu Alagu]

On Aug 8, 4:57 pm, Jon Rosebaugh <[EMAIL PROTECTED]> wrote:
> On 2007-08-07 23:35:26 -0500, Madhu Alagu <[EMAIL PROTECTED]> said:
>
> > Thanking so much for all the informations and links.I would like to
> > use Mako Templates(www.makotemplates.org).Ilike to use simple and
> > python default module...
>
> Mako is an excellent template system, but you'll have a lot of work to
> do making it into a reporting system.



Any reporting template in python ?

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

Re: Destruction of generator objects

[Kay Schluehr]

On Aug 11, 2:50 pm, Stefan Bellon <[EMAIL PROTECTED]> wrote:

> So why is the destructor not called when the generator is even
> explicitly 'del'ed? Does somebody else still hold a reference on it?

You ( we ) have produced a reference cycle. In that case __del__
doesn't work properly ( according to the docs ). The cycle is caused
by the following assignment in your code:

   self.gen = self._value()

So we have to refactor the solution to eliminate the cycle. I spent
some time to create a generic decorator solution and a protocol for
handling / releasing the resources.

1) Create a FinalizerGenerator class that is cycle free ( of course
you can find a trick to shoot yourself in your foot ). Pass a
generator function together with its arguments into the constructor.
An additional callable attribute close is used together with __del__.

class FinalizerGenerator(object):
def __init__(self, gen, *args, **kwd):
print "gen init"
self._gen = gen# no cycle when passing the _value function
self.close = lambda: sys.stdout.write("gen del")  # assign
cleanup function

def __del__(self):
self.close()

def __iter__(self):
print "gen iter"
return self

def next(self):
print "gen next"
return self.gen.next()

2) Define generators s.t. they yield the resource to be destroyed as
their first value.

def producer(resource):
print "gen value"
yield resource   # yield resource before start iteration
for item in resource:
yield item

3) Define the destructor for the resource. The resource must be passed
as a first argument. The return value is a callable without arguments
that serves as a close() function within FinalizerGenerator.__del__
method.

def close_resource(resource):
return lambda: sys.stdout.write("close resource: %s"%resource)

4) The finalize_with decorator

def finalize_with(close_resource):
def closing(func_gen):
def fn(*args, **kwd):
# fg serves as a replacement for the original generator
func_def
fg = FinalizerGenerator(func_gen)(*args, **kwd)
# apply the closing protocol
resource = fg.next()
fg.close = close_resource(resource)
return fg
fn.__name__ = func_gen.__name__
return fn
return closing


5) decorate the generator and check it out

@finalize_with(close_resource)
def producer(resource):
print "gen value"
yield resource
for item in resource:
yield item

def test():
pg = producer([1,2,3])
pg.next()

>>> test()
gen init
gen next# request for resource in finalize_with
gen value
gen next
close resource: [1, 2, 3]  # yep


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

python + XUL

[Madhu Alagu]

Hi



Python + XUL Success Stories




Thanks

Madhu Alagu

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

Re: is there anybody using __del__ correctly??

[Michele Simionato]

On Aug 10, 7:09 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
> There were also a few recipes posted during this discussion that wrap
> weakrefs up a bit nicer so it's easier to use them in place of __del__:
>
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519635

I knew about your recipe and I thought it was clever, *very*
clever. I have been thinking about it a bit more today and
here is an alternative, which does not require metaclasses,
does not require descriptors, and does not require the user to
declare the attributes she will use in the __finalize__ method.
Warning: it is no more tested than the test case in your recipe:

import weakref

_get = object.__getattribute__
_set = object.__setattr__
_del = object.__delattr__

def getinnerobj(self):
return _get(self, '*innerobj*')

class Impostor(object):
"It tries very hard to impersonate the inner object"
def __init__(self, obj):
_set(self, '*innerobj*', obj)
def __getattribute__(self, name):
return getattr(getinnerobj(self), name)
def __setattr__(self, name, value):
_set(getinnerobj(self), name, value)
def __delattr__(self, name):
_del(getinnerobj(self), name)

_refset = set()

class Finalized(object):
def __new__(cls, *args, **kw):
self = super(Finalized, cls).__new__(cls, *args, **kw)
self.__init__(*args, **kw)
def finalize(ref, refset=_refset):
refset.remove(ref)
cls.__finalize__(self)
fake = Impostor(self)
_refset.add(weakref.ref(fake, finalize))
return fake
def __finalize__(self):
pass

Hope you will enjoy it,

   Michele Simionato

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

Database intensive application

[Rohit]

I am a novice. I want to know whether Python can be used to develop
client/server database and web applications like .NET. Which is the
best book/source to learn Python?

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