Re: [Tutor] Tutor Digest, Vol 126, Issue 64

[Najam Qasim]

What is preferable method to debug and execute python code in Mac? I do not 
like the cmd/terminal execution. Thank you.

> On Aug 26, 2014, at 6:00 AM, tutor-requ...@python.org wrote:
> 
> Send Tutor mailing list submissions to
>tutor@python.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://mail.python.org/mailman/listinfo/tutor
> or, via email, send a message with subject or body 'help' to
>tutor-requ...@python.org
> 
> You can reach the person managing the list at
>tutor-ow...@python.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tutor digest..."
> 
> 
> Today's Topics:
> 
>   1. time vs. timeit (diliup gabadamudalige)
>   2. Re: time vs. timeit (Chris ?Kwpolska? Warrick)
> 
> 
> --
> 
> Message: 1
> Date: Tue, 26 Aug 2014 09:56:55 +0530
> From: diliup gabadamudalige 
> To: "tutor@python.org" 
> Subject: [Tutor] time vs. timeit
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi all,
> 
> 1. why do some say that the time module is more accurate than the timeit
> module?
> s = time.time()
> or
> s = timeit.timeit()
> 
> 2. Why is it that both modules never return the same answer on each run?
> 
> Thank you for your response.
> 
> -- 
> Diliup Gabadamudalige
> 
> http://www.diliupg.com
> http://soft.diliupg.com/
> 
> **
> This e-mail is confidential. It may also be legally privileged. If you are
> not the intended recipient or have received it in error, please delete it
> and all copies from your system and notify the sender immediately by return
> e-mail. Any unauthorized reading, reproducing, printing or further
> dissemination of this e-mail or its contents is strictly prohibited and may
> be unlawful. Internet communications cannot be guaranteed to be timely,
> secure, error or virus-free. The sender does not accept liability for any
> errors or omissions.
> **
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> 
> 
> --
> 
> Message: 2
> Date: Tue, 26 Aug 2014 10:34:15 +0200
> From: Chris ?Kwpolska? Warrick 
> To: diliup gabadamudalige 
> Cc: "tutor@python.org" 
> Subject: Re: [Tutor] time vs. timeit
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8
> 
> On Tue, Aug 26, 2014 at 6:26 AM, diliup gabadamudalige
>  wrote:
>> Hi all,
>> 
>> 1. why do some say that the time module is more accurate than the timeit
>> module?
>> s = time.time()
>> or
>> s = timeit.timeit()
>> 
>> 2. Why is it that both modules never return the same answer on each run?
> 
> The two functions have completely different uses, and do completely
> different things.
> 
 help(time.time)
> Help on built-in function time in module time:
> 
> time(...)
>time() -> floating point number
> 
>Return the current time in seconds since the Epoch.
>Fractions of a second may be present if the system clock provides them.
> 
> 
> In other words, return this: http://en.wikipedia.org/wiki/Unix_time
> 
> 
 help(timeit)
> NAME
>timeit - Tool for measuring execution time of small code snippets.
> 
> [?]
> |  timeit(self, number=100)
> |  Time 'number' executions of the main statement.
> |
> |  To be precise, this executes the setup statement once, and
> |  then returns the time it takes to execute the main statement
> |  a number of times, as a float measured in seconds.  The
> |  argument is the number of times through the loop, defaulting
> |  to one million.  The main statement, the setup statement and
> |  the timer function to be used are passed to the constructor.
> 
> -- 
> Chris ?Kwpolska? Warrick 
> PGP: 5EAAEA16
> stop html mail | always bottom-post | only UTF-8 makes sense
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> Tutor maillist  -  Tutor@python.org
> https://mail.python.org/mailman/listinfo/tutor
> 
> 
> --
> 
> End of Tutor Digest, Vol 126, Issue 64
> **
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Tutor Digest, Vol 126, Issue 64

[Alan Gauld]

On 27/08/14 02:41, Najam Qasim wrote:

What is preferable method to debug and execute python code in Mac?
I do not like the cmd/terminal execution.


That is a very personal choice. You don't tell us what you don't
like about the terminal or what features you consider important
in your choice of tools. You also don't tell us if you have any previous 
programming experience and what tools you used there.


On the basis that you want a non CLI tool I can only offer some 
suggestions in increasing order of complexity:


Emacs Python mode - If you use emacs for other programming languages 
then this will be familiar to you. Integrates Python development with 
the other emacs functions. Really only a sensible option if you

already use emacs.

IDLE - comes with Python, offers a very basic GUI text editor
and debugger in addition to a Python >>> prompt.

IPython - offers a more sophisticated version of the >>> prompt 
including notebook facilities for retrieving previous sessions

(and much more)

