twitter: comp.lang.python - 25 new messages in 12 topics

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

==============================================================================
TOPIC: question about list extension
http://groups.google.com/group/comp.lang.python/t/7d837e4cf084d84f?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Apr 16 2010 6:41 am
From: J

Ok... I know pretty much how .extend works on a list... basically it
just tacks the second list to the first list... like so:

>>> lista=[1]
>>> listb=[2,3]
>>> lista.extend(listb)
>>> print lista;
[1, 2, 3]

what I'm confused on is why this returns None:

>>> lista=[1]
>>> listb=[2,3]
>>> print lista.extend(listb)
None
>>> print lista
[1, 2, 3]

So why the None? Is this because what's really happening is that
extend() and append() are directly manipulating the lista object and
thus not actuall returning a new object?

Even if that assumption of mine is correct, I would have expected
something like this to work:

>>> lista=[1]
>>> listb=[2,3]
>>> print (lista.extend(listb))
None

The reason this is bugging me right now is that I'm working on some
code. My program has a debugger class that takes a list as it's only
(for now) argument. That list, is comprised of messages I want to
spit out during debug, and full output from system commands being run
with Popen...

So the class looks something like this:

class debugger():
def printout(self,info):
for line in info:
print "DEBUG: %s" % line

and later on, it get's called like this

meminfo = Popen('cat
/proc/meminfo',shell=True,stdout=PIPE).communicate[0].splitlines()

if debug:
debugger.printout(meminfo)

easy enough....

BUT, what if I have several lists I want to pass on multiple lists...

So changing debugger.printout() to:

def printout(self,*info):

lets me pass in multiple lists... and I can do this:

for tlist in info:
for item in tlist:
print item

which works well...

So, what I'm curious about, is there a list comprehension or other
means to reduce that to a single line?

I tried this, which didn't work because I'm messing up the syntax, somehow:

def func(*info)
print [ i for tlist in info for i in tlist ]

so can someone help me understand a list comprehension that will turn
those three lines into on?

It's more of a curiosity thing at this point... and not a huge
difference in code... I was just curious about how to make that work.

Cheers,

Jeff

== 2 of 4 ==
Date: Fri, Apr 16 2010 7:23 am
From: Bruno Desthuilliers

J a écrit :
> Ok... I know pretty much how .extend works on a list... basically it
> just tacks the second list to the first list... like so:
>
>>>> lista=[1]
>>>> listb=[2,3]
>>>> lista.extend(listb)
>>>> print lista;
> [1, 2, 3]
>
> what I'm confused on is why this returns None:

> So why the None? Is this because what's really happening is that
> extend() and append() are directly manipulating the lista object and
> thus not actuall returning a new object?

Exactly.

> Even if that assumption of mine is correct, I would have expected
> something like this to work:
>
>>>> lista=[1]
>>>> listb=[2,3]
>>>> print (lista.extend(listb))
> None

So what ? It JustWork(tm). list.extend returns None, so "None" is
printed !-)

(snip)

> So changing debugger.printout() to:
>
> def printout(self,*info):
>
> lets me pass in multiple lists... and I can do this:
>
> for tlist in info:
> for item in tlist:
> print item
>
> which works well...
>
> So, what I'm curious about, is there a list comprehension or other
> means to reduce that to a single line?

Why do you think the above code needs to be "reduced to a single line" ?
What's wrong with this snippet ???

> It's more of a curiosity thing at this point... and not a huge
> difference in code... I was just curious about how to make that work.

Uh, ok.

What about:

from itertools import chain

def printout(*infos):
print "\n".join("%s" % item for item in chain(*infos))

HTH

== 3 of 4 ==
Date: Fri, Apr 16 2010 7:37 am
From: Lie Ryan

On 04/16/10 23:41, J wrote:
> Ok... I know pretty much how .extend works on a list... basically it
> just tacks the second list to the first list... like so:
>
>>>> lista=[1]
>>>> listb=[2,3]
>>>> lista.extend(listb)
>>>> print lista;
> [1, 2, 3]
>
> what I'm confused on is why this returns None:
>
>>>> lista=[1]
>>>> listb=[2,3]
>>>> print lista.extend(listb)
> None
>>>> print lista
> [1, 2, 3]
>
> So why the None? Is this because what's really happening is that
> extend() and append() are directly manipulating the lista object and
> thus not actuall returning a new object?

In python every function that does not explicitly returns a value or use
a bare return returns None. So:

def foo():
pass
def bar():
return

print foo()
print bar()

you can say that returning None is python's equivalent to void return
type in other languages.

> Even if that assumption of mine is correct, I would have expected
> something like this to work:
>
>>>> lista=[1]
>>>> listb=[2,3]
>>>> print (lista.extend(listb))
> None

Why would these has to be different?
print None
print (None)

<snip>

> So, what I'm curious about, is there a list comprehension or other
> means to reduce that to a single line?

from itertools import chain
def printout(*info):
print '\n'.join(map(str, chain(*info)))

or using generator comprehension

from itertools import chain
def printout(*info):
print '\n'.join(str(x) for x in chain(*info))

== 4 of 4 ==
Date: Fri, Apr 16 2010 7:59 am
From: "J. Cliff Dyer"

On Sat, 2010-04-17 at 00:37 +1000, Lie Ryan wrote:
> On 04/16/10 23:41, J wrote:

> > So, what I'm curious about, is there a list comprehension or other
> > means to reduce that to a single line?
>
> from itertools import chain
> def printout(*info):
> print '\n'.join(map(str, chain(*info)))
>
> or using generator comprehension
>
> from itertools import chain
> def printout(*info):
> print '\n'.join(str(x) for x in chain(*info))

It's even easier if you don't need to modify lista.

print lista + listb

==============================================================================
TOPIC: Merge two directories together
http://groups.google.com/group/comp.lang.python/t/f0ca461448450a6d?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Apr 16 2010 6:48 am
From: Keith Hughitt

Suppose you have two file-trees with common sub-directories but
different files that you want to merge together, e.g.

/test/
/test/a/
/test/a/file1

/test2/
/test2/a/
/test2/a/file2

You can easily merge the directories in Linux using the "cp" command:

cp -r test/* test2/

While Python provides some helpful methods for moving files and
directories around (shutil.move, shutil.copytree, etc), none of them
seem to be able to merge two directories.

I've looked around some on Google for an alternative to calling cp
directly, but so far no luck.

Any ideas?

== 2 of 3 ==
Date: Fri, Apr 16 2010 10:43 am
From: Steven Howe

Think about using the subprocess module. There are calls made just for
your. Notably (using command pydoc subprrocess.call) :
---------------------
subprocess.call = call(*popenargs, **kwargs)
Run command with arguments. Wait for command to complete, then
return the returncode attribute.

The arguments are the same as for the Popen constructor. Example:

retcode = call(["ls", "-l"])
---------------------

Steven Howe

On 04/16/2010 06:48 AM, Keith Hughitt wrote:
> Suppose you have two file-trees with common sub-directories but
> different files that you want to merge together, e.g.
>
> /test/
> /test/a/
> /test/a/file1
>
> /test2/
> /test2/a/
> /test2/a/file2
>
> You can easily merge the directories in Linux using the "cp" command:
>
> cp -r test/* test2/
>
> While Python provides some helpful methods for moving files and
> directories around (shutil.move, shutil.copytree, etc), none of them
> seem to be able to merge two directories.
>
> I've looked around some on Google for an alternative to calling cp
> directly, but so far no luck.
>
> Any ideas?
>

== 3 of 3 ==
Date: Fri, Apr 16 2010 11:16 am
From: "Dave W."

> While Python provides some helpful methods for moving files and
> directories around (shutil.move, shutil.copytree, etc), none of
> them seem to be able to merge two directories.
-snip-
> Any ideas?

It's not pretty, but you could hack up the original copytree()
source so it ignores errors from the makedirs() call. Then it
should work more-or-less like 'cp -r'. This isn't ideal, because
'OSError' is thrown, which could mean that the dir already exists
(okay), or it could be a 'real' error, like the current user doesn't
have permission to write to the destination. (See 'XXX' in the code
below.)

Better would be to match on the error string and only ignore the
'directory exists' error. Unfortunately, the error messages do
vary per-platform. Here's what I see under Windows when the
directory already exists:

WindowsError: [Error 183] Cannot create a file when that file
already exists: 'test2'

and under CentOS:

OSError: [Errno 17] File exists: 'test2'

The code below seems to work under both Linux and Windows; but I
didn't really test it much, so handle with care. :-}

----------

def copytree(src, dst, symlinks=False, ignore=None):
import os
from shutil import copy2, copystat, Error

names = os.listdir(src)
if ignore is not None:
ignored_names = ignore(src, names)
else:
ignored_names = set()

try:
os.makedirs(dst)
except OSError, exc:
# XXX - this is pretty ugly
if "file already exists" in exc[1]: # Windows
pass
elif "File exists" in exc[1]: # Linux
pass
else:
raise

errors = []
for name in names:
if name in ignored_names:
continue
srcname = os.path.join(src, name)
dstname = os.path.join(dst, name)
try:
if symlinks and os.path.islink(srcname):
linkto = os.readlink(srcname)
os.symlink(linkto, dstname)
elif os.path.isdir(srcname):
copytree(srcname, dstname, symlinks, ignore)
else:
copy2(srcname, dstname)
# XXX What about devices, sockets etc.?
except (IOError, os.error), why:
errors.append((srcname, dstname, str(why)))
# catch the Error from the recursive copytree so that we can
# continue with other files
except Error, err:
errors.extend(err.args[0])
try:
copystat(src, dst)
except WindowsError:
# can't copy file access times on Windows
pass
except OSError, why:
errors.extend((src, dst, str(why)))
if errors:
raise Error, errors

==============================================================================
TOPIC: Can anyone reproduce this crash?
http://groups.google.com/group/comp.lang.python/t/d9ae972a6dc8e80d?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 16 2010 6:50 am
From: "Alf P. Steinbach"

* Alf P. Steinbach:
>
> Found a another bug discussion with
>
> * same exception,
> 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER
>
> * same address,
> 0x78588389
>
> * almost same Python version,
> namely Py3,
>
> * almost same context,
> namely occurring when program terminates,
>
> at
>
> <url:
> http://www.mail-archive.com/pyinstaller@googlegroups.com/msg01564.html>
>
> Can I report a bug with so little information -- not generally
> reproducible, but hey, someone else has seen something nearly identical?

OK, I did, <url: http://bugs.python.org/issue8418>.

Cheers,

- Alf

==============================================================================
TOPIC: Updated License Term Agreement for VC Redistributable in VS 2008 SP1
http://groups.google.com/group/comp.lang.python/t/eca5d339ea8086df?hl=en
==============================================================================

== 1 of 5 ==
Date: Fri, Apr 16 2010 7:05 am
From: python@bdurham.com

Hi Tim,

> The license agreement change fixes a problem that was accidentally introduced by Visual Studio 2008 SP1. The redistributable package that can
be downloaded directly from Microsoft (which you would use if you had
the Express Edition) has the right license to begin with. It never had
the
restriction. http://msdn.microsoft.com/en-us/library/ms235299.aspx.
Microsoft's intent is that you be able to distribute the non-debug
runtimes with any applications built with Visual Studio.

Original poster here. Thanks for your insight!

> They are evil, but not arbitrarily malicious.

Regards,
Malcolm

----- Original message -----
From: "Tim Roberts" <timr@probo.com>
To: python-list@python.org
Date: Fri, 16 Apr 2010 00:31:35 -0700
Subject: Re: Updated License Term Agreement for VC Redistributable in VS
2008 SP1

Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>
>I don't think this license agreement change involves the express
>editions, which are free. Correct me if I'm wrong here?

The license agreement change fixes a problem that was accidentally
introduced by Visual Studio 2008 SP1. The redistributable package that
can
be downloaded directly from Microsoft (which you would use if you had
the
Express Edition) has the right license to begin with. It never had the
restriction.

http://msdn.microsoft.com/en-us/library/ms235299.aspx

Microsoft's intent is that you be able to distribute the non-debug
runtimes
with any applications built with Visual Studio. They are evil, but not
arbitrarily malicious.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
--
http://mail.python.org/mailman/listinfo/python-list

== 2 of 5 ==
Date: Fri, Apr 16 2010 8:59 am
From: CM

On Apr 16, 3:31 am, Tim Roberts <t...@probo.com> wrote:
> Andrej Mitrovic <andrej.mitrov...@gmail.com> wrote:
>
> >I don't think this license agreement change involves the express
> >editions, which are free. Correct me if I'm wrong here?
>
> The license agreement change fixes a problem that was accidentally
> introduced by Visual Studio 2008 SP1. The redistributable package that can
> be downloaded directly from Microsoft (which you would use if you had the
> Express Edition) has the right license to begin with. It never had the
> restriction.
>
> http://msdn.microsoft.com/en-us/library/ms235299.aspx
>
> Microsoft's intent is that you be able to distribute the non-debug runtimes
> with any applications built with Visual Studio. They are evil, but not
> arbitrarily malicious.

Just to be clear: are you saying that if one has Visual Studio 2008
Express Edition (the free one), one then has the right to redistribute
the necessary dlls for using py2exe to make working Python 2.6
executables?

Thanks,
Che

== 3 of 5 ==
Date: Fri, Apr 16 2010 10:01 am
From: Lie Ryan

On 04/15/10 06:38, python@bdurham.com wrote:
> Alex,
>
>> I do not see anything about redistribution, only installation, unless I am missing something?
>
> I read "installation" to mean the same as "redistribution" in the
> context of this article. Perhaps I'm wrong?
>

Does it makes sense to be able to install a library in other's computer,
but not redistribute it? Hmm... I'll have to consult a lawyer.

== 4 of 5 ==
Date: Fri, Apr 16 2010 10:40 am
From: python@bdurham.com

Lie,

> Does it makes sense to be able to install a library in other's computer, but not redistribute it? Hmm... I'll have to consult a lawyer.

See Tim Robert's response (I can't remember which Python mailing list)

<quote>
The license agreement change fixes a problem that was accidentally
introduced by Visual Studio 2008 SP1. The redistributable package that
can be downloaded directly from Microsoft (which you would use if you
had the Express Edition) has the right license to begin with. It never
had the restriction.

http://msdn.microsoft.com/en-us/library/ms235299.aspx

Microsoft's intent is that you be able to distribute the non-debug
runtimes with any applications built with Visual Studio. They are evil,
but not arbitrarily malicious.
</quote>

Malcolm

== 5 of 5 ==
Date: Fri, Apr 16 2010 10:45 am
From: Lie Ryan

On 04/17/10 03:40, python@bdurham.com wrote:
> Lie,
>
>> Does it makes sense to be able to install a library in other's computer, but not redistribute it? Hmm... I'll have to consult a lawyer.
>
> See Tim Robert's response (I can't remember which Python mailing list)
>

I was responding to Alex Hall's comment (and your subsequent reply)

"""
python@bdurham.com wrote:
> Alex Hall wrote:
>> I do not see anything about redistribution, only
>> installation, unless I am missing something?
> I read "installation" to mean the same as "redistribution" in the
> context of this article. Perhaps I'm wrong?
"""

it appears to me *if* someone had written an EULA that allows
installation on other machine but not redistributing it, they must be
fairly insane (in this case, Microsoft isn't insane enough to write such
EULA for their VC).

==============================================================================
TOPIC: How to run program in Linux
http://groups.google.com/group/comp.lang.python/t/016d98fe9ae9a991?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 16 2010 7:32 am
From: Dave Angel

Jim Byrnes wrote:
> Dave Angel wrote:
>> Jim Byrnes wrote:
>>> <div class="moz-text-flowed" style="font-family: -moz-fixed">I am just
>>> learning Python and am new to Linux so I am probably doing something
>>> to trip myself up. I am trying to run an example GUI program that
>>> fetches a record from a database. All the files are in the same folder.
>>>
>>> The program runs but its results vary depending on how I started it.
>>> If I run it from the terminal or Idle, I enter a key and the program
>>> fetches the proper record. If I run it from Nautilis or a panel
>>> launcher, I enter the proper key and I get an error message saying the
>>> key does not exist.
>>>
>>> I am assuming that I am having path issues but don't know how to
>>> correct it.
>>>
>>> Thamks, Jim
>>>
>> Presumably you're also new to mailing lists.
>
> Not really.
>
>> At an absolute minimum when you describe an error, PASTE the error
>> message, complete with traceback, into your message. As it stands, I'm
>> left wondering which key on your keyboard can possibly "not exist."
>> Perhaps it's a non-ASCII code, and you're getting some encoding error.
>> That's a common discrepancy between running from a terminal and running
>> from some GUI.
>
> The error was generated by the program, not Python. The 'key' I was
> referring to was a dictionary type key, not a physical one on the
> keyboard.
>
>> Even better is to specify the version of Python this program is
>> presumably written in, and what Linux distro. Then you say it's a GUI
>> program, so you should specify which GUI library you're using.
>
> Python 2.6, Ubuntu 9.10, tkinter
>
>> Now if I do a bunch of guessing, I might come up with the likelihood
>> that your "Nautilus" is supplying a different current directory than the
>> one the script is located in. You can find that out by looking at:
>> os.path.abspath(os.curdir)
>
> OK, thanks. If that is the case how do I correct it?
>
>> But of course how you print that depends on what GUI package you're
>> running.
>>
>> DaveA
>>
>
> Regards, Jim
>
>
You forgot to include the list in your reply. Try using reply-all instead.

If you determine that the current directory is your problem, and that
Nautilus isn't setting it the way you'd like, then you may have to
resort to other ways to identify the other files you mention. Easiest
way might be to use the __file__ attribute of each module, which gives
its complete path. So your code in the main script could do something
like (untested):
target = os.path.dirname(__file__)
os.chdir(target)

Better is usually to ignore current directory, and passed the desired
directory name into whatever function is going to use it.

HTH,

DaveA

==============================================================================
TOPIC: Download Visual Studio Express 2008 now
http://groups.google.com/group/comp.lang.python/t/65e34924e7d42c90?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 16 2010 7:58 am
From: Robert Kern

On 2010-04-16 07:30 AM, Brian Blais wrote:
> On Apr 12, 2010, at 16:36 , Martin v. Loewis wrote:
>
>> If you are planning to build Python extension modules in the next five
>> years, I recommend that you obtain a copy of VS Express
>
> Am I missing something here? I have heard this before, but I have built
> extension modules many times under windows (using Cython) and never once
> used a MS product. I've just had to change a distutils config file to
> use a different compiler (mingw32, directions here:
> http://docs.cython.org/src/tutorial/appendix.html). It seems to work
> fine. What is the basis of this claim that you need MS Visual Studio to
> do it?

Most extensions will work okay when compiled with mingw32. However, mingw32 is
still based on MSVCRT6.dll as its C runtime. You would get errors whenever a
FILE* pointer crosses over the boundary. distutils will tell it to link with the
CRT that Python is currently built with, but some of the headers aren't up to
date for that CRT, so some C++ extensions will not work (a command C++ operation
triggers a table lookup in a static table defined in the CRT, but it differs in
size between versions).

--
Robert Kern

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

==============================================================================
TOPIC: Suppress output to stdout/stderr in InteractiveInterpreter
http://groups.google.com/group/comp.lang.python/t/e5e40b7fe474a2ec?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Apr 16 2010 8:16 am
From: Robert Kern

On 2010-04-16 00:42 AM, Dave W. wrote:
>>> Think I'll start a new post with the subject: "Globally override
>>> built-in print function?"
>
>> Don't bother. Replacing sys.stdout is the right thing to do. It
>> won't interfere with the C++ streams...
> -snip-
>
> I'm not so certain. Won't the C++ host app share the same
> stdin/stdout/stderr file descriptors with the embedded Python
> interpreter? So there's at least the *potential* for a background
> C++ thread dedicated to processing Python commands (which redirect
> stdout) to interfere with, say, the main thread's log statements to
> stdout. Seems like I could wind up with log statements in my
> interpreter results.

No. Changing the object that the name sys.stdout refers to does not swap out the
underlying file descriptors.

> Anyway, that's why I've got this mild obsession with finding a way
> to capture output from the interpreter *without* redirecting
> stdout...

Not possible. Many things write directly to sys.stdout/sys.stderr.

--
Robert Kern

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

== 2 of 2 ==
Date: Fri, Apr 16 2010 9:46 am
From: "Dave W."

>>> Don't bother. Replacing sys.stdout is the right thing to do. It
>>> won't interfere with the C++ streams...

>> I'm not so certain. Won't the C++ host app share the same
>> stdin/stdout/stderr file descriptors with the embedded Python
>> interpreter?

> No. Changing the object that the name sys.stdout refers to does
> not swap out the underlying file descriptors.

Whoa--that's a bombshell. I guess I shouldn't have assumed that
this was the case, but it seemed so 'obvious'. Glad I was wrong,
since it makes like much, much easier. Thank you!

[xref "Globally override built-in print function?"]

==============================================================================
TOPIC: Reactive programming in Python ?
http://groups.google.com/group/comp.lang.python/t/4b8b621985163c1a?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Apr 16 2010 8:18 am
From: pca

Dear all,

Could "reactive programming" still increase the productivity and joy
of Python programming? I'd like to hear your thoughts on the idea
that object-oriented "programming by formula", as in a spreadsheet,
would simplify our work, because we would not have to worry about the
sequence of program execution anymore.

In fact, I have seeded an open-source project, Yoopf, that enables
programming by formula within Python, with the goal of dramatically
accelerating the development of the model view in the MVC model.
Declarative-style programming has accelerated the development of the
presentation layer (with HTML, CSS) and the Database layer (with SQL),
so why not take advantage of it for the Business Logic layer too?

You can find more information on this project at www.yoopf.org. Your
comments are more than welcome!

Best regards,
P. Carbonnelle

== 2 of 2 ==
Date: Fri, Apr 16 2010 11:03 am
From: Mike Kent

On Apr 16, 11:18 am, pca <pcarb...@yooper.be> wrote:
> Dear all,
>
> Could "reactive programming" still increase the productivity and joy
> of Python programming? I'd like to hear your thoughts on the idea
> that object-oriented "programming by formula", as in a spreadsheet,
> would simplify our work, because we would not have to worry about the
> sequence of program execution anymore.
>
> In fact, I have seeded an open-source project, Yoopf, that enables
> programming by formula within Python, with the goal of dramatically
> accelerating the development of the model view in the MVC model.
> Declarative-style programming has accelerated the development of the
> presentation layer (with HTML, CSS) and the Database layer (with SQL),
> so why not take advantage of it for the Business Logic layer too?
>
> You can find more information on this project atwww.yoopf.org. Your
> comments are more than welcome!
>
> Best regards,
> P. Carbonnelle

The requested URL /www.yoopf.org was not found on this server.

==============================================================================
TOPIC: Globally override built-in print function?
http://groups.google.com/group/comp.lang.python/t/82f31845d1e646ba?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Apr 16 2010 8:20 am
From: Robert Kern

On 2010-04-15 21:17 PM, Dave W. wrote:
>>> I naively thought I could capture output from exec()'ed print
>>> invocations by (somehow) overriding 'print' globally. But this
>>> seems not to be possible.<snip>
>
>>
>> old_print = __builtins__.print
>> __builtins__.print = printhook
>> yield
>> __builtins__.print = old_print
>
> I'm pretty sure this is semantically equivalent to my original code,
> but I gave it a try anyway.

Not at all. Declaring "global print" then assigning to "print" simply changes
what the module's "print" variable refers to. Other modules are unaffected.
"Global" variables aren't truly global; they are actually local to the module.
You need to replace it in the __builtins__ because that's where everyone else
gets it.

> FWIW, it doesn't work, either. :-}

Right. Lie answered why. I didn't pay attention and thought you were already
using Python 3.

--
Robert Kern

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

== 2 of 3 ==
Date: Fri, Apr 16 2010 9:50 am
From: "Dave W."

>>> old_print = __builtins__.print
>>> __builtins__.print = printhook
>>> yield
>>> __builtins__.print = old_print
>
>> I'm pretty sure this is semantically equivalent to my original
>> code, but I gave it a try anyway.
>
> Not at all. Declaring "global print" then assigning to "print"
> simply changes what the module's "print" variable refers to. Other
> modules are unaffected. "Global" variables aren't truly global;
> they are actually local to the module. You need to replace it in
> the __builtins__ because that's where everyone else gets it.
>
> > FWIW, it doesn't work, either. :-}
>
> Right. Lie answered why. I didn't pay attention and thought you
> were already using Python 3.

Thanks, Robert and Lie for the considered and informative responses.
Getting feedback like this from people who really understand
Python's internals is invaluable. Sounds like redirecting
stdout/stderr is the way to go. (Especially given that they're not
the 'real' stdout/stderr---that was news to me!)

[xref "Suppress output to stdout/stderr in InteractiveInterpreter"]

== 3 of 3 ==
Date: Fri, Apr 16 2010 10:17 am
From: "J. Cliff Dyer"

On Fri, 2010-04-16 at 09:50 -0700, Dave W. wrote:
> >>> old_print = __builtins__.print
> >>> __builtins__.print = printhook
> >>> yield
> >>> __builtins__.print = old_print
> >
> >> I'm pretty sure this is semantically equivalent to my original
> >> code, but I gave it a try anyway.
> >
> > Not at all. Declaring "global print" then assigning to "print"
> > simply changes what the module's "print" variable refers to. Other
> > modules are unaffected. "Global" variables aren't truly global;
> > they are actually local to the module. You need to replace it in
> > the __builtins__ because that's where everyone else gets it.
> >
> > > FWIW, it doesn't work, either. :-}
> >
> > Right. Lie answered why. I didn't pay attention and thought you
> > were already using Python 3.
>
> Thanks, Robert and Lie for the considered and informative responses.
> Getting feedback like this from people who really understand
> Python's internals is invaluable. Sounds like redirecting
> stdout/stderr is the way to go. (Especially given that they're not
> the 'real' stdout/stderr---that was news to me!)
>
> [xref "Suppress output to stdout/stderr in InteractiveInterpreter"]

It's good to remember that names in python are just names. The objects
that have the names "sys.stdout" and "sys.stderr" are the real deal, but
when you assign a file object to them, you are not actually
"redirecting" anything. You are assigning a name (sys.stdout) to a
different file object. The old object still points to STDOUT, but
sys.stdout no longer refers to that object as long as your assignment
remains in scope.

==============================================================================
TOPIC: python wia and RegisterEvent
http://groups.google.com/group/comp.lang.python/t/1e6968e296d75797?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 16 2010 8:37 am
From: gelonida

Hi Mark,

On Apr 16, 3:16 am, Mark Hammond <skippy.hamm...@gmail.com> wrote:
> On 16/04/2010 7:15 AM,gelonidawrote:
>
> The model used by pywin32 is more "low level" than that exposed by some
> of the MS languages. You probably need something closer to:
>
> class MgrHandlerClass:
> def OnEvent(self, EventID=defaultNamedNotOptArg, ...):
> print "Called back with ..."
>
> manager = win32com.client.DispatchWithEvents("WIA.DeviceManager",
> MgrHandlerClass)
> manager.RegisterEvent(EventID=constants.wiaEventDeviceConnected,DeviceID=u'*')
> manager.RegisterEvent(EventID=constants.wiaEventDeviceDisconnected,DeviceID=u'*')
>
> And magically your OnEvent should be called when the event happens.
> Googling for 'DispatchWithEvents' might find some good hits for more
> information.
>

I'm still stuck. Please look at following code snippet.
I tried to reduce it to the absolute minimum.
running under WinXP and python 2.6.4

import win32com.client,pythoncom,time

defaultNamedNotOptArg=pythoncom.Empty
wiaEventDeviceConnected =u'{A28BBADE-64B6-11D2-
A231-00C04FA31809}' # from enum EventID

class MgrHandlerClass: # doesn't work either
def OnEvent(self, EventID=defaultNamedNotOptArg,
DeviceID=defaultNamedNotOptArg, ItemID=defaultNamedNotOptArg):
print "Called back with ..."

manager = win32com.client.DispatchWithEvents("WIA.DeviceManager",
MgrHandlerClass)
manager.RegisterEvent(EventID=wiaEventDeviceConnected,DeviceID=u'*')

while True:
print "sleep"
time.sleep(10)

When I plug / unplug a USB WIA device nothing shows up.
My C# implementation prints messages on wiaEventDeviceConnected /
wiaEventDeviceDisconnected events if I register them.

What am I missing?

Should MgrHandlerClass inherit from some kind of default class?

==============================================================================
TOPIC: Incorrect scope of list comprehension variables
http://groups.google.com/group/comp.lang.python/t/2b64b9a9069a324f?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 16 2010 8:48 am
From: aahz@pythoncraft.com (Aahz)

In article <4bb92850$0$8827$c3e8da3@news.astraweb.com>,
Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
>
>Nevertheless, it is a common intuition that the list comp variable should
>*not* be exposed outside of the list comp, and that the for-loop variable
>should. Perhaps it makes no sense, but it is very common -- I've never
>heard of anyone being surprised that the for-loop variable is exposed,
>but I've seen many people surprised by the fact that list-comps do expose
>their loop variable.

I've definitely seen people surprised by the for-loop behavior.
--
Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

==============================================================================
TOPIC: cross-platform coloured text in terminal
http://groups.google.com/group/comp.lang.python/t/1c1cb43fa8d7a8ac?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 16 2010 9:59 am
From: Lie Ryan

On 04/16/10 19:28, Jonathan Hartley wrote:
> I'm playing with ideas of what API to expose. My favourite one is to
> simply embed ANSI codes in the stream to be printed. Then this will
> work as-is on Mac and *nix. To make it work on Windows, printing could
> be done to a file0-like object which wraps stdout:

The problem with that is you're simply reinventing ANSI.SYS device driver.

An alternative API is you could override .__add__(), like so (completely
untested):

class Color(object):
def __init__(self, color):
self.color = map_the_color(color)
self.string = ""
def __add__(self, string):
self.string += string
return self
def __str__(self):
if terminal_can_do_ansi_color:
return ansicolorescape(self.string, self.color)
elif windows:
syscalltocolor(self.color)
print self.string
syscalltocolor(reset the color)
return ""

GREEN = Color('green')
print GREEN + "Great" + "Good"

you can even go a bit further and allow chained calls (again, completely
untested, but you get the idea):

class Color(object):
def __init__(self, color):
self.color = map_the_color(color)
self.stack = []
def __add__(self, string):
if isinstance(string, Color):
# not a string, chain the calls
self.stack.append((string.color, []]))
else:
# a string,
self.stack[-1][1].append(string)
return self
def __radd__(self, string):
self.stack.append([self.default, string])
return self

def __str__(self):
if ansi_capable:
return colorescape(format, string)
elif windows:
for format, string in self.stack:
syscalltocolor(color)
print string
return ""

GREEN = Color('green')
RED = Color('red')

print "Fairly" + GREEN + "Great" + RED + "Poor"

or something like that, and you will have an API that works
transparently on all platforms. The downside is that you cannot call
str(GREEN + "foo") on windows.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Friday, April 16, 2010

comp.lang.python - 25 new messages in 12 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts