Python-list Digest, Vol 129, Issue 4
Ramas Sami
ramas at live.co.uk
Tue Jun 3 06:07:49 EDT 2014
My Python 3.3 is shutting down soon I open the new file or existing Python file
Best Regards
--Ramas
From: python-list-request at python.org
Subject: Python-list Digest, Vol 129, Issue 4
To: python-list at python.org
Date: Tue, 3 Jun 2014 12:00:05 +0200
Send Python-list mailing list submissions to
python-list at python.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.python.org/mailman/listinfo/python-list
or, via email, send a message with subject or body 'help' to
python-list-request at python.org
You can reach the person managing the list at
python-list-owner at python.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-list digest..."
--Forwarded Message Attachment--
From: rustompmody at gmail.com
To: python-list at python.org
Date: Mon, 2 Jun 2014 23:28:10 -0700
Subject: Re: can someone explain the concept of "strings (or whatever) being immutable"
On Tuesday, June 3, 2014 10:36:37 AM UTC+5:30, Deb Wyatt wrote:
> That was just the first question. What does immutable really mean
> if you can add items to a list? and concatenate strings? I don't
> understand enough to even ask a comprehensible question, I guess.
It is with some pleasure that I see this question: Most people who are
clueless have no clue that they are clueless -- also called the
Dunning-Krüger effect.
Be assured that this question is much harder and problematic than people believe.
There are earlier discussions on this on this list, eg
https://groups.google.com/forum/#!topic/comp.lang.python/023NLi4XXR4[126-150-false]
[Sorry the archive thread is too broken to quote meaningfully]
Here's a short(!) summary:
Programmer's live in 2 worlds.
1. A timeless mathematical world. Philosophers call this the platonic world
after Plato's allegory of the cave:
http://en.wikipedia.org/wiki/Allegory_of_the_Cave
2. An in-time world that is called "Empirical" in philosophy
You cannot reject 2 because your programs run in time and produce
effects (hopefully!) in the empirical world.
You cannot reject 1 because the time at which you - the programmer -
function is in another space-time from the run-time of your program.
The very fact that you write a program means you have (been able to)
algorithmize out a complex *process* into a simpler recipe - a *program*.
Once you see the need for both worldviews 1 and 2 you will see why even the most
deft=footed trip up doing this dance. eg. When someone says:
3 is immutable but [1,2,3] is mutable this is not a necessary fact but
an incidental choice of python's semantics.
Functional languages make everything immutable
Assembly language makes everything mutable -- you can self-modify the
code containing 3 as an immediate operand in an instruction into one containing
something else.¹
However the basic (necessary not incidental) fact remains - you need to dance between
the two worldviews:
- platonic and empiric (in traditional philosophy lingo)
- declarative and imperative (in computer theory lingo)
- FP and OO styles (the two major fashions in programming languages)
Choose absolutely only the first and your program can have no effect
whatever including writing a result to the screen
Choose absolutely only the second that you can have no comprehension of your
program's semantics.
You can find this further elaborated on my blog whose title is a summarization
of what Ive written above: http://blog.languager.org/search/label/FP
--------------
¹Heck! Steven showed some trick to make it happen in python also
But Ive not fathomed the black magic!
--Forwarded Message Attachment--
From: rustompmody at gmail.com
To: python-list at python.org
Date: Mon, 2 Jun 2014 23:30:28 -0700
Subject: Re: Python 3 is killing Python
On Tuesday, June 3, 2014 11:42:30 AM UTC+5:30, jmf wrote:
> after thinking no
Yes [Also called Oui]
--Forwarded Message Attachment--
From: marko at pacujo.net
To: python-list at python.org
Date: Tue, 3 Jun 2014 09:36:51 +0300
Subject: Re: Benefits of asyncio
Paul Rubin <no.email at nospam.invalid>:
> Marko Rauhamaa <marko at pacujo.net> writes:
>> - Thread programming assumes each thread is waiting for precisely
>> one external stimulus in any given state -- in practice, each
>> state must be prepared to handle quite a few possible stimuli.
>
> Eh? Threads typically have their own event loop dispatching various
> kinds of stimuli.
I have yet to see that in practice. The "typical" thread works as
follows:
while True:
while request.incomplete():
request.read() # block
sql_stmt = request.process()
db.act(sql_stmt) # block
db.commit() # block
response = request.ok_response()
while response.incomplete():
response.write() # block
The places marked with the "block" comment are states with only one
valid input stimulus.
> Have threads communicate by message passing with immutable data in the
> messages, and things tend to work pretty straightforwardly.
Again, I have yet to see that in practice. It is more common, and
naturally enforced, with multiprocessing.
> Having dealt with some node.js programs and the nest of callbacks they
> morph into as the application gets more complicated, threads have
> their advantages.
If threads simplify an asynchronous application, that is generally done
by oversimplifying and reducing functionality.
Yes, a "nest of callbacks" can get messy very quickly. That is why you
need to be very explicit with your states. Your class needs to have a
state field named "state" with clearly named state values.
Marko
--Forwarded Message Attachment--
From: patil.jay2009 at gmail.com
To: python-list at python.org
Date: Mon, 2 Jun 2014 23:40:18 -0700
Subject: Re: Lock Windows Screen GUI using python
On Tuesday, 3 June 2014 10:39:31 UTC+5:30, Ian wrote:
> On Mon, Jun 2, 2014 at 10:28 PM, Jaydeep Patil <patil.jay2009 at gmail.com> wrote:
>
> > Dear all,
>
> > Can we Lock Windows Screen GUI till program runs & unlock screen GUI when program finishes?
>
>
>
> If you mean can you programmatically bring up the Windows lock screen,
>
> then you can do this:
>
>
>
> import ctypes
>
> ctypes.windll.user32.LockWorkStation()
>
>
>
> The only way to unlock it is for the user to log in.
>
>
>
> If you mean something else, you'll have to be more specific.
Hi Lan,
Currently I am doing some automation in python excel. It read the data & plots number of graphs. It took more than 20 minutes. So while running my python program if user clicks on excel, error came.
So just i want to lock GUI not workstation.
I hope you understand this.
Let me know if you have any idea about it.
Regards
Jaydeep Patil
--Forwarded Message Attachment--
From: ian.g.kelly at gmail.com
To: python-list at python.org
Date: Tue, 3 Jun 2014 01:09:38 -0600
Subject: Re: Lock Windows Screen GUI using python
On Tue, Jun 3, 2014 at 12:40 AM, Jaydeep Patil <patil.jay2009 at gmail.com> wrote:
> Hi Lan,
>
> Currently I am doing some automation in python excel. It read the data & plots number of graphs. It took more than 20 minutes. So while running my python program if user clicks on excel, error came.
>
> So just i want to lock GUI not workstation.
>
> I hope you understand this.
>
> Let me know if you have any idea about it.
You can set the Application.Interactive property on Excel to block user input:
http://msdn.microsoft.com/en-us/library/office/ff841248(v=office.15).aspx
Example:
excel_app = win32com.client.Dispatch("Excel.Application")
excel_app.Interactive = False
try:
# Do some automation...
finally:
excel_app.Interactive = True
--Forwarded Message Attachment--
From: steve at pearwood.info
To: python-list at python.org
Date: Tue, 3 Jun 2014 07:46:26 +0000
Subject: Re: can someone explain the concept of "strings (or whatever) being immutable"
On Mon, 02 Jun 2014 21:06:37 -0800, Deb Wyatt wrote:
> """a_string = "This is a string"
> a_string is pointing to the above string
>
> now I change the value of a_string
This is where English can lead us astray. "Change the value of a_string"
can mean two different things. An analogy may help make it clear.
Some people give their car a name. Suppose I call my car "Vera". I might
then "change the value of Vera" by replacing the engine with a more
powerful one, installing superchargers, giving the car a new paint job,
and replacing the tape desk with an MP3 player. The name "Vera" still
refers to the same physical car, but now it is quite different from how
it was before. This is equivalent to modifying a mutable value (like a
list) in-place.
On the other hand, I might instead trade in my car for a newer model, and
transfer the name with it. (I'm very unimaginative when it comes to names
-- if I had children, they would all be called Chris, and all my pets are
called Fluffy -- even the goldfish.) Whereas before Vera referred to a
blue Toyota, now it refers to a red Ford. This is equivalent to replacing
the string with a new string.
In Python terms, we call that "re-binding". "Binding" is another term for
assignment to a name. All of these things are binding operations:
import math
from random import random
x = 23
my_string = my_string.upper()
while these are mutation operations which change the value in-place:
my_list[0] = 42
my_list.append(None)
my_list.sort()
some_dict['key'] = 'hello world'
some_dict.clear()
Only mutable objects can be changed in place: e.g. lists, dicts, sets.
Immutable objects are fixed at creation, and cannot be changed: strings,
ints, floats, etc.
Some objects fall into a kind of grey area. Tuples are immutable, but
tuples can include mutable objects inside them, and they remain mutable
even inside the tuple.
t = (1, 2, []) # tuple is fixed
t[2] = [1] # fails, because you're trying to mutate the tuple
t[2].append(1) # succeeds, because you're mutating the list inside t
> a_string = "This string is different" I understand that now a_string is
> pointing to a different string than it was before, in a different
> location.
>
> my question is what happens to the original string?? Is it still in
> memory somewhere, nameless? """
> That was just the first question. What does immutable really mean if
> you can add items to a list? and concatenate strings? I don't
> understand enough to even ask a comprehensible question, I guess.
No, it's an excellent question!
When an object is *unbound*, does it float free in memory? In principle,
it could, at least for a little while. In practice, Python will recognise
that the string is not being used for anything, and reclaim the memory
for it. That's called "garbage collection". There are no promises made
about when that happens though. It could be instantly, or it could be in
an hour. It depends on the specific version and implementation of Python.
(CPython, the standard version, will almost always garbage collect
objects nearly instantly. Jython, which is Python on the Java Virtual
Machine, only garbage collects objects every few seconds. So it does
vary.)
In the case of lists, we've seen that a list is mutable, so you can
append items to lists. In the case of string concatenation, strings are
immutable, so code like this:
s = "Hello"
s += " World!"
does not append to the existing string, but creates a new string, "Hello
World!", and binds it to the name s. Then the two older strings, "Hello"
and " World!" are free to be garbage collected.
--
Steven
--Forwarded Message Attachment--
From: patil.jay2009 at gmail.com
To: python-list at python.org
Date: Tue, 3 Jun 2014 00:53:44 -0700
Subject: Re: Lock Windows Screen GUI using python
On Tuesday, 3 June 2014 12:39:38 UTC+5:30, Ian wrote:
> On Tue, Jun 3, 2014 at 12:40 AM, Jaydeep Patil <patil.jay2009 at gmail.com> wrote:
>
> > Hi Lan,
>
> >
>
> > Currently I am doing some automation in python excel. It read the data & plots number of graphs. It took more than 20 minutes. So while running my python program if user clicks on excel, error came.
>
> >
>
> > So just i want to lock GUI not workstation.
>
> >
>
> > I hope you understand this.
>
> >
>
> > Let me know if you have any idea about it.
>
>
>
> You can set the Application.Interactive property on Excel to block user input:
>
> http://msdn.microsoft.com/en-us/library/office/ff841248(v=office.15).aspx
>
>
>
> Example:
>
>
>
> excel_app = win32com.client.Dispatch("Excel.Application")
>
> excel_app.Interactive = False
>
> try:
>
> # Do some automation...
>
> finally:
>
> excel_app.Interactive = True
Hi Lan,
Thanks for sharing valuable info.
I have another query.
We can now block user inputs. But in my automation three is copy & paste work going on continuously in Excel before plotting the graphs.
During copy paste of excel data, if user by mistake doing some copy & paste operation outside excel(for e.g. doing copy paste in outlook mails, firefox browser etc), it may be cause for the another error.
How i can control this?
Thanks & Regards
Jaydeep Patil
--Forwarded Message Attachment--
From: breamoreboy at yahoo.co.uk
To: python-list at python.org
Date: Tue, 3 Jun 2014 08:59:38 +0100
Subject: Re: can someone explain the concept of "strings (or whatever) being immutable"
On 03/06/2014 07:28, Rustom Mody wrote:
> On Tuesday, June 3, 2014 10:36:37 AM UTC+5:30, Deb Wyatt wrote:
>> That was just the first question. What does immutable really mean
>> if you can add items to a list? and concatenate strings? I don't
>> understand enough to even ask a comprehensible question, I guess.
>
> It is with some pleasure that I see this question: Most people who are
> clueless have no clue that they are clueless -- also called the
> Dunning-Krüger effect.
>
> Be assured that this question is much harder and problematic than people believe.
>
> There are earlier discussions on this on this list, eg
>
> https://groups.google.com/forum/#!topic/comp.lang.python/023NLi4XXR4[126-150-false]
>
> [Sorry the archive thread is too broken to quote meaningfully]
>
This list is available in maybe six different places, so I had to
chuckle that you picked just about the worst possible to reference :)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
--Forwarded Message Attachment--
From: __peter__ at web.de
To: python-list at python.org
Date: Tue, 3 Jun 2014 10:01:26 +0200
Subject: Re: Strange Behavior
Steven D'Aprano wrote:
> On Mon, 02 Jun 2014 20:05:29 +0200, robertw89 wrote:
>
>> I invoked the wrong bug.py :/ , works fine now (this happens to me when
>> im a bit tired sometimes...).
>
> Clarity in naming is an excellent thing. If you have two files called
> "bug.py", that's two too many.
In the case of the OP the code is likely to be thrown away once the bug is
found. Putting all experiments into a single folder even with the overly
generic name "bug" would have been "good enough" to avoid the problem.
> Imagine having fifty files called "program.py". Which one is which? How
> do you know? Programs should be named by what they do (think of Word,
> which does word processing, or Photoshop, which does photo editing), or
> when that isn't practical, at least give them a unique and memorable name
> (Outlook, Excel). The same applies to files demonstrating bugs.
Outlook and Excel are only good names because these are popular
applications. If I were to name some private scripts in that style and not
use them for a few months -- I don't think I'd have a clue what excel.py is
meant to do.
I have a few find_dupes dedupe_xxx compare_xxx scripts lying around and no
idea which is which. So a reasonably clear name is not sufficient if there
are other scripts that perform similar tasks.
One approach that seems to be working so far is to combine several scripts
into one using argparse subparsers. This results in more frequent usage
which means I can get away with short meaningless names, and infrequent
actions are just one
$ xx -h
away.
--Forwarded Message Attachment--
From: breamoreboy at yahoo.co.uk
To: python-list at python.org
Date: Tue, 3 Jun 2014 09:03:12 +0100
Subject: Re: Python 3 is killing Python
On 03/06/2014 07:30, Rustom Mody wrote:
> On Tuesday, June 3, 2014 11:42:30 AM UTC+5:30, jmf wrote:
>
>> after thinking no
>
> Yes [Also called Oui]
>
I'm very puzzled over "thinking", what context was this in as I've
kill-filed our most illustrious resident unicode expert?
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
--Forwarded Message Attachment--
From: breamoreboy at yahoo.co.uk
To: python-list at python.org
Date: Tue, 3 Jun 2014 09:05:55 +0100
Subject: Re: Lock Windows Screen GUI using python
On 03/06/2014 08:53, Jaydeep Patil wrote:
Would you please use the mailing list
https://mail.python.org/mailman/listinfo/python-list or read and action
this https://wiki.python.org/moin/GoogleGroupsPython to prevent us
seeing double line spacing and single line paragraphs, thanks.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
--Forwarded Message Attachment--
From: pmiscml at gmail.com
CC: python-list at python.org
To: tjreedy at udel.edu
Date: Tue, 3 Jun 2014 11:31:14 +0300
Subject: Re: Benefits of asyncio
Hello,
On Mon, 02 Jun 2014 21:51:35 -0400
Terry Reedy <tjreedy at udel.edu> wrote:
> To all the great responders. If anyone thinks the async intro is
> inadequate and has a paragraph to contribute, open a tracker issue.
Not sure about intro (where's that?), but docs
(https://docs.python.org/3/library/asyncio.html) are pretty confusing
and bugs are reported, with no response:
http://bugs.python.org/issue21365
>
> --
> Terry Jan Reedy
--
Best regards,
Paul mailto:pmiscml at gmail.com
--Forwarded Message Attachment--
From: DMusiige at sennheisercommunications.com
To: python-list at python.org
Date: Tue, 3 Jun 2014 08:10:03 +0000
Subject: Automating windows media player on win7
Hi guys,
I have been fighting with automating wmplayer but with no success.
It looks to me that using the .OCX would be the best option. I found the code below on the net but I cannot get it to work.
I can see from device manager that a driver is started by I get no audio out.
What am I doing wrong guys?
# this program will play MP3, WMA, MID, WAV files via the WindowsMediaPlayer
from win32com.client import Dispatch
mp = Dispatch("WMPlayer.OCX")
tune = mp.newMedia("./plays.wav")
mp.currentPlaylist.appendItem(tune)
mp.controls.play()
raw_input("Press Enter to stop playing")
mp.controls.stop()
Br
Deo
--Forwarded Message Attachment--
From: rosuav at gmail.com
CC: python-list at python.org
Date: Tue, 3 Jun 2014 18:47:11 +1000
Subject: Re: Benefits of asyncio
On Tue, Jun 3, 2014 at 4:36 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> I have yet to see that in practice. The "typical" thread works as
> follows:
>
> while True:
> while request.incomplete():
> request.read() # block
> sql_stmt = request.process()
> db.act(sql_stmt) # block
> db.commit() # block
> response = request.ok_response()
> while response.incomplete():
> response.write() # block
>
> The places marked with the "block" comment are states with only one
> valid input stimulus.
> ...
> Yes, a "nest of callbacks" can get messy very quickly. That is why you
> need to be very explicit with your states. Your class needs to have a
> state field named "state" with clearly named state values.
Simple/naive way to translate this into a callback system is like this:
def request_read_callback(request, data):
request.read(data) # however that part works
if not request.incomplete():
request.process()
def write(request, data):
request.write_buffer += data
request.attempt_write() # sets up callbacks for async writing
def request.process(self): # I know this isn't valid syntax
db.act(whatever) # may block but shouldn't for long
db.commit() # ditto
write(self, response) # won't block
This works as long as your database is reasonably fast and close
(common case for a lot of web servers: DB runs on same computer as web
and application and etc servers). It's nice and simple, lets you use a
single database connection (although you should probably wrap it in a
try/finally to ensure that you roll back on any exception), and won't
materially damage throughput as long as you don't run into problems.
For a database driven web site, most of the I/O time will be waiting
for clients, not waiting for your database.
Getting rid of those blocking database calls means having multiple
concurrent transactions on the database. Whether you go async or
threaded, this is going to happen. Unless your database lets you run
multiple simultaneous transactions on a single connection (I don't
think the Python DB API allows that, and I can't think of any DB
backends that support it, off hand), that means that every single
concurrency point needs its own database connection. With threads, you
could have a pool of (say) a dozen or so, one per thread, with each
one working synchronously; with asyncio, you'd have to have one for
every single incoming client request, or else faff around with
semaphores and resource pools and such manually. The throughput you
gain by making those asynchronous with callbacks is quite probably
destroyed by the throughput you lose in having too many simultaneous
connections to the database. I can't prove that, obviously, but I do
know that PostgreSQL requires up-front RAM allocation based on the
max_connections setting, and trying to support 5000 connections
started to get kinda stupid.
So how do you deal with the possibility that the database will block?
"Pure" threading (one thread listens for clients, spin off a thread
for each client, end the thread when the client disconnects) copes
poorly; async I/O copes poorly. The thread pool copes well (you know
exactly how many connections you'll need - one per thread in the
pool), but doesn't necessarily solve the problem (you can get all
threads waiting on the database and none handling other requests).
Frankly, I think the only solution is to beef up the database so it
won't block for too long (and, duh, to solve any stupid locking
problems, because they WILL kill you :) ).
> If threads simplify an asynchronous application, that is generally done
> by oversimplifying and reducing functionality.
Which means that I disagree with this statement. In my opinion, both
simple models (pure threading and asyncio) can express the same
functionality; the hybrid thread-pool model may simplify things a bit
in the interests of resource usage; but threading does let you think
about code the same way for one client as for fifty, without any
change of functionality. Compare:
# Console I/O:
def print_menu():
print("1: Spam")
print("2: Ham")
print("3: Quit")
def spam():
print("Spam, spam, spam, spam,")
while input("Continue? ")!="NO!":
print("spam, spam, spam...")
def mainloop():
print("Welcome!")
while True:
print_menu()
x = int(input("What would you like? "))
if x == 1: spam()
elif x == 2: ham()
elif x == 3: break
else: print("I don't know numbers like %d."%x)
print("Goodbye!")
I could translate this into a pure-threading system very easily:
# Socket I/O:
import consoleio
class TerminateRequest(Exception): pass
tls = threading.local()
def print(s):
tls.socket.write(s+"\r\n") # Don't forget, most of the internet uses \r\n!
def input(prompt):
tls.socket.write(s)
while '\n' not in tls.readbuffer:
tls.readbuffer += tls.socket.read()
if not tls.socket.connected(): raise TerminateRequest
ret, _, tls.readbuffer = tls.readbuffer.partition("\n")
return ret.strip("\r")
consoleio.print = print
consoleio.input = input
def thread(sock):
tls.socket = sock
tls.readbuffer = ""
try: consoleio.mainloop()
except TerminateRequest: pass
mainsock = socket.socket() # bind to port, whatever
mainsock.listen(5)
while True:
threading.Thread(target=thread,args=(mainsock.accept(),))
The only changes I made to the application main loop are to change
(via injection) print and input to use the socket. Everything else -
the (bad) logic inside spam(), helper functions, etc, etc - works
exactly the same way. So if you're coming from a single-thread
single-client starting point, it's definitely way simpler to follow a
model like this. (And I have written enough programs along this sort
of line to be able to write the above without more than some quick
checks to see how thread-local storage is done in Python. It's a
really simple model. On the flip side, that does also mean the code
above is completely untested, not to mention stubby in places, so it
probably won't actually run.)
How do you translate that to asynchronous I/O? Normally, with piles
and piles of callbacks. I haven't looked into tulip yet, but my
understanding is that it may be possible to tulipify the above code in
the same way that I socketified it - you'd simply have a "yield from"
inside input(), which would let the system go and deal with other
requests; but otherwise, you would need to completely rewrite the main
code. The exact same functionality would look a lot messier; and you
have the exact same problems to deal with either way. Your connection
state has to cope with both input and output buffers (since you have
to make sure you don't block inside print() either), and while you can
in most applications assume that there won't be a huge amount of
output buffering (and can therefore let mainloop() pretend that it all
got written instantly, while the actual writing happens in the
background), sometimes you have to be explicit about that part of
state too. So the consoleio module above would need a lot of separate
states: every single print() or input() call becomes its own state, in
which the connection might stall. Do you really want to do that with
callbacks? Because it would *definitely* be less clear.
ChrisA
--Forwarded Message Attachment--
From: rosuav at gmail.com
CC: python-list at python.org
Date: Tue, 3 Jun 2014 18:57:35 +1000
Subject: Re: Automating windows media player on win7
On Tue, Jun 3, 2014 at 6:10 PM, Deogratius Musiige
<DMusiige at sennheisercommunications.com> wrote:
> Hi guys,
>
>
>
> I have been fighting with automating wmplayer but with no success.
>
> It looks to me that using the .OCX would be the best option. I found the
> code below on the net but I cannot get it to work.
>
> I can see from device manager that a driver is started by I get no audio
> out.
>
> What am I doing wrong guys?
>
>
>
> # this program will play MP3, WMA, MID, WAV files via the WindowsMediaPlayer
>
> from win32com.client import Dispatch
>
> mp = Dispatch("WMPlayer.OCX")
>
> tune = mp.newMedia("./plays.wav")
>
> mp.currentPlaylist.appendItem(tune)
>
> mp.controls.play()
>
> raw_input("Press Enter to stop playing")
>
> mp.controls.stop()
>
>
>
> Br
>
> Deo
First suggestion: post plain text to this list, not HTML. You don't
need it to look like the above. :)
Secondly: Is there a particular reason that you need to be automating
Windows Media Player specifically? I have a similar project which
works by sending keystrokes, which means it works with anything that
reacts to keys; mainly, I use it with VLC. It can invoke a movie or
audio file, can terminate the process, and can send a variety of
commands via keys. It's designed to be used on a (trusted) LAN.
Code is here:
https://github.com/Rosuav/Yosemite
Once something's invoked by the Yosemite project, it simply runs as
normal inside VLC. Easy to debug audio problems, because they're
managed the exact same way. Granted, this does assume that it's given
full control of the screen (it's designed to manage full-screen video
playback; in fact, my siblings are right now watching Toy Story 3 in
the other room, using an old laptop driving a TV via S-Video, all
managed via the above project), so it may not be ideal for background
music on a computer you use for other things; but feel free to borrow
ideas and/or code from there. (And for what it's worth, I use this as
one of my sources of BGM when I'm coding - just let it invoke the
file, then manually flip focus back to what I'm doing.)
ChrisA
--Forwarded Message Attachment--
From: rosuav at gmail.com
CC: python-list at python.org
Date: Tue, 3 Jun 2014 19:11:02 +1000
Subject: Re: Lock Windows Screen GUI using python
On Tue, Jun 3, 2014 at 5:53 PM, Jaydeep Patil <patil.jay2009 at gmail.com> wrote:
>
> During copy paste of excel data, if user by mistake doing some copy & paste operation outside excel(for e.g. doing copy paste in outlook mails, firefox browser etc), it may be cause for the another error.
>
> How i can control this?
Suggestion: Don't. If you really need this level of control of the
workstation, you are going about things wrongly. This is a recipe for
fragility and horrific usability problems. There are two simple
solutions:
1) Make it really obvious that you're controlling the computer, by
putting something big across the screen - a splash screen, of sorts -
which is set to Always On Top and gives a message. And then just trust
that the user won't do anything, because you've done everything
reasonable. No further control needed.
2) Automate your code by moving stuff around on the disk, *not* by
actually working through Excel. Twenty minutes of Excel automation
should probably become a proper application that reads in some data
and generates some graphs. And it'd probably be faster, too (even if
Excel's performance is stellar, which I very much doubt, it's always
slower to work through a GUI than to do the work directly). Figure out
what you're really trying to do, and do that directly.
Also, please follow Mark's advice.
ChrisA
--Forwarded Message Attachment--
From: marko at pacujo.net
To: python-list at python.org
Date: Tue, 3 Jun 2014 12:10:12 +0300
Subject: Re: Benefits of asyncio
Chris Angelico <rosuav at gmail.com>:
> def request.process(self): # I know this isn't valid syntax
> db.act(whatever) # may block but shouldn't for long
> db.commit() # ditto
> write(self, response) # won't block
>
> This works as long as your database is reasonably fast and close
I find that assumption unacceptable.
The DB APIs desperately need asynchronous variants. As it stands, you
are forced to delegate your DB access to threads/processes.
> So how do you deal with the possibility that the database will block?
You separate the request and response parts of the DB methods. That's
how it is implemented internally anyway.
Say no to blocking APIs.
> but otherwise, you would need to completely rewrite the main code.
That's a good reason to avoid threads. Once you realize you would have
been better off with an async approach, you'll have to start over. You
can easily turn a nonblocking solution into a blocking one but not the
other way around.
Marko
--Forwarded Message Attachment--
From: rosuav at gmail.com
CC: python-list at python.org
Date: Tue, 3 Jun 2014 19:30:14 +1000
Subject: Re: Benefits of asyncio
On Tue, Jun 3, 2014 at 7:10 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>
>> def request.process(self): # I know this isn't valid syntax
>> db.act(whatever) # may block but shouldn't for long
>> db.commit() # ditto
>> write(self, response) # won't block
>>
>> This works as long as your database is reasonably fast and close
>
> I find that assumption unacceptable.
It is a dangerous assumption.
> The DB APIs desperately need asynchronous variants. As it stands, you
> are forced to delegate your DB access to threads/processes.
>
>> So how do you deal with the possibility that the database will block?
>
> You separate the request and response parts of the DB methods. That's
> how it is implemented internally anyway.
>
> Say no to blocking APIs.
Okay, but how do you handle two simultaneous requests going through
the processing that you see above? You *MUST* separate them onto two
transactions, otherwise one will commit half of the other's work. (Or
are you forgetting Databasing 101 - a transaction should be a logical
unit of work?) And since you can't, with most databases, have two
transactions on one connection, that means you need a separate
connection for each request. Given that the advantages of asyncio
include the ability to scale to arbitrary numbers of connections, it's
not really a good idea to then say "oh but you need that many
concurrent database connections". Most systems can probably handle a
few thousand threads without a problem, but a few million is going to
cause major issues; but most databases start getting inefficient at a
few thousand concurrent sessions.
>> but otherwise, you would need to completely rewrite the main code.
>
> That's a good reason to avoid threads. Once you realize you would have
> been better off with an async approach, you'll have to start over. You
> can easily turn a nonblocking solution into a blocking one but not the
> other way around.
Alright. I'm throwing down the gauntlet. Write me a purely nonblocking
web site concept that can handle a million concurrent connections,
where each one requires one query against the database, and one in a
hundred of them require five queries which happen atomically. I can do
it with a thread pool and blocking database queries, and by matching
the thread pool size and the database concurrent connection limit, I
can manage memory usage fairly easily; how do you do it efficiently
with pure async I/O?
ChrisA
--Forwarded Message Attachment--
From: rosuav at gmail.com
CC: python-list at python.org
Date: Tue, 3 Jun 2014 19:46:27 +1000
Subject: Re: Automating windows media player on win7
On Tue, Jun 3, 2014 at 7:42 PM, Deogratius Musiige
<DMusiige at sennheisercommunications.com> wrote:
> Hi Chris,
>
> I want to have wmplayer as part of my automitized test for a headset via the
> USB HID.
>
> I want to be able to execute some of the following operations in my python
> script:
>
> 1. Play
>
> 2. Get playing track
>
> 3. Next
>
> 4. Get active device
>
> 5. …
>
> I am not sure if you are able to do this with your project
Play, definitely. Next, not specifically, but by sending the letter
'n' you can achieve that. Active device? Not sure what you mean there.
The one part that doesn't exist is "Get playing track". But you could
manage this the other way around, by not invoking a playlist at all.
If you run "vlc --play-and-exit some_file.wav", then when that process
terminates, the track has finished. Kill the process or send Ctrl-Q to
skip to the next track. Keep track (pun intended) of what file you've
most recently invoked.
I'm not sure how this ties in with your headset testing, though.
By the look of things, the Yosemite project isn't a "here it is, just
deploy it" solution, but you may find that there's some useful code
you can borrow.
ChrisA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20140603/4f7868c7/attachment.html>
More information about the Python-list
mailing list