XCode - The standard developers tool on a Mac. Integrates
with GUI tools for building Cocoa applications

Eclipse - The industry standard IDE supports editing, execution
and debugging of code plus integration with version control.
Also has plugins for a host of other functions such as design
and testing.

Netbeans - Another popular tool in industry, similar to Xcode
and Eclipse in complexity and power.

You will need to look at the various web sites and try them
out to decide which one suits you best.

There are some commercial tools too but I've stuck with
free for now.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] debug and execute python code in Mac

[Najam Qasim]

> What is preferable method to debug and execute python code in Mac?
> I do not like the cmd/terminal execution. Thanks !
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] simple unicode question

[Albert-Jan Roskam]

- Original Message -
> From: Steven D'Aprano 
> To: tutor@python.org
> Cc: 
> Sent: Tuesday, August 26, 2014 2:08 PM
> Subject: Re: [Tutor] simple unicode question
> 
> On Tue, Aug 26, 2014 at 03:58:17AM -0700, Albert-Jan Roskam wrote:
> 
>>  Interesting, you follow a "look before you leap" approach here, 
>>  whereas `they` always say it is easier to ”ask forgiveness than 
>>  permission” in python. 
> 
> Anyone who says it is *ALWAYS* easier is lying or confused :-)
> 
> It is *often*, perhaps even *usually* better to use a AFTP approach, but 
> not necessarily easier. Sometimes it is more work, but safer, or better. 
> For instance, it is wrong (i.e. buggy) to use a LBYL approach here:
> 
> 
> if os.path.exists(filename):
>     f = open(filename)
>     process(f.read())
> 
> Why is it wrong? Just because the file exists, doesn't mean you can open 
> it for reading. And just because it exists at the instant you do the 
> test, doesn't mean it will still exist a millisecond later when Python 
> tries to open the file. Perhaps another process or user has deleted it 
> in the fraction of a second between the two lines.
> 
> But sometimes AFTP is the wrong approach too. Consider a case where you 
> have to do a number of things, and only if *all* of them can be done do 
> you want to proceed. For example, baking a cake:
> 
> - pour the cake mix and milk into a bowl;
> - mix;
> - pour into a pan;
> - put into the oven;
> - cook for 30 minutes.
> 
> If you don't have an oven, there's no point mixing the cake mix and milk 
> 
> together, you'll just waste it. So you need to LBYL, make sure you have 
> the cake mix AND the milk AND a bowl AND a pan AND an oven before you 
> even start. If even one thing is missing, you don't proceed.
> 
> 
>>  But LBYL is much faster, which is relevant 
>>  because the function could be called millions and millions of times. 
> 
> Not necessarily! It depends on how often you have failures. Let's time 
> two examples: looking up something in a dict, where the key is never 
> missing. Copy and paste this code:
> 
> 
> from timeit import Timer
> setup = 'd = {"a": 1, "b": 2}'
> 
> t1 = Timer("""
> if "a" in d: x = d["a"]
> if "b" in d: x = d["b"]
> """, setup)  # LBYL version
> 
> t2 = Timer("""
> try:
>     x = d["a"]
> except KeyError:
>     pass
> try:
>     x = d["b"]
> except KeyError:
>     pass
> """, setup)  # AFTP version
> 
> 
> 
> And here are the results when I run it:
> 
> py> min(t1.repeat())
> 0.3348677200265229
> py> min(t2.repeat())
> 0.23994551179930568
> 
> So in this case, the LBYL example is significantly slower.
> 
> Now let's try it again, only this time the key will be missing half the 
> time:
> 
> 
> t3 = Timer("""
> if "a" in d: x = d["a"]
> if "c" in d: x = d["c"]
> """, setup)  # LBYL version
> 
> t4 = Timer("""
> try:
>     x = d["a"]
> except KeyError:
>     pass
> try:
>     x = d["c"]
> except KeyError:
>     pass
> """, setup)  # AFTP version
> 
> 
> And the results:
> 
> py> min(t3.repeat())
> 0.24967589927837253
> py> min(t4.repeat())
> 0.8413973557762802
> 
> Now the LBYL version is faster.
> 
> 
>>  If have noticed before that try-except is quite an expensive structure 
>>  to initialize (for instance membership testing with ´in´ is cheaper 
>>  than try-except-KeyError when getting items from a dictionary)
> 
> Funny you should say that :-)
> 
> Actually, try...except is almost free to *initialise*. Setting up the 
> try block is very, very cheap, it takes hardly any time:
> 
> py> timeit.timeit("len([])")  # No try
> 0.19250816199928522
> py> timeit.timeit("""
> ... try:
> ...     len([])
> ... except: pass""")  # With try
> 0.21191818173974752
> 
> That's not a lot of difference: less than 0.02μs.
> 
> But, *catching* the exception is quite expensive. So the overhead of 
> putting code inside a try block is negligible, virtually free, but the 
> cost of actually catching the exception is quite heavy. So if there are 
> lots and lots of exceptions, LBYL will probably be faster. But if they 
> are rare, then the cost of looking before you leap isn't worth it, you 
> should just leap. The exact crossover point will depend on how costly it 
> is to look first versus the cost of the exception, but as a very rough 
> rule of thumb, I go by:
> 
> if *fewer* than 1 in 10 operations will raise an exception, then use 
> try...except; but if *more* than 1 in 10 operations will raise an 
> exception, and it is safe to do so, then LBYL may be appropriate.

 
Thanks a lot, Steven! This kind of stuff should be in a book. I haven't seen 
any Python book where this kind of "it depends on your data" kind of 
considerations are discussed. Do you know of any real life examples where the 
code is written in such a way that it could switch from AFTP to LBYL and vice 
versa? It would probably look ugly, and it would have overhead. But if you 
would switch strategy after processing, say, 1000 records, then why not do it 
if it saves time?
 
regards,
ALbert-

[Tutor] Python Programming

[Jake]

To whom it may concern,
My name is Jake and I have recently started the GCSE computing course with 
school. As summer holidays homework we have been asked to make a game. So I 
have made a Capital Cities Quiz. When I run my program this part of my coding 
does not seem to work:
answera = input()
if answera == ["Oslo" or "oslo"]:
print ("CORRECT!!")
score = score + 1
else:
print("INCORRECT!!")

When I type Oslo or oslo as my answer it keeps telling me that it is incorrect. 
I was wondering if it would be possible for you to tell me what I have done 
wrong and hopefully point me in the right direction.
I look forward to hearing from you,

Jake
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] debug and execute python code in Mac

[Patrick Thunstrom]

On Wed, Aug 27, 2014 at 7:14 AM, Najam Qasim  wrote:
> What is preferable method to debug and execute python code in Mac?
>
> I do not like the cmd/terminal execution. Thanks !
>
>
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>

I don't know many ways to debug code that don't involve the terminal
in some fashion. Even with a good IDE you're going to have a terminal
built in for output.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] datetime substraction

[Anirudh Tamsekar]

Hi Alan/Danny/Steve,

Thank you very much, I'm able to get the script working.


-Regards,
Anirudh Tamsekar


On Tue, Aug 26, 2014 at 10:25 PM, Alan Gauld 
wrote:

> On 26/08/14 10:10, Anirudh Tamsekar wrote:
>
>  *Traceback (most recent call last):*
>> *  File "./rsyslog_check.py", line 22, in *
>> *difft=cur_time-mt*
>> *TypeError: unsupported operand type(s) for -: 'str' and 'str'*
>>
>>
>> Request your help. Also point any good documentation where I can get
>> quick reference.
>>
>> ct = time.ctime(os.path.getctime(tfile))
>> mt = time.ctime(os.path.getctime(tfile))
>>
>
> You are converting the times to strings before you subtract them. Don't do
> that, subtract the times as returned by os.path.getctime() and time.time().
>
>  cur_time = time.ctime()
>> difft=int(cur_time-mt)
>>
>
> You need to subtract the numeric versions of the times not the strings.
>
> The best quick references are the dir() and help() builtin functions.
> For more detail read the documentation for time, os.path (and maybe
> datetime) modules.
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.flickr.com/photos/alangauldphotos
>
>
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python Programming

[Alan Gauld]

On 27/08/14 14:40, Jake wrote:

To whom it may concern,
My name is Jake and I have recently started the GCSE computing course with 
school.



answera = input()
if answera == ["Oslo" or "oslo"]:


This doesn't do what you think it does.

["Oslo" or "oslo"]  is a list

"Oslo" or "oslo"   is the content of the list and
is a boolean expression which evaluates to True.
(Each non-empty string is considered True by Python)

So your 'if' line looks to Python like:

if answera == [True]:

But answera is a string so it will never equal a list
with a single boolean value so you go to the else
clause.

A better way to do what you want is to convert the input
to lowercase using the string lower() method and compare
that to the string you want, like so:

if answera.lower() == "oslo":

If you need to check multiple possible answers you can use
a list of strings and the 'in' operator like this:

if answera.lower() in ['amsterdam', 'london', 'oslo']:

HTH
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] simple unicode question

[Alan Gauld]

On 27/08/14 15:57, Albert-Jan Roskam wrote:


if *fewer* than 1 in 10 operations will raise an exception, then use
try...except; but if *more* than 1 in 10 operations will raise an
exception, and it is safe to do so, then LBYL may be appropriate.



Thanks a lot, Steven! This kind of stuff should be in a book.


It is in lots of books but they aren't Python books; they are generic 
software engineering books. Because this is not really a language 
specific type design issue, its general software design.


> Do you know of any real life examples where the code is written
> in such a way that it could switch from AFTP to LBYL

It would be very unlikely since it would almost always be a case of 
premature optimisation. You would need to be inside a very tight loop to 
make that kind of optimisation worthwhile in real world scenarios.

(And the cost of evaluating it would probably outweigh any gains.)

Much more important is to make the code correct and maintainable than to 
worry about slight performance issues before they are a proven issue.
Building those kind of self modifying control flows makes code much more 
error prone and difficult to modify.


The vast majority of performance issues in software are to do with 
blockages in IO processing(network, disk access, human input, etc)
or database processing (big data or complex searches) or in traversing 
complex/deep data structures. Very few real-world performance issues

are related to simple code execution issues.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] Interacting with stderr

[Crush]

Hello, it has been a while and I hope I am sending to the correct email. 

How would I go about running a conditional statement against the contents of 
stderr. For instance, if "blah blah blah" is in stderr do X, else do Y. 

CODE: SELECT ALL
 
#!/usr/bin/env python
import subprocess
from subprocess import PIPE
i = 0
while i < 10:
p = subprocess.call("avconv -v verbose -re -analyzeduration 1000 -i 
http://localhost:6498/ms2/1382097438004/0MediaPlayer+0+/octoshape+hVV+octolive.americaone.com+V+aone+V+live+V+ONECONNXT_DEMO1_HD_flv/aoneliveONECONNXTDEMO1HDflv
  -c:v rawvideo -c:a pcm_s16le -ar 48000 -f nut - | ./bmdplay -m 12 -f pipe:0", 
shell=True)
i += 1
if i == 10:
print "Gave up"


The above code works and I get no tracebacks, however I need to add to it and 
check the contents of stderr. Avconv by default sends the audio and video to 
stdout, which then sends the signal to a capture card in the machine. Avconv is 
sending the status of the broadcasted signal i.e. frames, time, fps, etc. to 
stderr, which is displayed in the terminal. 

Bo ___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Interacting with stderr

[Cameron Simpson]

On 27Aug2014 18:45, Crush  wrote:

Hello, it has been a while and I hope I am sending to the correct email.

How would I go about running a conditional statement against the contents of
stderr. For instance, if "blah blah blah" is in stderr do X, else do Y.


   #!/usr/bin/env python
   import subprocess
   from subprocess import PIPE
   i = 0
   while i < 10:
   p = subprocess.call("avconv -v verbose -re -analyzeduration 1000 -i http://localhost:6498/ms2/1382097438004/0MediaPlayer+0+/octoshape+hVV+octolive.americaone.com+V+aone+V+live+V+ONECONNXT_DEMO1_HD_flv/aoneliveONECONNXTDEMO1HDflv -c:v rawvideo -c:a pcm_s16le -ar 48000 -f nut - | ./bmdplay -m 12 -f pipe:0", 

shell=True)

   i += 1
   if i == 10:
   print "Gave up"

The above code works and I get no tracebacks, however I need to add to it and
check the contents of stderr. Avconv by default sends the audio and video to
stdout, which then sends the signal to a capture card in the machine. Avconv
is sending the status of the broadcasted signal i.e. frames, time, fps, etc.
to stderr, which is displayed in the terminal.


Send stderr to a file, using a parameter like:

  stderr=open('stderr.out', 'w')

in your call() call. Then open 'stderr.out' and look for the relevant 
information.


Obviously in a "real" program you'd take care to make that a temporary file 
with a unique name using the functions from the "tempfile" module, etc. But 
make it work first.


Cheers,
Cameron Simpson 

The Few. The Proud. The Politically Incorrect.  - Steve Masticola
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] debug and execute python code in Mac

[Alan Gauld]

On 27/08/14 13:47, Patrick Thunstrom wrote:


I do not like the cmd/terminal execution. Thanks !


I don't know many ways to debug code that don't involve the terminal
in some fashion. Even with a good IDE you're going to have a terminal
built in for output.


Not necessarily. A text display widget within a GUI is very different 
from a text based terminal. Many graphical debuggers display data 
structures in a hierarchical model where you can expand/close the 
various levels etc.


But I think the OP is specifically wanting to avoid command prompts. The 
question is: Does he mean all prompts (including

Python's) or just the OS prompt? If its all prompts then it gets
much harder to find an IDE that will suit.


--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Interacting with stderr

[Alan Gauld]

On 27/08/14 23:45, Crush wrote:

Hello, it has been a while and I hope I am sending to the correct email.

How would I go about running a conditional statement against the
contents of stderr. For instance, if "blah blah blah" is in stderr do X,
else do Y.


You can access stderr just like you access stdout.
The recommended way is via communicate:

---
Popen.communicate(input=None, timeout=None)

Interact with process: Send data to stdin. Read data from stdout and 
stderr, until end-of-file is reached. Wait for process to terminate. The 
optional input argument should be data to be sent to the child process, 
or None, if no data should be sent to the child. The type of input must 
be bytes or, if universal_newlines was True, a string.


communicate() returns a tuple (stdoutdata, stderrdata).

Note that if you want to send data to the process’s stdin, you need to 
create the Popen object with stdin=PIPE. Similarly, to get anything 
other than None in the result tuple, you need to give stdout=PIPE and/or 
stderr=PIPE too.



HTH
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] Interacting with stderr

[Crush]

ches) or in traversing 
> complex/deep data structures. Very few real-world performance issues
> are related to simple code execution issues.
> 
> -- 
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.flickr.com/photos/alangauldphotos
> 
> 
> 
> --
> 
> Message: 3
> Date: Wed, 27 Aug 2014 18:45:41 -0400
> From: Crush 
> To: "tutor@python.org" 
> Subject: [Tutor] Interacting with stderr
> Message-ID: <77745ca4-8f7d-410c-800d-f0a3c711d...@gmail.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hello, it has been a while and I hope I am sending to the correct email. 
> 
> How would I go about running a conditional statement against the contents of 
> stderr. For instance, if "blah blah blah" is in stderr do X, else do Y. 
> 
> CODE: SELECT ALL
> 
> #!/usr/bin/env python
> import subprocess
> from subprocess import PIPE
> i = 0
> while i < 10:
>p = subprocess.call("avconv -v verbose -re -analyzeduration 1000 -i 
> http://localhost:6498/ms2/1382097438004/0MediaPlayer+0+/octoshape+hVV+octolive.americaone.com+V+aone+V+live+V+ONECONNXT_DEMO1_HD_flv/aoneliveONECONNXTDEMO1HDflv
>   -c:v rawvideo -c:a pcm_s16le -ar 48000 -f nut - | ./bmdplay -m 12 -f 
> pipe:0", shell=True)
>i += 1
>if i == 10:
>print "Gave up"
> 
> 
> The above code works and I get no tracebacks, however I need to add to it and 
> check the contents of stderr. Avconv by default sends the audio and video to 
> stdout, which then sends the signal to a capture card in the machine. Avconv 
> is sending the status of the broadcasted signal i.e. frames, time, fps, etc. 
> to stderr, which is displayed in the terminal. 
> 
> Bo 
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://mail.python.org/pipermail/tutor/attachments/20140827/05ab01b4/attachment-0001.html>
> 
> --
> 
> Message: 4
> Date: Thu, 28 Aug 2014 08:55:39 +1000
> From: Cameron Simpson 
> To: "tutor@python.org" 
> Subject: Re: [Tutor] Interacting with stderr
> Message-ID: <20140827225539.ga55...@cskk.homeip.net>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> 
>> On 27Aug2014 18:45, Crush  wrote:
>> Hello, it has been a while and I hope I am sending to the correct email.
>> 
>> How would I go about running a conditional statement against the contents of
>> stderr. For instance, if "blah blah blah" is in stderr do X, else do Y.
>> 
>> 
>>   #!/usr/bin/env python
>>   import subprocess
>>   from subprocess import PIPE
>>   i = 0
>>   while i < 10:
>>   p = subprocess.call("avconv -v verbose -re -analyzeduration 1000 -i 
>> http://localhost:6498/ms2/1382097438004/0MediaPlayer+0+/octoshape+hVV+octolive.americaone.com+V+aone+V+live+V+ONECONNXT_DEMO1_HD_flv/aoneliveONECONNXTDEMO1HDflv
>>  -c:v rawvideo -c:a pcm_s16le -ar 48000 -f nut - | ./bmdplay -m 12 -f 
>> pipe:0",
> shell=True)
>>   i += 1
>>   if i == 10:
>>   print "Gave up"
>> 
>> The above code works and I get no tracebacks, however I need to add to it and
>> check the contents of stderr. Avconv by default sends the audio and video to
>> stdout, which then sends the signal to a capture card in the machine. Avconv
>> is sending the status of the broadcasted signal i.e. frames, time, fps, etc.
>> to stderr, which is displayed in the terminal.
> 
> Send stderr to a file, using a parameter like:
> 
>   stderr=open('stderr.out', 'w')
> 
> in your call() call. Then open 'stderr.out' and look for the relevant 
> information.
> 
> Obviously in a "real" program you'd take care to make that a temporary file 
> with a unique name using the functions from the "tempfile" module, etc. But 
> make it work first.
> 
> Cheers,
> Cameron Simpson 
> 
> The Few. The Proud. The Politically Incorrect.  - Steve Masticola
> 
> 
> --
> 
> Message: 5
> Date: Thu, 28 Aug 2014 00:31:08 +0100
> From: Alan Gauld 
> To: tutor@python.org
> Subject: Re: [Tutor] debug and execute python code in Mac
> Message-ID: 
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> On 27/08/14 13:47, Patrick Thunstrom wrote:
> 
>>> I do not like the cmd/terminal execution. Thanks !
>> 
>> I don't know many ways to debug code that don't involve the terminal
>> in some fashion. Even with a good IDE you're going t

Re: [Tutor] Python Programming

[D . V . N . Sarma డి . వి . ఎన్ . శర్మ]

change the line

if answera == ["Oslo" or "oslo"]:

to

if answera == "Oslo" or  answera == "oslo":

and see if it works.

regards,
Sarma.


On Thu, Aug 28, 2014 at 12:27 AM, Alan Gauld 
wrote:

> On 27/08/14 14:40, Jake wrote:
>
>> To whom it may concern,
>> My name is Jake and I have recently started the GCSE computing course
>> with school.
>>
>
>  answera = input()
>> if answera == ["Oslo" or "oslo"]:
>>
>
> This doesn't do what you think it does.
>
> ["Oslo" or "oslo"]  is a list
>
> "Oslo" or "oslo"   is the content of the list and
> is a boolean expression which evaluates to True.
> (Each non-empty string is considered True by Python)
>
> So your 'if' line looks to Python like:
>
> if answera == [True]:
>
> But answera is a string so it will never equal a list
> with a single boolean value so you go to the else
> clause.
>
> A better way to do what you want is to convert the input
> to lowercase using the string lower() method and compare
> that to the string you want, like so:
>
> if answera.lower() == "oslo":
>
> If you need to check multiple possible answers you can use
> a list of strings and the 'in' operator like this:
>
> if answera.lower() in ['amsterdam', 'london', 'oslo']:
>
> HTH
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.flickr.com/photos/alangauldphotos
>
>
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Interacting with stderr

[Cameron Simpson]

Before we proceed, two requests:

Please do not top post. Post below, and trim the irrelevant content, so things 
read like a conversation.


Please consider reading the list on an article-by-article basis instead of as a 
digest. You will get a better discussion view and we will see your messages in 
a nice threaded chain. By replying to a digest you have broken the chaining 
(because the digest is not part of the chain). If you find it noisy, just add a 
filter to your mailer to send list messages to their own folder. For example, I 
have a "python" mail folder which receives several python related lists, 
keeping it out of my main inbox.


Returning to your subprocess questions...

On 27Aug2014 20:28, Crush  wrote:

As far as sending the contents of stderr to a tmp file...hmmm, i
will try that. My only concern is, many of these systems run live
demo feeds for many days...10+. Im afraid the file will fill up
very quickly and present problems.


Ok. Then a file may not be entirely suitable to your task.


Stderr=PIPE causes the terminal to hang. I can not wait for the process to 
terminate, i need to read stderr as it is being fed data.. Would fifos be of 
any use here?


First off, stderr=PIPE _is_ a FIFO; it constructs a pipe between the subprocess 
and your python program.


However, if you need to read the stream as it occurs then you should not use 
"call()", which inherently waits for the command to finish.


Instead, use the Popen constructor (also part of the subprocess module).

Crude and incomplete and untested example:

  from subprocess import Popen, PIPE

  P = Popen("avconv ... lots of arguments...", shell=True, stderr=PIPE)

  for line in P.stderr:
  ... examine the line from stderr ...

  # ok, we have read all of stderr now
  xit = P.wait()
  if xit != 0:
  ... command was unsuccessful, complain, maybe abort ...

Cheers,
Cameron Simpson 

ep0: 3c509 in test mode. Erase pencil mark!
   This means that someone has scribbled with pencil in the test area
   on the card. Erase the pencil mark and reboot. (This is not a joke).
- OpenBSD 2.3 ep(4) ethernet drive manual entry
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Interacting with stderr

[Danny Yoo]

> Crude and incomplete and untested example:
>
>   from subprocess import Popen, PIPE
>
>   P = Popen("avconv ... lots of arguments...", shell=True, stderr=PIPE)
>
>   for line in P.stderr:
>   ... examine the line from stderr ...
>
>   # ok, we have read all of stderr now
>   xit = P.wait()
>   if xit != 0:
>   ... command was unsuccessful, complain, maybe abort ...


The subprocess documentation has a few good examples of pipelines that
should apply to this scenario.  I'd recommend the original questioner
look at the documentation here closely, because he or she is using a
feature of 'subprocess' that is a bit iffy, namely, the use of
"shell=True".  Try to avoid "shell=True" unless you really have no
choice.

Rather than construct the pipeline through the shell, do it through
Python if you can.  See:

https://docs.python.org/2/library/subprocess.html#replacing-shell-pipeline

Also, prefer the use of communicate() rather than wait() in the
scenario above.  Otherwise, the code is susceptible to PIPEs getting
overflowed.  See:


https://docs.python.org/2/library/subprocess.html#subprocess.Popen.communicate


Best of wishes!
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Interacting with stderr

[Cameron Simpson]

On 27Aug2014 18:56, Danny Yoo  wrote:

Crude and incomplete and untested example:

  from subprocess import Popen, PIPE

  P = Popen("avconv ... lots of arguments...", shell=True, stderr=PIPE)

  for line in P.stderr:
  ... examine the line from stderr ...

  # ok, we have read all of stderr now
  xit = P.wait()
  if xit != 0:
  ... command was unsuccessful, complain, maybe abort ...


The subprocess documentation has a few good examples of pipelines that
should apply to this scenario.  I'd recommend the original questioner
look at the documentation here closely, because he or she is using a
feature of 'subprocess' that is a bit iffy, namely, the use of
"shell=True".  Try to avoid "shell=True" unless you really have no
choice.


Yes, but I was deliberately avoiding that aspect until the OP had their stderr 
issue worked out.



Rather than construct the pipeline through the shell, do it through
Python if you can.  See:
   https://docs.python.org/2/library/subprocess.html#replacing-shell-pipeline


But his use case is not using a shell pipeline, so irrelevant. It just makes 
things more complex for him.



Also, prefer the use of communicate() rather than wait() in the
scenario above.  Otherwise, the code is susceptible to PIPEs getting
overflowed.  See:
   
https://docs.python.org/2/library/subprocess.html#subprocess.Popen.communicate


Again, disagree. In this specific case, disagree strongly.

Firstly, the OP is not feeding stuff to stdin nor collecting stdout.

Secondly, the OP has made it clear that they're not in a position to wait for 
the command to finish; they need to read stderr as it occurs because the run 
time is very long and they need to act earlier than process completion.


Thirdly, I generally consider advice to use .communicate bad advise.

.communicate has many potential issues:

Primarily, it hides all the mechanics. He will learn nothing.

Next, if .call() is not doing what he needs (and it is not), then .communicate 
will not help either.


Also, .communicate() reads in all of stdout and stderr. This has issues. He's 
already suggested stdout has to go somewhere else, and that he needs to read 
stderr in a streaming fashion. Also, by reading in all of stdout and stderr, 
.communicate can consume an unbounded amount of memory: either of these two 
streams may be more than fits in the machine's memory, or more than one wishes 
to use. Particularly in audio/video processing (as he is doing) there is a lot 
of scope for output streams to be very large.


Further, the doco on .communicate does not say _how_ stdout and stderr are 
read. Is one read, and then the other? Are threads spawned and both read in 
parallel? Is there some awful select/epoll based event loop involved? None of 
these things is specified. If one is read and then then other, there is scope 
for deadlock or just arbitrary stallage.


Personally, I pretty much never have a use for .call or .communicate. Using 
.pipe keeps the requirements on me clear and leaves me maximum flexibility to 
handle I/O and process completion as I see fit.


As you can see from my example code, it is hardly difficult to use Popen 
directly in the OP's use case, and arguably better.


Cheers,
Cameron Simpson 

So YOU recant your IRRATIONAL Assertion right now or we will not LIKE
YOU any more.   - drieux
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Interacting with stderr

[Danny Yoo]

>> Rather than construct the pipeline through the shell, do it through
>> Python if you can.  See:
>>
>> https://docs.python.org/2/library/subprocess.html#replacing-shell-pipeline
>
> But his use case is not using a shell pipeline, so irrelevant. It just makes
> things more complex for him.


Did I misread the code?  Here's the snippet I thought was part of the question:

>>   p = subprocess.call("avconv -v verbose -re -analyzeduration 1000 
>> -ihttp://localhost:6498/ms2/1382097438004/0MediaPlayer+0+/octoshape+hVV+octolive.americaone.com+V+aone+V+live+V+ONECONNXT_DEMO1_HD_flv/aoneliveONECONNXTDEMO1HDflv
>>  -c:v rawvideo -c:a pcm_s16le -ar 48000 -f nut - | ./bmdplay -m 12 -f 
>> pipe:0",
> shell=True)

where there's a pipeline between the avconv process mbdplay process.



> Again, disagree. In this specific case, disagree strongly.
>
> Firstly, the OP is not feeding stuff to stdin nor collecting stdout.
>
> Secondly, the OP has made it clear that they're not in a position to wait
> for the command to finish; they need to read stderr as it occurs because the
> run time is very long and they need to act earlier than process completion.

The OP's situation is somewhat unusual.  My apologies for not reading
the thread thoroughly and closely.  I got distracted by the initial
digest message.


> Thirdly, I generally consider advice to use .communicate bad advise.
>
> .communicate has many potential issues:
>
> Primarily, it hides all the mechanics. He will learn nothing.


If it helps, let me qualify the statement that communicate() is
usually an appropriate solution.  For simple, common cases where the
interaction isn't that large or long-running, Popen.communicate() is
probably the right tool.  That is, I would usually recommend
Popen.communicate() _unless_ the details made it the wrong tool.  I
misread the problem statement, so yeah, my bad.

The OP's requirements are unusual: it's a long running process, it's
generating a dynamic, large amount of stderr output, it's disregarding
stdout, and there's a desire to process the stderr on the fly.  In
that situation, your solution sounds reasonable.
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] debug and execute python code in Mac

[Sebastian Silva]

I stumbled today upon this IDE for the mac http://plotdevice.io/

From the looks of it, it seems like a nice tool for teaching/learning 
Python. Too bad it's mac only. If you try it, do share your experience. 
I don't use non-free operating systems, so I can't try it myself.


Regards,

Sebastian



El mié, 27 de ago 2014 a las 6:14 AM, Najam Qasim 
 escribió:

What is preferable method to debug and execute python code in Mac?
I do not like the cmd/terminal execution. Thanks !
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Interacting with stderr

[Cameron Simpson]

On 27Aug2014 22:42, Danny Yoo  wrote:

Rather than construct the pipeline through the shell, do it through
Python if you can.  See:

https://docs.python.org/2/library/subprocess.html#replacing-shell-pipeline


But his use case is not using a shell pipeline, so irrelevant. It just makes
things more complex for him.


Did I misread the code?  Here's the snippet I thought was part of the question:


  p = subprocess.call("avconv -v verbose -re -analyzeduration 1000 
-ihttp://localhost:6498/ms2/1382097438004/0MediaPlayer+0+/octoshape+hVV+octolive.americaone.com+V+aone+V+live+V+ONECONNXT_DEMO1_HD_flv/aoneliveONECONNXTDEMO1HDflv
 -c:v rawvideo -c:a pcm_s16le -ar 48000 -f nut - | ./bmdplay -m 12 -f pipe:0",

shell=True)


where there's a pipeline between the avconv process mbdplay process.


You didn't misread it. I did; I missed the pipe symbol.

Nonetheless, for the sake of getting his stuff working it should perhaps be 
chased later. In any case, he could easily be moving to putting that pipeline 
in a small shell script and just invoking the script from python. I've got any 
number of one or two line shell scripts like that.


I agree that using shell=True is usually worth trying to avoid.


Again, disagree. In this specific case, disagree strongly.

Firstly, the OP is not feeding stuff to stdin nor collecting stdout.

Secondly, the OP has made it clear that they're not in a position to wait
for the command to finish; they need to read stderr as it occurs because the
run time is very long and they need to act earlier than process completion.


The OP's situation is somewhat unusual.  My apologies for not reading
the thread thoroughly and closely.  I got distracted by the initial
digest message.


I can imagine. I'm not a big fan of digests.


Thirdly, I generally consider advice to use .communicate bad advise.

.communicate has many potential issues:

Primarily, it hides all the mechanics. He will learn nothing.


If it helps, let me qualify the statement that communicate() is
usually an appropriate solution.  For simple, common cases where the
interaction isn't that large or long-running, Popen.communicate() is
probably the right tool.  That is, I would usually recommend
Popen.communicate() _unless_ the details made it the wrong tool.  I
misread the problem statement, so yeah, my bad.

The OP's requirements are unusual: it's a long running process, it's
generating a dynamic, large amount of stderr output, it's disregarding
stdout, and there's a desire to process the stderr on the fly.  In
that situation, your solution sounds reasonable.


Ta.

The other thing about communicate and (less so) call is that they do so much.  
When a particular part isn't working, figuring out what to fix is harder.


On a tutor list, what's our stance on exploring the operation at a lower level 
so the OP gets a better feel for what's going on? I'm aware we don't need to 
agree on that stance:-)


Cheers,
Cameron Simpson 

It is very easy to be blinded to the essential uselessness of them by
the sense of achievement you get from getting them to work at all. In
other words - their fundamental design flaws are completely hidden by
their superficial design flaws. - Douglas Adams on VCRs etc
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor