py2exe with python 2.5

[vedrandekovic]

Hello,

Now,I was install python 2.5 and remove python 2.4 completely.After I
write:
$ python mysetup.py py2exe
...
 import py2exe_ util
ImportError: Module use of conflicts with this version of Python

...ok, I know what is a problem, I haven't remove python completely,
in my computer is one more folder Panda3D-1.4.0 but when I remove it
and all dll files include python24.dll, I cannot run python or make
that setup.
(That panda3d contain python)


Regards,
Vedran

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

is there anybody using __del__ correctly??

[Michele Simionato]

The title is provocative, of course ;)

However, I was browsing through our codebase here at work and I
noticed a few
usages of __del__ as a resource finalizer (i.e. __del__ just calls a
close
method).

I consider this practice an error, since with __del__
you are never sure that the resource will be released
(http://docs.python.org/ref/customization.html#l2h-175) and anyway
this
should be done with try .. finally or the 'with' statement.

So I got into thinking: "yes, using __del__ as a resource finalizer is
wrong,
but then what are good use cases for it? Let's look at the standard
library and see what people use __del__ for".

So I did, and to my dismay 95% of the __del__ methods in the standard
library
are just calling a close method!!

In particular this happens in the following modules: (Python 2.5 on
Ubuntu):

 zipfile, wave, urllib, close, tarfile, sunau, shelve, httplib, gzip,
 fileinput, dumbdbm, audiodev, aifc, bsddb.dbshelve, tempfile, socket,
 platform, ... (I got tired after this point)

I see one good use case for __del__ in wsgiref.validate: here __del__
prints a warning if the resource is *not* closed explicitely.
Something
similar happens in subprocess and popen2, where __del__ updates the
list
of active processes.

So I am beginning to  wonder if there exists good use cases for
__del__,
apart for debugging/checking purposes. Can you provide some?
Yes, you may take that as a challenge ;)


  Michele Simionato


P.S. BTW, I should mention that if you search comp.lang.python for
__del__
you will find hundreds of people who were bitten by __del__, so I
usually give
advices such as "you should never __del__ in your code". If I am wrong
in
giving this advice, please let me know!

P.P.S. Here and there I hear rumors about deprecating __del__ and
nothing
happens, are there any news about that? Expecially concerning Py3k?

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

Re: The Future of Python Threading

[Jean-Paul Calderone]

On Fri, 10 Aug 2007 10:01:51 -, "Justin T." <[EMAIL PROTECTED]> wrote:
>Hello,
>
>While I don't pretend to be an authority on the subject, a few days of
>research has lead me to believe that a discussion needs to be started
>(or continued) on the state and direction of multi-threading python.
>
> [snip - threading in Python doesn't exploit hardware level parallelism
>  well, we should incorporate stackless and remove the GIL to fix this]
>

I think you have a misunderstanding of what greenlets are.  Greenlets are
essentially a non-preemptive user-space threading mechanism.  They do not
allow hardware level parallelism to be exploited.

In a hypothetical Python interpreter, equivalent to current CPython except
for the removal of the GIL, you could certainly have greenlets running in
different pthreads, and thus take care of hardware parallelism, but you
could do the same without greenlets too.

So Stackless Python is an unrelated matter.

>There has been much discussion on this in the past [2]. Those
>discussions, I feel, were premature. Now that stackless is mature (and
>continuation free!), Py3k is in full swing, and parallel programming
>has been fully realized as THE next big problem for computer science,
>the time is ripe for discussing how we will approach multi-threading
>in the future.

Many of the discussions rehash the same issues as previous ones.  Many
of them are started based on false assumptions or are discussions between
people who don't have a firm grasp of the relevant issues.

I don't intend to suggest that no improvements can be made in this area of
Python interpreter development, but it is a complex issue and cheerleading
will only advance the cause so far.  At some point, someone needs to write
some code.  Stackless is great, but it's not the code that will solve this
problem.

In the mean time, you might consider some multi-process solutions.  There
are a number of tools for getting concurrency like that.

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

Re: The Future of Python Threading

[Chris Mellon]

On 8/10/07, Ben Sizer <[EMAIL PROTECTED]> wrote:
> On 10 Aug, 15:38, Ben Finney <[EMAIL PROTECTED]>
> wrote:
> > "Justin T." <[EMAIL PROTECTED]> writes:
> > > The truth is that the future (and present reality) of almost every
> > > form of computing is multi-core, and there currently is no effective
> > > way of dealing with concurrency.
> >
> > Your post seems to take threading as the *only* way to write code for
> > multi-core systems, which certainly isn't so.
> >
> > 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.

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. Message passing and
"shared-nothing" concurrency are very popular and extremely effective,
both in performance and reliability.

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

> > > We still worry about setting up threads, synchronization of message
> > > queues, synchronization of shared memory regions, dealing with
> > > asynchronous behaviors, and most importantly, how threaded an
> > > application should be.
> >
> > All of which is avoided by designing the program to operate as
> > discrete processes communicating via well-defined IPC mechanisms.
>
> 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Future of Python Threading

[brad]

Justin T. wrote:
> Hello,
> 
> While I don't pretend to be an authority on the subject, a few days of
> research has lead me to believe that a discussion needs to be started
> (or continued) on the state and direction of multi-threading python.

This is all anecdotal... threads in Python work great for me. I like 
Ruby's green threads too, but I find py threads to be more robust. We've 
written a tcp scanner (threaded connects) and can process twenty ports 
on two /16s (roughly 171K hosts) in about twenty minutes. I'm happy with 
that. However, that's all I've ever really used threads for, so I'm 
probably less of an expert than you are :) I guess it comes down to what 
you're doing with them.

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

building a rather simple server in python

[boazin]

Hi all,

I was trying to build a rather simple server (with a twist) using
asyncore and got myself complicated.
Well, here's the deal:

My server will handle multiple connections, some require reply, and
some not (they will disconnect by themselves)
all the clients want to to deliver binary data to a socket we'll call
P socket. this socket is a device that hopefully always wating for new
data (It's actually a hardware).
The replies will come on a different socket, we'll call socket T. When
the server receives a reply (again binary data) it will send it to all
the "wating for reply" clients (the client will determine if it is for
him or not).
My problems arise when I need to write to socket P and then somehow,
somewhen, read the responses from socket T.

Hopefully, the description is clear enough

I tried to use asyncore and got tangled up with the reactiveness of
it.
Any ideas? how to use it with asyncore? other implementations?

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

cookielib

[Boris Ozegovic]

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?

-- 
Ne dajte da nas lažljivac Bandić truje:
http://cnn.blog.hr/arhiva-2007-06.html#1622776372
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: is there anybody using __del__ correctly??

[Steven Bethard]

Raymond Hettinger wrote:
> [Michele Simionato]
>>  Here and there I hear rumors about deprecating __del__ and
>> nothing
>> happens, are there any news about that? Expecially concerning Py3k?
> 
> I was writing a Py3K PEP advocating the elimination of __del__
> because:
> 
> * 'with closing()' and try/finally are the preferred ways of calling
> close()
> 
> * it is easy to accidently keep or introduce a reference that blocks
> the __del__ logic
> 
> * under-the-hood, the implementation of __del__ clashes badly with GC
> logic and is a maintenance nightmare
> 
> * the body of a __del__ method may unintentionally resurrect an object
> that was in the process of being deleted
> 
> For the PEP to have a chance, I neede to make build-outs to the
> weakref module so that existing use cases for __del__ can be easily
> migrated.  That hasn't been done yet, so the campaign to eliminate
> __del__ is stalled.

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
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519610
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519621

Since they're using weakrefs, you shouldn't have to worry about some of 
the weirdness of __del__.

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

Re: The Future of Python Threading

[Jean-Paul Calderone]

On Fri, 10 Aug 2007 16:37:19 -, "Justin T." <[EMAIL PROTECTED]> wrote:
>On Aug 10, 3:52 am, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>> On Fri, 10 Aug 2007 10:01:51 -, "Justin T." <[EMAIL PROTECTED]> wrote:
>> >Hello,
>>
>> >While I don't pretend to be an authority on the subject, a few days of
>> >research has lead me to believe that a discussion needs to be started
>> >(or continued) on the state and direction of multi-threading python.
>>
>> > [snip - threading in Python doesn't exploit hardware level parallelism
>> >  well, we should incorporate stackless and remove the GIL to fix this]
>>
>> I think you have a misunderstanding of what greenlets are.  Greenlets are
>> essentially a non-preemptive user-space threading mechanism.  They do not
>> allow hardware level parallelism to be exploited.
>
>I'm not an expert, but I understand that much. What greenlets do is
>force the programmer to think about concurrent programming. It doesn't
>force them to think about real threads, which is good, because a
>computer should take care of that for you.Greenlets are nice because
>they can run concurrently, but they don't have to. This means you can
>safely divide them up among many threads. You could not safely do this
>with just any old python program.

There may be something to this.  On the other hand, there's no _guarantee_
that code written with greenlets will work with pre-emptive threading instead
of cooperative threading.  There might be a tendency on the part of developers
to try to write code which will work with pre-emptive threading, but it's just
that - a mild pressure towards a particular behavior.  That's not sufficient
to successfully write correct software (where "correct" in this context means
"works when used with pre-emptive threads", of course).

One also needs to consider the tasks necessary to really get this integration
done.  It won't change very much if you just add greenlets to the standard
library.  For there to be real consequences for real programmers, you'd
probably want to replace all of the modules which do I/O (and maybe some
that do computationally intensive things) with versions implemented using
greenlets.  Otherwise you end up with a pretty hard barrier between greenlets
and all existing software that will probably prevent most people from changing
how they program.

Then you have to worry about the other issues greenlets introduce, like
invisible context switches, which can make your code which _doesn't_ use
pre-emptive threading broken.

All in all, it seems like a wash to me.  There probably isn't sufficient
evidence to answer the question definitively either way, though.  And trying
to make it work is certainly one way to come up with such evidence. :)

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

Re: The Future of Python Threading

[Justin T.]

On Aug 10, 3:57 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> Justin T. wrote:
> > Hello,
>
> > While I don't pretend to be an authority on the subject, a few days of
> > research has lead me to believe that a discussion needs to be started
> > (or continued) on the state and direction of multi-threading python.
> [...]
> > What these seemingly unrelated thoughts come down to is a perfect
> > opportunity to become THE next generation language. It is already far
> > more advanced than almost every other language out there. By
> > integrating stackless into an architecture where tasklets can be
> > divided over several parallelizable threads, it will be able to
> > capitalize on performance gains that will have people using python
> > just for its performance, rather than that being the excuse not to use
> > it.
>
> Aah, the path to world domination. You know you don't *have* to use
> Python for *everything*.
>
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.

>
> 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.

>
> I doubt that a thread on c.l.py is going to change much. It's the
> python-dev and py3k lists where you'll need to take up the cudgels,
> because I can almost guarantee nobody is going to take the GIL out of
> 2.6 or 2.7.
>

I was hoping to get a constructive conversation on what the structure
of a multi-threaded python would look like. It would appear that this
was not the place for that.

> Is it even possible
> to run threads of the same process at different priority levels on all
> platforms?
No, it's not, and even fewer allow the scheduler to change the
priority dynamically. Linux, however, is one that does.

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

building a rather simple server in python

[boazin]

Hi all,

I was trying to build a rather simple server (with a twist) using
asyncore and got myself complicated.
Well, here's the deal:

My server will handle multiple connections, some require reply, and
some not (they will disconnect by themselves)
all the clients want to to deliver binary data to a socket we'll call
P socket. this socket is a device that hopefully always wating for new
data (It's actually a hardware).
The replies will come on a different socket, we'll call socket T. When
the server receives a reply (again binary data) it will send it to all
the "wating for reply" clients (the client will determine if it is for
him or not).
My problems arise when I need to write to socket P and then somehow,
somewhen, read the responses from socket T.

Hopefully, the description is clear enough

I tried to use asyncore and got tangled up with the reactiveness of
it.
Any ideas? how to use it with asyncore? other implementations?

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

Leo 4.4.4 beta 1 released

[Edward K Ream]

Leo 4.4.4 beta is available at:
http://sourceforge.net/project/showfiles.php?group_id=3458&package_id=29106

Leo is a text editor, data organizer, project manager and much more. See:
http://webpages.charter.net/edreamleo/intro.html

The highlights of Leo 4.4.4:

- A threading_colorizer plugin replaces the __jEdit_colorizer__ plugin. 
This plugin features much better performance.

- Support for @auto nodes.  Such nodes allow people to collaborate using Leo 
without inserting Leo sentinels in the files Leo generates.

Links:
--
Leo:  http://webpages.charter.net/edreamleo/front.html
Home: http://sourceforge.net/projects/leo/
Download: http://sourceforge.net/project/showfiles.php?group_id=3458
CVS:  http://leo.tigris.org/source/browse/leo/
Quotes:   http://webpages.charter.net/edreamleo/testimonials.html


Edward K. Ream   email:  [EMAIL PROTECTED]
Leo: http://webpages.charter.net/edreamleo/front.html



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

Re: The Future of Python Threading

[Aahz]

In article <[EMAIL PROTECTED]>,
Nick Craig-Wood  <[EMAIL PROTECTED]> wrote:
>
>This would of course make C extensions more complicated...

It's even worse than that.  One of the goals for Python is to make it
easy to call into random libraries, and there are still plenty around
that aren't thread-safe (not even talking about thread-hot).
-- 
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: Ipc mechanisms and designs.

[Alex Martelli]

king kikapu <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> inspired of the topic "The Future of Python Threading", i started to
> realize that the only way to utilize the power of multiple cores using
> Python, is spawn processes and "communicate" with them.
> 
> If we have the scenario:
> 
> 1. Windows (mainly) development
> 2. Processes are running in the same machine
> 3. We just want to "pass" info from one process to another. Info may
> be simple data types or user defined Python objects.
> 
> what is the best solution (besides sockets) that someone can implement
> so to have 2 actually processes that interchanged data between them ?
> I looked at Pyro and it looks really good but i wanted to experiment
> with a simpler solution.

Check out 


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

Re: The Future of Python Threading

[Ben Sizer]

On 10 Aug, 15:38, Ben Finney <[EMAIL PROTECTED]>
wrote:
> "Justin T." <[EMAIL PROTECTED]> writes:
> > The truth is that the future (and present reality) of almost every
> > form of computing is multi-core, and there currently is no effective
> > way of dealing with concurrency.
>
> Your post seems to take threading as the *only* way to write code for
> multi-core systems, which certainly isn't so.
>
> 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.

> > We still worry about setting up threads, synchronization of message
> > queues, synchronization of shared memory regions, dealing with
> > asynchronous behaviors, and most importantly, how threaded an
> > application should be.
>
> All of which is avoided by designing the program to operate as
> discrete processes communicating via well-defined IPC mechanisms.

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.

--
Ben Sizer

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

Ipc mechanisms and designs.

[king kikapu]

Hi,

inspired of the topic "The Future of Python Threading", i started to
realize that the only way to utilize the power of multiple cores using
Python, is spawn processes and "communicate" with them.

If we have the scenario:

1. Windows (mainly) development
2. Processes are running in the same machine
3. We just want to "pass" info from one process to another. Info may
be simple data types or user defined Python objects.

what is the best solution (besides sockets) that someone can implement
so to have 2 actually processes that interchanged data between them ?
I looked at Pyro and it looks really good but i wanted to experiment
with a simpler solution.

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

Re: The Future of Python Threading

[Nick Craig-Wood]

Bjoern Schliessmann <[EMAIL PROTECTED]> wrote:
>  Justin T. wrote:
> 
> > The detrimental effects of the GIL have been discussed several
> > times and nobody has ever done anything about it. 
> 
>  Also it has been discussed that dropping the GIL concept requires
>  very fine locking mechanisms inside the interpreter to keep data
>  serialised. The overhead managing those fine ones properly is not
>  at all negligible, and I think it's more than managing 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%...

> > 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!

>  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.

The linux kernel has moved onwards to finer and finer grained locking.

I think one important point to learn from the linux experience is to
make the locking a compile time choice.  You can build a uniprocessor
linux kernel with all the locking taken out or you can build a
multi-processor kernel with fine grained locking.

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.

The user could then choose which python to run.

This would of course make C extensions more complicated...

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

Re: High performance binary data

[sturlamolden]

On Aug 10, 2:26 am, Steve <[EMAIL PROTECTED]> wrote:
> I want to ready binary data from a udp socket effeciently as possible
> in python.  I know of the struct package but do people have any tips
> when dealing with binary data in python?  Is there a library or api
> that is faster when dealing with binary data. I am looking for a any
> one with experience or ideas on the subject.  Pointers any one?

I would recommend NumPy for manipulating binary data. It is primarily
intended for numerics, but it is excellent for dealing with any kind
of binary data as well. It can handle mutable buffers of any kind of
integer or float, as well as arrays of C-like structs (record arrays
in numpy). You can typecast and create subarrays without copying any
data, simply by providing a new "view" into the buffer. You can also
get access to strided subsections without creating copies. And it is
very fast.

www.scipy.org

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

Re: The Future of Python Threading

[king kikapu]

> All of which is avoided by designing the program to operate as
> discrete processes communicating via well-defined IPC mechanisms.

Hi Ben,

i would like to learn more about this, have you got any links to give
me so i can have a look ?

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

Re: wxPython before MainLoop

[Steve Holden]

[david] wrote:
> [...] I don't think  wxPython is really ready for Windows.
> 
I don't think you are really ready to for GUIs ;-)

Fortunately, it doesn't matter what *I* think.

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: High performance binary data

[Nick Craig-Wood]

Steve <[EMAIL PROTECTED]> wrote:
>  I want to ready binary data from a udp socket effeciently as possible
>  in python.  I know of the struct package but do people have any tips
>  when dealing with binary data in python?  Is there a library or api
>  that is faster when dealing with binary data. I am looking for a any
>  one with experience or ideas on the subject.  Pointers any one?

Check out construct: http://construct.wikispaces.com/

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

Re: wxPython before MainLoop

[Bjoern Schliessmann]

[david] wrote:

> I'm disappointed that I didn't get a wxPython solution.
> 
> If the only way to get wxPython to correctly handle
> this simple task is to code around it, 

LOL -- did you try coding this app with native windows means, like
MFC? You will have *exactly* the same problem, and *exactly* for
the same reason. The organisation of wxWidgets (and thus, wxPython)
is very near to Windows GUI coding philosophy.

> I don't think wxPython is really ready for Windows.

I suggest you first went getting experience with other GUI libraries
before you make such statements. 

Also, wxPython is a thin wrapper around wxWidgets C++ library which
is widely used for Windows apps. And with wxWidgets, you'd *also*
have the same problem.

> Bjoern, you're wrong. The GUI needs to be displayed
> for the user to analyse. A delay between display and
> readiness is much better than a delay before display
> or a delay with the GUI half-drawn.

This may be, but it strongly depends on the application itself.
 
> Mike, the screen does display correctly, it's just
> that in Windows, screen updates are not processed
> while the application is busy.

That's the matter in just about *every* GUI framework using an event
loop. And I don't know any that doesn't. Thus, there are two widely
used standard solutions:

* use a worker thread, or

* call a "process all pending events now" function repeatedly during
  the work (here: wx.Yield, wx.SafeYield, wx.YieldIfNeeded).

Regards,


Björn

-- 
BOFH excuse #92:

Stale file handle (next time use Tupperware(tm)!)

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

Re: The Future of Python Threading

[Aahz]

In article <[EMAIL PROTECTED]>,
Steve Holden  <[EMAIL PROTECTED]> wrote:
>
>I doubt that a thread on c.l.py is going to change much. It's the 
>python-dev and py3k lists where you'll need to take up the cudgels, 
>because I can almost guarantee nobody is going to take the GIL out of 
>2.6 or 2.7.

Actually, python-ideas is the right place for this.  Threads have been
hashed and rehashed over and over and over and over and over again
through the years; python-dev and python-3000 should not get cluttered
because another Quixote rides up.
-- 
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

AttributeError: 'module' object has no attribute 'HTTPSHandler'

[[EMAIL PROTECTED]]

Hi
I built and installed python 2.5 from source and when I do this:

opener = urllib2.build_opener(SmartRedirectHandler(),
DefaultErrorHandler(), urllib2.HTTPSHandler())

I get this error.
AttributeError: 'module' object has no attribute 'HTTPSHandler'

What should I do?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Trent Mick]

Dick Moores wrote:
> At 06:13 PM 8/9/2007, Ben Finney wrote:
>> It's important to also realise that the language is *deliberately*
>> non-committal on whether any given value will have this behaviour;
>> that is, it's entirely left to the language implementation which
>> optimisation trade-offs to make, and the language user (that's you and
>> I) should *not* expect any particular behaviour to hold between
>> different implementations.
> 
> I'm not clear on the meaning of "implementations" 
> here.  Would 2.5 for Windows, Mac, Linux all be 
> different implementations? Would Iron Python be another? ActivePython?

(Note that I'm jumping into this without having read the thread, so 
apologies if I didn't grasp the question in its proper context.)

Separate Python "implementations" generally refers to a separate source 
code base for that Python build. According to that definition, current 
examples of Python implementations are: CPython (from python.org, 
C-based), Jython (Java-based), Stackless Python (I'm not that familiar 
to how much of the CPython source code, if any, Stackless borrows), 
IronPython (.NET/C#-based), possibly PyPy (Python-based, I'm not that 
familiar with it). Also eventually interesting might be the recently 
announced IronMonkey (http://wiki.mozilla.org/Tamarin:IronMonkey).

Windows, Mac, Linux, etc. installations/builds/installers of a 
particular implementation would be different platform *builds* (my 
language).

ActivePython is a separate (from python.org's) *distribution* of CPython 
-- i.e. the sample implementation as CPython (same source code). This is 
similar, in some respects, to SuSE, Debian, RedHat, Ubuntu, etc. being 
different distributions of Linux.


Trent

-- 
Trent Mick
trentm at activestate.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Stackless Integration

[Terry Reedy]

"Justin T." <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| > And as far as I know or
| > could find in the PEP index, C. Tismer has never submitted a PEP asking
| > that it be made so.  Doing so would mean a loss of control, so there is 
a
| > downside as well as the obvious upside of distribution.
| That's true. Though, hopefully, the powers that be would allow him to
| maintain it while it's in the stdlib.

A commitment to maintain is a requirement, not something allowed.  By loss 
of control, I meant things like comforming to PSF's C and Python code style 
guide, responding to possible api change requests, and meeting doc and test 
suite requirement.  There is also the policy of no-feature-additions with 
bug-fix releases (x.y.*).  Is the development of stackless essentially 
finished?  and the design 'frozen'?

| Maybe we should file a PEP for| him... :)

You could offer to help him, but only he can offer his code.  Judging from 
discussions of other proposed additions, I expect that the PEP submitter(s) 
would have to substantively deal with questions like
* Do the C stack manipulations interfere with other operations, either core 
or extensions?  What test have you run to show that it does not.?
* Is the functionality portable to Jython and IronPython? (No is a strike 
against acceptance.)  If so, how easily?
* Generators were, in a sense, an alternative to continuation-stackless. 
The 2.5 addition of generator.send(), making communication more easily 
2-way, makes generators more like tasklets.  So why do we really need them? 
How about an alternative implementation built on generators?

If you want some idea of the type of back and forth discussion that may be 
involved, look at the discussion of Eby's generic functions PEP (3124) on 
the Py-3000 list.

Terry Jan Reedy



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

Re: beginner whitespace question

[eggie5]

On Aug 9, 10:37 pm, James Stroud <[EMAIL PROTECTED]> wrote:
> Dan Bishop wrote:
> >> Tabs are for tables, hence the name. "Use spaces for space and use tabs
> >> for tables" can be a little mnemonic to help you remember the rules. We
> >> can make a little song together if you can think of some things that
> >> rhyme with "don't" and "use" and "tabs".
>
> > "won't"
>
> > "blues", "booze", "bruise", "choose", "cruise", "fuse", "hues",
> > "Jews", "lose", "muse", "news", "snooze", "views", etc.
>
> > "abs", "cabs", "crabs", "dabs", "grabs", "labs", "scabs", "slabs",
> > "stabs", etc.
>
> When you want to screw your whitespace--don't!
> Take this little pledge and I know you won't:
>
> When I was in school I would take of booze
> While my typing teacher said I'm free to use
> Space or formfeed or even tabs
> And I punched so hard with my pinkie that scabs
> Covered my Jake and Elwood tatoos.
> (You didn't see that one coming did yous?)

I'm so confused, I have no idea what's going on...

-- 
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/519635http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519610http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519621
>
> Since they're using weakrefs, you shouldn't have to worry about some of
> the weirdness of __del__.
>
> STeVe

Then I will mention my own contribution to the cookbook,
which does not use weak references, but just atexit:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/523007

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

Re: (Re)announcing APL 2007

[rjp]

On Aug 6, 9:20 am, Paul Mansour <[EMAIL PROTECTED]> wrote:

> APL2007 Roll Call: Is anyone going to this?
>
> I'm thinking about going, but I don't want to the only one to show up,
> as in San Diego.

Here here.

Sorry to mention the elephant in the room, but this discussion begs
the obvious question:  what is the rationale for putting on this
conference?  Perhaps I missed that discussion, and if so, please
excuse me.

As we know, there are already two well-attended APL vendor conferences
in the world each year, plus several other more local gatherings.

Speaking as an APL consultant and product distributor, this puts
people in a tough spot, since we now have at least three events to
consider travelling to and attending (assuming APL2000 is hosting its
usual Florida event this year?).

I suppose I should be happy for another opportunity to meet and
network with potential APL colleagues and customers, but if it's
mainly the same small audience at each event, the costs are hard to
justify more than once per year.

I don't have any answers to this dilemma yet, but I think it requires
a lot more discussion. Just putting on a conference and hoping people
attend may, at this point I think, be somewhat counterproductive.

...richard


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

Re: The Future of Python Threading

[Justin T.]

On Aug 10, 3:52 am, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Fri, 10 Aug 2007 10:01:51 -, "Justin T." <[EMAIL PROTECTED]> wrote:
> >Hello,
>
> >While I don't pretend to be an authority on the subject, a few days of
> >research has lead me to believe that a discussion needs to be started
> >(or continued) on the state and direction of multi-threading python.
>
> > [snip - threading in Python doesn't exploit hardware level parallelism
> >  well, we should incorporate stackless and remove the GIL to fix this]
>
> I think you have a misunderstanding of what greenlets are.  Greenlets are
> essentially a non-preemptive user-space threading mechanism.  They do not
> allow hardware level parallelism to be exploited.

I'm not an expert, but I understand that much. What greenlets do is
force the programmer to think about concurrent programming. It doesn't
force them to think about real threads, which is good, because a
computer should take care of that for you.Greenlets are nice because
they can run concurrently, but they don't have to. This means you can
safely divide them up among many threads. You could not safely do this
with just any old python program.

>
> >There has been much discussion on this in the past [2]. Those
> >discussions, I feel, were premature. Now that stackless is mature (and
> >continuation free!), Py3k is in full swing, and parallel programming
> >has been fully realized as THE next big problem for computer science,
> >the time is ripe for discussing how we will approach multi-threading
> >in the future.
>
> Many of the discussions rehash the same issues as previous ones.  Many
> of them are started based on false assumptions or are discussions between
> people who don't have a firm grasp of the relevant issues.

That's true, but there are actually a lot of good ideas in there as
well.

>
> I don't intend to suggest that no improvements can be made in this area of
> Python interpreter development, but it is a complex issue and cheerleading
> will only advance the cause so far.  At some point, someone needs to write
> some code.  Stackless is great, but it's not the code that will solve this
> problem.
Why not? It doesn't solve it on its own, but its a pretty good start
towards something that could.

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

Re: is there anybody using __del__ correctly??

[Raymond Hettinger]

[Michele Simionato]
>  Here and there I hear rumors about deprecating __del__ and
> nothing
> happens, are there any news about that? Expecially concerning Py3k?

I was writing a Py3K PEP advocating the elimination of __del__
because:

* 'with closing()' and try/finally are the preferred ways of calling
close()

* it is easy to accidently keep or introduce a reference that blocks
the __del__ logic

* under-the-hood, the implementation of __del__ clashes badly with GC
logic and is a maintenance nightmare

* the body of a __del__ method may unintentionally resurrect an object
that was in the process of being deleted

For the PEP to have a chance, I neede to make build-outs to the
weakref module so that existing use cases for __del__ can be easily
migrated.  That hasn't been done yet, so the campaign to eliminate
__del__ is stalled.

> I should mention that if you search comp.lang.python
> for __del__ you will find hundreds of people who were
> bitten by __del__, so I usually give advices such as
> "you should never __del__ in your code"

Good advice. Explicit finalization is almost always preferable.



Raymond Hettinger

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

Re: py2exe with python 2.5

[vedrandekovic]

On 10 kol, 14:38, Ant <[EMAIL PROTECTED]> wrote:
> On Aug 10, 11:47 am, [EMAIL PROTECTED] wrote:
>
> > On 10 kol, 11:02, Ant <[EMAIL PROTECTED]> wrote:
> ...
> > yes,Python 2.5 is on the path, but how can I remove panda3d from that
> > path?
>
> Hit Win - Break to bring up the System Properties dialog (you can also
> get here through the Control Panel).
>
> Go to the Advanced tab, and click the "Environment Variables" button.
> Find the PATH variable in one of the two lists, and edit it. Just
> remove the Panda3D entry.
>
> Note you'll have to restart your console to pick up any changes.
>
> --
> Ant...
>
> http://antroy.blogspot.com/

Hi,

Ok,I have done that. But how can I restart console now?

Regards,
Vedran

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

Re: The Future of Python Threading

[Cameron Laird]

In article <[EMAIL PROTECTED]>,
Bjoern Schliessmann  <[EMAIL PROTECTED]> wrote:
>Justin T. wrote:
>
>> The detrimental effects of the GIL have been discussed several
>> times and nobody has ever done anything about it. 
>
>Also it has been discussed that dropping the GIL concept requires
>very fine locking mechanisms inside the interpreter to keep data
>serialised. The overhead managing those fine ones properly is not
>at all negligible, and I think it's more than managing GIL.
>
>> The truth is that the future (and present reality) of almost every
>> form of computing is multi-core,
>
>Is it? 8)
.
.
.
I reinforce some of these points slightly:
A.  An effective change to the GIL impacts not just
Python in the sense of the Reference Manual, but
also all its extensions.  That has the potential
to be a big, big cost; and
B.  At least part of the attention given multi-core
processors--or, perhaps more accurately, the
claims that multi-cores deserve threading re-
writes--smells like vendor manipulation.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Deleting objects on the fly

[Terry Reedy]

"Campbell Barton" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| Michele Simionato wrote:
| > Probably not, 'del x' just decrements the reference count,

Or as
http://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.

tjr



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

Re: Smoother Lines in Turtle Graphics

[kyosohma]

On Aug 9, 6:56 pm, tomy <[EMAIL PROTECTED]> wrote:
> Hi All
> I am a newbie to turtle graphics in python, so sorry if you find this
> question too easy.
> How can I get smoother lines in turtle graphics?
> I am using python on windows.
>
> Thanks in advance

You may be better off using PIL or pygame for this sort of thing.

Mike

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

Re: Puzzled by "is"

[Marc 'BlackJack' Rintsch]

On Fri, 10 Aug 2007 10:57:22 -0700, Dick Moores wrote:

> At 06:13 PM 8/9/2007, Ben Finney wrote:
>>Others have already said that it's an implementation optimisation,
>>which seems to partly answer your question.
>>
>>It's important to also realise that the language is *deliberately*
>>non-committal on whether any given value will have this behaviour;
>>that is, it's entirely left to the language implementation which
>>optimisation trade-offs to make, and the language user (that's you and
>>I) should *not* expect any particular behaviour to hold between
>>different implementations.
> 
> I'm not clear on the meaning of "implementations" 
> here.  Would 2.5 for Windows, Mac, Linux all be 
> different implementations? Would Iron Python be another? ActivePython?

Taken to the extreme you shouldn't rely on implementation details at all,
so even the very same interpreter might cache and reuse the empty tuple in
one run but not in the next.

For me CPython, Iron Python and Jython are different implementations as
they are all written from scratch.

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

pat-match.lisp or extend-match.lisp in Python?

[ekzept]

anyone have either pat-match.lisp or extend-match.lisp redone in
Python?  or how about knowing where there might be such a thing?

sources:

   http://norvig.com/paip/patmatch.lisp

   
http://www.cs.northwestern.edu/academics/courses/325/programs/extend-match.lisp

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

Re: Does PyModule_GetDict return information about class method variables?

[Marc 'BlackJack' Rintsch]

On Fri, 10 Aug 2007 05:54:03 -0700, MD wrote:

> On Aug 10, 12:43 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>> class A(object):
>> def foo(self):
>> bar = 42
>>
>> The local name `bar` only exists if `foo()` is called on an instance of `A`.
>
>Thanks for your reply. I am calling my extension function from the
> class method itself. So at that point the variable does exist. I am
> puzzled why PyModule_GetDict is not able to access the variable even
> though it does exist at that point.

It does not exist in the module or the function object but on the stack. 
Let's go to C again:


void baz(void);

void foo(void)
{
int bar = 42;
baz();
}

How do you get from `baz()` the value of `foo()`\s local `bar`?  Other
than ugly non portable stack trickery!?

Why don't you just give the object as argument to your C function? 
Wanting to poke around in the callers name space is code smell.  Don't do
that.

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

Re: Ipc mechanisms and designs.

[Nikita the Spider]

In article <[EMAIL PROTECTED]>,
 king kikapu <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> inspired of the topic "The Future of Python Threading", i started to
> realize that the only way to utilize the power of multiple cores using
> Python, is spawn processes and "communicate" with them.
> 
> If we have the scenario:
> 
> 1. Windows (mainly) development
> 2. Processes are running in the same machine
> 3. We just want to "pass" info from one process to another. Info may
> be simple data types or user defined Python objects.
> 
> what is the best solution (besides sockets) that someone can implement
> so to have 2 actually processes that interchanged data between them ?
> I looked at Pyro and it looks really good but i wanted to experiment
> with a simpler solution.

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/

Good luck with whatever you choose

-- 
Philip
http://NikitaTheSpider.com/
Whole-site HTML validation, link checking and more
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: wxPython before MainLoop

[kyosohma]

On Aug 9, 8:51 pm, "[david]" <[EMAIL PROTECTED]> wrote:
> I'm disappointed that I didn't get a wxPython solution.
>
> If the only way to get wxPython to correctly handle
> this simple task is to code around it, I don't think
> wxPython is really ready for Windows.
>
> Is there a better place to ask?
>
> Regarding the suggestions:
>
> Bjoern, you're wrong. The GUI needs to be displayed
> for the user to analyse. A delay between display and
> readiness is much better than a delay before display
> or a delay with the GUI half-drawn.
>
> Mike, the screen does display correctly, it's just
> that in Windows, screen updates are not processed
> while the application is busy.
>
> 7Stud, that's a solution. Unless anyone comes up
> with a direct solution, I guess I'll have to do that.
>
> [david]
>
> [david] wrote:
> > I'd like to refresh the display before I start the main loop.
>
> > I have code like this:
>
> > app = App()
> > app.Show()
> > app.long_slow_init()
> > app.MainLoop()
>
> > The main frame partly loads at Show, but because the mainloop has not
> > started yet, the display does not update until long_slow_init() finishes.
>
> > Alternatively, I could code
>
> > app = App()
> > app.long_slow_init()
> > app.Show()
> > app.MainLoop()
>
> > Which would give me a crisp Show, but there would be a long slow wait
> > before the app showed any activity at all. I would need a splash screen.
>
> > I'd rather not have a splash screen (and I don't know how anyway). I'd
> > like to just make app.Show() finish correctly before running
> > long_slow_init.
>
> > Is there a wx internal method that I can use to give Windows the
> > opportunity to finish painting the frame before I run long_slow_init()?
>
> > Or is there a better idea?
>
> > (david)

Chris is right. The only way to interact with a gui is with a separate
thread, otherwise you're blocking the gui's mainloop thread. That's
why I gave that link. That's how to do it in every GUI I'm aware of.

Mike

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

Re: Python MAPI

[kyosohma]

On Aug 10, 5:05 am, vasudevram <[EMAIL PROTECTED]> wrote:
> On Jul 23, 6:07 pm, [EMAIL PROTECTED] wrote:
>
> >Well, I ran Process Monitor with some filters enabled to only watch
>
> Thunderbird and MS Word. Unfortunately, that didn't give me any of the
> registry edits, so I disabled my filters and ran it without. Now I
> have a log file with 28,000 entries. It's amazing to see all the stuff
> that happens in just a few moments, but how am I supposed to parse
> this mess?
>
> Explorer.exe and outlook express do thousands of the registry calls
> and the paths they manipulate vary wildly. Oh well, I'll be off the
> clock in about 15 minutes so it can wait until Monday.
>
> Thanks for your help. I'll post if I figure out anything...hopefully
> you'll do the same.
>
> ---
>
> Sorry for not replying earlier ... I searched this list for the topic
> (Python MAPI) a few times but couldn't find it - not sure why - maybe
> Google Groups's indexing gets messed up sometimes ...
>
> Yes, so many entries would be a problem to parse manually ...
>
> That's why I suggested using a grep for Windows - or, preferably, an
> egrep - which is a more powerful version of grep; e.g. basic grep only
> allows you to use one regexp at a time - while egrep allows you to use
> extended regular expressions, such as "pattern1|pattern2", also
> "patt(e|u)rn(1|2)" which looks in parallel for pattern1, patturn1,
> pattern2 and patturn2 - I used a made-up example where the spelling of
> pattern could be wrong, but it works for any other cases of
> alternative patterns and subpatterns as well. Not sure if there is any
> egrep for Windows - try Googling. If not, and the problem is important
> enough, you might want to install Cygwin (its a big download, so first
> check if it _does_ have egrep in it).
>
> Vasudev

There are some programs that do grep for Windows. I'll mess with them.

Mike

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

Re: Does PyModule_GetDict return information about class method variables?

[MD]

Hi Marc,
   Thanks for your reply. I am calling my extension function from the
class method itself. So at that point the variable does exist. I am
puzzled why PyModule_GetDict is not able to access the variable even
though it does exist at that point.

Thanks,
-Manas

On Aug 10, 12:43 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Thu, 09 Aug 2007 19:34:37 -0700, MD wrote:
> >I have a variable which is defined inside a class method. When I
> > call PyModule_GetDict on the module containing this class, the
> > dictionary doesn't contain any information about this variable. Is
> > this expected behavior? If so, what options do I have to access this
> > variable from my Python C extension.
>
> You can't access names in methods because they don't exist until you call
> the method.  It's just like local variables in C.  Consider:
>
> void foo(void)
> {
> int bar = 42;
>
> }
>
> Here `bar` does not exist until you call `foo()` and it disappears as soon
> as the function returns.
>
> It's the very same situation in Python:
>
> class A(object):
> def foo(self):
> bar = 42
>
> The local name `bar` only exists if `foo()` is called on an instance of `A`.
>
> Ciao,
> Marc 'BlackJack' Rintsch


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

Re: Question about properties.

[Gerardo Herzig]

king kikapu wrote:

>On Aug 10, 1:33 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>  
>
>>On Fri, 10 Aug 2007 03:21:29 -0700, king kikapu wrote:
>>
>>
>>>Hi,
>>>  
>>>
>>>i read in a book the following code snippet that is dealing with
>>>properties:
>>>  
>>>
>>>class ProtectAndHideX(object):
>>>def __init__(self, x):
>>>assert isinstance(x, int), '"x" must be an integer!"'
>>>self.__x = ~x
>>>  
>>>
>>>def get_x(self):
>>>return ~self.__x
>>>  
>>>
>>>x = property(get_x)
>>>  
>>>
>>>Can anyone please help me understand what the symbol "~" does here ??
>>>  
>>>
>>This has nothing to do with properties.  For integer objects ``~`` is the
>>bitwise negation or invertion operator.
>>
>>Ciao,
>>Marc 'BlackJack' Rintsch
>>
>>
>
>Xmmm...ok then but what is actually doing there ?? I removed it and
>things seems to work the same way...
>
>  
>
I guess it is the `Hide' part of the Protectand*Hide* class.
Gerardo
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py2exe with python 2.5

[Ant]

On Aug 10, 11:47 am, [EMAIL PROTECTED] wrote:
> On 10 kol, 11:02, Ant <[EMAIL PROTECTED]> wrote:
...
> yes,Python 2.5 is on the path, but how can I remove panda3d from that
> path?

Hit Win - Break to bring up the System Properties dialog (you can also
get here through the Control Panel).

Go to the Advanced tab, and click the "Environment Variables" button.
Find the PATH variable in one of the two lists, and edit it. Just
remove the Panda3D entry.

Note you'll have to restart your console to pick up any changes.

--
Ant...

http://antroy.blogspot.com/


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

Re: Question about properties.

[Steve Holden]

king kikapu wrote:
> On Aug 10, 1:33 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>> On Fri, 10 Aug 2007 03:21:29 -0700, king kikapu wrote:
>>> Hi,
>>> i read in a book the following code snippet that is dealing with
>>> properties:
>>> class ProtectAndHideX(object):
>>> def __init__(self, x):
>>> assert isinstance(x, int), '"x" must be an integer!"'
>>> self.__x = ~x
>>> def get_x(self):
>>> return ~self.__x
>>> x = property(get_x)
>>> Can anyone please help me understand what the symbol "~" does here ??
>> This has nothing to do with properties.  For integer objects ``~`` is the
>> bitwise negation or invertion operator.
>>
>> Ciao,
>> Marc 'BlackJack' Rintsch
> 
> Xmmm...ok then but what is actually doing there ?? I removed it and
> things seems to work the same way...
> 
Observe the name of the class. I believe the integer value is inverted 
merely as a demonstration that the value can be "obscured" somehow - in 
a more complex example the author might have insisted in string values, 
the encrypted them. It's not essential to the example, it merely shows 
that the value retrieved from the property can be computed from 
underlying attributes.

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: subprocess.Popen(cmd) question

[WolfgangZ]

WolfgangZ schrieb:
> Hello,
> 
> I'm starting some subprocesses inside a loop. The processes run 
> independent and dont need any communication between each other. Due to 
> memory issues I need to limit the number of running processes to around 
> 10. How can I insert a break into my loop to wait until some processes 
> are finished?
> 
> Some minimal examplecode:
> 
> import subprocess
> for i in range(0,100):
>  cmd='ping localhost'
>  p=subprocess.Popen(cmd)
>  p.wait()
> 
> Thanks for any ideas.
> 
> Wolfgang
> 

Problem solved by using "threading"

Wolfgang

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

Re: The Future of Python Threading

[Paul Boddie]

On 10 Aug, 12:01, "Justin T." <[EMAIL PROTECTED]> wrote:
>
> While I don't pretend to be an authority on the subject, a few days of
> research has lead me to believe that a discussion needs to be started
> (or continued) on the state and direction of multi-threading python.
>
> Python is not multi-threading friendly.

Yes it is: Jython and IronPython support free threading; CPython,
however, does not. Meanwhile, take a look at this page for different
flavours of alternative solutions:

http://wiki.python.org/moin/ParallelProcessing

Paul

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

Re: subprocess.Popen(cmd) question

[Peter Otten]

WolfgangZ wrote:

> I'm starting some subprocesses inside a loop. The processes run
> independent and dont need any communication between each other. Due to
> memory issues I need to limit the number of running processes to around
> 10. How can I insert a break into my loop to wait until some processes
> are finished?
> 
> Some minimal examplecode:
> 
> import subprocess
> for i in range(0,100):
>  cmd='ping localhost'
>  p=subprocess.Popen(cmd)
>  p.wait()
> 

Just polling the processes may be good enough:

import random
import subprocess
import sys
import time
from itertools import islice
from functools import partial

PROCESSES = 100
SIMULTANEOUS = 10

def info(*args):
print >> sys.stderr, " ".join(str(a) for a in args)

class Process(object):
def __init__(self, index):
self.index = index
info("starting process #%d" % index)
self.process = subprocess.Popen(["ping", "localhost", "-w", "%d" %
random.randrange(1, 6)])
def __nonzero__(self):
running = self.process.poll() is None
if not running:
# XXX ugly side effect
info("process #%d terminated" % self.index)
return running

def processes():
for i in range(PROCESSES):
yield partial(Process, i)

def main():
starters = processes()
running = [sp() for sp in islice(starters, SIMULTANEOUS)]
while running:
before = len(running)
running = [p for p in running if p]
after = len(running)
if before == after:
info("waiting")
time.sleep(1)
else:
running.extend(sp() for sp in islice(starters, SIMULTANEOUS -
len(running)))
info("that's all, folks")

if __name__ == "__main__":
main()

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

Re: Smoother Lines in Turtle Graphics

[Ant]

On Aug 10, 11:41 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> tomy wrote:
> > Hi All
...
> What turtle graphics? I'm not aware that there is some
> standard-turtle-graphics available, so it might be a problem of your
> turtle-graphics-package.
>
> Diez

import turtle

Its part of the standard Library! I don't know the answer to the OP's
question mind you, I'd played around a little with it a while ago, but
nothing more.

Python: Batteries and Turtles included!

--
Ant...

http://antroy.blogspot.com/




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

Re: The Future of Python Threading

[Steve Holden]

Justin T. wrote:
> Hello,
> 
> While I don't pretend to be an authority on the subject, a few days of
> research has lead me to believe that a discussion needs to be started
> (or continued) on the state and direction of multi-threading python.
[...]
> What these seemingly unrelated thoughts come down to is a perfect
> opportunity to become THE next generation language. It is already far
> more advanced than almost every other language out there. By
> integrating stackless into an architecture where tasklets can be
> divided over several parallelizable threads, it will be able to
> capitalize on performance gains that will have people using python
> just for its performance, rather than that being the excuse not to use
> it.
> 
Aah, the path to world domination. You know you don't *have* to use 
Python for *everything*.

> The nice thing is that this requires a fairly doable amount of work.
> First, stackless should be integrated into the core. Then there should
> be an effort to remove the reliance on the GIL for python threading.
> After that, advanced features like moving tasklets amongst threads
> should be explored. I can imagine a world where a single python web
> application is able to redistribute its millions of requests amongst
> thousands of threads without the developer ever being aware that the
> application would eventually scale. An efficient and natively multi-
> threaded implementation of python will be invaluable as cores continue
> to multiply like rabbits.
> 
Be my guest, if it's so simple.

> There has been much discussion on this in the past [2]. Those
> discussions, I feel, were premature. Now that stackless is mature (and
> continuation free!), Py3k is in full swing, and parallel programming
> has been fully realized as THE next big problem for computer science,
> the time is ripe for discussing how we will approach multi-threading
> in the future.
> 
I doubt that a thread on c.l.py is going to change much. It's the 
python-dev and py3k lists where you'll need to take up the cudgels, 
because I can almost guarantee nobody is going to take the GIL out of 
2.6 or 2.7.

> 
> [1] I haven't actually looked at the GIL code. It's possible that it
> creates a bunch of wait queues for each nice level that a python
> thread is running at and just wakes up the higher priority threads
> first, thus maintaining the nice values determined by the scheduler,
> or something. I highly doubt it. I bet every python thread gets an
> equal chance of getting that lock despite whatever patterns the
> scheduler may have noticed.
> 
It's possible that a little imp tosses a coin and decides which thread 
gets to run next. The point of open source is that it's easy to dispel 
ignorance and make your own changes if you are competent to do so. Talk 
is cheap, code is costly. Your bet is worth nothing. Is it even possible 
to run threads of the same process at different priority levels on all 
platforms?

> [2]
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/7d16083cf34a706f/858e64a2a6a5d976?q=stackless%2C+thread+paradigm&lnk=ol&;
> http://www.stackless.com/pipermail/stackless/2003-June/000742.html
> ... More that I lost, just search this group.
> 
Anyone who's been around Python for a while is familiar with the issues. 
Have you actually asked Chris Tismer whether he's happy to see Stackless 
go into the core? He was far from certain that would be a good idea at 
PyCon earlier this year. He probably has his reasons ...

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: Question about properties.

[king kikapu]

On Aug 10, 1:33 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Fri, 10 Aug 2007 03:21:29 -0700, king kikapu wrote:
> > Hi,
>
> > i read in a book the following code snippet that is dealing with
> > properties:
>
> > class ProtectAndHideX(object):
> > def __init__(self, x):
> > assert isinstance(x, int), '"x" must be an integer!"'
> > self.__x = ~x
>
> > def get_x(self):
> > return ~self.__x
>
> > x = property(get_x)
>
> > Can anyone please help me understand what the symbol "~" does here ??
>
> This has nothing to do with properties.  For integer objects ``~`` is the
> bitwise negation or invertion operator.
>
> Ciao,
> Marc 'BlackJack' Rintsch

Xmmm...ok then but what is actually doing there ?? I removed it and
things seems to work the same way...

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

Re: Smoother Lines in Turtle Graphics

[Diez B. Roggisch]

tomy wrote:

> Hi All
> I am a newbie to turtle graphics in python, so sorry if you find this
> question too easy.
> How can I get smoother lines in turtle graphics?
> I am using python on windows.

What turtle graphics? I'm not aware that there is some
standard-turtle-graphics available, so it might be a problem of your
turtle-graphics-package.

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

Re: Issues of state

[Steve Holden]

greg wrote:
> Jay Loden wrote:
>> Like most things involving dynamic client side-javascript code and AJAX
>> technology, it's a lot harder than you'd like it to be to solve the problem, 
>> but
>> in cases where the Back button is really an issue, it's worth the effort.
> 
> So if you're willing to put in a huge amount of time,
> effort and ingenuity, it's possible to overcome a
> problem that only existed in the first place because
> you chose an inappropriate technique for implementing
> a user interface...
> 
Exactly my point. Once you start to involve a complex framework to 
handle state and interactions you see less and less advantage to 
"desktop web" applications, since it's hard to match the directness and 
simplicity of a native GUI.

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: Question about properties.

[dijkstra . arjen]

On Aug 10, 12:21 pm, king kikapu <[EMAIL PROTECTED]> wrote:
> Hi,
>
> i read in a book the following code snippet that is dealing with
> properties:
>
> class ProtectAndHideX(object):
> def __init__(self, x):
> assert isinstance(x, int), '"x" must be an integer!"'
> self.__x = ~x
>
> def get_x(self):
> return ~self.__x
>
> x = property(get_x)
>
> Can anyone please help me understand what the symbol "~" does here ??
>
> Thanks for any help!

>>> help(2)

 |  __invert__(...)
 |  x.__invert__() <==> ~x



hth.
Duikboot


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

Question about properties.

[king kikapu]

Hi,

i read in a book the following code snippet that is dealing with
properties:

class ProtectAndHideX(object):
def __init__(self, x):
assert isinstance(x, int), '"x" must be an integer!"'
self.__x = ~x

def get_x(self):
return ~self.__x

x = property(get_x)


Can anyone please help me understand what the symbol "~" does here ??

Thanks for any help!

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

Re: beginner whitespace question

[Ben Finney]

James Stroud <[EMAIL PROTECTED]> writes:

> When you want to screw your whitespace--don't!
> Take this little pledge and I know you won't:

James, you're a poet
And you don't even realise

-- 
 \  "[...] a Microsoft Certified System Engineer is to information |
  `\ technology as a McDonalds Certified Food Specialist is to the |
_o__)   culinary arts." —Michael Bacarella |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python MAPI

[vasudevram]

On Jul 23, 6:07 pm, [EMAIL PROTECTED] wrote:

>Well, I ran Process Monitor with some filters enabled to only watch
Thunderbird and MS Word. Unfortunately, that didn't give me any of the
registry edits, so I disabled my filters and ran it without. Now I
have a log file with 28,000 entries. It's amazing to see all the stuff
that happens in just a few moments, but how am I supposed to parse
this mess?

Explorer.exe and outlook express do thousands of the registry calls
and the paths they manipulate vary wildly. Oh well, I'll be off the
clock in about 15 minutes so it can wait until Monday.

Thanks for your help. I'll post if I figure out anything...hopefully
you'll do the same.

---

Sorry for not replying earlier ... I searched this list for the topic
(Python MAPI) a few times but couldn't find it - not sure why - maybe
Google Groups's indexing gets messed up sometimes ...

Yes, so many entries would be a problem to parse manually ...

That's why I suggested using a grep for Windows - or, preferably, an
egrep - which is a more powerful version of grep; e.g. basic grep only
allows you to use one regexp at a time - while egrep allows you to use
extended regular expressions, such as "pattern1|pattern2", also
"patt(e|u)rn(1|2)" which looks in parallel for pattern1, patturn1,
pattern2 and patturn2 - I used a made-up example where the spelling of
pattern could be wrong, but it works for any other cases of
alternative patterns and subpatterns as well. Not sure if there is any
egrep for Windows - try Googling. If not, and the problem is important
enough, you might want to install Cygwin (its a big download, so first
check if it _does_ have egrep in it).

Vasudev



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

Re: Deleting objects on the fly

[Campbell Barton]

Michele Simionato wrote:
> On Aug 10, 2:25 am, Godzilla <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> I wish to know whether I should delete objects created on the fly via
>> the "del obj" statement. I noticed the RAM usage increased whenever
>> the application is being run for a long time. I am creating lots of
>> objects (messages) on the fly for communication between threads.
>>
>> Rather than having python's gc to do the work, does it make a
>> difference if I force a deletion?
>>
>> Thanks.
> 
> Probably not, 'del x' just decrements the reference count, but
> it is the gc who does the real job. See 
> http://docs.python.org/ref/customization.html#l2h-175
> 
> Do you have reference cycles in your application? You should
> tell us something more.
> 
>Michele Simionato
> 

del x will remove x from memory if nothing else is refering to it, but 
this dosnt really take the load off the GC since the GC will still check 
the references and remove if there are none.

In some cases you could use to save ram...

a = 'really big string'
...do stuff with a...
del a

b = 'another really big string'
...do stuff with b...
del b


in the case that 'a' is not needed, after its used, and you dont want to 
re-use the variable name. then del will free some ram since they both 
wont need to exist at the same time.

WHen I say free ram, python its self will probably keep the ram for 
later use but at least it wont need a and b in memory at once, so its 
likely not to use as much ram.

But be careful using del in a loop since it can slow things down, its 
like adding and removing an item from a dictionary many times. your 
better off just redefining that variable or using del after the loops 
finished.

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

The Future of Python Threading

[Justin T.]

Hello,

While I don't pretend to be an authority on the subject, a few days of
research has lead me to believe that a discussion needs to be started
(or continued) on the state and direction of multi-threading python.

Python is not multi-threading friendly. Any code that deals with the
python interpreter must hold the global interpreter lock (GIL). This
has the effect of serializing (to a certain extent) all python
specific operations. IE, any thread that is written purely in python
will not release the GIL except at particular (and possibly non-
optimal) times. Currently that's the rather arbitrary quantum of 100
bytecode instructions. Since the ability of the OS to schedule python
threads is based on when its possible to run that thread (according to
the lock), python threads do not benefit from a good scheduler in the
same manner that real OS threads do, even though python threads are
supposed to be a thin wrapper around real OS threads[1].

The detrimental effects of the GIL have been discussed several times
and nobody has ever done anything about it. This is because the GIL
isn't really that bad right now. The GIL isn't held that much, and
pthreads spawned by python-C interations (Ie, those that reside in
extensions) can do all their processing concurrently as long as they
aren't dealing with python data. What this means is that python
multithreading isn't really broken as long as python is thought of as
a convenient way of manipulating C. After all, 100 bytecode
instructions go by pretty quickly, so the GIL isn't really THAT
invasive.

Python, however, is much better than a convenient method of
manipulating C. Python provides a simple language  which can be
implemented in any way, so long as promised behaviors continue. We
should take advantage of that.

The truth is that the future (and present reality) of almost every
form of computing is multi-core, and there currently is no effective
way of dealing with concurrency. We still worry about setting up
threads, synchronization of message queues, synchronization of shared
memory regions, dealing with asynchronous behaviors, and most
importantly, how threaded an application should be. All of this is
possible to do manually in C, but its hardly optimal. For instance, at
compile time you have no idea if your library is going to be running
on a machine with 1 processor or 100. Knowing that makes a huge
difference in architecture as 200 threads might run fine on the 100
core machine where it might thrash the single processor to death.
Thread pools help, but they need to be set up and initialized. There
are very few good thread pool implementations that are meant for
generic use.

It is my feeling that there is no better way of dealing with dynamic
threading than to use a dynamic language. Stackless python has proven
that clever manipulation of the stack can dramatically improve
concurrent performance in a single thread. Stackless revolves around
tasklets, which are a nearly universal concept.

For those who don't follow experimental python implementations,
stackless essentially provides an integrated scheduler for "green
threads" (tasklets), or extremely lightweight snippets of code that
can be run concurrently. It even provides a nice way of messaging
between the tasklets.

When you think about it, lots of object oriented code can be organized
as tasklets. After all, encapsulation provides an environment where
side effects of running functions can be minimized, and is thus
somewhat easily parallelized (with respect to other objects).
Functional programming is, of course, ideal, but its hardly the trendy
thing these days. Maybe that will change when people realize how much
easier it is to test and parallelize.

What these seemingly unrelated thoughts come down to is a perfect
opportunity to become THE next generation language. It is already far
more advanced than almost every other language out there. By
integrating stackless into an architecture where tasklets can be
divided over several parallelizable threads, it will be able to
capitalize on performance gains that will have people using python
just for its performance, rather than that being the excuse not to use
it.

The nice thing is that this requires a fairly doable amount of work.
First, stackless should be integrated into the core. Then there should
be an effort to remove the reliance on the GIL for python threading.
After that, advanced features like moving tasklets amongst threads
should be explored. I can imagine a world where a single python web
application is able to redistribute its millions of requests amongst
thousands of threads without the developer ever being aware that the
application would eventually scale. An efficient and natively multi-
threaded implementation of python will be invaluable as cores continue
to multiply like rabbits.

There has been much discussion on this in the past [2]. Those
discussions, I feel, were premature. Now that stackless is mature (and
continuation free!

Re: wxPython - drawing without paint event

[7stud]

On Aug 9, 7:46 pm, Matt Bitten <[EMAIL PROTECTED]> wrote:
> I've got a wxPython program that needs to do some drawing on a DC on a
> regular basis And there is no event,
> so my code doesn't get called. What do I do?

Then the event is: "on a regular basis", i.e. the passage of time.
You can use a wx.Timer to create events at regular intervals, which
your code can respond to:

---
import wx

class MyFrame(wx.Frame):
def __init__(self):
wx.Frame.__init__(self, None, -1, "My Window")

panel = wx.Panel(self, -1)
self.text = wx.StaticText(panel, -1, "hello", pos=(40, 40) )

self.timer = wx.Timer(self)
self.Bind(wx.EVT_TIMER, self.on_timer_event)
self.timer.Start(milliseconds=1000, oneShot=False)

def on_timer_event(self, event):
if self.text.GetLabel() == "hello":
self.text.SetLabel("goodbye")
else:
self.text.SetLabel("hello")


app = wx.App(redirect=False)

win = MyFrame()
win.Show()

app.MainLoop()


Make sure you save the timer in self so that you have a permanent
reference to the object, otherwise the timer will be destroyed when
__init_ returns.




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

Re: is there anybody using __del__ correctly??

[greg]

Michele Simionato wrote:
> So I did, and to my dismay 95% of the __del__ methods in the standard
> library are just calling a close method!

You can't conclude that this is wrong just from
looking at the __del__ method itself. You need to
consider whether there is any way the thing being
closed could be referenced from somewhere else.

If that's so, the __del__ method may be performing
a useful service by closing it more promptly than
it would otherwise be.

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

Re: how to get output.

[indu_shreenath]

On Aug 10, 12:02 am, Larry Bates <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I corrected a typ below.
>
> > On Aug 9, 12:50 pm, [EMAIL PROTECTED] wrote:
> >> Hey,
>
> >> I did write the following:
> >> but it does not work.
>
> >> import subprocess as sp
> >> try:
> >> p = sp.Popen("DIR . /AD /B", stdout=sp.PIPE)
> >> result = p.communicate()[0]
> >> print result
> >>  except:
> >>  print "error"
>
> >> This throws error.
> >> DIR . /AD /B will list out only directories in the current directory.
>
> >> Thanks,
> >> Indu
>
> >> On Aug 9, 11:46 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
>
> >>> indu_shreenath schrieb:
>  Hey,
>  I want to get the output of "DIR /AD /B" command to a varriable using
>  python. How can I do this?
> >>> Using the subprocess-module.
> >>> However, I'm not sure what DIR /AD /B does - but there are many
> >>> functions in module os that might deliver what you want without invoking
> >>> an external command.
> >>> Diez- Hide quoted text -
> >> - Show quoted text -
>
> That is better done in python with:
>
> import os
> dirs=[d for d in os.listdir(os.curdir) if os.path.isdir(d)]
>
> or
>
> dirs=filter(os.path.isdir, os.listdir(os.curdir))
>
> -Larry- Hide quoted text -
>
> - Show quoted text -

Thanks I could implement it.

Indu



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

subprocess.Popen(cmd) question

[WolfgangZ]

Hello,

I'm starting some subprocesses inside a loop. The processes run 
independent and dont need any communication between each other. Due to 
memory issues I need to limit the number of running processes to around 
10. How can I insert a break into my loop to wait until some processes 
are finished?

Some minimal examplecode:

import subprocess
for i in range(0,100):
 cmd='ping localhost'
 p=subprocess.Popen(cmd)
 p.wait()

Thanks for any ideas.

Wolfgang

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

float to string with different precision

[zunbeltz]

Hi,

I have to print float numbers to a file. Each float should be 5
characters in width (4 numbers and the decimal point).
My problem is that I do not now how to specify float to have different
numbers of decimals. For example

5.32 -> 5.320
10.356634 -> 10.357
289.234 -> 289.2

In the string formating operations only fixed number of decimal digits
is allow.

Thanks in advance for the help,

Zunbeltz

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

Re: Misleading wikipedia article on Python 3?

[greg]

Evan Klitzke wrote:

> You can easily modify print in a safe way.

Yes, but you'd still have to replace the builtin print
function with your own to get it used by non-cooperative
code. That doesn't seem to gain you much over replacing
sys.stdout with something that intercepts and logs
stuff written to it.

 > What do you find wrong with this sort of "monkeypatching"?

At least sys.stdout was designed somewhat with the
possibility of replacing it in mind. It's not an
entirely unexpected thing to do. Replacing something
in the builtin namespace seems like a more drastic
step, somehow.

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

Re: float to string with different precision

[Peter Otten]

 [EMAIL PROTECTED] wrote:

> I have to print float numbers to a file. Each float should be 5
> characters in width (4 numbers and the decimal point).
> My problem is that I do not now how to specify float to have different
> numbers of decimals. For example
> 
> 5.32 -> 5.320
> 10.356634 -> 10.357
> 289.234 -> 289.2
> 
> In the string formating operations only fixed number of decimal digits
> is allow.

>>> ["%#.4g" % f for f in [5.32, 10.356634, 289.234, 123456789.]]
['5.320', '10.36', '289.2', '1.235e+08']

Found by playing around with format strings, so no guarantees.

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

Re: Issues of state

[greg]

Jay Loden wrote:
> Like most things involving dynamic client side-javascript code and AJAX
> technology, it's a lot harder than you'd like it to be to solve the problem, 
> but
> in cases where the Back button is really an issue, it's worth the effort.

So if you're willing to put in a huge amount of time,
effort and ingenuity, it's possible to overcome a
problem that only existed in the first place because
you chose an inappropriate technique for implementing
a user interface...

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

Re: pep 3116 behaviour on non-blocking reads

[greg]

Antoon Pardon wrote:
> I would like the developers to reconsider and return 0 bytes when no
> bytes are available and let None indicate end of file.

That would be a major departure from the way IO has
always been handled before in Python, which follows
the Unix model.

Also, only code that deals with non-blocking streams
will ever get None, and such code is relatively rare,
so most code won't have to worry about the None case.

Even when dealing with a non-blocking stream, usually
there will be some other way (such as select) used to
determine when there is something to be read from a
stream, and it won't be read otherwise. In that case,
the code *still* won't ever see a None.

So I think the PEP has it right.

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

Re: py2exe with python 2.5

[Ant]

On Aug 10, 8:39 am, [EMAIL PROTECTED] wrote:
> Hello,
>
> Now,I was install python 2.5 and remove python 2.4 completely.After I
> write:
> $ python mysetup.py py2exe
> ...
>  import py2exe_ util
> ImportError: Module use of conflicts with this version of Python
>
> ...ok, I know what is a problem, I haven't remove python completely,
> in my computer is one more folder Panda3D-1.4.0 but when I remove it
> and all dll files include python24.dll, I cannot run python or make
> that setup.
> (That panda3d contain python)
>
> Regards,
> Vedran

Sounds like your path needs setting up properly. Try typing echo %PATH
% into your console window to find out if Python2.5 is in the path. If
you are using the default setup, then c:\Python25 should be on the
path.

--
Ant...

http://antroy.blogspot.com/


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

Re: tempfile behavior

[greg]

Marc 'BlackJack' Rintsch wrote:
> File descriptors are integers.  It's a low level C thing.  Either use the
> low level functions in `os` or open the file with the `filename`.

In particular, os.fdopen(fd) will give you a
file object.

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

com: makepy gencache.EnsureModule

[Kai Rosenthal]

Hello,

I' having a problem with gencache.EnsureModule:

I used win32com\client\makepy.py to successfully generate Python
sources.
Unfortunately, after I call win32com.client.Dispatch(), the object I
get back is of type "COMObject" instead of one of the generated
classes.

In particular, I'm trying to interact with SolidWorks Extensibility
Type Library and the PROGID is "SldWorks.Application".

Using win32com\client\makepy.py -i
SolidWorks Extensibility Type Library
 {801A-A66C-11D3-A8BD-861EBBD6}, lcid=0, major=1, minor=0
 >>> # Use these commands in Python code to auto generate .py support
 >>> from win32com.client import gencache
 >>> gencache.EnsureModule('{801A-A66C-11D3-A8BD-861EBBD6}',
0, 1, 0)

Looking in win32com\gen-py, the appropriate file _does_ exist:
801A-A66C-11D3-A8BD-861EBBD6x0x1x0.py
and it does contain the correct class definitions.

Then, in my code:
>>> mod = 
>>> win32com.client.gencache.EnsureModule('{801A2001-A66C-11D3-A8BD-861EBBD6}',
>>>  0, 1, 0)
>>> mod
None
>>> ob = win32com.client.Dispatch("SldWorks.Application")
>>> ob


Why are the object mod is None and the object ob is   instead  >?
Any bright ideas as to what's going wrong here?

Thanks for your hints, Kai

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

Re: Stackless Integration

[Bruno Desthuilliers]

Steve Holden a écrit :
> Bruno Desthuilliers wrote:
>> Jean-Paul Calderone a écrit :
>>> On Thu, 09 Aug 2007 09:00:27 -, "Justin T." <[EMAIL PROTECTED]> 
>>> wrote:
 Hi,

 I've been looking at stackless python a little bit, and it's awesome.
 My question is, why hasn't it been integrated into the upstream python
 tree? Does it cause problems with the current C-extensions? It seems
 like if something is fully compatible and better, then it would be
 adopted. However, it hasn't been in what appears to be 7 years of
 existence, so I assume there's a reason.
>>> It's not Pythonic.
>>
>> Hum... Yes ? Really ? Care to argument ?
> 
> Unfortunately such arguments quickly descend to the "yes it is", "no it 
> isn't" level, as there is no objective measure of Pythonicity.

indeed !-)

But that doesn't prevent from honestly trying to explain why one asserts 
such a thing - which Jean-Paul did in another post in this thread.

> Twisted is a complex set of packages

Sure. Now I may be dumb, but I thought it was about stackless, not about 
Twisted...

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

Re: programmatically define a new variable on the fly

[Bruno Desthuilliers]

Lee Sander a écrit :
> Hi,
> 
> I would like to define a new variable which is not predefined by me.
> For example,
> I want to create an array called "X%s" where "%s" is to be determined
> based on the data I am processing. So, for example, if I the file
> I'm reading has
> g 99
> on the first line, I want to create a new variable  called "Xg" whose
> length
> is 99.
> I tried eval("Xg=[0]*99") but that did not work.
> 
> any help would be greatly appreciated

As others already pointed out, the canonical solution is to use a dict, 
and it's almost always the best solution - a variant being to use an 
object (eventually a module object) and dynamically add attributes to it 
using setattr()[1].

Now, for the corner case where you *really* want to dynamically create 
new names in the module itself, the solution is to use exec. But I would 
definitively *not* recommand this solution unless you really know what 
you're doing and why you're doing it.

For the record, I did use this last solution twice in seven years. And 
it was mostly to avoid repeating boilerplate code in some low-level 
module of a framework. Definitively not a common case...


[1] which, FWIW, doesn't make much differences since attributes are 
stored in dicts

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

Re: Question about properties.

[Marc 'BlackJack' Rintsch]

On Fri, 10 Aug 2007 03:21:29 -0700, king kikapu wrote:

> Hi,
> 
> i read in a book the following code snippet that is dealing with
> properties:
> 
> class ProtectAndHideX(object):
> def __init__(self, x):
> assert isinstance(x, int), '"x" must be an integer!"'
> self.__x = ~x
> 
> def get_x(self):
> return ~self.__x
> 
> x = property(get_x)
> 
> 
> Can anyone please help me understand what the symbol "~" does here ??

This has nothing to do with properties.  For integer objects ``~`` is the
bitwise negation or invertion operator.

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

Re: Issues of state

[Jay Loden]

Steve Holden wrote:
> greg wrote:
>> Jay Loden wrote:
>>> Like most things involving dynamic client side-javascript code and AJAX
>>> technology, it's a lot harder than you'd like it to be to solve the 
>>> problem, but
>>> in cases where the Back button is really an issue, it's worth the effort.
>> So if you're willing to put in a huge amount of time,
>> effort and ingenuity, it's possible to overcome a
>> problem that only existed in the first place because
>> you chose an inappropriate technique for implementing
>> a user interface...
>>
> Exactly my point. Once you start to involve a complex framework to 
> handle state and interactions you see less and less advantage to 
> "desktop web" applications, since it's hard to match the directness and 
> simplicity of a native GUI.

This is true, you certainly won't get an argument from me! I've spent a lot of
time explaining to people why a real-time GUI and the HTTP protocol don't get
along. Event-driven programming using a request/response framework == square
peg, round hole. But, it seems like the benefits of a web-based GUI make for a
big hammer, so people keep pounding away at that square peg ;)

On the negative side, developing any sort of non-trivial web application is
fraught with problems:

  * language limitations of javascript/(X)HTML
  * highly varied implementations of CSS, HTML, js
  * browser-specific bugs (and features)
  * no real IDE to speak of
  * no way to receive events without some very ugly hacks or polling

However, there are also major benefits, which is why you see so many companies
and individuals jumping on the Web 2.0 train:

  * lower barrier of entry to creating a GUI (compare how quickly
most people can turn out a form in HTML versus creating a GUI
with the same entry fields)
  * cross-platform (yes, you have to support multiple browsers,
but once you do, it works on the majority of platforms. For
instance, support Firefox means OS X, Linux, Windows, etc all
supported at once
  * Convenience for the end user - no need to install anything to
use your software, which entices a lot more people to use it.
This is less of a valid concern in an enterprise environment, but
it still attracts people to feel they don't need to install
something locally
  * available from multiple machines without extra effort for the user
  * Familiar interface (in most cases at least) to the user; more
comfortable for them, less they need to learn.
  * Potentially available on many new platforms such as the iPhone,
with some presentation tweaks. Good luck writing a cross-platform
GUI app that runs on all the major OSes and mobile devices using a
standard GUI toolkit etc. (or shipping the Python interpreter with
an app intended for a Windows Mobile device, for instance)

Your point is absolutely valid, though. I think the web 2.0 craze has people
doing some things that just don't really make sense (like implementing Photoshop
in a browser - what's next, AutoCAD?). The bottom line is that there are many
many things that a native GUI is much better at and more than likely always will
be. If you're developing an application, it's important to stop and ask yourself
why it needs to be a web-based application, and unless you've got compelling
reasons, the native GUI should win out.

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

Re: float to string with different precision

[Zentrader]

On Aug 10, 1:12 am, Peter Otten <[EMAIL PROTECTED]> wrote:
>  [EMAIL PROTECTED] wrote:
> > I have to print float numbers to a file. Each float should be 5
> > characters in width (4 numbers and the decimal point).
> > My problem is that I do not now how to specify float to have different
> > numbers of decimals. For example
>
> > 5.32 -> 5.320
> > 10.356634 -> 10.357
> > 289.234 -> 289.2
>
> > In the string formating operations only fixed number of decimal digits
> > is allow.
> >>> ["%#.4g" % f for f in [5.32, 10.356634, 289.234, 123456789.]]
>
> ['5.320', '10.36', '289.2', '1.235e+08']
>
> Found by playing around with format strings, so no guarantees.
>
> Peter

If the above does not work
[/code]test_list = [ 5.32, 10.35634, 289.234 ]
for num in test_list :
   str_num = "%11.5f" % (num)   ## expand to at least 5
   print str_num, "-->", str_num.strip()[:5][/code]

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

Python Dies on "make install"

[fartknuckle]

When I try to build and install python from source It configures and 
makes fine but upon 'make install' I always get to this
point:



Listing /usr/local/lib/python2.5/xml/sax ...
Compiling /usr/local/lib/python2.5/xml/sax/__init__.py ...
Compiling /usr/local/lib/python2.5/xml/sax/_exceptions.py ...
Compiling /usr/local/lib/python2.5/xml/sax/expatreader.py ...
Compiling /usr/local/lib/python2.5/xml/sax/handler.py ...
Compiling /usr/local/lib/python2.5/xml/sax/saxutils.py ...
Compiling /usr/local/lib/python2.5/xml/sax/xmlreader.py ...
Compiling /usr/local/lib/python2.5/xmllib.py ...
Compiling /usr/local/lib/python2.5/xmlrpclib.py ...
Compiling /usr/local/lib/python2.5/zipfile.py ...
make: *** [libinstall] Error 1 



I am currently trying to install 2.5.1. I get the error no matter what the
version is. Does anyone have an idea what may be causing this?

I have gone through the config.log and found no errors concerning
zipfile.py or zipfile or zip. I am thinking the error is the next command
after the zipfile.py installation because I can go into 
/usr/local/lib/python2.5 and zipfile.py is installed.

Any help much appreciated.

Thanks



-- 
Take summa dis punk!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Future of Python Threading

[Luc Heinrich]

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Future of Python Threading

[Ben Finney]

"Justin T." <[EMAIL PROTECTED]> writes:

> The truth is that the future (and present reality) of almost every
> form of computing is multi-core, and there currently is no effective
> way of dealing with concurrency.

Your post seems to take threading as the *only* way to write code for
multi-core systems, which certainly isn't so.

Last I checked, multiple processes can run concurrently on multi-core
systems. That's a well-established way of structuring a program.

> We still worry about setting up threads, synchronization of message
> queues, synchronization of shared memory regions, dealing with
> asynchronous behaviors, and most importantly, how threaded an
> application should be.

All of which is avoided by designing the program to operate as
discrete processes communicating via well-defined IPC mechanisms.

-- 
 \  "I can picture in my mind a world without war, a world without |
  `\   hate. And I can picture us attacking that world, because they'd |
_o__)never expect it."  -- Jack Handey |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about properties.

[Dustan]

On Aug 10, 5:31 am, [EMAIL PROTECTED] wrote:
> On Aug 10, 12:21 pm, king kikapu <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hi,
>
> > i read in a book the following code snippet that is dealing with
> > properties:
>
> > class ProtectAndHideX(object):
> > def __init__(self, x):
> > assert isinstance(x, int), '"x" must be an integer!"'
> > self.__x = ~x
>
> > def get_x(self):
> > return ~self.__x
>
> > x = property(get_x)
>
> > Can anyone please help me understand what the symbol "~" does here ??
>
> > Thanks for any help!
> >>> help(2)
>
> 
>  |  __invert__(...)
>  |  x.__invert__() <==> ~x
>
> hth.
> Duikboot

http://docs.python.org/ref/unary.html

The unary ~ (invert) operator yields the bit-wise inversion of its
plain or long integer argument. The bit-wise inversion of x is defined
as -(x+1). It only applies to integral numbers.

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

Re: Question about properties.

[Antti Rasinen]

> Hi,
>
> i read in a book the following code snippet that is dealing with
> properties:
>
> class ProtectAndHideX(object):
> def __init__(self, x):
> assert isinstance(x, int), '"x" must be an integer!"'
> self.__x = ~x
>
> def get_x(self):
> return ~self.__x
>
> x = property(get_x)
>
>
> Can anyone please help me understand what the symbol "~" does here ??

My guess is that the example tries to show that it does not matter how the
property computes the value. You can -- if you want -- to store integers
as their bit-inverted versions (the ~ operator) and then do the conversion
when getting the property value.

Assume you initialized the object with ProtectAndHideX(4). Outside the
object you don't have access to the original __x. And! Even if you changed
the name of the variable name to y, you'd have hidden_x.y == -5 instead of
4.

The example is very contrived. There might be some security related cases
where you need to hide what you store in memory, though. (Hopefully they
do more than just invert the bits! :)

NB: I don't know what the original author was thinking here -- my
telepathy isn't what it used to be.

-- 
[ Antti Rasinen <*> [EMAIL PROTECTED] ]

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

Re: Smoother Lines in Turtle Graphics

[Steve Holden]

Jeremy Sanders wrote:
> Ant wrote:
> 
>> Python: Batteries and Turtles included!
> 
> I didn't know that! It looks like turtle is based on Tk, which doesn't have
> antialiasing yet (see http://wiki.tcl.tk/10101 ), so it can't really be
> made nice and smooth (unless you could somehow use tkzinc/tkpath to draw
> with).
> 
> I suppose turtle wouldn't be that hard to reimplement it to use Qt/Gtk
> instead.
> 
Doing that would make it less useful, though, since the primary value of 
turtle is to provide something that (sort of) works fro the standard 
library without adding further batteries.

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: The Future of Python Threading

[Bjoern Schliessmann]

Justin T. wrote:

> The detrimental effects of the GIL have been discussed several
> times and nobody has ever done anything about it. 

Also it has been discussed that dropping the GIL concept requires
very fine locking mechanisms inside the interpreter to keep data
serialised. The overhead managing those fine ones properly is not
at all negligible, and I think it's more than managing GIL.

> The truth is that the future (and present reality) of almost every
> form of computing is multi-core,

Is it? 8)

The question is: If it really was, how much of useful performance
gain would you get?

Regards,


Björn

-- 
BOFH excuse #336:

the xy axis in the trackball is coordinated with the summer solstice

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

Re: Smoother Lines in Turtle Graphics

[Jeremy Sanders]

Ant wrote:

> Python: Batteries and Turtles included!

I didn't know that! It looks like turtle is based on Tk, which doesn't have
antialiasing yet (see http://wiki.tcl.tk/10101 ), so it can't really be
made nice and smooth (unless you could somehow use tkzinc/tkpath to draw
with).

I suppose turtle wouldn't be that hard to reimplement it to use Qt/Gtk
instead.

Jeremy

-- 
Jeremy Sanders
http://www.jeremysanders.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Question about properties.

[king kikapu]

Maybe is just a writers' "play" and nothing else.

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

Re: py2exe with python 2.5

[vedrandekovic]

On 10 kol, 11:02, Ant <[EMAIL PROTECTED]> wrote:
> On Aug 10, 8:39 am, [EMAIL PROTECTED] wrote:
>
>
>
> > Hello,
>
> > Now,I was install python 2.5 and remove python 2.4 completely.After I
> > write:
> > $ python mysetup.py py2exe
> > ...
> >  import py2exe_ util
> > ImportError: Module use of conflicts with this version of Python
>
> > ...ok, I know what is a problem, I haven't remove python completely,
> > in my computer is one more folder Panda3D-1.4.0 but when I remove it
> > and all dll files include python24.dll, I cannot run python or make
> > that setup.
> > (That panda3d contain python)
>
> > Regards,
> > Vedran
>
> Sounds like your path needs setting up properly. Try typing echo %PATH
> % into your console window to find out if Python2.5 is in the path. If
> you are using the default setup, then c:\Python25 should be on the
> path.
>
> --
> Ant...
>
> http://antroy.blogspot.com/

Hi,

yes,Python 2.5 is on the path, but how can I remove panda3d from that
path?

Regards,
Vedran

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

Re: wxPython before MainLoop

[Chris Mellon]

On 8/9/07, Heikki Toivonen <[EMAIL PROTECTED]> wrote:
> [david] wrote:
> > I'd like to refresh the display before I start the main loop.
>
> We have this kind of situation in Chandler, where we display and update
> the splash screen before we enter MainLoop.
>
> 1. Create app object
>http://lxr.osafoundation.org/source/chandler/Chandler.py#080
>
> 2. During app object creation, in OnInit, put up splash screen and update it
>
> http://lxr.osafoundation.org/source/chandler/application/Application.py#433
>
> 3. The splash screen refresh is basically: draw new stuff,
> self.Layout(), self.Update(), wx.Yield()
> http://lxr.osafoundation.org/source/chandler/application/Application.py#1421
>
> 3. Start MainLoop
>http://lxr.osafoundation.org/source/chandler/Chandler.py#086
>

wxYield spins the event loop in place. This can have some serious
consequences if you aren't very careful with your usage, like
recursively entering event handlers. I generally consider it an
experts only interface, and avoid it.

Thankfully, in Python 2.5 you can do some very nice things with
Pythons generators. Basically, replace your wxYielding code with a
python generator that just yields where you used to wxYield, and then
call your generator repeatedly with wx.CallAfter.

Here's an (unpolished) example of a progress dialog that is updated
via generator:

import wx


def startupTask():
for ii in xrange(1001):
cont, skip = yield ii, "step %s"%str(ii)
if not cont:
raise StopIteration



class GeneratorProgress(wx.ProgressDialog):
""" Progress dialog fed via generator.
Task let should be a python generator that yields (value, message) tuples
and is sent (continue, skip) tuples, as per the arguments to and return
values from the wx.ProgressDialog.Update method.
"""
def __init__(self, title, message, tasklet, *args, **kwargs):
super(GeneratorProgress, self).__init__(title, message, *args, **kwargs)
self.tasklet = tasklet
wx.CallAfter(self.iterate)

def iterate(self, cont=None, skip=None):
try:
if cont is None and skip is None:
value, msg = self.tasklet.next()
else:
value, msg = self.tasklet.send((cont, skip))
cont, skip = self.Update(value, msg)
wx.CallAfter(self.iterate, cont, skip)
except StopIteration:
self.Destroy()

def main():
app = wx.App(False)
f = wx.Frame(None)
pg = GeneratorProgress("Startup", "running task...",
startupTask(), parent=f, maximum=1000)
pg.Show()
f.Show()
app.MainLoop()

if __name__ == '__main__':
main()
-- 
http://mail.python.org/mailman/listinfo/python-list

Fwd: AttributeError: 'module' object has no attribute 'HTTPSHandler'

[Matt McCredie]

> I built and installed python 2.5 from source and when I do this:
>
> opener = urllib2.build_opener(SmartRedirectHandler(),
> DefaultErrorHandler(), urllib2.HTTPSHandler())
>
> I get this error.
> AttributeError: 'module' object has no attribute 'HTTPSHandler'
>
> What should I do?


You need `_ssl.pyd' for HTTPSHandler to work. I guess, try to figure
out why that wasn't built, then build it. I suppose I _might_ be able
to give a little more help, but you haven't mentioned what platform
you are using. Even then, I'm not an expert on building Python.

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

Re: programmatically define a new variable on the fly

[Bart Ogryczak]

On 10 ago, 00:11, Lee Sander <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I would like to define a new variable which is not predefined by me.
> For example,
> I want to create an array called "X%s" where "%s" is to be determined
> based on the data I am processing. So, for example, if I the file
> I'm reading has
> g 99
> on the first line, I want to create a new variable  called "Xg" whose
> length
> is 99.
> I tried eval("Xg=[0]*99") but that did not work.

>>> letter = 'g'
>>> import __main__
>>> setattr(__main__,'X%s'%letter,[0]*99)
>>> Xg
[0, 0, 0 ...

Anyway, I don´t see the point in this. Why don´t you just use
something like X['g'] instead?

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

Re: Threaded Design Question

[Graeme Glass]

Using IPC is just adding needles complexity to your program. Instead
of constantly scanning the directory for files and then adding them to
a Queue, and then having to worry if that specific file may have
already been popped off the queue and is currently running by one of
the workers, just poll the directory for a specific event, ala
CREATE.

If you are using a *nix based system, you can use, pyinotify (http://
pyinotify.sourceforge.net/) using EventsCodes.IN_CREATE event.
Else if you using a windows system, take a look at:
http://tgolden.sc.sabren.com/python/win32_how_do_i/watch_directory_for_changes.html,
Tim has a couple of different ideas, sure one of them will be what you
need.

Then all you have to do is added newly created files to the queue,
fork the off to workers and the workers can delete them when they
done. No need to worry if someone is working with it already, as it
will only be added once to the queue, when it is created. HTH.

Regards,
Graeme

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

Re: Stackless Integration

[Bruno Desthuilliers]

Bruno Desthuilliers a écrit :
> Steve Holden a écrit :
(snip)
>> Twisted is a complex set of packages
> 
> Sure. Now I may be dumb, but I thought it was about stackless, not about 
> Twisted...

Sorry, didn't saw your other post.

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

Re: wxPython before MainLoop

[Chris Mellon]

On 8/9/07, [david] <[EMAIL PROTECTED]> wrote:
> I'm disappointed that I didn't get a wxPython solution.
>
> If the only way to get wxPython to correctly handle
> this simple task is to code around it, I don't think
> wxPython is really ready for Windows.
>

This sort of blathering is really just insulting. You don't know what
you're doing, but that doesn't mean that "wxPython isn't really ready
for Windows".

You can't interact with a window without an event loop running. This
is not (just) a wxPython limitation, it's intrinsic in guis in general
and in the windows platform in particular.

You need to do 2-step initialization, and you need to break it into
bits (or threads) that can operate independently of the event loop. If
you would like some suggestions as to how to do that in your
particular case, please feel free to post details on the wx-python
list, but leave your attitude at the door.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The Future of Python Threading

[kyosohma]

On Aug 10, 5:57 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> Justin T. wrote:
> > Hello,
>
> > The nice thing is that this requires a fairly doable amount of work.
> > First, stackless should be integrated into the core. Then there should
> > be an effort to remove the reliance on the GIL for python threading.
> > After that, advanced features like moving tasklets amongst threads
> > should be explored. I can imagine a world where a single python web
> > application is able to redistribute its millions of requests amongst
> > thousands of threads without the developer ever being aware that the
> > application would eventually scale. An efficient and natively multi-
> > threaded implementation of python will be invaluable as cores continue
> > to multiply like rabbits.
>
> Be my guest, if it's so simple.
>
>
>
> 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 -

I've been watching this Intel TBB thing and it sounds like it might be
useful for threading. This fellow claims that he's going to play with
SWIG and may use it to create bindings to TBB for Python, although
he's starting with Perl:

http://softwareblogs.intel.com/2007/07/26/threading-building-blocks-and-c/

Dunno what the license ramifications are though.

Mike

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

Re: The Future of Python Threading

[brad]

brad wrote:

> This is all anecdotal... threads in Python work great for me. I like 
> Ruby's green threads too,

I forgot to mention that Ruby is moving to a GIL over green threads in v2.0
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Dick Moores]

At 06:13 PM 8/9/2007, Ben Finney wrote:
>Content-Transfer-Encoding: base64Grzegorz 
>Słodkowicz <[EMAIL PROTECTED]  [EMAIL PROTECTED] 
>theorisation but I'd rather expect the interpreter
> > simply not to create a second tuple while there already is an
> > identical one.
>
>Others have already said that it's an implementation optimisation,
>which seems to partly answer your question.
>
>It's important to also realise that the language is *deliberately*
>non-committal on whether any given value will have this behaviour;
>that is, it's entirely left to the language implementation which
>optimisation trade-offs to make, and the language user (that's you and
>I) should *not* expect any particular behaviour to hold between
>different implementations.

I'm not clear on the meaning of "implementations" 
here.  Would 2.5 for Windows, Mac, Linux all be 
different implementations? Would Iron Python be another? ActivePython?

Thanks,

Dick


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

Re: The Future of Python Threading

[Justin T.]

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

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

Re: Python Dies on "make install"

[Jarek Zgoda]

fartknuckle napisał(a):

> When I try to build and install python from source It configures and 
> makes fine but upon 'make install' I always get to this
> point:
> 
> 
> 
> Listing /usr/local/lib/python2.5/xml/sax ...
> Compiling /usr/local/lib/python2.5/xml/sax/__init__.py ...
> Compiling /usr/local/lib/python2.5/xml/sax/_exceptions.py ...
> Compiling /usr/local/lib/python2.5/xml/sax/expatreader.py ...
> Compiling /usr/local/lib/python2.5/xml/sax/handler.py ...
> Compiling /usr/local/lib/python2.5/xml/sax/saxutils.py ...
> Compiling /usr/local/lib/python2.5/xml/sax/xmlreader.py ...
> Compiling /usr/local/lib/python2.5/xmllib.py ...
> Compiling /usr/local/lib/python2.5/xmlrpclib.py ...
> Compiling /usr/local/lib/python2.5/zipfile.py ...
> make: *** [libinstall] Error 1 
> 
> 
> 
> I am currently trying to install 2.5.1. I get the error no matter what the
> version is. Does anyone have an idea what may be causing this?
> 
> I have gone through the config.log and found no errors concerning
> zipfile.py or zipfile or zip. I am thinking the error is the next command
> after the zipfile.py installation because I can go into 
> /usr/local/lib/python2.5 and zipfile.py is installed.
> 
> Any help much appreciated.

I saw this (and reported this issue in SF's tracker) at some time around
2.2/2.3 (just cann't recall). I don't know what causes this problem
exactly, but in my case the installation succeeded if I removed prevoius
python's library directory (/usr/lib/python2.x or
/usr/local/lib/python2.x). The module that stopped installation was
exactly the same.

-- 
Jarek Zgoda
http://jpa.berlios.de/
-- 
http://mail.python.org/mailman/listinfo/python-list

Module imports during object instantiation

[Ritesh Raj Sarraf]

Hi,

I've been very confused about why this doesn't work. I mean I don't see any
reason why this has been made not to work.

class Log:

def __init__(self, verbose, lock = None):

if verbose is True:
self.VERBOSE = True
else: self.VERBOSE = False


if lock is None or lock != 1:
self.DispLock = False
else:
self.DispLock = threading.Lock()
self.lock = True

if os.name == 'posix':
   self.platform = 'posix'
   self.color = get_colors()

elif os.name in ['nt', 'dos']:
self.platform = 'microsoft'

try:
import SomeModule
except ImportError:
self.Set_Flag = None

if self.Set_Flag is not None:
self.color = SomeModule.get_colors_windows()

else:
self.platform = None
self.color = None

When I create an object the "import" part never gets executed. Is there a
reason behind it ?
I mean I'd like to keep my class as independent as I want. So that when
later I need to use it somewhere else, I don't need to know if it depends
on any modules.

Currently, the way I'm left is to globally go and import the module and set
a flag there.


Ritesh
-- 
If possible, Please CC me when replying. I'm not subscribed to the list.

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

Re: The Future of Python Threading

[Bjoern Schliessmann]

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?
 
>>> 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.

>>  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.

> 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?

> 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.
 
> 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.

Regards,


Björn

-- 
BOFH excuse #391:

We already sent around a notice about that.

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

Re: Module imports during object instantiation

[James Stroud]

Ritesh Raj Sarraf wrote:
> Hi,
> 
> I've been very confused about why this doesn't work. I mean I don't see any
> reason why this has been made not to work.
> 
> class Log:
> 
> def __init__(self, verbose, lock = None):
> 
> if verbose is True:
> self.VERBOSE = True
> else: self.VERBOSE = False
> 
> 
> if lock is None or lock != 1:
> self.DispLock = False
> else:
> self.DispLock = threading.Lock()
> self.lock = True
> 
> if os.name == 'posix':
>self.platform = 'posix'
>self.color = get_colors()
> 
> elif os.name in ['nt', 'dos']:
> self.platform = 'microsoft'
> 
> try:
> import SomeModule
> except ImportError:
> self.Set_Flag = None
> 
> if self.Set_Flag is not None:
> self.color = SomeModule.get_colors_windows()
> 
> else:
> self.platform = None
> self.color = None
> 
> When I create an object the "import" part never gets executed. Is there a
> reason behind it ?
> I mean I'd like to keep my class as independent as I want. So that when
> later I need to use it somewhere else, I don't need to know if it depends
> on any modules.
> 
> Currently, the way I'm left is to globally go and import the module and set
> a flag there.
> 
> 
> Ritesh

You do realize your import statement will only be called for nt and dos 
systems don't you?

James

-- 
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/
-- 
http://mail.python.org/mailman/listinfo/python-list